[ python-Bugs-1161187 ] Install problem 2.4.1rc1 on Win98
Bugs item #1161187, was opened at 2005-03-11 08:56 Message generated for change (Comment added) made by m_webber_sydney You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Spider (m_webber_sydney) Assigned to: Martin v. Löwis (loewis) Summary: Install problem 2.4.1rc1 on Win98 Initial Comment: Python 2.4.1 Release Candidate 1. I installed (with all the defautl settings) python-2.4.1c1.msi on a Windows 98 machine. The shortcuts in the Start / Programs / Python 2.4 group includes a shortcut named "Python Manuals". This shortcut is inactive - does not point to anything valid, and clicking on it does not bring up the manuals. I assume that the shortcut should point to C:/Python24/Doc/Python24.chm which certainly exists on my machine and works ok if I access it directly. I guess the install builds the shortcut wrongly. -- >Comment By: Spider (m_webber_sydney) Date: 2005-03-14 08:37 Message: Logged In: YES user_id=1237039 Uninstalled, rebooted and reinstalled using c:\windows\system\msiexec /i python-2.4.1c1.msi /l*v python.log The log file (1.1MB) is available, probably too big to cut/paste into here. I can email it to you if you like. -- Comment By: Martin v. Löwis (loewis) Date: 2005-03-13 22:39 Message: Logged In: YES user_id=21627 Somebody suggested in the newsgroup to request a log file; I should have thought of this earlier. So please reinstall the MSI file, using msiexec /i python-2.4.1c1.msi /l*v python.log and attach the resulting python.log to this report. -- Comment By: Martin v. Löwis (loewis) Date: 2005-03-12 22:25 Message: Logged In: YES user_id=21627 Do the other links work fine? If so, I'm about to give up and make the doc link non-advertised. Before that, I'd like you to run another experiment: The documentation has no working directory. It should be possible to edit the shortcut to change the working directory (this is possible on XP atleast), please try setting it to c:\python24\docs (or whereever the chm is located). tim_one: right, the Tk links are also advertised (it was the "Edit with IDLE" context menu that can't be made advertised). That they are not editable is a magic of Installer: They don't primarily contain the target file name, but the package code of the MSI file, plus the key name in the Shortcut table (or some such). To see that work, delete python24.chm, then run the start menu item for documentation. Microsoft calls it "resiliency" -- Comment By: Tim Peters (tim_one) Date: 2005-03-12 18:16 Message: Logged In: YES user_id=31435 Hmm. On my box (WinXP, etc), _all_ the shortcut property sheets look like this (greyed out target, disabled buttons) with the sole exception of "Uninstall Python". Why they don't come up with editable strings and "Find Target ..." enabled remains a mystery then. -- Comment By: Spider (m_webber_sydney) Date: 2005-03-12 13:05 Message: Logged In: YES user_id=1237039 Installer was already on the machine. I am testing this under VMWare, by the way. -- Comment By: Martin v. Löwis (loewis) Date: 2005-03-12 12:13 Message: Logged In: YES user_id=21627 Did you install Installer 2.0 as part of the Python installation, or was it already on your machine? If you did install it, did you reboot after installing it? -- Comment By: Spider (m_webber_sydney) Date: 2005-03-12 11:59 Message: Logged In: YES user_id=1237039 As requested, I uninstalled, rebooted and then installed with C;\windows\system\msiexec.exe /i python-2.4.1c1.msi DISABLEADVTSHORTCUTS=1 That worked, and the shortcut to the Manuals was correctly built this time (I did not need to reboot). Let me know if you want any further tests. Matthew -- Comment By: Martin v. Löwis (loewis) Date: 2005-03-12 11:16 Message: Logged In: YES user_id=21627 Also, did you reboot the machine after installing the install 2.0? According to http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/platform_support_of_advertisement.asp advertised shortcuts don't work until the machine is rebooted. -- Comment By: Martin v. Löwis (loewis) Date: 2005-03-12 11:14 Message: Logged In: YES user_id=21627 m_webber_sydney, can you please also try the following procedure, and report whether it ch
[ python-Bugs-1161187 ] Install problem 2.4.1rc1 on Win98
Bugs item #1161187, was opened at 2005-03-11 08:56
Message generated for change (Comment added) made by m_webber_sydney
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470
Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Spider (m_webber_sydney)
Assigned to: Martin v. Löwis (loewis)
Summary: Install problem 2.4.1rc1 on Win98
Initial Comment:
Python 2.4.1 Release Candidate 1.
I installed (with all the defautl settings)
python-2.4.1c1.msi on a Windows 98 machine.
The shortcuts in the Start / Programs / Python 2.4
group includes a shortcut named "Python Manuals".
This shortcut is inactive - does not point to anything
valid, and clicking on it does not bring up the manuals.
I assume that the shortcut should point to
C:/Python24/Doc/Python24.chm which certainly exists on
my machine and works ok if I access it directly.
I guess the install builds the shortcut wrongly.
--
>Comment By: Spider (m_webber_sydney)
Date: 2005-03-14 08:50
Message:
Logged In: YES
user_id=1237039
I looked at the log file, and an extract is below. It shows
fairly clearly that when the "Manuals" shortcut is created,
the arguments are missing.
Let me know if you still want the full log.
MSI (c) (63:E3): Note: 1: 2360
MSI (c) (63:E3): Note: 1: 2360
MSI (c) (63:E3): Note: 1: 2360
MSI (c) (63:E3): Note: 1: 2360
MSI (c) (63:E3): Executing op: InstallProtectedFiles(AllowUI=1)
MSI (c) (63:E3): Executing op:
ActionStart(Name=CreateShortcuts,Description=Creating
shortcuts,Template=Shortcut: )
Action 08:30:42: CreateShortcuts. Creating shortcuts
MSI (c) (63:E3): Executing op:
SetTargetFolder(Folder=23\Python 2.4\)
MSI (c) (63:E3): SHFOLDER::SHGetFolderPath returned:
C:\WINDOWS\Start Menu\Programs
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=PYTHON|Python (command
line),Feature=DefaultFeature,Component={4DC71ADD-ADA5-4029-A5BC-5E8858F4243C},,,WorkingDir=C:\Python24\,Icon=python_icon.exe,IconIndex=2,,,)
CreateShortcuts: Shortcut: PYTHON|Python (command line)
MSI (c) (63:E3): Executing op: ShortcutCreate(Name=IDLE|IDLE
(Python
GUI),Feature=TclTk,Component={1E82B1B6-0262-4141-918C-8A03ED896CB7},,Arguments="C:\Python24\Lib\idlelib\idle.pyw",WorkingDir=C:\Python24\,Icon=python_icon.exe,IconIndex=0,,,)
CreateShortcuts: Shortcut: IDLE|IDLE (Python GUI)
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=MODDOCS|Module
Docs,Feature=TclTk,Component={1E82B1B6-0262-4141-918C-8A03ED896CB7},,Arguments="C:\Python24\Tools\scripts\pydocgui.pyw",WorkingDir=C:\Python24\,Icon=python_icon.exe,IconIndex=0,,,)
CreateShortcuts: Shortcut: MODDOCS|Module Docs
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=MANUAL|Python
Manuals,Feature=Documentation,Component={A7ED4080-C9C8-4AD4-BBAF-2D2846B7FF95}
CreateShortcuts: Shortcut: MANUAL|Python Manuals
MSI (c) (63:E3): Executing op:
SetTargetFolder(Folder=23\Python 2.4\)
MSI (c) (63:E3): SHFOLDER::SHGetFolderPath returned:
C:\WINDOWS\Start Menu\Programs
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=UNINST|Uninstall
Python,,,FileName=C:\WINDOWS\SYSTEM\msiexec,Arguments=/x{be027411-8e6b-4440-a29b-b07df0690230},,)
CreateShortcuts: Shortcut: UNINST|Uninstall Python
MSI (c) (63:E3): Executing op:
ActionStart(Name=WriteRegistryValues,Description=Writing
system registry values,Template=Key: , Name: , Value: )
Action 08:30:42: WriteRegistryValues. Writing system
registry values
MSI (c) (63:E3): Executing op:
ProgressTotal(Total=23,Type=1,ByteEquivalent=13200)
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\.py,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=Python.File,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.py, Name: , Value:
Python.File
MSI (c) (63:E3): Executing op: RegAddValue(Name=Content
Type,Value=text/plain,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.py, Name: Content Type,
Value: text/plain
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\.pyw,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=Python.NoConFile,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.pyw, Name: , Value:
Python.NoConFile
MSI (c) (63:E3): Executing op: RegAddValue(Name=Content
Type,Value=text/plain,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.pyw, Name: Content
Type, Value: text/plain
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\.pyc,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=Python.CompiledFile,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.pyc, Name: , Value:
Python.CompiledFile
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\.pyo,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=Python.CompiledFile,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.pyo, Name: , Value:
Python
[ python-Feature Requests-1154351 ] add get_current_dir_name() to os module
Feature Requests item #1154351, was opened at 2005-03-01 16:26 Message generated for change (Comment added) made by hoffmanm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1154351&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hoffman (hoffmanm) Assigned to: Nobody/Anonymous (nobody) Summary: add get_current_dir_name() to os module Initial Comment: os.getcwd() does not use the contents of the PWD environment variable, much as the glibc getcwd() does not. This means that if a user sets the path using a symbolic link, it will be dereferenced before being passed by os.getcwd(). I propose that get_current_dir_name() be added, either as a call to the glibc get_current_dir_name(), which uses the PWD environment variable and therefore will not dereference symbolic links in the path, or as a fallback to this Pure Python function: def get_current_dir_name(): cwd = os.getcwd() try: pwd = os.environ["PWD"] except KeyError: return cwd cwd_stat, pwd_stat = map(os.stat, [cwd, pwd]) if cwd_stat.st_dev == pwd_stat.st_dev and cwd_stat.st_ino == pwd_stat.st_ino: return pwd else: return cwd -- >Comment By: Michael Hoffman (hoffmanm) Date: 2005-03-14 09:03 Message: Logged In: YES user_id=987664 Thanks for your comments. I agree that a better description of the difference here is necessary. I just checked the glibc source and this is almost exactly what it does. It actually does an os.stat on "." and only calls __getcwd() if necessary. It's in glibc-2.3.4/io/getdirname.c if you're curious. I'll make that change and add the patch to my list of things to do... Since st_dev and st_ino don't work outside Posix, should I just return os.getcwd() on other platforms? -- Comment By: Martin v. Löwis (loewis) Date: 2005-03-13 23:00 Message: Logged In: YES user_id=21627 I was going to say "what is the advantage of using the PWD variable?", but, thinking about it three times, I found that it gives you what the user typed in the last cd(1), independent of symbolic links. So even though you wrote what it does, and how it differs from getcwd, its not at all obvious that this is a good thing (even though I now agree it is a good thing) Would you like to work on a patch? A pure Python implementation sounds reasonable, if your code is what glibc does as well. It seems to me that the documentation patch is really crucial here, or else users will wonder "what the heck...". -- Comment By: Michael Hoffman (hoffmanm) Date: 2005-03-01 16:27 Message: Logged In: YES user_id=987664 Hmmm... my indentation seems to have gone by the wayside. Still you can probably figure out what the code is supposed to do -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1154351&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1160534 ] Autoconf failure on FreeBSD 5.3, and AC_INIT set incorrectly
Bugs item #1160534, was opened at 2005-03-10 10:19 Message generated for change (Comment added) made by rptb1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160534&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Brooksby (rptb1) Assigned to: Nobody/Anonymous (nobody) Summary: Autoconf failure on FreeBSD 5.3, and AC_INIT set incorrectly Initial Comment: Begin forwarded message: Date: 8 March 2005 18:20:48 GMT To: bug-autoconf@gnu.org Subject: Autoconf asked me to tell you about this bug On a clean FreeBSD 5.3 machine, do: cd /usr/local/lang/python make install and you will see, amongst other things: checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking ncurses.h usability... no checking ncurses.h presence... yes configure: WARNING: ncurses.h: present but cannot be compiled configure: WARNING: ncurses.h: check for missing prerequisite headers? configure: WARNING: ncurses.h: proceeding with the preprocessor's result configure: WARNING: ## ## configure: WARNING: ## Report this to [EMAIL PROTECTED] ## configure: WARNING: ## ## checking for ncurses.h... yes checking poll.h usability... yes checking poll.h presence... yes checking for poll.h... yes checking pthread.h usability... yes checking pthread.h presence... yes checking for pthread.h... yes --- Begin forwarded message: Date: 9 March 2005 11:47:03 GMT To: Richard Brooksby <[EMAIL PROTECTED]> Cc: bug-autoconf@gnu.org Subject: Re: Autoconf asked me to tell you about this bug Hello, On Tue, Mar 08, 2005 at 06:20:48PM +, Richard Brooksby wrote: On a clean FreeBSD 5.3 machine, do: cd /usr/local/lang/python you should report this bug to the bug report address of the "python" project. Tell them to read the section "Present But Cannot Be Compiled" of the manual to autoconf-2.59. They have misconfigured the bug report address in AC_INIT, so also tell them to change it to *their* bug report address. -- >Comment By: Richard Brooksby (rptb1) Date: 2005-03-14 10:41 Message: Logged In: YES user_id=927536 Sorry if the text isn't helpful -- I'm just following instructions. Please find config.log attached. -- Comment By: Martin v. Löwis (loewis) Date: 2005-03-12 22:36 Message: Logged In: YES user_id=21627 That information does not help to resolve the problem, and it is not clear that it is a problem in Python's configure - it could be a bug in your operating system installation also. Please attach the config.log. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160534&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1156259 ] [2.4 regression] seeking in codecs.reader broken
Bugs item #1156259, was opened at 2005-03-03 23:29
Message generated for change (Comment added) made by doko
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156259&group_id=5470
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 7
Submitted By: Matthias Klose (doko)
Assigned to: Walter Dörwald (doerwalter)
Summary: [2.4 regression] seeking in codecs.reader broken
Initial Comment:
[forwarded from
https://bugzilla.ubuntu.com/show_bug.cgi?id=6972 ]
This is a regression; the following script (call as
"scriptname some_textfile")
fails.
It is obvious that the file starts with a number of
random bytes from the
previous run.
Uncommenting the two #XXX lines makes the bug go away.
So does running it with
Python 2.3.5
import sys
import codecs
from random import random
data = codecs.getreader("utf-8")(open(sys.argv[1]))
df = data.read()
for t in range(30):
#XXX data.seek(0,1)
#XXX data.read()
data.seek(0,0)
dn=""
for l in data:
dn += l
if random() < 0.1: break
if not df.startswith(dn):
print "OUCH",t
print "BAD:", dn[0:100]
print "GOOD:", df[0:100]
sys.exit(1)
print "OK",len(df)
sys.exit(0)
--
>Comment By: Matthias Klose (doko)
Date: 2005-03-14 12:02
Message:
Logged In: YES
user_id=60903
added doc string
--
Comment By: Walter Dörwald (doerwalter)
Date: 2005-03-08 15:40
Message:
Logged In: YES
user_id=89016
OK, I'll check in the patch at the beginning of next week
(I'm currently away from CVS).
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2005-03-08 15:00
Message:
Logged In: YES
user_id=38388
Walter: the patch looks good. Please also add a doc-string
mentioning the resetting of the codec in case .seek() is used.
Whether .seek() causes a mess or not is not within the
responsibility of the codec - it's an application space
decision to make, otherwise we would have to introduce the
notion of seeking code points (rather than bytes) which I'd
rather not like to do since this can break existing
applications in many ways.
--
Comment By: Matthias Urlichs (smurf)
Date: 2005-03-08 14:20
Message:
Logged In: YES
user_id=10327
Ahem -- seek(0,*whatever*) should still be allowed, whatever
else you do, please.
Reading UTF-16 from an odd position in a file isn't always
an error -- sometimes text is embedded in weird on-disk data
structures. As long as tell() returns something you can
seek() back to, nobody's got a right to complain -- file
position arithmetic in general is nonportable.
--
Comment By: Walter Dörwald (doerwalter)
Date: 2005-03-04 12:44
Message:
Logged In: YES
user_id=89016
How about the following patch? Unfortunately this breaks the
codec in more obscure cases. Calling seek(0, 1) should have
now effect, but with this patch it does. Maybe calling
seek() should be prohibited? Calling a seek(1, 1) in a
UTF-16 stream completely messes up the decoded text.
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2005-03-04 10:56
Message:
Logged In: YES
user_id=38388
This is obviously related to the buffer logic that Walter added
to support .readline().
In order to fix the problem, a .seek() method must be
implemented
that resets the buffers whenever called (before asking the
stream
to seek to the specified stream position).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156259&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1162912 ] typesseq-mutable lacks note on combined key/cmp usage
Bugs item #1162912, was opened at 2005-03-14 12:20 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=1162912&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stefan Behnel (scoder) Assigned to: Nobody/Anonymous (nobody) Summary: typesseq-mutable lacks note on combined key/cmp usage Initial Comment: The documentation about list.sort() and sorted() does not state how the keyword arguments cmp and key interact. Aparently, if key is supplied, cmp works on the result of the key function and no longer on the item itself. This should be documented. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162912&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1153075 ] PyXxx_Check(x) trusts x->ob_type->tp_mro
Bugs item #1153075, was opened at 2005-02-27 21:55 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153075&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Armin Rigo (arigo) Summary: PyXxx_Check(x) trusts x->ob_type->tp_mro Initial Comment: The functions PyInt_Check(), PyString_Check(), PyList_Check() etc. are used all over the core to check which typecasts are safe, from PyObject* to the various PyXxxObject*. But the macros themselves are implemented by inspecting the "tp_mro" tuple of the incoming object's type. As the latter can be completely controlled by the user, an object can pretend to inherit from anything and pass the PyXxx_Check() checks of its choice, even if its memory layout is actually completely wrong. See attached example. -- >Comment By: Armin Rigo (arigo) Date: 2005-03-14 11:25 Message: Logged In: YES user_id=4771 I tried to convince myself that this check always accepts the default mro, but there are more implicit assumptions around than I can handle in a quick review... Instead, I modified the patch so that a debug build of Python always does the check in mro_internal(). This results in a shallow problem: the basestring type has tp_basicsize==0, which makes the computation of its solid_base trigger an assertion in extra_ivars(). If I hack around this problem, then I cannot quickly find an example of built-in mro that triggers a TypeError, but it doesn't mean there isn't one... -- Comment By: Michael Hudson (mwh) Date: 2005-03-06 18:47 Message: Logged In: YES user_id=6656 I think the attached fixes all this. What it does: check the return value of PySequence_Tuple (duh). Check that the returned sequence contains only types or old-style classes. Checks that the solid_base of each type in the returned sequence is a supertype of the solid_base of type being built. Adds a few tests. The error messages are a bit inscrutable. I find it hard to care. Assigning to Armin for the first look. Might want to get Guido to look at it too. When Armin and I talked about this on IRC we found a few oddities in the general area, but I don't know if it's worth opening a new bug report for them... -- Comment By: Michael Hudson (mwh) Date: 2005-03-03 09:50 Message: Logged In: YES user_id=6656 Certainly some more checking of what the user-defined MRO contains would be good -- check the attached, which dumps core at class definition time... -- Comment By: Armin Rigo (arigo) Date: 2005-03-03 09:34 Message: Logged In: YES user_id=4771 The PyXxx_Check() macros are #defined with PyObject_TypeCheck(). Should we change all these #defines to use a new PyObject_LayoutCheck() or something, and document to C extension writers that they should also switch to the new function? More generally, should we review *all* usages of PyObject_TypeCheck() and decide if they really meant that or PyObject_LayoutCheck()? Do we care about types that are solid subclasses of 'int' but don't have it in their MRO? Should we just forget the whole idea and sanity-check the user-defined mro, which after all would just add another strange undocumented condition to typeobject.c? :-) -- Comment By: Michael Hudson (mwh) Date: 2005-03-02 20:11 Message: Logged In: YES user_id=6656 Hmm, yeah, that works. It wasn't totally clear to me that the user couldn't maliciously influence tp_base, but I don't think they can... A helper function is presumably in order, unless PyType_IsSubtype should be changed. -- Comment By: Armin Rigo (arigo) Date: 2005-03-02 17:03 Message: Logged In: YES user_id=4771 To solve the problem, as hinted in the title of this tracker, I think that PyXxx_Check() should simply not trust any mro. What PyInt_Check() really means at the C level is to check if an object memory layout is compatible with PyIntObject. This is easy to figure out by walking the "solid base" chain, tp_base. As a side note, PyPy gives the same error as Python 2.2. However, both in PyPy and in Python 2.2, you can still build an instance of the strange class X as follows: >>> x = object.__new__(X) Still, all the methods of x are resolved via the dict type. In PyPy we get a clean TypeError because the methods thus found don't apply to non-dict objects. In Python 2.2 you can crash the interpreter just as in more recent Python releases, e.g. with x[5]=6. -
[ python-Bugs-1153075 ] PyXxx_Check(x) trusts x->ob_type->tp_mro
Bugs item #1153075, was opened at 2005-02-27 21:55 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153075&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Armin Rigo (arigo) Summary: PyXxx_Check(x) trusts x->ob_type->tp_mro Initial Comment: The functions PyInt_Check(), PyString_Check(), PyList_Check() etc. are used all over the core to check which typecasts are safe, from PyObject* to the various PyXxxObject*. But the macros themselves are implemented by inspecting the "tp_mro" tuple of the incoming object's type. As the latter can be completely controlled by the user, an object can pretend to inherit from anything and pass the PyXxx_Check() checks of its choice, even if its memory layout is actually completely wrong. See attached example. -- >Comment By: Michael Hudson (mwh) Date: 2005-03-14 11:41 Message: Logged In: YES user_id=6656 Well, emprically that can't happen because the patch passes test_descr, and far sillier things happen in that file than in real life. More theoretically... I'll think about it :) -- Comment By: Armin Rigo (arigo) Date: 2005-03-14 11:25 Message: Logged In: YES user_id=4771 I tried to convince myself that this check always accepts the default mro, but there are more implicit assumptions around than I can handle in a quick review... Instead, I modified the patch so that a debug build of Python always does the check in mro_internal(). This results in a shallow problem: the basestring type has tp_basicsize==0, which makes the computation of its solid_base trigger an assertion in extra_ivars(). If I hack around this problem, then I cannot quickly find an example of built-in mro that triggers a TypeError, but it doesn't mean there isn't one... -- Comment By: Michael Hudson (mwh) Date: 2005-03-06 18:47 Message: Logged In: YES user_id=6656 I think the attached fixes all this. What it does: check the return value of PySequence_Tuple (duh). Check that the returned sequence contains only types or old-style classes. Checks that the solid_base of each type in the returned sequence is a supertype of the solid_base of type being built. Adds a few tests. The error messages are a bit inscrutable. I find it hard to care. Assigning to Armin for the first look. Might want to get Guido to look at it too. When Armin and I talked about this on IRC we found a few oddities in the general area, but I don't know if it's worth opening a new bug report for them... -- Comment By: Michael Hudson (mwh) Date: 2005-03-03 09:50 Message: Logged In: YES user_id=6656 Certainly some more checking of what the user-defined MRO contains would be good -- check the attached, which dumps core at class definition time... -- Comment By: Armin Rigo (arigo) Date: 2005-03-03 09:34 Message: Logged In: YES user_id=4771 The PyXxx_Check() macros are #defined with PyObject_TypeCheck(). Should we change all these #defines to use a new PyObject_LayoutCheck() or something, and document to C extension writers that they should also switch to the new function? More generally, should we review *all* usages of PyObject_TypeCheck() and decide if they really meant that or PyObject_LayoutCheck()? Do we care about types that are solid subclasses of 'int' but don't have it in their MRO? Should we just forget the whole idea and sanity-check the user-defined mro, which after all would just add another strange undocumented condition to typeobject.c? :-) -- Comment By: Michael Hudson (mwh) Date: 2005-03-02 20:11 Message: Logged In: YES user_id=6656 Hmm, yeah, that works. It wasn't totally clear to me that the user couldn't maliciously influence tp_base, but I don't think they can... A helper function is presumably in order, unless PyType_IsSubtype should be changed. -- Comment By: Armin Rigo (arigo) Date: 2005-03-02 17:03 Message: Logged In: YES user_id=4771 To solve the problem, as hinted in the title of this tracker, I think that PyXxx_Check() should simply not trust any mro. What PyInt_Check() really means at the C level is to check if an object memory layout is compatible with PyIntObject. This is easy to figure out by walking the "solid base" chain, tp_base. As a side note, PyPy gives the same error as Python 2.2. However, both in PyPy and in Python 2.2, you can still build an instance of the
[ python-Bugs-1158005 ] unixccompiler.py should deal with env in linker
Bugs item #1158005, was opened at 2005-03-07 01:42 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158005&group_id=5470 Category: Distutils Group: Python 2.3 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Edward Moy (edwardmoy) Assigned to: Nobody/Anonymous (nobody) Summary: unixccompiler.py should deal with env in linker Initial Comment: When the linker command begins with env, plus some environment settings, and when the target is c++, the modified linker command should place the c++ command in the proper place, which is not the first element of the linker array. The following seems to be fix the problem: --- unixccompiler.py.orig 2004-08-29 09:45:13.0 -0700 +++ unixccompiler.py2005-03-06 16:36:05.0 -0800 @@ -172,7 +172,12 @@ else: linker = self.linker_so[:] if target_lang == "c++" and self.compiler_cxx: -linker[0] = self.compiler_cxx[0] +i = 0 +if os.path.basename(linker[0]) == "env": +i = 1 +while '=' in linker[i]: +i = i + 1 +linker[i] = self.compiler_cxx[0] self.spawn(linker + ld_args) except DistutilsExecError, msg: raise LinkError, msg -- >Comment By: Jack Jansen (jackjansen) Date: 2005-03-14 15:41 Message: Logged In: YES user_id=45365 Indeed, 2.3.5 (and 2.4.1) were patched wrt. the MACOSX_DEPLOYMENT_TARGET environment specifically to address this problem. -- Comment By: Edward Moy (edwardmoy) Date: 2005-03-10 08:34 Message: Logged In: YES user_id=1233904 OK, looks like my problem was with 2.3.4, so I made that patch. Now that 2.3.5 is out, I didn't notice that this patch doesn't seem to be necessary anymore. Sorry for wasting your time. -- Comment By: Martin v. Löwis (loewis) Date: 2005-03-10 00:58 Message: Logged In: YES user_id=21627 Can you find out where it does pick it up *from*, please? Search the distutils and config directories of Python, and the wxWindows directories for clues; also print your env. -- Comment By: Edward Moy (edwardmoy) Date: 2005-03-10 00:22 Message: Logged In: YES user_id=1233904 I don't know the internal of python all that well, but I know that python (and perl as well) use "env MACOSX_DEPLOYMENT_TARGET=10.3 cc" as the link command, because this environment variable is required to enable the dynamic lookup symbol resolution feature in the linker (used with two-level namespaces). This is all rather Mac OS X specific, but I'm assuming since the python distributed with Mac OS X does this, that wxWidgets is picking that up and doing the same thing, as it should. -- Comment By: Martin v. Löwis (loewis) Date: 2005-03-10 00:03 Message: Logged In: YES user_id=21627 Hmm. Where does the "env MACOSX_DEPLOYMENT_TARGET" come from? I cannot find it in the Python build process or distutils. So if it is in the wxPython setup.py, it sure must be a bug in that setup.py, no? -- Comment By: Edward Moy (edwardmoy) Date: 2005-03-09 22:42 Message: Logged In: YES user_id=1233904 I was trying to build wxPython on Mac OS X. Without the change, it would compile all .c files, then when it tried to link, it would execute a command that looked like: g++ MACOSX_DEPLOYMENT_TARGET=10.3 c++ ... and fail. This is because it overwrote "env" with "g++". It needs to skip the env and its arguments, and replace (in this case) the c++. -- Comment By: Martin v. Löwis (loewis) Date: 2005-03-08 16:08 Message: Logged In: YES user_id=21627 Can you please give a specific example of what you did, what you expected to happen, and what happened instead (precise error messages, etc)? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158005&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-1163139 ] expm1 and log1p
Feature Requests item #1163139, was opened at 2005-03-14 17:24 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=1163139&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Keith Briggs (kbriggs) Assigned to: Nobody/Anonymous (nobody) Summary: expm1 and log1p Initial Comment: Could we please have expm1 and log1p interfaced in the math module (where these exist in libm)? These are essential for any serious mathematical applications. lgamma would be nice too. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1163139&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-1163139 ] expm1 and log1p
Feature Requests item #1163139, was opened at 2005-03-14 12:24 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1163139&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Keith Briggs (kbriggs) Assigned to: Nobody/Anonymous (nobody) Summary: expm1 and log1p Initial Comment: Could we please have expm1 and log1p interfaced in the math module (where these exist in libm)? These are essential for any serious mathematical applications. lgamma would be nice too. -- >Comment By: Tim Peters (tim_one) Date: 2005-03-14 12:39 Message: Logged In: YES user_id=31435 Hard one, since none of those functions are required by the C89 standard, Python doesn't require more than C89, and the math module overwhelmingly consists of thin wrappers around the platform C's implementations. When C99 is universally available, then it will be easy. Before then, someone would have to volunteer non-trivial work (for example, Microsoft's C runtime doesn't supply any of these -- it's a x-platform mess). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1163139&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-1163139 ] expm1 and log1p
Feature Requests item #1163139, was opened at 2005-03-14 17:24 Message generated for change (Comment added) made by kbriggs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1163139&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Keith Briggs (kbriggs) Assigned to: Nobody/Anonymous (nobody) Summary: expm1 and log1p Initial Comment: Could we please have expm1 and log1p interfaced in the math module (where these exist in libm)? These are essential for any serious mathematical applications. lgamma would be nice too. -- >Comment By: Keith Briggs (kbriggs) Date: 2005-03-14 17:59 Message: Logged In: YES user_id=888261 Is there an objection in principle to including something in the math module only if it is found in the system's libm? If so, a solution would be to use a C implementation of expm1 when it is not already supplied, for example from fdlibm: http://www.netlib.org/fdlibm/ -- Comment By: Tim Peters (tim_one) Date: 2005-03-14 17:39 Message: Logged In: YES user_id=31435 Hard one, since none of those functions are required by the C89 standard, Python doesn't require more than C89, and the math module overwhelmingly consists of thin wrappers around the platform C's implementations. When C99 is universally available, then it will be easy. Before then, someone would have to volunteer non-trivial work (for example, Microsoft's C runtime doesn't supply any of these -- it's a x-platform mess). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1163139&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-1163139 ] expm1 and log1p
Feature Requests item #1163139, was opened at 2005-03-14 12:24 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1163139&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Keith Briggs (kbriggs) Assigned to: Nobody/Anonymous (nobody) Summary: expm1 and log1p Initial Comment: Could we please have expm1 and log1p interfaced in the math module (where these exist in libm)? These are essential for any serious mathematical applications. lgamma would be nice too. -- >Comment By: Tim Peters (tim_one) Date: 2005-03-14 13:20 Message: Logged In: YES user_id=31435 Python code intends to be portable, and the math module hasn't yet included any platform-specific functions. I used to write math libraries for a living, so I know about netlib . If that's the intended approach to portability , it still needs someone to volunteer to do all the non-trivial coding, testing, doc, license-hassling, and x-platform config work. Won't be me because I can't make time for it. Note that you could easily write an extension module exposing these functions on _your_ platform (assuming your platform C supplies them). -- Comment By: Keith Briggs (kbriggs) Date: 2005-03-14 12:59 Message: Logged In: YES user_id=888261 Is there an objection in principle to including something in the math module only if it is found in the system's libm? If so, a solution would be to use a C implementation of expm1 when it is not already supplied, for example from fdlibm: http://www.netlib.org/fdlibm/ -- Comment By: Tim Peters (tim_one) Date: 2005-03-14 12:39 Message: Logged In: YES user_id=31435 Hard one, since none of those functions are required by the C89 standard, Python doesn't require more than C89, and the math module overwhelmingly consists of thin wrappers around the platform C's implementations. When C99 is universally available, then it will be easy. Before then, someone would have to volunteer non-trivial work (for example, Microsoft's C runtime doesn't supply any of these -- it's a x-platform mess). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1163139&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1163178 ] IDNA StreamReader broken
Bugs item #1163178, was opened at 2005-03-14 19:38
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=1163178&group_id=5470
Category: Unicode
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
Assigned to: Martin v. Löwis (loewis)
Summary: IDNA StreamReader broken
Initial Comment:
It seems that the IDNA StreamReader is broken (this
problem occurs both in Python 2.3.4 and Python 2.4):
>>> import codecs, cStringIO
>>> r =
codecs.getreader("idna")(cStringIO.StringIO("abc"))
>>> r.read(1)
u'a'
>>> r.read(1)
u'b'
>>> r.read(1)
u'c'
>>> r.read(1)
u'.'
>>> r.read(1)
u'.'
I would have expected that read(1) returns u"" after
the third call.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163178&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-1154351 ] add get_current_dir_name() to os module
Feature Requests item #1154351, was opened at 2005-03-01 17:26 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1154351&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hoffman (hoffmanm) Assigned to: Nobody/Anonymous (nobody) Summary: add get_current_dir_name() to os module Initial Comment: os.getcwd() does not use the contents of the PWD environment variable, much as the glibc getcwd() does not. This means that if a user sets the path using a symbolic link, it will be dereferenced before being passed by os.getcwd(). I propose that get_current_dir_name() be added, either as a call to the glibc get_current_dir_name(), which uses the PWD environment variable and therefore will not dereference symbolic links in the path, or as a fallback to this Pure Python function: def get_current_dir_name(): cwd = os.getcwd() try: pwd = os.environ["PWD"] except KeyError: return cwd cwd_stat, pwd_stat = map(os.stat, [cwd, pwd]) if cwd_stat.st_dev == pwd_stat.st_dev and cwd_stat.st_ino == pwd_stat.st_ino: return pwd else: return cwd -- >Comment By: Martin v. Löwis (loewis) Date: 2005-03-14 20:17 Message: Logged In: YES user_id=21627 Equalling get_current_dir_name and getcwd for non-POSIX systems seems like a conservative approach, so I'm for it. Alternatively, one might think that PWD won't be set on non-POSIX systems. -- Comment By: Michael Hoffman (hoffmanm) Date: 2005-03-14 10:03 Message: Logged In: YES user_id=987664 Thanks for your comments. I agree that a better description of the difference here is necessary. I just checked the glibc source and this is almost exactly what it does. It actually does an os.stat on "." and only calls __getcwd() if necessary. It's in glibc-2.3.4/io/getdirname.c if you're curious. I'll make that change and add the patch to my list of things to do... Since st_dev and st_ino don't work outside Posix, should I just return os.getcwd() on other platforms? -- Comment By: Martin v. Löwis (loewis) Date: 2005-03-14 00:00 Message: Logged In: YES user_id=21627 I was going to say "what is the advantage of using the PWD variable?", but, thinking about it three times, I found that it gives you what the user typed in the last cd(1), independent of symbolic links. So even though you wrote what it does, and how it differs from getcwd, its not at all obvious that this is a good thing (even though I now agree it is a good thing) Would you like to work on a patch? A pure Python implementation sounds reasonable, if your code is what glibc does as well. It seems to me that the documentation patch is really crucial here, or else users will wonder "what the heck...". -- Comment By: Michael Hoffman (hoffmanm) Date: 2005-03-01 17:27 Message: Logged In: YES user_id=987664 Hmmm... my indentation seems to have gone by the wayside. Still you can probably figure out what the code is supposed to do -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1154351&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1156259 ] [2.4 regression] seeking in codecs.reader broken
Bugs item #1156259, was opened at 2005-03-03 23:29
Message generated for change (Comment added) made by doerwalter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156259&group_id=5470
Category: Extension Modules
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Matthias Klose (doko)
Assigned to: Walter Dörwald (doerwalter)
Summary: [2.4 regression] seeking in codecs.reader broken
Initial Comment:
[forwarded from
https://bugzilla.ubuntu.com/show_bug.cgi?id=6972 ]
This is a regression; the following script (call as
"scriptname some_textfile")
fails.
It is obvious that the file starts with a number of
random bytes from the
previous run.
Uncommenting the two #XXX lines makes the bug go away.
So does running it with
Python 2.3.5
import sys
import codecs
from random import random
data = codecs.getreader("utf-8")(open(sys.argv[1]))
df = data.read()
for t in range(30):
#XXX data.seek(0,1)
#XXX data.read()
data.seek(0,0)
dn=""
for l in data:
dn += l
if random() < 0.1: break
if not df.startswith(dn):
print "OUCH",t
print "BAD:", dn[0:100]
print "GOOD:", df[0:100]
sys.exit(1)
print "OK",len(df)
sys.exit(0)
--
>Comment By: Walter Dörwald (doerwalter)
Date: 2005-03-14 20:22
Message:
Logged In: YES
user_id=89016
Checked in as:
Lib/codecs.py 1.39
Lib/encodings/utf_16.py 1.6
Lib/test/test_codecs.py 1.21
I've also added a reset() method to the UTF-16 reader that
resets the decode method as well as a test in test_codecs.py.
Backported to release24-maint as:
Lib/codecs.py 1.35.2.4
Lib/encodings/utf_16.py 1.5.2.1
Lib/test/test_codecs.py 1.15.2.3
(Here the test is implemented differently, because the 2.4
branch doesn't have a BasicUnicodeTest test case in
test_codecs.py)
--
Comment By: Matthias Klose (doko)
Date: 2005-03-14 12:02
Message:
Logged In: YES
user_id=60903
added doc string
--
Comment By: Walter Dörwald (doerwalter)
Date: 2005-03-08 15:40
Message:
Logged In: YES
user_id=89016
OK, I'll check in the patch at the beginning of next week
(I'm currently away from CVS).
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2005-03-08 15:00
Message:
Logged In: YES
user_id=38388
Walter: the patch looks good. Please also add a doc-string
mentioning the resetting of the codec in case .seek() is used.
Whether .seek() causes a mess or not is not within the
responsibility of the codec - it's an application space
decision to make, otherwise we would have to introduce the
notion of seeking code points (rather than bytes) which I'd
rather not like to do since this can break existing
applications in many ways.
--
Comment By: Matthias Urlichs (smurf)
Date: 2005-03-08 14:20
Message:
Logged In: YES
user_id=10327
Ahem -- seek(0,*whatever*) should still be allowed, whatever
else you do, please.
Reading UTF-16 from an odd position in a file isn't always
an error -- sometimes text is embedded in weird on-disk data
structures. As long as tell() returns something you can
seek() back to, nobody's got a right to complain -- file
position arithmetic in general is nonportable.
--
Comment By: Walter Dörwald (doerwalter)
Date: 2005-03-04 12:44
Message:
Logged In: YES
user_id=89016
How about the following patch? Unfortunately this breaks the
codec in more obscure cases. Calling seek(0, 1) should have
now effect, but with this patch it does. Maybe calling
seek() should be prohibited? Calling a seek(1, 1) in a
UTF-16 stream completely messes up the decoded text.
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2005-03-04 10:56
Message:
Logged In: YES
user_id=38388
This is obviously related to the buffer logic that Walter added
to support .readline().
In order to fix the problem, a .seek() method must be
implemented
that resets the buffers whenever called (before asking the
stream
to seek to the specified stream position).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156259&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-1154351 ] add get_current_dir_name() to os module
Feature Requests item #1154351, was opened at 2005-03-01 16:26 Message generated for change (Comment added) made by hoffmanm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1154351&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hoffman (hoffmanm) Assigned to: Nobody/Anonymous (nobody) Summary: add get_current_dir_name() to os module Initial Comment: os.getcwd() does not use the contents of the PWD environment variable, much as the glibc getcwd() does not. This means that if a user sets the path using a symbolic link, it will be dereferenced before being passed by os.getcwd(). I propose that get_current_dir_name() be added, either as a call to the glibc get_current_dir_name(), which uses the PWD environment variable and therefore will not dereference symbolic links in the path, or as a fallback to this Pure Python function: def get_current_dir_name(): cwd = os.getcwd() try: pwd = os.environ["PWD"] except KeyError: return cwd cwd_stat, pwd_stat = map(os.stat, [cwd, pwd]) if cwd_stat.st_dev == pwd_stat.st_dev and cwd_stat.st_ino == pwd_stat.st_ino: return pwd else: return cwd -- >Comment By: Michael Hoffman (hoffmanm) Date: 2005-03-14 19:45 Message: Logged In: YES user_id=987664 It might if they were using a ported UNIX shell. But I think trusting PWD without checking it is a Bad Thing. -- Comment By: Martin v. Löwis (loewis) Date: 2005-03-14 19:17 Message: Logged In: YES user_id=21627 Equalling get_current_dir_name and getcwd for non-POSIX systems seems like a conservative approach, so I'm for it. Alternatively, one might think that PWD won't be set on non-POSIX systems. -- Comment By: Michael Hoffman (hoffmanm) Date: 2005-03-14 09:03 Message: Logged In: YES user_id=987664 Thanks for your comments. I agree that a better description of the difference here is necessary. I just checked the glibc source and this is almost exactly what it does. It actually does an os.stat on "." and only calls __getcwd() if necessary. It's in glibc-2.3.4/io/getdirname.c if you're curious. I'll make that change and add the patch to my list of things to do... Since st_dev and st_ino don't work outside Posix, should I just return os.getcwd() on other platforms? -- Comment By: Martin v. Löwis (loewis) Date: 2005-03-13 23:00 Message: Logged In: YES user_id=21627 I was going to say "what is the advantage of using the PWD variable?", but, thinking about it three times, I found that it gives you what the user typed in the last cd(1), independent of symbolic links. So even though you wrote what it does, and how it differs from getcwd, its not at all obvious that this is a good thing (even though I now agree it is a good thing) Would you like to work on a patch? A pure Python implementation sounds reasonable, if your code is what glibc does as well. It seems to me that the documentation patch is really crucial here, or else users will wonder "what the heck...". -- Comment By: Michael Hoffman (hoffmanm) Date: 2005-03-01 16:27 Message: Logged In: YES user_id=987664 Hmmm... my indentation seems to have gone by the wayside. Still you can probably figure out what the code is supposed to do -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1154351&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-1155485 ] file() on a file
Feature Requests item #1155485, was opened at 2005-03-02 23:48 Message generated for change (Comment added) made by felixlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1155485&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Felix Lee (felixlee) Assigned to: Nobody/Anonymous (nobody) Summary: file() on a file Initial Comment: it would be nice if file(f) worked when f is already a file, either by returning f or by constructing a new file that refers to the same thing. that would make it easy to write functions that can take either a file or a filename as an argument, like so: def p(f): print list(file(f)) which is kind of like using int() as a cast operation. -- >Comment By: Felix Lee (felixlee) Date: 2005-03-14 20:47 Message: Logged In: YES user_id=77867 that argument also works against str() and list(). it's not obvious whether str(s) and list(v) should return itself, a proxy, or a copy, and they're all useful in different situations. I don't think anyone would argue that the ambiguity means those should be undefined. I think file(f) is similar. it has a few more issues because files are special, but I think picking a reasonable behavior for file(f) would simplify some programming. returning a dup is probably the least surprising in most situations, because of f.close(). -- Comment By: Martin v. Löwis (loewis) Date: 2005-03-13 22:53 Message: Logged In: YES user_id=21627 It's not at all obvious what this should do. Three alternatives come to mind: 1. return f 2. return a wrapper object which delegates all calls 3. return a new file object, which is dup(2)'ed from the original one. Either of them might be meaningful in some context, and they are mutually incompatible. In the face of ambiguity, refuse the temptation to guess, so I'm -1. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1155485&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1163244 ] Syntax error on large file with MBCS encoding
Bugs item #1163244, was opened at 2005-03-14 21:20 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=1163244&group_id=5470 Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tim N. van der Leeuw (tnleeuw) Assigned to: Nobody/Anonymous (nobody) Summary: Syntax error on large file with MBCS encoding Initial Comment: Large files generated by make-py.py from the win32all extensions cannot be compiled by Python2.4.1rc1 - they give a syntax error. This is a regression from 2.3.5 (With Python2.4, the interpreter crashes. That is fixed now.) Removing the mbcs encoding line from the top of the file, compilation succeeds. File should be attached, as zip-file. Probably requires win32all extensions to be installed to be compiled / imported (generated using build 203 of the win32all extensions). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163244&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-978632 ] configure and gmake fail in openbsd 3.5 i386
Bugs item #978632, was opened at 2004-06-24 02:16 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=978632&group_id=5470 Category: Installation Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: - (panterrap) Assigned to: Nobody/Anonymous (nobody) Summary: configure and gmake fail in openbsd 3.5 i386 Initial Comment: Problem with compiler of python-2.3.4 in OpenBSD 3.5 i386 # ./configure --prefix=/usr/local/python-2.3.4 --with-cxx=/usr/bin/gcc 4 warnings sections in configure configure: WARNING: ncurses.h: present but cannot be compiled configure: WARNING: ncurses.h: check for missing prerequisite headers? configure: WARNING: ncurses.h: proceeding with the preprocessor's result configure: WARNING: ## ## configure: WARNING: ## Report this to [EMAIL PROTECTED] ## configure: WARNING: ## ## - configure: WARNING: sys/audioio.h: present but cannot be compiled configure: WARNING: sys/audioio.h: check for missing prerequisite headers? configure: WARNING: sys/audioio.h: proceeding with the preprocessor's result configure: WARNING: ## ## configure: WARNING: ## Report this to [EMAIL PROTECTED] ## configure: WARNING: ## ## -- configure: WARNING: sys/lock.h: present but cannot be compiled configure: WARNING: sys/lock.h: check for missing prerequisite headers? configure: WARNING: sys/lock.h: proceeding with the preprocessor's result configure: WARNING: ## ## configure: WARNING: ## Report this to [EMAIL PROTECTED] ## configure: WARNING: ## ## -- configure: WARNING: sys/select.h: present but cannot be compiled configure: WARNING: sys/select.h: check for missing prerequisite headers? configure: WARNING: sys/select.h: proceeding with the preprocessor's result configure: WARNING: ## ## configure: WARNING: ## Report this to [EMAIL PROTECTED] ## configure: WARNING: ## ## --- my compilation in this platform # gmake /usr/bin/gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Modules/ccpython.o ./Modules/ccpython.cc In file included from /usr/include/sys/select.h:38, from Include/pyport.h:118, from Include/Python.h:48, from ./Modules/ccpython.cc:3: /usr/include/sys/event.h:53: syntax error before `;' /usr/include/sys/event.h:55: syntax error before `;' gmake: *** [Modules/ccpython.o] Error 1 - P.D.: Python-2.2.3 in this platform ok -- >Comment By: Martin v. Löwis (loewis) Date: 2005-03-14 21:54 Message: Logged In: YES user_id=21627 Closed because of lack of activity. -- Comment By: Martin v. Löwis (loewis) Date: 2004-06-27 23:03 Message: Logged In: YES user_id=21627 Can you please analyse the problem in more detail, and suggest a patch? If not, can you please attach the config.log that you got when running configure? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=978632&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-1155485 ] file() on a file
Feature Requests item #1155485, was opened at 2005-03-03 00:48 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1155485&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Felix Lee (felixlee) Assigned to: Nobody/Anonymous (nobody) Summary: file() on a file Initial Comment: it would be nice if file(f) worked when f is already a file, either by returning f or by constructing a new file that refers to the same thing. that would make it easy to write functions that can take either a file or a filename as an argument, like so: def p(f): print list(file(f)) which is kind of like using int() as a cast operation. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-03-14 22:20 Message: Logged In: YES user_id=21627 The same argument can *not* be made for strings, since strings are immutable, so it does not matter whether you get the original thing or a copy. Also, str(x) invokes x's __str__ conversion. For lists, the argument is also different: list(x) requires an iterable object and creates a list out of it. The notion of an iterable object is well-defined, and if you pass something that is not iterable, you get a TypeError. For files, this is entirely different. file() does not take one argument, but three (and two of them are optional). The first (mandatory) argument is a "filename". It might be debatable what precisely a file name is, and indeed you can pass both byte strings and unicode strings. A file, most certainly, is *not* a filename, and there is no notion of "converting to a file" in Python (e.g. by means of __file__). This just isn't a useful generalization. -- Comment By: Felix Lee (felixlee) Date: 2005-03-14 21:47 Message: Logged In: YES user_id=77867 that argument also works against str() and list(). it's not obvious whether str(s) and list(v) should return itself, a proxy, or a copy, and they're all useful in different situations. I don't think anyone would argue that the ambiguity means those should be undefined. I think file(f) is similar. it has a few more issues because files are special, but I think picking a reasonable behavior for file(f) would simplify some programming. returning a dup is probably the least surprising in most situations, because of f.close(). -- Comment By: Martin v. Löwis (loewis) Date: 2005-03-13 23:53 Message: Logged In: YES user_id=21627 It's not at all obvious what this should do. Three alternatives come to mind: 1. return f 2. return a wrapper object which delegates all calls 3. return a new file object, which is dup(2)'ed from the original one. Either of them might be meaningful in some context, and they are mutually incompatible. In the face of ambiguity, refuse the temptation to guess, so I'm -1. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1155485&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1160534 ] Autoconf failure on FreeBSD 5.3, and AC_INIT set incorrectly
Bugs item #1160534, was opened at 2005-03-10 11:19 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160534&group_id=5470 Category: Build >Group: 3rd Party >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Richard Brooksby (rptb1) Assigned to: Nobody/Anonymous (nobody) Summary: Autoconf failure on FreeBSD 5.3, and AC_INIT set incorrectly Initial Comment: Begin forwarded message: Date: 8 March 2005 18:20:48 GMT To: bug-autoconf@gnu.org Subject: Autoconf asked me to tell you about this bug On a clean FreeBSD 5.3 machine, do: cd /usr/local/lang/python make install and you will see, amongst other things: checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking ncurses.h usability... no checking ncurses.h presence... yes configure: WARNING: ncurses.h: present but cannot be compiled configure: WARNING: ncurses.h: check for missing prerequisite headers? configure: WARNING: ncurses.h: proceeding with the preprocessor's result configure: WARNING: ## ## configure: WARNING: ## Report this to [EMAIL PROTECTED] ## configure: WARNING: ## ## checking for ncurses.h... yes checking poll.h usability... yes checking poll.h presence... yes checking for poll.h... yes checking pthread.h usability... yes checking pthread.h presence... yes checking for pthread.h... yes --- Begin forwarded message: Date: 9 March 2005 11:47:03 GMT To: Richard Brooksby <[EMAIL PROTECTED]> Cc: bug-autoconf@gnu.org Subject: Re: Autoconf asked me to tell you about this bug Hello, On Tue, Mar 08, 2005 at 06:20:48PM +, Richard Brooksby wrote: On a clean FreeBSD 5.3 machine, do: cd /usr/local/lang/python you should report this bug to the bug report address of the "python" project. Tell them to read the section "Present But Cannot Be Compiled" of the manual to autoconf-2.59. They have misconfigured the bug report address in AC_INIT, so also tell them to change it to *their* bug report address. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-03-14 22:34 Message: Logged In: YES user_id=21627 Thanks for the report! Looking at the file, I see In file included from configure:4766: /usr/include/ncurses.h:289: error: conflicting types for 'wchar_t' /usr/include/stdlib.h:58: error: previous declaration of 'wchar_t' was here So it looks like your system has conflicting definitions of wchar_t, one in ncurses.h, and one in stdlib.h. I thought I had seen this before, but I cannot find a resolution. You might want to report this to the FreeBSD people. As for the autoconf manual hint: they propose to perform further includes to make the header compilable. However, since the header is truly broken, this is no solution. As for the hint to change the bug reporting address: I have now done this, and committed this change as configure.in 1.475.2.7 configure 1.462.2.7 configure.in 1.483 configure 1.470 Closing the report as fixed, 3rd party. -- Comment By: Richard Brooksby (rptb1) Date: 2005-03-14 11:41 Message: Logged In: YES user_id=927536 Sorry if the text isn't helpful -- I'm just following instructions. Please find config.log attached. -- Comment By: Martin v. Löwis (loewis) Date: 2005-03-12 23:36 Message: Logged In: YES user_id=21627 That information does not help to resolve the problem, and it is not clear that it is a problem in Python's configure - it could be a bug in your operating system installation also. Please attach the config.log. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160534&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1162677 ] Unable to Install Python 2.4.1rc1 on windows XP SP2
Bugs item #1162677, was opened at 2005-03-14 01:32 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162677&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sergio Correia (sergiocorreia) Assigned to: Nobody/Anonymous (nobody) Summary: Unable to Install Python 2.4.1rc1 on windows XP SP2 Initial Comment: First of all, YES i had everything i needed to install, and yes i read the info on the site. When i tried to install python-2.4.1c1.msi (or even ActivePython-2.4.0-244-win32-ix86.msi), install "ended prematurely because of an error". I tried everything but, after a while i found a way to avoid the bug. I was installing from "F:\Docs\Varios\Sandbox".. i moved the msi file to C:\ and then the install (both, python and activepython) worked out perfectly. Folders were not shared, restricted, compressed or on a network (it was a normal local hard disk). Any ideas on why that happened? Thanks PS: Sorry about the sp. mistakes. I am not very fluent on technical english. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-03-14 22:36 Message: Logged In: YES user_id=21627 No, but I know how to find out. Please run, in a cmd.exe window, msiexec /i python-2.4.1c1.msi /l*v python.log Compress python.log with Winzip, and attach the resulting file to this report. As a wild guess: could it be that F: is SUBSTed? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162677&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1066546 ] test_pwd fails on 64bit system (Opteron)
Bugs item #1066546, was opened at 2004-11-15 10:34
Message generated for change (Comment added) made by doerwalter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1066546&group_id=5470
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_pwd fails on 64bit system (Opteron)
Initial Comment:
test test_pwd failed -- Traceback (most recent call last):
File "/tmp/miki/Python-2.4b2/Lib/test/test_pwd.py",
line 42, in test_values
self.assert_(pwd.getpwuid(e.pw_uid) in
entriesbyuid[e.pw_uid])
OverflowError: signed integer is greater than maximum
$ cat /proc/version
Linux version 2.4.21-20.ELsmp
([EMAIL PROTECTED]) (gcc version 3.2.3
20030502 (Red Hat Linux 3.2.3-42)) #1 SMP Wed Aug 18
20:34:58 EDT 2004
Processor is AMD Opteron 2.4MHz
--
>Comment By: Walter Dörwald (doerwalter)
Date: 2005-03-14 23:17
Message:
Logged In: YES
user_id=89016
On a 32bit system adding the line
nobody:x:4294967294:65534:nobody:/:/bin/false
to /etc/passwd pwd.getpwall() gives me an entry:
('nobody', 'x', -2, 65534, 'nobody', '/', '/bin/false')
and
pwd.getpwuid(-2)
gives me
('nobody', 'x', -2, 65534, 'nobody', '/', '/bin/false')
Maybe for 64bit systems the SETI macro should use
PyLong_FromUnsignedLong() instead of PyInt_FromLong()? Can
you try the following patch?
--
Comment By: Miki Tebeka (tebeka)
Date: 2004-11-17 09:43
Message:
Logged In: YES
user_id=358087
1. How do I find the largest user id?
2. It's 4294967294
3. Can't attach etc/password since it's a company machine
(IT will kill me :-)
However there is a similar line for nobody with 65534
The hardware is 4 CPU with 16GB of memory.
OS is: Red Hat Enterprise Linux AS release 3 (Taroon Update 3)
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2004-11-17 02:58
Message:
Logged In: YES
user_id=33168
I just tested this on an opteron and it ran ok, so this
problem isn't necessarily opteron/64-bit specific. What is
the largest user id on the system? What is the value of
pw_uid that is causing a problem? Can you attach your
/etc/passwd file? If so, you may want to change any user info.
I have:
nobody:x:65534:65534:nobody:/:/bin/false
I tried adding another nobody with a larger uid, but did not
have any problems with the test. This is on a gentoo system.
--
Comment By: Miki Tebeka (tebeka)
Date: 2004-11-15 10:36
Message:
Logged In: YES
user_id=358087
Ran with -v:
$ ./python Lib/test/test_pwd.py -v
test_errors (__main__.PwdTest) ... ok
test_values (__main__.PwdTest) ... ERROR
==
ERROR: test_values (__main__.PwdTest)
--
Traceback (most recent call last):
File "Lib/test/test_pwd.py", line 42, in test_values
self.assert_(pwd.getpwuid(e.pw_uid) in
entriesbyuid[e.pw_uid])
OverflowError: signed integer is greater than maximum
--
Ran 2 tests in 0.480s
FAILED (errors=1)
Traceback (most recent call last):
File "Lib/test/test_pwd.py", line 92, in ?
test_main()
File "Lib/test/test_pwd.py", line 89, in test_main
test_support.run_unittest(PwdTest)
File "/tmp/miki/Python-2.4b2/Lib/test/test_support.py",
line 290, in run_unitt
est
run_suite(suite, testclass)
File "/tmp/miki/Python-2.4b2/Lib/test/test_support.py",
line 275, in run_suite
raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
File "Lib/test/test_pwd.py", line 42, in test_values
self.assert_(pwd.getpwuid(e.pw_uid) in
entriesbyuid[e.pw_uid])
OverflowError: signed integer is greater than maximum
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1066546&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1163325 ] "special" decimals aren't hashable
Bugs item #1163325, was opened at 2005-03-14 22: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=1163325&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Marien Zwart (marienz) Assigned to: Nobody/Anonymous (nobody) Summary: "special" decimals aren't hashable Initial Comment: Python 2.4 (#1, Feb 22 2005, 15:02:34) [GCC 3.4.3-20050110 (Gentoo Linux 3.4.3.20050110, ssp-3.4.3.20050110-0, pie-8.7 on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import decimal >>> hash(decimal.NaN) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/decimal.py", line 720, in __hash__ i = int(self) File "/usr/lib/python2.4/decimal.py", line 1410, in __int__ return context._raise_error(InvalidContext) File "/usr/lib/python2.4/decimal.py", line 2215, in _raise_error raise error, explanation decimal.InvalidOperation This behaviour doesn't match the comment in decimal.py's __hash__: # Decimal integers must hash the same as the ints # Non-integer decimals are normalized and hashed as strings # Normalization assures that hast(100E-1) == hash(10) Would it make sense to wrap the int(self) in an except block and return hash(str(self.normalize())) if this raises? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163325&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1163325 ] "special" decimals aren't hashable
Bugs item #1163325, was opened at 2005-03-14 17:37 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163325&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Marien Zwart (marienz) >Assigned to: Tim Peters (tim_one) Summary: "special" decimals aren't hashable Initial Comment: Python 2.4 (#1, Feb 22 2005, 15:02:34) [GCC 3.4.3-20050110 (Gentoo Linux 3.4.3.20050110, ssp-3.4.3.20050110-0, pie-8.7 on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import decimal >>> hash(decimal.NaN) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/decimal.py", line 720, in __hash__ i = int(self) File "/usr/lib/python2.4/decimal.py", line 1410, in __int__ return context._raise_error(InvalidContext) File "/usr/lib/python2.4/decimal.py", line 2215, in _raise_error raise error, explanation decimal.InvalidOperation This behaviour doesn't match the comment in decimal.py's __hash__: # Decimal integers must hash the same as the ints # Non-integer decimals are normalized and hashed as strings # Normalization assures that hast(100E-1) == hash(10) Would it make sense to wrap the int(self) in an except block and return hash(str(self.normalize())) if this raises? -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-03-14 17:42 Message: Logged In: YES user_id=80475 Since two NaNs are never equal to one another, I would think that it doesn't make sense to hash them. Tim, do you have another thoughts on the subject? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163325&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1105699 ] Warnings in Python.h with gcc 4.0.0
Bugs item #1105699, was opened at 2005-01-19 19:52 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105699&group_id=5470 Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: Warnings in Python.h with gcc 4.0.0 Initial Comment: (this happens for every file that includes Python.h) In file included from ../Include/Python.h:55, from ../Objects/intobject.c:4: ../Include/pyport.h:396: warning: 'struct winsize' declared inside parameter list ../Include/pyport.h:397: warning: 'struct winsize' declared inside parameter list The source lines look like this: extern int openpty(int *, int *, char *, struct termios *, struct winsize *); extern int forkpty(int *, char *, struct termios *, struct winsize *); -- >Comment By: Bob Ippolito (etrepum) Date: 2005-03-14 17:52 Message: Logged In: YES user_id=139309 Turns out that this is a GCC4 bug (not sure which, though). The OS headers are fine. -- Comment By: Martin v. Löwis (loewis) Date: 2005-03-04 15:15 Message: Logged In: YES user_id=21627 What operating system is this on? struct winsize should have been included through . Then, the mentioning of it in the propotypes is not a declaration, just a reference. So if you get this warning, it probably indicates a problem with your system headers. -- Comment By: Richard Kettlewell (rjk1002) Date: 2005-01-31 10:43 Message: Logged In: YES user_id=217390 C does guarantee that all struct pointers share the same *representation* (section 6.2.5 of C99). That's not what the compiler is complaining about here. Rather, a struct declared inside a parameter list is restricted in scope to that parameter list, and so is not the same structure as one declared outside it, even if the tag is the same. The solution is to forward-declare the struct (as an incomplete type, i.e. just "struct winsize;") before any of the declarations that use it. Then the struct tag will mean the same thing in every scope. -- Comment By: Tim Peters (tim_one) Date: 2005-01-20 18:13 Message: Logged In: YES user_id=31435 The warning almost certainly means that there's no declaration of struct winsize in scope when these externs are declared. That's bad, because C doesn't guarantee that all pointers are the same size (although they are on all Python platforms I'm aware of). Some quality time with Google suggested that other projects wormed around this by #include'ing instead of , because the former but not the latter #include's where the winsize struct was defined. Beats me -- ain't a Windows problem . -- Comment By: Bob Ippolito (etrepum) Date: 2005-01-20 17:49 Message: Logged In: YES user_id=139309 Beats me, it's probably just "bad style". It's a problem because it shows up a lot in the output, so we should at least figure out how to disable this warning so that it doesn't become annoying. -- Comment By: Michael Hudson (mwh) Date: 2005-01-20 10:18 Message: Logged In: YES user_id=6656 Why is this a problem? Is it not valid C or something? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105699&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1163367 ] correct/clarify documentation for super
Bugs item #1163367, was opened at 2005-03-14 16:39 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=1163367&group_id=5470 Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: correct/clarify documentation for super Initial Comment: The current documentation for super is confusing. For instance, it says that it returns "the superclass of type" which is incorrect; it actually returns the next type in type's MRO. Well, to be truthful, it doesn't even do that; it returns a proxy object which makes that type's attributes available, but that's just another reason to fix the documentation. I suggest changing the wording to something like: """super(type[, object-or-type]) Return an object that exposes the attributes available through the type's superclasses, without exposing the attributes of the type itself. Attributes will be looked up using the normal resolution order, omitting the first class in the MRO (that is, the type itself). If the second argument is present, it should either be an instance of object, in which case isinstance(object-or-type, type) must be true, or it should be an instance of type, in which case issubclass(object-or-type, type) must be true. The typical use for this form of super is to call a cooperative superclass method: class C(B): def meth(self, arg): super(C, self).meth(arg) If the second argument to super is omitted, the super object returned will not expose any attributes directly. However, attributes will be accessible whenever the descriptor machinery is invoked, e.g. though explicit invocation of __get__. Note that super is undefined for implicit lookups using statements or operators such as "super(C, self)[name]". These must be spelled out with their explicit lookup, e.g. "super(C, self).__getitem__(name)". New in version 2.2. """ It's not perfect and I welcome suggestions for re-wording, but I think it's substantially more accurate about what super actually does. It also moves the "second argument omitted" situation to the end, since this is a vastly more uncommon use case. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163367&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-1155485 ] file() on a file
Feature Requests item #1155485, was opened at 2005-03-02 18:48 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1155485&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Felix Lee (felixlee) Assigned to: Nobody/Anonymous (nobody) Summary: file() on a file Initial Comment: it would be nice if file(f) worked when f is already a file, either by returning f or by constructing a new file that refers to the same thing. that would make it easy to write functions that can take either a file or a filename as an argument, like so: def p(f): print list(file(f)) which is kind of like using int() as a cast operation. -- >Comment By: Tim Peters (tim_one) Date: 2005-03-14 19:00 Message: Logged In: YES user_id=31435 I'm also -1 on this -- I have no idea what would make sense when applying file() to a file object, or to a file-like object. Therefore anything it did in response would be surprising to me, except for raising an exception. -- Comment By: Martin v. Löwis (loewis) Date: 2005-03-14 16:20 Message: Logged In: YES user_id=21627 The same argument can *not* be made for strings, since strings are immutable, so it does not matter whether you get the original thing or a copy. Also, str(x) invokes x's __str__ conversion. For lists, the argument is also different: list(x) requires an iterable object and creates a list out of it. The notion of an iterable object is well-defined, and if you pass something that is not iterable, you get a TypeError. For files, this is entirely different. file() does not take one argument, but three (and two of them are optional). The first (mandatory) argument is a "filename". It might be debatable what precisely a file name is, and indeed you can pass both byte strings and unicode strings. A file, most certainly, is *not* a filename, and there is no notion of "converting to a file" in Python (e.g. by means of __file__). This just isn't a useful generalization. -- Comment By: Felix Lee (felixlee) Date: 2005-03-14 15:47 Message: Logged In: YES user_id=77867 that argument also works against str() and list(). it's not obvious whether str(s) and list(v) should return itself, a proxy, or a copy, and they're all useful in different situations. I don't think anyone would argue that the ambiguity means those should be undefined. I think file(f) is similar. it has a few more issues because files are special, but I think picking a reasonable behavior for file(f) would simplify some programming. returning a dup is probably the least surprising in most situations, because of f.close(). -- Comment By: Martin v. Löwis (loewis) Date: 2005-03-13 17:53 Message: Logged In: YES user_id=21627 It's not at all obvious what this should do. Three alternatives come to mind: 1. return f 2. return a wrapper object which delegates all calls 3. return a new file object, which is dup(2)'ed from the original one. Either of them might be meaningful in some context, and they are mutually incompatible. In the face of ambiguity, refuse the temptation to guess, so I'm -1. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1155485&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1163325 ] "special" decimals aren't hashable
Bugs item #1163325, was opened at 2005-03-14 17:37 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163325&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Marien Zwart (marienz) >Assigned to: Nobody/Anonymous (nobody) Summary: "special" decimals aren't hashable Initial Comment: Python 2.4 (#1, Feb 22 2005, 15:02:34) [GCC 3.4.3-20050110 (Gentoo Linux 3.4.3.20050110, ssp-3.4.3.20050110-0, pie-8.7 on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import decimal >>> hash(decimal.NaN) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/decimal.py", line 720, in __hash__ i = int(self) File "/usr/lib/python2.4/decimal.py", line 1410, in __int__ return context._raise_error(InvalidContext) File "/usr/lib/python2.4/decimal.py", line 2215, in _raise_error raise error, explanation decimal.InvalidOperation This behaviour doesn't match the comment in decimal.py's __hash__: # Decimal integers must hash the same as the ints # Non-integer decimals are normalized and hashed as strings # Normalization assures that hast(100E-1) == hash(10) Would it make sense to wrap the int(self) in an except block and return hash(str(self.normalize())) if this raises? -- >Comment By: Tim Peters (tim_one) Date: 2005-03-14 19:04 Message: Logged In: YES user_id=31435 Well, I'm not really a fan of Python's tying hashability to "usable as a dict key", but given that's what Python _does_, ya, hashing a NaN doesn't make sense. marienz, by "special" decimals did you mean only NaNs, or do you have other cases in mind too? -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-03-14 17:42 Message: Logged In: YES user_id=80475 Since two NaNs are never equal to one another, I would think that it doesn't make sense to hash them. Tim, do you have another thoughts on the subject? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163325&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1163401 ] uncaught AttributeError deep in urllib
Bugs item #1163401, was opened at 2005-03-14 16:39
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=1163401&group_id=5470
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: K Lars Lohn (lohnk)
Assigned to: Nobody/Anonymous (nobody)
Summary: uncaught AttributeError deep in urllib
Initial Comment:
Python 2.4 and Python 2.3.4 running under Suse 9.2
We're getting an AttributeError exception "AttributeError: 'NoneType' object
has no attribute 'read'" within a very simple call to urllib.urlopen.
This was discovered while working on Sentry 2, the new mirror integrity checker
for the Mozilla project. We try to touch hundreds of URLs to make sure that
the files are present on each of the mirrors. One particular URL kills the
call to urllib.urlopen:
http://mozilla.mirrors.skynet.be/pub/ftp.mozilla.org/firefox/releases/1.0/win32/en-US/Firefox%20Setup%201.0.exe
This file probably does not exist on the mirror, however, in other cases of bad
URLs, we get much more graceful failures when we try to read from the object
returned by urllib.urlopen.
>>> import urllib
>>> urlReader =
>>> urllib.urlopen("http://mozilla.mirrors.skynet.be/pub/ftp.mozilla.org/firefox/releases/1.0/win32/en-US/Firefox%20Setup%201.0.exe";)
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/local/lib/python2.4/urllib.py", line 77, in urlopen
return opener.open(url)
File "/usr/local/lib/python2.4/urllib.py", line 180, in open
return getattr(self, name)(url)
File "/usr/local/lib/python2.4/urllib.py", line 305, in open_http
return self.http_error(url, fp, errcode, errmsg, headers)
File "/usr/local/lib/python2.4/urllib.py", line 322, in http_error
return self.http_error_default(url, fp, errcode, errmsg, headers)
File "/usr/local/lib/python2.4/urllib.py", line 550, in http_error_default
return addinfourl(fp, headers, "http:" + url)
File "/usr/local/lib/python2.4/urllib.py", line 836, in __init__
addbase.__init__(self, fp)
File "/usr/local/lib/python2.4/urllib.py", line 786, in __init__
self.read = self.fp.read
AttributeError: 'NoneType' object has no attribute 'read'
The attached file is a three line scipt that demos the problem.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163401&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1161187 ] Install problem 2.4.1rc1 on Win98
Bugs item #1161187, was opened at 2005-03-11 03:56
Message generated for change (Comment added) made by tim_one
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470
Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Spider (m_webber_sydney)
Assigned to: Martin v. Löwis (loewis)
Summary: Install problem 2.4.1rc1 on Win98
Initial Comment:
Python 2.4.1 Release Candidate 1.
I installed (with all the defautl settings)
python-2.4.1c1.msi on a Windows 98 machine.
The shortcuts in the Start / Programs / Python 2.4
group includes a shortcut named "Python Manuals".
This shortcut is inactive - does not point to anything
valid, and clicking on it does not bring up the manuals.
I assume that the shortcut should point to
C:/Python24/Doc/Python24.chm which certainly exists on
my machine and works ok if I access it directly.
I guess the install builds the shortcut wrongly.
--
>Comment By: Tim Peters (tim_one)
Date: 2005-03-14 21:20
Message:
Logged In: YES
user_id=31435
Martin, re "resiliency": Cool -- that works! Microsoft has too
much spare cash .
--
Comment By: Spider (m_webber_sydney)
Date: 2005-03-14 03:50
Message:
Logged In: YES
user_id=1237039
I looked at the log file, and an extract is below. It shows
fairly clearly that when the "Manuals" shortcut is created,
the arguments are missing.
Let me know if you still want the full log.
MSI (c) (63:E3): Note: 1: 2360
MSI (c) (63:E3): Note: 1: 2360
MSI (c) (63:E3): Note: 1: 2360
MSI (c) (63:E3): Note: 1: 2360
MSI (c) (63:E3): Executing op: InstallProtectedFiles(AllowUI=1)
MSI (c) (63:E3): Executing op:
ActionStart(Name=CreateShortcuts,Description=Creating
shortcuts,Template=Shortcut: )
Action 08:30:42: CreateShortcuts. Creating shortcuts
MSI (c) (63:E3): Executing op:
SetTargetFolder(Folder=23\Python 2.4\)
MSI (c) (63:E3): SHFOLDER::SHGetFolderPath returned:
C:\WINDOWS\Start Menu\Programs
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=PYTHON|Python (command
line),Feature=DefaultFeature,Component={4DC71ADD-ADA5-4029-A5BC-5E8858F4243C},,,WorkingDir=C:\Python24\,Icon=python_icon.exe,IconIndex=2,,,)
CreateShortcuts: Shortcut: PYTHON|Python (command line)
MSI (c) (63:E3): Executing op: ShortcutCreate(Name=IDLE|IDLE
(Python
GUI),Feature=TclTk,Component={1E82B1B6-0262-4141-918C-8A03ED896CB7},,Arguments="C:\Python24\Lib\idlelib\idle.pyw",WorkingDir=C:\Python24\,Icon=python_icon.exe,IconIndex=0,,,)
CreateShortcuts: Shortcut: IDLE|IDLE (Python GUI)
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=MODDOCS|Module
Docs,Feature=TclTk,Component={1E82B1B6-0262-4141-918C-8A03ED896CB7},,Arguments="C:\Python24\Tools\scripts\pydocgui.pyw",WorkingDir=C:\Python24\,Icon=python_icon.exe,IconIndex=0,,,)
CreateShortcuts: Shortcut: MODDOCS|Module Docs
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=MANUAL|Python
Manuals,Feature=Documentation,Component={A7ED4080-C9C8-4AD4-BBAF-2D2846B7FF95}
CreateShortcuts: Shortcut: MANUAL|Python Manuals
MSI (c) (63:E3): Executing op:
SetTargetFolder(Folder=23\Python 2.4\)
MSI (c) (63:E3): SHFOLDER::SHGetFolderPath returned:
C:\WINDOWS\Start Menu\Programs
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=UNINST|Uninstall
Python,,,FileName=C:\WINDOWS\SYSTEM\msiexec,Arguments=/x{be027411-8e6b-4440-a29b-b07df0690230},,)
CreateShortcuts: Shortcut: UNINST|Uninstall Python
MSI (c) (63:E3): Executing op:
ActionStart(Name=WriteRegistryValues,Description=Writing
system registry values,Template=Key: , Name: , Value: )
Action 08:30:42: WriteRegistryValues. Writing system
registry values
MSI (c) (63:E3): Executing op:
ProgressTotal(Total=23,Type=1,ByteEquivalent=13200)
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\.py,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValue(,Value=Python.File,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.py, Name: , Value:
Python.File
MSI (c) (63:E3): Executing op: RegAddValue(Name=Content
Type,Value=text/plain,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.py, Name: Content Type,
Value: text/plain
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\.pyw,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=Python.NoConFile,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.pyw, Name: , Value:
Python.NoConFile
MSI (c) (63:E3): Executing op: RegAddValue(Name=Content
Type,Value=text/plain,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.pyw, Name: Content
Type, Value: text/plain
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\.pyc,,BinaryType=0)
MSI (c) (63:E3): Executing op:
RegAddValue(,Value=Python.CompiledFile,)
WriteRegistryValues: Key:
HKEY_LOCAL_MACHINE\Software\Classes\.pyc, Name: , Value:
Python.CompiledFile
MSI (c
[ python-Bugs-1163325 ] "special" decimals aren't hashable
Bugs item #1163325, was opened at 2005-03-14 17:37
Message generated for change (Comment added) made by foom
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163325&group_id=5470
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Marien Zwart (marienz)
Assigned to: Nobody/Anonymous (nobody)
Summary: "special" decimals aren't hashable
Initial Comment:
Python 2.4 (#1, Feb 22 2005, 15:02:34)
[GCC 3.4.3-20050110 (Gentoo Linux 3.4.3.20050110,
ssp-3.4.3.20050110-0, pie-8.7 on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import decimal
>>> hash(decimal.NaN)
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.4/decimal.py", line 720, in
__hash__
i = int(self)
File "/usr/lib/python2.4/decimal.py", line 1410, in
__int__
return context._raise_error(InvalidContext)
File "/usr/lib/python2.4/decimal.py", line 2215, in
_raise_error
raise error, explanation
decimal.InvalidOperation
This behaviour doesn't match the comment in
decimal.py's __hash__:
# Decimal integers must hash the same as the ints
# Non-integer decimals are normalized and hashed as strings
# Normalization assures that hast(100E-1) == hash(10)
Would it make sense to wrap the int(self) in an except
block and return hash(str(self.normalize())) if this
raises?
--
Comment By: James Y Knight (foom)
Date: 2005-03-14 23:15
Message:
Logged In: YES
user_id=1104715
NaN, Inf, and negInf all fail to hash.
Inf and negInf are equal to themselves, so they don't have any problem
being used as a dict key.
As for NaN, I don't see any harm in allowing it to return a hashcode
anyways, but perhaps you're right.
However, in that case, it would be nice to have the exception raised be
somewhat more regular and expected-looking than a InvalidOperation
from int(). Perhaps it should raise TypeError('Decimal("NaN") is
unhashable').
--
Comment By: Tim Peters (tim_one)
Date: 2005-03-14 19:04
Message:
Logged In: YES
user_id=31435
Well, I'm not really a fan of Python's tying hashability
to "usable as a dict key", but given that's what Python
_does_, ya, hashing a NaN doesn't make sense.
marienz, by "special" decimals did you mean only NaNs, or
do you have other cases in mind too?
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-14 17:42
Message:
Logged In: YES
user_id=80475
Since two NaNs are never equal to one another, I would think
that it doesn't make sense to hash them. Tim, do you have
another thoughts on the subject?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163325&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1163325 ] "special" decimals aren't hashable
Bugs item #1163325, was opened at 2005-03-14 17:37
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163325&group_id=5470
Category: Python Library
Group: Python 2.4
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Marien Zwart (marienz)
>Assigned to: Anthony Baxter (anthonybaxter)
Summary: "special" decimals aren't hashable
Initial Comment:
Python 2.4 (#1, Feb 22 2005, 15:02:34)
[GCC 3.4.3-20050110 (Gentoo Linux 3.4.3.20050110,
ssp-3.4.3.20050110-0, pie-8.7 on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import decimal
>>> hash(decimal.NaN)
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.4/decimal.py", line 720, in
__hash__
i = int(self)
File "/usr/lib/python2.4/decimal.py", line 1410, in
__int__
return context._raise_error(InvalidContext)
File "/usr/lib/python2.4/decimal.py", line 2215, in
_raise_error
raise error, explanation
decimal.InvalidOperation
This behaviour doesn't match the comment in
decimal.py's __hash__:
# Decimal integers must hash the same as the ints
# Non-integer decimals are normalized and hashed as strings
# Normalization assures that hast(100E-1) == hash(10)
Would it make sense to wrap the int(self) in an except
block and return hash(str(self.normalize())) if this
raises?
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-15 00:00
Message:
Logged In: YES
user_id=80475
Fixed. See Lib/decimal.py 1.35.
Anthony, can this be backported to 2.4.1 or does it need to
wait for 2.4.2?
--
Comment By: James Y Knight (foom)
Date: 2005-03-14 23:15
Message:
Logged In: YES
user_id=1104715
NaN, Inf, and negInf all fail to hash.
Inf and negInf are equal to themselves, so they don't have any problem
being used as a dict key.
As for NaN, I don't see any harm in allowing it to return a hashcode
anyways, but perhaps you're right.
However, in that case, it would be nice to have the exception raised be
somewhat more regular and expected-looking than a InvalidOperation
from int(). Perhaps it should raise TypeError('Decimal("NaN") is
unhashable').
--
Comment By: Tim Peters (tim_one)
Date: 2005-03-14 19:04
Message:
Logged In: YES
user_id=31435
Well, I'm not really a fan of Python's tying hashability
to "usable as a dict key", but given that's what Python
_does_, ya, hashing a NaN doesn't make sense.
marienz, by "special" decimals did you mean only NaNs, or
do you have other cases in mind too?
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-14 17:42
Message:
Logged In: YES
user_id=80475
Since two NaNs are never equal to one another, I would think
that it doesn't make sense to hash them. Tim, do you have
another thoughts on the subject?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163325&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1162677 ] Unable to Install Python 2.4.1rc1 on windows XP SP2
Bugs item #1162677, was opened at 2005-03-13 19:32 Message generated for change (Comment added) made by sergiocorreia You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162677&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sergio Correia (sergiocorreia) Assigned to: Nobody/Anonymous (nobody) Summary: Unable to Install Python 2.4.1rc1 on windows XP SP2 Initial Comment: First of all, YES i had everything i needed to install, and yes i read the info on the site. When i tried to install python-2.4.1c1.msi (or even ActivePython-2.4.0-244-win32-ix86.msi), install "ended prematurely because of an error". I tried everything but, after a while i found a way to avoid the bug. I was installing from "F:\Docs\Varios\Sandbox".. i moved the msi file to C:\ and then the install (both, python and activepython) worked out perfectly. Folders were not shared, restricted, compressed or on a network (it was a normal local hard disk). Any ideas on why that happened? Thanks PS: Sorry about the sp. mistakes. I am not very fluent on technical english. -- >Comment By: Sergio Correia (sergiocorreia) Date: 2005-03-15 01:00 Message: Logged In: YES user_id=1238520 Thanks for the reply. So i uninstalled it, tried again from the "F:\Docs\Varios\Sandbox" folder, got the same error, and attached the log. Btw, F: is a physical drive, and its not SUBSTed. =) Oh, the last lines of the log were: === Logging stopped: 15/03/2005 00:54:23 === MSI (c) (24:A0) [00:54:23:153]: Note: 1: 1708 MSI (c) (24:A0) [00:54:23:153]: Note: 1: 2262 2: Error 3: - 2147287038 MSI (c) (24:A0) [00:54:23:153]: Note: 1: 2262 2: Error 3: - 2147287038 MSI (c) (24:A0) [00:54:23:153]: Product: Python 2.4.1c1 -- Installation failed. MSI (c) (24:A0) [00:54:23:163]: Grabbed execution mutex. MSI (c) (24:A0) [00:54:23:163]: Cleaning up uninstalled install packages, if any exist MSI (c) (24:A0) [00:54:23:173]: MainEngineThread is returning 1603 === Verbose logging stopped: 15/03/2005 00:54:23 === -- Comment By: Martin v. Löwis (loewis) Date: 2005-03-14 16:36 Message: Logged In: YES user_id=21627 No, but I know how to find out. Please run, in a cmd.exe window, msiexec /i python-2.4.1c1.msi /l*v python.log Compress python.log with Winzip, and attach the resulting file to this report. As a wild guess: could it be that F: is SUBSTed? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162677&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
