[ python-Bugs-1571023 ] _ssl module can't be built on windows
Bugs item #1571023, was opened at 2006-10-05 01:31 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571023&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: �iga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: _ssl module can't be built on windows Initial Comment: Revision 52152 on the release24-maint branch updated the OpenSSL package to version 0.9.7l, which causes linking errors due to unresolved symbols. This can be fixed with a backport of patch 1197150: http://www.python.org/sf/1197150 -- >Comment By: Martin v. Löwis (loewis) Date: 2006-10-06 09:02 Message: Logged In: YES user_id=21627 Thanks for the report. This is now fixed with r52201. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571023&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1570284 ] Launcher reset to factory button provides bad command-line
Bugs item #1570284, was opened at 2006-10-03 23:17 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570284&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: jjackson (jejackson) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: Launcher reset to factory button provides bad command-line Initial Comment: If I push the "Reset to factory settings" in Python Launcher's Preferences window, the command line gets a bogues "(null)" inserted, which makes a mess of things. I don't think that was what was intended. In trying to debug this, I notice in the source for FileSettings.m, at line 209 there are two duplicated lines: [NSNumber numberWithBool: nosite], @"nosite", [NSNumber numberWithBool: nosite], @"nosite", Also, I notice at FileSettings.m:236 value = [dict objectForKey: @"nosite"]; if (value) nosite = [value boolValue]; value = [dict objectForKey: @"nosite"]; if (value) tabs = [value boolValue]; I'm wondering if these second "nosite"s should be "tabs", and if that would fix the problem. -- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-10-06 12:26 Message: Logged In: YES user_id=580910 I'll have a look at this this weekend. On first glance the analysis for the source code looks correct and both lines should be changed, but I don't have time just ow to do this and test the results just now (and then backport to the 2.5 and 2.4 trees) P.S. I'll be doing a huge checking on the 2.4 branch this weekend, backporting the universal python stuff to the official tree. Last week was busier than expected, hence the late checkin. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-10-04 07:48 Message: Logged In: YES user_id=33168 Ronald, I'm guessing that Jack still doesn't have time. Do you know anything about this? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570284&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1572084 ] .eml attachments in email
Bugs item #1572084, was opened at 2006-10-06 14:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1572084&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: rainwolf8472 (rainwolf8472) Assigned to: Nobody/Anonymous (nobody) Summary: .eml attachments in email Initial Comment: I think there's a bug somewhere in the email package. I wanted to write a script to send emails with certain attachments using libgmail, and found this one, http://pramode.net/articles/lfy/fuse/4.txt , it works fine with most files, but it fails with .eml files, and what i can't understand is that if I change the extension of those .eml files to .txt, the script works fine. However, when trying to mail a simple textfile containing "hello", en changing the extension to .eml before sending, it fails again. it doesn't fail when I don't change the extension to .eml. Any help please? I pasted the output I get (over and over again) in the attached textfile. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1572084&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1545341 ] setup() keyword have to be list (doesn't work with tuple)
Bugs item #1545341, was opened at 2006-08-23 10:49
Message generated for change (Comment added) made by akuchling
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545341&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: STINNER Victor (haypo)
>Assigned to: A.M. Kuchling (akuchling)
Summary: setup() keyword have to be list (doesn't work with tuple)
Initial Comment:
Code:
== 8< =
from distutils.core import setup
setup(..., classifier=('Intended Audience ::
Developers', 'Environment :: Console ::
Curses'), ...)
== 8< =
The query: "./setup.py register" will create HTML
request:
GHSKFJDLGDS7543FJKLFHRE75642756743254
Content-Disposition: form-data; name="classifiers"
('Intended Audience :: Developers', 'Environment ::
Console :: Curses')
Instead of a multipart part for each value.
The bug is stupid, see attached patch.
Haypo
--
>Comment By: A.M. Kuchling (akuchling)
Date: 2006-10-06 09:20
Message:
Logged In: YES
user_id=11375
Fix applied to trunk in rev. 52211; I'll backport to 2.5 and
2.4.
The Distutils code is intended to be compatible with Python
2.1, so I've reworked the change to keep using type()
instead of isinstance(). Patch attached.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545341&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1572210 ] help(x) for for keywords too
Feature Requests item #1572210, was opened at 2006-10-06 11:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1572210&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: help(x) for for keywords too Initial Comment: At the interactive prompt, help(object) is very useful. It would be nice if it also worked on keywords. """ >>> help(object) Help on class object in module __builtin__: class object | The most base type """ vs """ >>> help(with) SyntaxError: invalid syntax """ At the moment, the workaround is to open the documentation, pick a document that doesn't seem quite right (language reference?), go to the index, and look for the keyword. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1572210&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1572210 ] help(x) for keywords too
Feature Requests item #1572210, was opened at 2006-10-06 11:06 Message generated for change (Settings changed) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1572210&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) >Summary: help(x) for keywords too Initial Comment: At the interactive prompt, help(object) is very useful. It would be nice if it also worked on keywords. """ >>> help(object) Help on class object in module __builtin__: class object | The most base type """ vs """ >>> help(with) SyntaxError: invalid syntax """ At the moment, the workaround is to open the documentation, pick a document that doesn't seem quite right (language reference?), go to the index, and look for the keyword. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1572210&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1572210 ] help(x) for keywords too
Feature Requests item #1572210, was opened at 2006-10-06 15:06
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1572210&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: help(x) for keywords too
Initial Comment:
At the interactive prompt, help(object) is very useful.
It would be nice if it also worked on keywords.
"""
>>> help(object)
Help on class object in module __builtin__:
class object
| The most base type
"""
vs
"""
>>> help(with)
SyntaxError: invalid syntax
"""
At the moment, the workaround is to open the
documentation, pick a document that doesn't seem quite
right (language reference?), go to the index, and look
for the keyword.
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-06 15:59
Message:
Logged In: YES
user_id=849994
Doesn't help("if") work for you?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1572210&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1545341 ] setup() keyword have to be list (doesn't work with tuple)
Bugs item #1545341, was opened at 2006-08-23 16:49
Message generated for change (Comment added) made by haypo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545341&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: STINNER Victor (haypo)
Assigned to: A.M. Kuchling (akuchling)
Summary: setup() keyword have to be list (doesn't work with tuple)
Initial Comment:
Code:
== 8< =
from distutils.core import setup
setup(..., classifier=('Intended Audience ::
Developers', 'Environment :: Console ::
Curses'), ...)
== 8< =
The query: "./setup.py register" will create HTML
request:
GHSKFJDLGDS7543FJKLFHRE75642756743254
Content-Disposition: form-data; name="classifiers"
('Intended Audience :: Developers', 'Environment ::
Console :: Curses')
Instead of a multipart part for each value.
The bug is stupid, see attached patch.
Haypo
--
>Comment By: STINNER Victor (haypo)
Date: 2006-10-06 18:12
Message:
Logged In: YES
user_id=365388
Ok nice ;-)
--
Comment By: A.M. Kuchling (akuchling)
Date: 2006-10-06 15:20
Message:
Logged In: YES
user_id=11375
Fix applied to trunk in rev. 52211; I'll backport to 2.5 and
2.4.
The Distutils code is intended to be compatible with Python
2.1, so I've reworked the change to keep using type()
instead of isinstance(). Patch attached.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545341&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1572210 ] help(x) for keywords too
Feature Requests item #1572210, was opened at 2006-10-06 11:06
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1572210&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: help(x) for keywords too
Initial Comment:
At the interactive prompt, help(object) is very useful.
It would be nice if it also worked on keywords.
"""
>>> help(object)
Help on class object in module __builtin__:
class object
| The most base type
"""
vs
"""
>>> help(with)
SyntaxError: invalid syntax
"""
At the moment, the workaround is to open the
documentation, pick a document that doesn't seem quite
right (language reference?), go to the index, and look
for the keyword.
--
>Comment By: Jim Jewett (jimjjewett)
Date: 2006-10-06 12:26
Message:
Logged In: YES
user_id=764593
No, it doesn't -- but putting the keyword in quotes does at
least change the error message to saying that topic and
keyword documentation is not available because the Python
HTML documentation files could not be found.
I'm using Windows XP, the 2.4 and 2.5 binaries from
python.org, if I changed anything it was just the install
directory to be Python2.5 (or 2.4 for 2.4))
The documentation (as a chm file) is found by the F1 key.
Is this likely to be a windows build issue?
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-10-06 11:59
Message:
Logged In: YES
user_id=849994
Doesn't help("if") work for you?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1572210&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1572320 ] parser stack overflow
Bugs item #1572320, was opened at 2006-10-06 18:37
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1572320&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: j�rgen urner (cereb_00)
Assigned to: Nobody/Anonymous (nobody)
Summary: parser stack overflow
Initial Comment:
Executing this raw (malformed) tuple
raises:
s_push: parser stack overflow
MemoryError
instead of SyntaxError.
Sorry for not tracking it down more, but the tuple was
actually much longer, so I did at least a bit of that.
Removing the last member raises SyntaxError
as expected.
(
("indigo", "#4B0082)",
("gold", "#FFD700)",
("firebrick", "#B2)",
("indianred", "#CD5C5C)",
("yellow", "#00)",
("darkolivegreen", "#556B2F)",
("darkseagreen", "#8FBC8F)",
("mediumvioletred", "#C71585)",
("mediumorchid", "#BA55D3)",
("chartreuse", "#7FFF00)",
("mediumslateblue", "#7B68EE)",
("black", "#00)",
("springgreen", "#00FF7F)",
("crimson", "#DC143C)",
("lightsalmon", "#FFA07A)",
("brown", "#A52A2A)",
("turquoise", "#40E0D0)",
("olivedrab", "#6B8E23)",
("silver", "#C0C0C0)",
("skyblue", "#87CEEB)",
("gray", "#808080)",
("darkturquoise", "#00CED1)",
("goldenrod", "#DAA520)",
("darkgreen", "#006400)",
("darkviolet", "#9400D3)",
("darkgray", "#A9A9A9)",
("lime", "#00FF00)",
("lightpink", "#FFB6C1)",
("teal", "#008080)",
("darkmagenta", "#8B008B)",
("lightgoldenrodyellow", "#FAFAD2)",
("lavender", "#E6E6FA)",
)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1572320&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1572210 ] help(x) for keywords too
Feature Requests item #1572210, was opened at 2006-10-06 17:06
Message generated for change (Comment added) made by theller
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1572210&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: help(x) for keywords too
Initial Comment:
At the interactive prompt, help(object) is very useful.
It would be nice if it also worked on keywords.
"""
>>> help(object)
Help on class object in module __builtin__:
class object
| The most base type
"""
vs
"""
>>> help(with)
SyntaxError: invalid syntax
"""
At the moment, the workaround is to open the
documentation, pick a document that doesn't seem quite
right (language reference?), go to the index, and look
for the keyword.
--
>Comment By: Thomas Heller (theller)
Date: 2006-10-06 21:25
Message:
Logged In: YES
user_id=11105
> Is this likely to be a windows build issue?
No. pydoc cannot use the .chm file. Either you should
download the HTML files yourself, or you can compile the
.chm file in a windows command shell (note that the
decompilation runs in the background, and has no user
interface):
C:\Python24\Doc>hh -decompile . Python24.chm
C:\Python24\Doc>dir *.chm
Datenträger in Laufwerk C: ist ...
Volumeseriennummer: ...
Verzeichnis von C:\Python24\Doc
06.10.2006 21:23 3.732 about.html
06.10.2006 21:23 8.689 acks.html
06.10.2006 21:23 4.445 index.html
06.10.2006 21:2335.525 modindex.html
4 Datei(en) 52.391 Bytes
0 Verzeichnis(se), 8.506.798.080 Bytes frei
C:\Python24\Doc>
The other HTML files are created in subdirectories, and
help("if") now works.
--
Comment By: Jim Jewett (jimjjewett)
Date: 2006-10-06 18:26
Message:
Logged In: YES
user_id=764593
No, it doesn't -- but putting the keyword in quotes does at
least change the error message to saying that topic and
keyword documentation is not available because the Python
HTML documentation files could not be found.
I'm using Windows XP, the 2.4 and 2.5 binaries from
python.org, if I changed anything it was just the install
directory to be Python2.5 (or 2.4 for 2.4))
The documentation (as a chm file) is found by the F1 key.
Is this likely to be a windows build issue?
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-10-06 17:59
Message:
Logged In: YES
user_id=849994
Doesn't help("if") work for you?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1572210&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-660098 ] New style classes and __hash__
Bugs item #660098, was opened at 2002-12-30 13:39
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660098&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Guido van Rossum (gvanrossum)
Summary: New style classes and __hash__
Initial Comment:
New style classes obviously inherit a __hash__
implementation from object which returns the id. Per
default this allows using instances as dictionary keys,
but usually with the wrong behaviour, because most
often user classes are mutable, and their contained data
should be used to calculate the hash value.
IMO one possible solution would be to change
typeobject.c:object_hash() to raise TypeError, and
change all the immutable (core) Python objects to use
_Py_HashPointer in their tp_hash slot.
--
>Comment By: Guido van Rossum (gvanrossum)
Date: 2006-10-06 17:19
Message:
Logged In: YES
user_id=6380
I don't recall what was wrong with the patch.
I do know that I fixed this in Python 3000; but the fix
there was only possible due to other unrelated fixes that
couldn't possibly be backported.
I propose to leave this broken until Py3k, so let's close
this bug.
--
Comment By: Daniel (danielhs)
Date: 2006-10-05 22:22
Message:
Logged In: YES
user_id=1609821
Still doesn't work as expected in 2.5.
Just wanted to bump along since I noticed this bug today,
and found this bug report (which hasn't changed in nearly 3
years).
--
Comment By: Guido van Rossum (gvanrossum)
Date: 2003-12-22 16:04
Message:
Logged In: YES
user_id=6380
Anybody see a reason why I shouldn't check this in? See
python-dev discussion.
--
Comment By: Guido van Rossum (gvanrossum)
Date: 2003-12-05 13:30
Message:
Logged In: YES
user_id=6380
Here's the patch I am thinking of.
--
Comment By: Guido van Rossum (gvanrossum)
Date: 2003-12-05 13:06
Message:
Logged In: YES
user_id=6380
I wonder if the solution could be as simple as removing the
tp_hash slot from the object class?
I just tried that and it passes the entire test suite, as
well as the tests that Tim added to the patch.
The trick is that PyObject_Hash() has a fallback which does
the right thing.
And when the base object class doesn't set tp_compare or
tp_richcompare, I think it should be allowed not to set
tp_hash either.
--
Comment By: Guido van Rossum (gvanrossum)
Date: 2003-05-11 09:41
Message:
Logged In: YES
user_id=6380
Oops, not so fast. This also makes object.__hash__() calls
fail when it is explicitly invoked, e.g. when a class
overrides __eq__ to print a message and then call the base
class __eq__, it must do the same for __hash__, but
object.__hash__ will still fail in this case. I'll think of
a fix for that.
--
Comment By: Guido van Rossum (gvanrossum)
Date: 2003-05-11 06:16
Message:
Logged In: YES
user_id=6380
OK, feel free to check it in.
--
Comment By: Tim Peters (tim_one)
Date: 2003-05-11 00:39
Message:
Logged In: YES
user_id=31435
The patch seems fines to me. I've attached a new patch,
combining yours with new tests in test_class.py.
--
Comment By: Guido van Rossum (gvanrossum)
Date: 2003-05-09 14:04
Message:
Logged In: YES
user_id=6380
A trick similar to what we do in object_new might work.
There, we raise an error if the tp_init slot is the default
function (object_init) and any arguments are passed.
I propose that object_hash checks that tp_compare and
tp_richcompare are both NULL. I'm attaching a patch -- let
me know if that works.
--
Comment By: Tim Peters (tim_one)
Date: 2003-05-09 13:54
Message:
Logged In: YES
user_id=31435
>>> class C: # classic class complains
... __cmp__ = lambda a, b: 0
...
>>> {C(): 1}
Traceback (most recent call last):
File "", line 1, in ?
TypeError: unhashable instance
>>> class C(object): # new-style class does not complain
... __cmp__ = lambda a, b: 0
...
>>> {C(): 1}
{<__main__.C object at 0x007F6970>: 1}
>>>
That was under current CVS. I see the same behavior in
2.2.3, so this isn't new.
About T
[ python-Bugs-660098 ] New style classes and __hash__
Bugs item #660098, was opened at 2002-12-30 13:39 Message generated for change (Comment added) made by danielhs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660098&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Guido van Rossum (gvanrossum) Summary: New style classes and __hash__ Initial Comment: New style classes obviously inherit a __hash__ implementation from object which returns the id. Per default this allows using instances as dictionary keys, but usually with the wrong behaviour, because most often user classes are mutable, and their contained data should be used to calculate the hash value. IMO one possible solution would be to change typeobject.c:object_hash() to raise TypeError, and change all the immutable (core) Python objects to use _Py_HashPointer in their tp_hash slot. -- Comment By: Daniel (danielhs) Date: 2006-10-06 17:29 Message: Logged In: YES user_id=1609821 I don't know if this is the right answer or not, but, this post seems to indicate that the fix would break Jython. But a later post in the thread notes that since the latest version of Jython is only version 2.1 this shouldn't be an issue. First post: http://mail.python.org/pipermail/python-list/2004-December/257637.html Second post: http://mail.python.org/pipermail/python-list/2004-December/257690.html Daniel -- Comment By: Guido van Rossum (gvanrossum) Date: 2006-10-06 17:19 Message: Logged In: YES user_id=6380 I don't recall what was wrong with the patch. I do know that I fixed this in Python 3000; but the fix there was only possible due to other unrelated fixes that couldn't possibly be backported. I propose to leave this broken until Py3k, so let's close this bug. -- Comment By: Daniel (danielhs) Date: 2006-10-05 22:22 Message: Logged In: YES user_id=1609821 Still doesn't work as expected in 2.5. Just wanted to bump along since I noticed this bug today, and found this bug report (which hasn't changed in nearly 3 years). -- Comment By: Guido van Rossum (gvanrossum) Date: 2003-12-22 16:04 Message: Logged In: YES user_id=6380 Anybody see a reason why I shouldn't check this in? See python-dev discussion. -- Comment By: Guido van Rossum (gvanrossum) Date: 2003-12-05 13:30 Message: Logged In: YES user_id=6380 Here's the patch I am thinking of. -- Comment By: Guido van Rossum (gvanrossum) Date: 2003-12-05 13:06 Message: Logged In: YES user_id=6380 I wonder if the solution could be as simple as removing the tp_hash slot from the object class? I just tried that and it passes the entire test suite, as well as the tests that Tim added to the patch. The trick is that PyObject_Hash() has a fallback which does the right thing. And when the base object class doesn't set tp_compare or tp_richcompare, I think it should be allowed not to set tp_hash either. -- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-11 09:41 Message: Logged In: YES user_id=6380 Oops, not so fast. This also makes object.__hash__() calls fail when it is explicitly invoked, e.g. when a class overrides __eq__ to print a message and then call the base class __eq__, it must do the same for __hash__, but object.__hash__ will still fail in this case. I'll think of a fix for that. -- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-11 06:16 Message: Logged In: YES user_id=6380 OK, feel free to check it in. -- Comment By: Tim Peters (tim_one) Date: 2003-05-11 00:39 Message: Logged In: YES user_id=31435 The patch seems fines to me. I've attached a new patch, combining yours with new tests in test_class.py. -- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-09 14:04 Message: Logged In: YES user_id=6380 A trick similar to what we do in object_new might work. There, we raise an error if the tp_init slot is the default function (object_init) and any arguments are passed. I propose that object_hash checks that tp_compare and tp_richcompare are both NULL. I'm attaching a patch -- let me know if that works. ---
[ python-Bugs-1572471 ] csv "dialect = 'excel-tab'" to use excel_tab
Bugs item #1572471, was opened at 2006-10-06 17:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1572471&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dan Goldner (goldner) Assigned to: Nobody/Anonymous (nobody) Summary: csv "dialect = 'excel-tab'" to use excel_tab Initial Comment: Python Library Reference v2.5 (19 September 2006), section 9.1.1, entry for class excel_tab: Documentation should note that though the class is excel_tab (with an underscore), the dialect name is 'excel-tab' (with a hyphen). Possible fix is to add a sentence: class excel_tab() The excel_tab class defines the usual properties of an Excel-generated TAB-delimited file. Specify in reader, writer, etc. with "dialect = 'excel-tab'" (with a hyphen, not an underscore). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1572471&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
