Being hashable is a different from being usable as dictionary key.
Dictionaries perform the lookup based on the hash value, but will
then have to check for hash collisions based on an equal comparison.
If an object does not define an equal comparison, then it is not
usable as dictionary
It's probably a good idea to implement __hash__ for objects that
implement comparisons, but it won't always work and it is certainly
not needed, unless you intend to use them as dictionary keys.
So you're suggesting that we document something like.
Classes that represent mutable values
Note that only instances have the default hash value id(obj). This
is not true in general. Most types don't implement the tp_hash
slot and thus are not hashable. Indeed, mutable types should not
implement that slot unless they know what they're doing :-)
By instances you mean instances of
This may have been true for old style classes, but as new style classes
inherit a default __hash__ from object - mutable objects *will* be usable as
dictionary keys (hashed on identity) *unless* they implement a __hash__
method that raises a type error.
I always thought this was a bug in
Hi Michele,
Do you have a URL for this blog?
Matt
___
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
Had a brief offline discussion with Michele - forwarding.
-- Forwarded message --
From: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: Mon, Aug 25, 2008 at 12:13 AM
On Aug 24, 3:43 pm, Matt Giuca [EMAIL PROTECTED] wrote:
Hi Michele,
Do you have a URL for this blog?
Sorry, here
ImportError: cannot import name annotate from /usr/snip/image.pyc
That could be handy.
Not sure it's necessary, however, and exposes some system information in the
error message. I can imagine a web app which prints out exception messages,
and this would mean the server file structure is
I think this is not the place to be discussing the patch (the tracker is),
but while I think of it, I'll just say:
You need to DECREF the fn variable (both
PyObject_GetAttrStringhttp://www.python.org/doc/api/object.htmland
PyString_FromString
http://www.python.org/doc/api/stringObjects.htmlreturn
Hi,
I thought I'd bring this up on both the tracker and mailing list, since it's
important. It seems the test suite breaks as of r65661. I've posted details
to the bug tracker and a patch which fixes the module in question (uuid.py).
http://bugs.python.org/issue3552
Cheers
Matt
Is the only issue with this feature that you might accidentally miss a comma
after a string in a sequence of strings? That seems like a significantly
obscure scenario compared to the usefulness of the current syntax, for
exactly the purpose Barry points out (which most people use all the time).
I
Hi,
I'm confused as to how you represent a bytes object in hexadecimal in Python
3. Of course in Python 2, you use str.encode('hex') to go to hex, and
hexstr.decode('hex') to go from hex.
In Python 3, they removed hex as a codec (which was a good move, I think).
Now there's the static method
Well, whether there's community support for this or not, I thought I'd have
a go at implementing this, so I did. I've submitted a feature request +
working patch to the bug tracker:
http://bugs.python.org/issue3532
Matt
PS. I mean
''.join(%02x % b for b in mybytes)
Wow .. a lot of replies today!
On Thu, Aug 7, 2008 at 2:09 AM, Martin v. Löwis [EMAIL PROTECTED]wrote:
It hasn't been given priority: There are currently 606 patches in the
tracker, many fixing bugs of some sort. It's not clear (to me, at least)
why this should be given priority over all the
This whole discussion circles too much, I think. Maybe it should be pepped?
The issue isn't circular. It's been patched and tested, then a whole lot of
people agreed including Guido. Then you and Bill wanted the bytes
functionality back. So I wrote that in there too, and Bill at least said
that
There are a lot of quotes around. Including After the most recent flurry
of
discussion I've lost track of what's the right thing to do.
But I don't talk for other people.
OK .. let me compose myself a little. Sorry I went ahead and assumed this
was closed.
It's just frustrating to me that
if there is anything I can do to speed this along.
Also I'd be interested in hearing anyone's opinion on the quote_from_bytes
issue as raised in the previous email. I posted a suggested implementation
of a more restrictive quote_from_bytes in that email, but I haven't included
it in the patch yet.
Matt
are
new features which can wait.
Matt Giuca
___
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
Alright, I've uploaded the new patch which adds the two requested
bytes-oriented functions, as well as accompanying docs and tests.
http://bugs.python.org/issue3300
http://bugs.python.org/file11009/parse.py.patch6
I'd rather have two pairs of functions, so that those who want to give
the readers
Bill wrote:
I'm not sure that's sufficient review, though I agree it's necessary.
The major consumers of quote/unquote are not in the Python standard
library.
I figured that Python 3.0 is designed to fix things, with the breaking
third-party code being an acceptable side-effect of that. So
so you can use quote_from_bytes on strings?
Yes, currently.
I assumed Guido meant it was okay to have quote accept string/byte input and
have a function that was redundant but limited in what it accepted (i.e.
quote_from_bytes accepts only bytes)
I suppose your implementation doesn't
is not inverse of quote; quote behaviour
internally-inconsistent; garbage when unquoting UTF-8-encoded URIs.
2. Default to UTF-8.
In favour: Matt Giuca, Brett Cannon, Jeroen Ruigrok van der Werven
Pros: Fully working and tested solution is implemented; recommended by
RFC 3986 for all future schemes
Arg! Damnit, why do my replies get split off from the main thread?
Sorry about any confusion this may be causing.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Con: URI encoding does not encode characters.
OK, for all the people who say URI encoding does not encode characters: yes
it does. This is not an encoding for binary data, it's an encoding for
character data, but it's unspecified how the strings map to octets before
being percent-encoded. From
debugging.
This means all my classes behave like containers currently do - their str
will call repr on the items. This proposal will make all of my classes
behave inconsistently with the standard container types.
- Matt Giuca
___
Python-Dev mailing list
Python
On Mon, Jul 14, 2008 at 4:54 AM, André Malo [EMAIL PROTECTED] wrote:
Ahem. The HTTP standard does ;-)
Really? Can you include a quotation please? The HTTP standard talks a lot
about ISO-8859-1 (Latin-1) in terms of actually raw encoded bytes, but not
in terms of URI percent-encoding (a
are positive, if anyone would like to review this
patch and check it in.
I have extensively tested it, and am now pretty confident that it won't
cause any grief if it's checked in.
Thanks very much,
Matt Giuca
___
Python-Dev mailing list
Python-Dev@python.org
http
they
were before; don't need to explicitly support them.
Cheers,
Matt Giuca
___
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
This POV is way too browser-centric...
This is but one example. Note that I found web forms to be the least
clear-cut example of choosing an encoding. Most of the time applications
seem to be using UTF-8, and all the standards I have read are moving towards
specifying UTF-8 (from being
28 matches
Mail list logo
