Re: [Python-Dev] urlparse brokenness
On Tue, 22 Nov 2005, Paul Jimenez wrote: > It is my assertion that urlparse is currently broken. Specifically, I > think that urlparse breaks an abstraction boundary with ill effect. [...] I have some comments, but I can't see a patch on SF. Did you post it? John ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python 3
Hi, don't know if this is known here, but it seems we have quite a long way to go: http://kuerzer.de/python3 Reinhold ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ast status, memory leaks, etc
On Tue, 22 Nov 2005, Fredrik Lundh wrote: [...] > http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Misc/README.valgrind?view=markup The up-to-date version of that (from SVN instead of old CVS repository) is here: http://svn.python.org/view/python/trunk/Misc/README.valgrind?view=markup John ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] CVS repository mostly closed now
I tried removing the CVS repository from SF; it turns out that this operation is not supported. Instead, it is only possible to remove it from the project page; pserver and ssh access remain indefinitely, as does viewcvs. The recommended procedure is to place a file into the repository indicating the repository has moved; this is what I just did. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] For Python 3k, drop default/implicit hash, and comparison
Three weeks ago, I read this and thought, "well, you have two options for a default comparison, one based on identity and one on value, both are useful sometimes and Guido prefers identity, and it's OK." But today I understood that I still think otherwise. In two sentences: sometimes you wish to compare objects according to "identity", and sometimes you wish to compare objects according to "values". Identity-based comparison is done by the "is" operator; Value-based comparison should be done by the == operator. Let's take the car example, and expand it a bit. Let's say wheels have attributes - say, diameter and manufacturer. Let's say those can't change (which is reasonable), to make wheels hashable. There are two ways to compare wheels: by value and by identity. Two wheels may have the same value, that is, they have the same diameter and were created by the same manufacturer. Two wheels may have the same identity, that is, they are actually the same wheel. We may want to compare wheels based on value, for example to make sure that all the car's wheels fit together nicely: assert car.wheel1 == car.wheel2 == car.wheel3 == car.wheel4. We may want to compare wheels based on identity, for example to make sure that we actually bought four wheels in order to assemble the car: assert car.wheel1 is not car.wheel2 and car.wheel3 is not car.wheel1 and car.wheel3 is not car.wheel2... We may want to associate values with wheels based on their values. For example, it's reasonable to suppose that the price of every wheel of the same model is the same. In that case, we'll write: price[wheel] = 25. We may want to associate values with wheels based on their identities. For example, we may want to note that a specific wheel is broken. For this, I'll first define a general class (I defined it before in one of the discussions, that's because I believe it's useful): class Ref(object): def __init__(self, obj): self._obj = obj def __call__(self): return self._obj def __eq__(self, other): return isinstance(other, ref) and self._obj is other._obj def __hash__(self): return id(self._obj) ^ 0xBEEF Now again, how will we say that a specific wheel is broken? Like this: broken[Ref(wheel)] = True Note that the Ref class also allows us to group wheels of the same kind in a set, regardless of their __hash__ method. I think that most objects, especially most user-defined objects, have a *value*. I don't have an exact definition, but a hint is that two objects that were created in the same way have the same value. Sometimes we wish to compare objects based on their identity - in those cases we use the "is" operator. Sometimes we wish to compare objects based on their value - and that's what the == operator is for. Sometimes we wish to use the value of objects as a dictionary key or as a set member, and that's easy. Sometimes we wish to use the identity of objects as a dictionary key or as a set member - and I claim that we should do that by using the Ref class, whose *value* is the object's *identity*, or by using a dict/set subclass, and not by misusing the __hash__ and __eq__ methods. I think that whenever value-based comparison is meaningful, the __eq__ and __hash__ should be value-based. Treating objects by identity should be done explicitly, by the one who uses the objects, by using the "is" operator or the Ref class. It should not be the job of the object to decide which method (value or identity) is more useful - it should allow the user to use both methods, by defining __eq__ and __hash__ based on value. Please give me examples which prove me wrong. I currently think that the only objects for whom value-based comparison is not meaningful, are objects which represent entities which are "outside" of the process, or in other words, entities which are not "computational". This includes files, sockets, possibly user-interface objects, loggers, etc. I think that objects that represent purely "data", have a "value" that they can be compared according to. Even wheels that don't have any attributes are simply equal to other wheels, and not equal to other objects. Since user-defined classes can interact with the "environment" only through other objects or functions, it is reasonable to suggest that they should get a value-based equality operator. Many times the value is defined by the __dict__ and __slots__ members, so it seems to me a reasonable default. I would greatly appreciate repliers that find a tiny bit of reason in what I said (even if they don't agree), and not deny it all as a complete load of rubbish. Thanks, Noam ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] For Python 3k, drop default/implicit hash, and comparison
Noam Raphael wrote:
> I would greatly appreciate repliers that find a tiny bit of reason in
> what I said (even if they don't agree), and not deny it all as a
> complete load of rubbish.
I don't understand what your message is. With this posting, did you
suggest that somebody does something specific? If so, who is that one,
and what should he do?
Anyway, a lot of your posting is what I thought was common knowledge;
and with some of it, I disagree.
> In two sentences: sometimes you wish to compare objects according to
> "identity", and sometimes you wish to compare objects according to
> "values". Identity-based comparison is done by the "is" operator;
> Value-based comparison should be done by the == operator.
Certainly.
> We may want to compare wheels based on value, for example to make sure
> that all the car's wheels fit together nicely: assert car.wheel1 ==
> car.wheel2 == car.wheel3 == car.wheel4.
I would never write it that way. This would suggest that the wheels
have to be "the same". However, this is certainly not true for wheels:
they have to have to be of the same make. Now, you write that wheels
only carry manufacturer and diameter. However, I would expect that
wheels grow additional attributes over time, like whether they are
left or right, and what their wear level is. So to write your property,
I would write
car.wheel1.manufacturer_and_make() ==
car.wheel2.manufacturer_and_make() ==
car.wheel3.manufacturer_and_make() ==
car.wheel4.manufacturer_and_make()
> We may want to associate values with wheels based on their values. For
> example, it's reasonable to suppose that the price of every wheel of
> the same model is the same. In that case, we'll write: price[wheel] =
> 25.
Again, I would not write it this way. I would find
wheel.price()
most natural. If I have the notion of a price list, then I would
try to understand what the price list is keyed-by, e.g. model number:
price[wheel.model] = 25
> Now again, how will we say that a specific wheel is broken? Like this:
>
> broken[Ref(wheel)] = True
If I want things to be keyed by identity, I would write
broken = IdentityDictionary()
...
broken[wheel] = True
although I would prefer to write
wheel.broken = True
> I think that most objects, especially most user-defined objects, have
> a *value*. I don't have an exact definition, but a hint is that two
> objects that were created in the same way have the same value.
Here I disagree. Consider the wheel example. I would expect that
a wheel has a "wear level" or some such, and that this changes over
time, and that it belongs to the "value" of the wheel ("value"
being synonym to "state"). As this changes over time, it is certainly
not that the object is created with that value.
Think of lists: what is their value? Are they created with it?
> Sometimes we wish to use the
> identity of objects as a dictionary key or as a set member - and I
> claim that we should do that by using the Ref class, whose *value* is
> the object's *identity*, or by using a dict/set subclass, and not by
> misusing the __hash__ and __eq__ methods.
I think we should a specific type of dictionary then.
> I think that whenever value-based comparison is meaningful, the __eq__
> and __hash__ should be value-based. Treating objects by identity
> should be done explicitly, by the one who uses the objects, by using
> the "is" operator or the Ref class. It should not be the job of the
> object to decide which method (value or identity) is more useful - it
> should allow the user to use both methods, by defining __eq__ and
> __hash__ based on value.
If objects are compared for value equality, the object should decide
which part of its state goes into that comparison. It may be that
two objects compare equal even though their state is memberwise
different:
Rational(1,2) == Rational(5,10)
> Please give me examples which prove me wrong. I currently think that
> the only objects for whom value-based comparison is not meaningful,
> are objects which represent entities which are "outside" of the
> process, or in other words, entities which are not "computational".
You mean, things of the real world, right? Like people, bank accounts,
and wheels.
Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] For Python 3k, drop default/implicit hash, and comparison
Noam Raphael wrote: > Three weeks ago, I read this and thought, "well, you have two options > for a default comparison, one based on identity and one on value, both > are useful sometimes and Guido prefers identity, and it's OK." But > today I understood that I still think otherwise. > well, this still belongs to comp.lang.python. > In two sentences: sometimes you wish to compare objects according to > "identity", and sometimes you wish to compare objects according to > "values". Identity-based comparison is done by the "is" operator; > Value-based comparison should be done by the == operator. > > Let's take the car example, and expand it a bit. Let's say wheels have > attributes - say, diameter and manufacturer. Let's say those can't > change (which is reasonable), to make wheels hashable. There are two > ways to compare wheels: by value and by identity. Two wheels may have > the same value, that is, they have the same diameter and were created > by the same manufacturer. Two wheels may have the same identity, that > is, they are actually the same wheel. > > We may want to compare wheels based on value, for example to make sure > that all the car's wheels fit together nicely: assert car.wheel1 == > car.wheel2 == car.wheel3 == car.wheel4. We may want to compare wheels > based on identity, for example to make sure that we actually bought > four wheels in order to assemble the car: assert car.wheel1 is not > car.wheel2 and car.wheel3 is not car.wheel1 and car.wheel3 is not > car.wheel2... > > We may want to associate values with wheels based on their values. For > example, it's reasonable to suppose that the price of every wheel of > the same model is the same. In that case, we'll write: price[wheel] = > 25. We may want to associate values with wheels based on their > identities. For example, we may want to note that a specific wheel is > broken. For this, I'll first define a general class (I defined it > before in one of the discussions, that's because I believe it's > useful): > > class Ref(object): > def __init__(self, obj): > self._obj = obj > def __call__(self): > return self._obj > def __eq__(self, other): > return isinstance(other, ref) and self._obj is other._obj > def __hash__(self): > return id(self._obj) ^ 0xBEEF > > Now again, how will we say that a specific wheel is broken? Like this: > > broken[Ref(wheel)] = True > > Note that the Ref class also allows us to group wheels of the same > kind in a set, regardless of their __hash__ method. > > I think that most objects, especially most user-defined objects, have > a *value*. I don't have an exact definition, but a hint is that two > objects that were created in the same way have the same value. > Sometimes we wish to compare objects based on their identity - in > those cases we use the "is" operator. Sometimes we wish to compare > objects based on their value - and that's what the == operator is for. > Sometimes we wish to use the value of objects as a dictionary key or > as a set member, and that's easy. Sometimes we wish to use the > identity of objects as a dictionary key or as a set member - and I > claim that we should do that by using the Ref class, whose *value* is > the object's *identity*, or by using a dict/set subclass, and not by > misusing the __hash__ and __eq__ methods. > > I think that whenever value-based comparison is meaningful, the __eq__ > and __hash__ should be value-based. Treating objects by identity > should be done explicitly, by the one who uses the objects, by using > the "is" operator or the Ref class. It should not be the job of the > object to decide which method (value or identity) is more useful - it > should allow the user to use both methods, by defining __eq__ and > __hash__ based on value. > > Please give me examples which prove me wrong. I currently think that > the only objects for whom value-based comparison is not meaningful, > are objects which represent entities which are "outside" of the > process, or in other words, entities which are not "computational". > This includes files, sockets, possibly user-interface objects, > loggers, etc. I think that objects that represent purely "data", have > a "value" that they can be compared according to. Even wheels that > don't have any attributes are simply equal to other wheels, and not > equal to other objects. Since user-defined classes can interact with > the "environment" only through other objects or functions, it is > reasonable to suggest that they should get a value-based equality > operator. Many times the value is defined by the __dict__ and > __slots__ members, so it seems to me a reasonable default. > > I would greatly appreciate repliers that find a tiny bit of reason in > what I said (even if they don't agree), and not deny it all as a > complete load of rubbish. > not if you think python-dev is a forum for such discussions on OO thinking vs other paradigms. > Thanks, > Noam >
Re: [Python-Dev] For Python 3k, drop default/implicit hash, and comparison
On 11/26/05, Noam Raphael <[EMAIL PROTECTED]> wrote: > [...stuff about using Ref() for identity dictionaries...] I too have thought along these lines, but I went one step further. There is an existing function that could be modified to produce Ref objects: id(). Making id() into a type allows it force unsignedness, incorporate a method for easy printing, maintain a reference to the target so that "id(x.foo) == id(x.bar)" doesn't risk reusing the same id.. and the id object would be the same size as an int object is today. I don't see any disadvantage, except perhaps code that assumes id() returns an int. That could be fixed by having id() subclass int for a few versions while we transition, although that may require we store the pointer seperate from the integer value. id() would be usable in dicts as a value, behaving as Noam suggests that Ref behave. Kills two birds with one stone. -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] For Python 3k, drop default/implicit hash, and comparison
Adam Olsen wrote: > On 11/26/05, Noam Raphael <[EMAIL PROTECTED]> wrote: >> [...stuff about using Ref() for identity dictionaries...] > > I too have thought along these lines, but I went one step further. > There is an existing function that could be modified to produce Ref > objects: id(). > > Making id() into a type allows it force unsignedness, incorporate a > method for easy printing, maintain a reference to the target so that > "id(x.foo) == id(x.bar)" doesn't risk reusing the same id.. and the id > object would be the same size as an int object is today. I don't see > any disadvantage, except perhaps code that assumes id() returns an > int. That could be fixed by having id() subclass int for a few > versions while we transition, although that may require we store the > pointer seperate from the integer value. > > id() would be usable in dicts as a value, behaving as Noam suggests > that Ref behave. Kills two birds with one stone. I've occasionally considered the concept of a "Ref" class - usually when I want to be able to access a value in multiple places, and have them all track rebinding operations. You can't do it perfectly (you need to rebind the attribute directly because objects aren't notified of name rebinding) but you can get pretty close (because objects *are* notified of augmented assignment). However, re-using id() for this doesn't seem like the right approach. Cheers, Nick. P.S. Yes, those musings where prompted at least in part by Paul Graham's ramblings ;) The sample version below obviously misses out all the slots it would actually need to delegate to get correct behaviour. Py> class Ref(object): ... def __init__(self, val): ... self._val = val ... def __str__(self): ... return str(self._val) ... def __repr__(self): ... return "%s(%s)" % (type(self).__name__, repr(self._val)) ... def __iadd__(self, other): ... self._val += other ... return self ... Py> n = Ref(1) Py> i = n Py> n += 2 Py> n Ref(3) Py> i Ref(3) Py> def make_accum(n): ... def accum(i, n=Ref(n)): ... n += i ... return n._val ... return accum ... Py> acc = make_accum(3) Py> acc(1) 4 Py> acc(5) 9 -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Weekly Python Patch/Bug Summary
Patch / Bug Summary ___ Patches : 372 open ( -7) / 2980 closed (+12) / 3352 total ( +5) Bugs: 908 open ( -2) / 5395 closed (+11) / 6303 total ( +9) RFE : 200 open ( +0) / 191 closed ( +0) / 391 total ( +0) New / Reopened Patches __ CodeContext - Improved text indentation (2005-11-21) http://python.org/sf/1362975 opened by Tal Einat test_cmd_line expecting English error messages (2005-11-23) CLOSED http://python.org/sf/1364545 opened by A.B., Khalid Add reference for en/decode error types (2005-11-23) CLOSED http://python.org/sf/1364946 opened by Wummel [PATCH] mmap fails on AMD64 (2005-11-24) http://python.org/sf/1365916 opened by Joe Wreschnig Patches Closed __ zlib.crc32 doesn't handle 0x seed (2005-11-07) http://python.org/sf/1350573 closed by akuchling xml.dom.minidom.Node.replaceChild(obj, x, x) removes child x (2005-01-01) http://python.org/sf/1094164 closed by akuchling Patch for (Doc) #1255218 (2005-10-17) http://python.org/sf/1328526 closed by birkenfeld Patch for (Doc) #1261659 (2005-10-17) http://python.org/sf/1328566 closed by birkenfeld Patch for (Doc) #1357604 (2005-11-18) http://python.org/sf/1359879 closed by birkenfeld CallTip Modifications (2005-05-11) http://python.org/sf/1200038 closed by kbk ensure lock is released if exception is raised (2005-10-05) http://python.org/sf/1314396 closed by bcannon test_cmd_line expecting English error messages (2005-11-23) http://python.org/sf/1364545 closed by doerwalter ToolTip.py: fix main() function (2005-10-06) http://python.org/sf/1315161 closed by kbk Add reference for en/decode error types (2005-11-23) http://python.org/sf/1364946 closed by doerwalter solaris 10 should not define _XOPEN_SOURCE_EXTENDED (2005-06-27) http://python.org/sf/1227966 closed by loewis Solaris 10 fails to compile complexobject.c [FIX incl.] (2005-02-05) http://python.org/sf/1116722 closed by loewis New / Reopened Bugs ___ textwrap.dedent() expands tabs (2005-11-19) http://python.org/sf/1361643 opened by Steven Bethard Text.edit_modified() doesn't work (2005-11-20) http://python.org/sf/1362475 opened by Ron Provost Problem with tapedevices and the tarfile module (2005-11-21) http://python.org/sf/1362587 opened by Henrik spawnlp is missing (2005-11-21) http://python.org/sf/1363104 opened by Greg MacDonald A possible thinko in the description of os/chmod (2005-11-22) CLOSED http://python.org/sf/1363712 opened by Evgeny Roubinchtein urllib cannot open data: urls (2005-11-25) CLOSED http://python.org/sf/1365984 opened by Warren Butler Bug bz2.BZ2File(...).seek(0,2) (2005-11-25) http://python.org/sf/1366000 opened by STINNER Victor inoorrect documentation for optparse (2005-11-25) http://python.org/sf/1366250 opened by Michael Dunn SRE engine do not release the GIL (2005-11-25) http://python.org/sf/1366311 opened by Eric Noyau inspect.getdoc fails on objs that use property for __doc__ (2005-11-26) http://python.org/sf/1367183 opened by Drew Perttula Bugs Closed ___ A possible thinko in the description of os.chmod (2005-11-22) http://python.org/sf/1363712 closed by birkenfeld docs need to discuss // and __future__.division (2001-08-08) http://python.org/sf/449093 closed by akuchling Prefer configured browser over Mozilla and friends (2005-11-17) http://python.org/sf/1359150 closed by birkenfeld Incorrect documentation of raw unidaq string literals (2005-11-17) http://python.org/sf/1359053 closed by birkenfeld "appropriately decorated" is undefined in MultiFile.push doc (2005-08-09) http://python.org/sf/1255218 closed by birkenfeld Tutorial doesn't cover * and ** function calls (2005-08-17) http://python.org/sf/1261659 closed by birkenfeld os.path.makedirs DOES handle UNC paths (2005-11-15) http://python.org/sf/1357604 closed by birkenfeld Exec Inside A Function (2005-04-06) http://python.org/sf/1177811 closed by birkenfeld Py_BuildValue k format units don't work with big values (2005-09-04) http://python.org/sf/1281408 closed by birkenfeld urllib cannot open data: urls (2005-11-25) http://python.org/sf/1365984 closed by birkenfeld imaplib: parsing INTERNALDATE (2003-03-06) http://python.org/sf/698706 closed by birkenfeld ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
