Re: [Python-Dev] bool conversion wart?
Can anyone who is in favor of changing this please come up with a spec for the new bool() signature? What would you do for the most common use case of bool(), which is converting an arbitrary value to its Boolean equivalent without using an if test or the "not not x" hack? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] bool conversion wart?
Guido van Rossum schrieb:
> Can anyone who is in favor of changing this please come up with a spec
> for the new bool() signature? What would you do for the most common
> use case of bool(), which is converting an arbitrary value to its
> Boolean equivalent without using an if test or the "not not x" hack?
I think this subthread doesn't propose to change bool(), but only to
stop inheriting bool from int, while giving bools an __index__ method
that returns 0 or 1 to still allow them being used as list indices.
The obvious consequence would be that arithmetic wouldn't work any
longer with bools involved.
Also, mapping access or set membership wouldn't work like now,
>>> d = {1: 2}
>>> d[True]
2
>>> True in set([1])
True
but that would only be logical.
Georg
___
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
Re: [Python-Dev] bool conversion wart?
Neal> Except, all the numeric types do, including int, float, and Neal> complex. But not bool. The fact that bool is a subclass of int is more historic than necessary. If not for Python's long usage of 0 and 1 to be the canonical False and True, I suspect that bool might have been implemented as a new standalone type. Skip ___ 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
Re: [Python-Dev] [Distutils] unicode bug in distutils
At 02:47 PM 2/24/2007 -0600, Tarek Ziadé wrote:
>I have created a setup.py file for distirbution and I bumped into
>a small bug when i tried to set my name in the contact field (Tarek Ziadé)
>
>Using string (utf8 file):
>
>setup(
> maintainer="Tarek Ziadé"
>)
>
>leads to:
>
> File ".../lib/python2.5/distutils/command/register.py", line 162, in
> send_metadata
> auth)
> File ".../lib/python2.5/distutils/command/register.py", line 257, in
> post_to_server
> value = unicode(value).encode("utf-8")
>UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 10:
>ordinal not in range(128)
>
>
>Using unicode:
>
>setup(
> maintainer=u"Tarek Ziadé"
>)
>
>leads to:
>
> File ".../lib/python2.5/distutils/dist.py", line 1094, in write_pkg_file
> file.write('Author: %s\n' % self.get_contact() )
>UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in
>position 18: ordinal not in range(128)
>
>I would propose a patch for this problem but i don't know what would be
>the best input (i guess unicode
> for names)
At 05:45 PM 2/24/2007 -0500, Tres Seaver wrote:
>Don't you still need to tell Python about the encoding of your string
>literals [1] [2] ? E.g.::
That's not the problem, it's that the code that writes the PKG-INFO file
doesn't handle Unicode. See
distutils.dist.DistributionMetadata.write_pkg_info(). It needs to use a
file with encoding support, if it's doing unicode
However, there's currently no standard, as far as I know, for what encoding
the PKG-INFO file should use. Meanwhile, the 'register' command accepts
Unicode, but is broken in handling it.
Essentially, the problem is that Python 2.5 broke this by adding a unicode
*requirement* to the "register" command. Previously, register simply sent
whatever you gave it, and the PKG-INFO writing code still
does. Unfortunately, this means that there is no longer any one value that
you can use for your name that will be accepted by both "register" and
anything that writes a PKG-INFO file.
Both register and write_pkg_info() are arguably broken here, and should be
able to work with either strings or unicode, and degrade gracefully in the
event of non-ASCII characters in a string. (Because even though "register"
is only run by the package's author, users may run other commands that
require a PKG-INFO, so a package prepared using Python <2.5 must still be
usable with Python 2.5 distutils, and Python <2.5 allows 8-bit maintainer
names.)
Unfortunately, this isn't fixable until there's a new 2.5.x release. For
previous Python versions, both register and write_pkg_info() accepted 8-bit
strings and passed them on as-is, so the only workaround for this issue at
the moment is to revert to Python 2.4 or less.
___
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
Re: [Python-Dev] bool conversion wart?
On 2/24/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Guido van Rossum schrieb:
> > Can anyone who is in favor of changing this please come up with a spec
> > for the new bool() signature? What would you do for the most common
> > use case of bool(), which is converting an arbitrary value to its
> > Boolean equivalent without using an if test or the "not not x" hack?
>
> I think this subthread doesn't propose to change bool(), but only to
> stop inheriting bool from int, while giving bools an __index__ method
> that returns 0 or 1 to still allow them being used as list indices.
>
> The obvious consequence would be that arithmetic wouldn't work any
> longer with bools involved.
>
> Also, mapping access or set membership wouldn't work like now,
>
> >>> d = {1: 2}
> >>> d[True]
> 2
> >>> True in set([1])
> True
>
> but that would only be logical.
How would this change be helpful? I'm utterly mystified by these
suggestions that bool would be more useful if it didn't behave like an
int in arithmetic.
On 2/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Neal> Except, all the numeric types do, including int, float, and
> Neal> complex. But not bool.
>
> The fact that bool is a subclass of int is more historic than necessary. If
> not for Python's long usage of 0 and 1 to be the canonical False and True, I
> suspect that bool might have been implemented as a new standalone type.
Not necessarily. I really like the idea that bool is embedded in int,
just like int is embedded in float (real), and real is embedded in
complex.
The construction signature is a different issue -- some people seem to
forget that constructor signatures don't need to match their base
class; it's not required by Liskov substitutability.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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
