Robin Munn wrote:
>>Revision 4077 is fine now. However, the same problem exists in revision
>>4284, which has a 0x01 character before the word "add". Same solution:
I now have fixed that as well.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@py
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robin Munn wrote:
> Revision 4077 is fine now. However, the same problem exists in revision
> 4284, which has a 0x01 character before the word "add". Same solution:
>
> echo "New commit message goes here" > new-message.txt
> svnadmin setlog --bypass-h
Noam Raphael <[EMAIL PROTECTED]> wrote:
> On 11/2/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > I believe the current behavior of __eq__ is more desireable than
> > comparing contents, as this may result in undesireable behavior
> > (recursive compares on large nested objects are now slow, whi
Noam Raphael wrote:
> 3. If someone does want to associate values with objects, he can
> explicitly use id:
> dct[id(x)] = 3.
This is fragile. Once all references to x are dropped,
it is possible for another object to be created having
the same id that x used to have. The dict now
unintentionally
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin v. Löwis wrote:
> Robin Munn wrote:
>
>> echo "New commit message goes here" > new-message.txt
>> svnadmin setlog --bypass-hooks -r 4077 /path/to/repos new-message.txt
>
>
> Thanks for pointing that out, and for giving those instructions.
> I
Robin Munn wrote:
> echo "New commit message goes here" > new-message.txt
> svnadmin setlog --bypass-hooks -r 4077 /path/to/repos new-message.txt
Thanks for pointing that out, and for giving those instructions.
I now corrected the log message.
Regards,
Martin
_
On 11/2/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > Should the default equality operator compare valuesinstead of
> identities?
>
> No. Look back into last year's python-dev postings where we agreed that
> identity would always imply equality. There were a number of practical
> reasons.
I've looked for classes in my /usr/lib/python2.4 directory. I won't go
over all the 7346 classes that were found there, but let's see:
"identity objects" that will continue to work because they contain
other "identity objects"
SocketServer, and everything which inherits fr
I think it should.
(I copy here messages from the thread about the default hash method.)
On 11/2/05, Michael Chermside <[EMAIL PROTECTED]> wrote:
> > Why not make the default __eq__ really compare the objects, that is,
> > their dicts and their slot-members?
>
> Short answer: not the desired beha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm trying to mirror the brand-new Python SVN repository with SVK, to
better be able to track both the trunk and the various branches. Since
I'm not a Python developer and don't have svn+ssh access, I'm doing so
over http. The process fails when trying
On 11/2/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
...
>
> A quick search in the list archives via google search
>"site:mail.python.org object __hash__"
> Says that Guido wanted to remove the default __hash__ method for object
> in Python 2.4, but that never actually happened.
>
> http://www
Hi,
I'm a norwegian applied mathematics student with an interest in
compilers, and I've been a long-time python user and a python-dev lurker
for some time. I'm very happy that you've integrated the AST branch into
mainline, but I noticed that the AST compiler does not perform much
optimization
Thank you for your encouraging words!
I am currently working on a PEP. I am sure that writing it is a good
idea, and that it would help with explaining this idea both to others
and to myself.
What I already wrote makes me think that it can be accomplished with
no really large changes to the langu
Noam Raphael <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> While writing my PEP about unifying mutable and immutable, I came upon this:
>
> Is there a reason why the default __hash__ method returns the id of the
> objects?
A quick search in the list archives via google search
"site:mail.pytho
Noam Raphael writes:
> Is there a reason why the default __hash__ method returns the id of the
objects?
>
> It is consistent with the default __eq__ behaviour, which is the same
> as "is", but:
>
> 1. It can easily become inconsistent, if someone implements __eq__ and
> doesn't implement __hash__.
Josiah Carlson writes:
> If you make such a suggestion, I would offer that you create a new PEP,
> because this discussion has gone beyond PEP 351, and has wandered into
> the realm of "What other kinds of objects would be interesting to have
> in a Python-like system?"
Noam Raphael replies:
> Tha
On 11/1/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> This is just a comment from the peanut gallery, as it's highly unlikely I'll
> be in attendance, but why not continue with the AST theme? Instead of
> working on the AST branch, you could start to propagate the AST
> representation aroun
Hello,
While writing my PEP about unifying mutable and immutable, I came upon this:
Is there a reason why the default __hash__ method returns the id of the objects?
It is consistent with the default __eq__ behaviour, which is the same
as "is", but:
1. It can easily become inconsistent, if someo
18 matches
Mail list logo
