[ python-Bugs-1551432 ] __unicode__ breaks for exception class objects
Bugs item #1551432, was opened at 2006-09-03 05:24 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551432&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Python Interpreter Core >Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 9 Submitted By: Marcin 'Qrczak' Kowalczyk (qrczak) >Assigned to: Brett Cannon (bcannon) Summary: __unicode__ breaks for exception class objects Initial Comment: PyObject_Unicode and the unicode function stopped working on class objects of subclasses of BaseException in Python 2.5. >>> unicode(ImportError) Traceback (most recent call last): File "", line 1, in TypeError: descriptor '__unicode__' of 'exceptions.BaseException' object needs an argument It should work analogously to str: >>> str(ImportError) "" -- >Comment By: Brett Cannon (bcannon) Date: 2006-09-09 00:20 Message: Logged In: YES user_id=357491 rev. 51837 and rev. 51838 have the fix in the trunk and 2.5, respectively. -- Comment By: Marcin 'Qrczak' Kowalczyk (qrczak) Date: 2006-09-05 15:08 Message: Logged In: YES user_id=50234 I think the way which is consistent with the current Python implementation is adding the tp_unicode slot. (Parenthetical remark. In the binding between Python and my language Kogut I'm exposing various standard APIs between the two languages automatically. And __unicode__ happened to be the *only* method which I needed to treat specially by tp_getattro. It's the only method I've encountered so far which is called by Python on lots of "ordinary" objects, and which doesn't have a C slot (and the consequence is that my default wrapper shouldn't forward it to the __unicode__ attribute in the other language, but to the appropriate API of the other language which obtains a Unicode rendition). This was a different issue than the topic of this bug, was solvable, but it was another suggestion that the way of handling __unicode__ is inconsistent with other *similar* attributes, similar in the sense of the amount of "genericity" and "magicness", and should have a C slot. The present problem is somewhat dual: now it's me who calls __unicode__ (even if indirectly), and it's Python who provides __unicode__ implementation of its objects. End of parenthetical remark.) Anyway, I'm afraid the issue is a symptom of a deeper problem. I was some time ago wondering how does Python distinguish whether x.foo, when x happens to be a class object (or type object), is meant to be an unbound method to be called with instances of that class, or a bound method to operate on the class object itself. It seems that Python doesn't attempt to use the second interpretation at all. Despite this, various standard operations are dressed in magic methods with names surrounded by double underscores do work for class objects! And while str(x) is the same as x.__str__() for most objects, it's not true for class objects and type objects: str(x) goes through the C slot while x.__str__() doesn't work. The set of methods which have C slots would seem to be just a shortcut for performance, but actually it has a semantic significance. Namely class objects and type objects can have specialized implementations of those methods, but not of ordinary methods. Fortunately it doesn't matter much in practice because the set of methods supported by class objects is fixed, and it just happens to be the subset of the methods with C slots. Unless some other objects can play the role of classes, and then the problem might reappear; I'm completely ignorant about Python metaclasses. -- Comment By: Brett Cannon (bcannon) Date: 2006-09-05 11:22 Message: Logged In: YES user_id=357491 This is because exceptions now define a proper __unicode__() method in the PyMethodDef array. This is what gets called and it requires an exception instance. Before it just fell through to the tp_str slot and that didn't complain. Unless some knows a better way (short of defining a tp_unicode slot), the only way to make this work would be to rip out the __unicode__() method. This would then require the function in the tp_str slot to have to detect if its arguments need to be Unicode or not (and I don't know how to do that off the top of my head; is their a PyUnicode_Check()?). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551432&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python
[ python-Bugs-718532 ] inspect, class instances and __getattr__
Bugs item #718532, was opened at 2003-04-10 01:31 Message generated for change (Comment added) made by baijum81 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=718532&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Stefan Schwarzer (sschwarzer) Assigned to: Ka-Ping Yee (ping) Summary: inspect, class instances and __getattr__ Initial Comment: inspect.isclass(class_instance) fails if the corresponding class uses a "wildcard" implementation of __getattr__. Example: Python 2.2.2 (#1, Nov 13 2002, 22:53:57) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import inspect >>> class X: ... def __getattr__(self, name): ... if name == 'foo': ... return 1 ... if name == 'bar': ... return 2 ... else: ... return "default" ... >>> x = X() >>> inspect.isclass(x) 1 The problematic expression in inspect.isclass is hasattr(object, '__bases__') which returns a true value. -- Comment By: Baiju M (baijum81) Date: 2006-09-09 18:44 Message: Logged In: YES user_id=565450 Due to this bug, 'pydoc modulename' is not working. pydoc tries to access __name__ attribute of classes, so it raises attribute error. (actually it is not a class, but an instance only). So please increase the priority of this bug. And this case is also not working (same issue): class X: __bases__ = () x = X() -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-24 10:55 Message: Logged In: YES user_id=80475 Ping, do you have a few minutes to look at this one and make sure its the right thing to do. -- Comment By: Facundo Batista (facundobatista) Date: 2005-05-31 00:45 Message: Logged In: YES user_id=752496 Don't know yet if it's a bug or not, but in Py2.4.1 inspect.isclass() is still returning True in these cases... -- Comment By: Stefan Schwarzer (sschwarzer) Date: 2005-01-28 22:14 Message: Logged In: YES user_id=383516 Hi Facundo The problem still exists in both Python 2.3.4 and 2.4. A possible test case is: import inspect import unittest class TestIsclass(unittest.TestCase): def test_instance_with_getattr(self): class Cls: def __getattr__(self, name): return "not important" obj = Cls() # obj is not a class self.failIf(inspect.isclass(obj)) -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 23:20 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-15 16:10 Message: Logged In: YES user_id=80475 Ping, if this change is made, will isclass() still be able to find extension classes? The addition of the hasattr(object, '__bases__') was made by you in ver 1.11 about two years ago. -- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-15 15:31 Message: Logged In: YES user_id=89016 type(object) in (types.TypeType, types.ClassType) won't work with custom metaclasses. isinstance(object, (type, types.ClassType)) would be better. -- Comment By: Stefan Schwarzer (sschwarzer) Date: 2003-04-15 13:31 Message: Logged In: YES user_id=383516 Hello Raymond, thanks for your reply. In fact, I'm also not sure if it counts as a bug. I also suggested a patch (handle __getattr__ requests for __bases__ with an AttributeError) for for the SF project which causes/d the problem. I think, if there's a better way to decide on "class-ness" than now, the code in inspect should be changed. Fortunately, it doesn't have to be backward-compatible, because the module is always distributed with a certain interpreter version. -- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-15 06:06 Message: Logged In: YES user_id=80475 Hmm. I'm not sure that counts as a bug. In an OO
[ python-Bugs-1542949 ] idle in python 2.5c1 freezes on macos 10.3.9
Bugs item #1542949, was opened at 2006-08-19 01:51 Message generated for change (Comment added) made by diggableme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542949&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.5 Status: Open Resolution: None Priority: 6 Submitted By: David Strozzi (dstrozzi) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: idle in python 2.5c1 freezes on macos 10.3.9 Initial Comment: Hi, I installed python 2.5b3 on a powerbook ppc laptop running macos 10.3.9 a few days ago. python and idle worked. Now I installed 2.5c1. python works fine from a terminal. When I start idle, it loads, puts up its menu bar, opens a shell window, displays usual startup info, and gives me a prompt. But, I can't type or get a cursor. Whenever I move the mouse over the idle window or menu bar, I get a spinning color wheel and can't do anything. I deleted the whole /library/python tree, reinstalled 2.5c1, and exactly the same thing happened. Oh, and I rebooted :) Not sure what is happening, or how to diagnose. -- Comment By: diggableme (diggableme) Date: 2006-09-09 17:18 Message: Logged In: YES user_id=1594326 I am a new user that is experiencing the same exact problem. I have OSX.3.9 and everytime I start IDLE, it freezes and the colorwheel somes up. When I view the console output, there are no errors or alert messages. I have also tried uninstalling and re-installing from the beginning with the same result. I have been using the instructions given at this site: http://www.python.org/download/mac/ desp I'm very interested to see if there is in fact a resolution to this problem. I'm at my wit's end. -dig -- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-08-28 16:59 Message: Logged In: YES user_id=580910 I've created a new installer from the head of the release25-maint branch and that works correctly. I'm keeping this issue open because I want to investigate why 2.5c1 doesn't work while the current head of the 2.5 branch does work. -- Comment By: David Strozzi (dstrozzi) Date: 2006-08-28 15:48 Message: Logged In: YES user_id=1056922 Well, if there's anything I can do as a 10.3.9 user to test this, let me know. Too busy to delve into the python source code though... -- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-08-28 15:22 Message: Logged In: YES user_id=580910 I can reproduce this on 10.3.9: IDLE starts and opens the interactive window, but then completely blocks (spinning cursor). If I start IDLE from the commandline (/Applications/MacPython\ 2.5/ IDLE.app/Contents/MacOS/IDLE) I get a message about 'console' not being a valid command name. That requires further looking into, but is a red herring for this particular problem, removing the Tk-console hiding code in macosxSupport.py results in the same behaviour, without any further output on the console as well. Upgrading aquatk to the latest version (8.4.10.0) on tcltkaqua.sf.net didn't help, IDLE still hangs (Duh, that's because there's a /System/Library/ Frameworks/Tk.framework, which means a user install won't be used for IDLE). The problem is also unrelated to my IDLE.app work, the same problem occurs when starting $prefix/lib/python2.5/idlelib/idle.py. According to gdb the IDLE process is handing in a semaphore call inside the Tcl mainloop. Time to get into serious debugging mode I guess :-( BTW. IDLE does work correctly on a 10.4.7 system. -- Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-28 13:59 Message: Logged In: YES user_id=149084 Maybe priority should be higher? Hopefully Ronald has time to look at this; I don't have access to a Mac. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542949&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1555496 ] Bug in the match function
Bugs item #1555496, was opened at 2006-09-09 22:02
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=1555496&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Regular Expressions
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: wojtekwu (wojtekwu)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: Bug in the match function
Initial Comment:
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import re
>>> as = re.compile("(a|((a|b)*))")
>>> wynik = as.match("aabaa")
>>> wynik.end()
1
>>> as = re.compile("(((a|b)*)|a)")
>>> wynik = as.match("aabaa")
>>> wynik.end()
5
>>>
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1555496&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1555496 ] Bug in the match function
Bugs item #1555496, was opened at 2006-09-09 20:02
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1555496&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Regular Expressions
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: wojtekwu (wojtekwu)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: Bug in the match function
Initial Comment:
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import re
>>> as = re.compile("(a|((a|b)*))")
>>> wynik = as.match("aabaa")
>>> wynik.end()
1
>>> as = re.compile("(((a|b)*)|a)")
>>> wynik = as.match("aabaa")
>>> wynik.end()
5
>>>
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-09-09 20:06
Message:
Logged In: YES
user_id=849994
IMHO that's not a bug, since we have a "leftmost
alternative" strategy, not a "longest match".
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1555496&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1555501 ] Please include pliblist for all plattforms
Bugs item #101, was opened at 2006-09-09 22:07 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=101&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Guido Guenther (guidog) Assigned to: Nobody/Anonymous (nobody) Summary: Please include pliblist for all plattforms Initial Comment: Hi, plistlib which is currently under ./Lib/plat-mac/plistlib.py is usefull on other platforms too (e.g. in apples calendar server which runs on OS X and Linux). Could this be moved to Lib/ for 2.5 so that other platforms can benefit from it too? Cheers, -- Guido -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=101&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1555496 ] Bug in the match function
Bugs item #1555496, was opened at 2006-09-09 16:02
Message generated for change (Comment added) made by tim_one
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1555496&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Regular Expressions
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: wojtekwu (wojtekwu)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: Bug in the match function
Initial Comment:
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import re
>>> as = re.compile("(a|((a|b)*))")
>>> wynik = as.match("aabaa")
>>> wynik.end()
1
>>> as = re.compile("(((a|b)*)|a)")
>>> wynik = as.match("aabaa")
>>> wynik.end()
5
>>>
--
>Comment By: Tim Peters (tim_one)
Date: 2006-09-09 18:23
Message:
Logged In: YES
user_id=31435
That's right -- the first ("leftmost") alternative that
matches wins; same as Perl, etc etc. Closing as Not-A-Bug.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-09-09 16:06
Message:
Logged In: YES
user_id=849994
IMHO that's not a bug, since we have a "leftmost
alternative" strategy, not a "longest match".
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1555496&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-780714 ] infinite __str__ recursion in thread causes seg fault
Bugs item #780714, was opened at 2003-07-31 10:37 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780714&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: Fixed Priority: 5 Submitted By: Stefan Gregory (stefan_gregory) Assigned to: Nobody/Anonymous (nobody) Summary: infinite __str__ recursion in thread causes seg fault Initial Comment: The following code reliably produces a segmentation fault under Solaris8 in Python2.3, Python2.2, Python2.1.3 and Python1.5. It produces a Bus Error when run on Python2.2 under OSX. Clearly it should produce a Python RuntimeError. import thread, time class Frog: def __str__(self): return str(self) f = Frog() thread.start_new_thread(str,(f,)) time.sleep(1000) This problem manifests in scenarios such as when you have 2 publishing objects (such as HTMLgen objects) A and B and you put A inside B and B inside A and each objects __str__ method calls its childrens __str__ methods and voila! (I hope this might be the reason my Zope server has been intermitently crashing for the past year or so though I have not found any recursive structures yet.) With Python2.3 gdb reports: vgetargskeywords (args=0x1bdaf0, keywords=0x0, format=0xd2579 "0:str", kwlist=0xf7b4c, p_va=0xfed0C02c) at Python/getargs.c:1167 Though with Python2.1 it dies at line 330 in getargs.c. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-09-10 02:03 Message: Logged In: YES user_id=21627 I fail to see the problem. You have to change the recursion limit; if you do, you risk a crash, as the documentation says: http://docs.python.org/lib/module-sys.html "This should be done with care, because a too-high limit can lead to a crash." With an unmodified recursionlimit in 2.4.3 on Windows, I get the expected RuntimeError. If it causes a crash on some system, it just means that the default recursion limit is too high for that platform (however, we don't seem to have a confirmation that the default recursion limit is too large for this application on any platform for Python 2.4 or 2.5). It is quite common that the system provides the main thread with a larger stack space than any additional thread, so it is not surprising that the stack overflow is detected on some system when the code is run in the main thread, yet crashes in an additional thread. The default recursion limit should be the conservative minimum of what the system minimally guarantees for any thread. It seems that the original problem has been fixed (although nobody apparently has tested Python 2.4 or 2.5 on Solaris8); I suggest to close this as fixed again. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-08-16 09:42 Message: Logged In: YES user_id=341410 >>> import sys >>> sys.setrecursionlimit(1) >>> class foo: ... def __str__(self): ... return str(self) ... >>> import threading >>> threading.Thread(target=foo().__str__).start() Kills 2.3, 2.4, and 2.5 on Windows, and 2.3 and 2.4 on linux (I can't test 2.5 on linux). Running in the main thread on Windows doesn't seem to be a big deal: >>> import sys >>> sys.setrecursionlimit(1) >>> class foo: ... def __str__(self): ... return str(self) ... >>> try: ... str(foo()) ... except Exception, why: ... print why ... Stack overflow >>> Note that the above crashes 2.3 and 2.4 on Linux. This is still a bug, at least in maintenance on 2.4. Suggested reopen. -- Comment By: SourceForge Robot (sf-robot) Date: 2006-08-14 04:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Georg Brandl (gbrandl) Date: 2006-07-30 13:16 Message: Logged In: YES user_id=849994 Under 2.5, I get a runtime error now, so this might be fixed. -- Comment By: Brett Cannon (bcannon) Date: 2003-08-05 21:22 Message: Logged In: YES user_id=357491 Forgot to mention that Modules/threadmodule.c has thread_PyThread_start_new_thread which uses Python/ thread_*.h's PyThread_start_new_thread for executing threads; the '*' is replaced with the threading library used on your platform. OS X should use thread_pthread.h (I think).
[ python-Bugs-1548332 ] whichdb too dumb
Bugs item #1548332, was opened at 2006-08-29 07:51
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548332&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.5
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Curtis Doty (dotysan)
Assigned to: Nobody/Anonymous (nobody)
Summary: whichdb too dumb
Initial Comment:
On my system with db4, I noticed that whichdb doesn't
know anything about more recent database types created
by the bsddb module.
Python 2.4.3 (#1, Jun 13 2006, 11:46:08)
[GCC 4.1.1 20060525 (Red Hat 4.1.1-1)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>>
>>> from whichdb import *
>>> import bsddb
>>>
>>> dbfile= "hash"
>>> bsddb.hashopen( dbfile)
{}
>>> whichdb( dbfile)
'dbhash'
>>> # yay
...
>>> dbfile= "btree"
>>> bsddb.btopen( dbfile)
{}
>>> whichdb( dbfile)
''
>>> # bah
...
>>> dbfile= "recno"
>>> bsddb.rnopen( dbfile)
{}
>>> whichdb( dbfile)
''
>>> # humbug!
It looks like both these database types share:
#define DB_BTREEMAGIC 0x053162
So this might be a start:
--- Python-2.5c1/Lib/whichdb.py.orig 2005-02-05
22:57:08.0 -0800
+++ Python-2.5c1/Lib/whichdb.py 2006-08-28
13:46:57.0 -0700
@@ -109,6 +109,10 @@
if magic in (0x00061561, 0x61150600):
return "dbhash"
+# Check for binary tree
+if magic == 0x00053162:
+return "btree"
+
# Unknown
return ""
But alas, I'm not clear on the best way to
differentiate between btree and recno.
The above example is on 2.4 but persists in 2.5.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2006-09-10 02:08
Message:
Logged In: YES
user_id=21627
It is not the job of whichdb to recognize certain database
types created by the bsddb module. Instead, as the doc
string says
"Guess which db package to use to open a db file."
The return value of whichdb is a *module name*. Since
"btree" is not a module name, the proposed change is incorrect.
Closing as invalid.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548332&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1545659 ] distutils needs vendor-packages support
Bugs item #1545659, was opened at 2006-08-24 04:28 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545659&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: John Levon (movement) Assigned to: Nobody/Anonymous (nobody) Summary: distutils needs vendor-packages support Initial Comment: Currently, distutils supports "site-packages". It should also provide an option for "vendor-packages". -- >Comment By: Martin v. Löwis (loewis) Date: 2006-09-10 02:09 Message: Logged In: YES user_id=21627 What is "vendor-packages"? It is not something that is part of Python, AFAICT, so I don't think Python should support it. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545659&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1545658 ] distutils home scheme lacks python versioning
Bugs item #1545658, was opened at 2006-08-24 04:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Levon (movement) Assigned to: Nobody/Anonymous (nobody) Summary: distutils home scheme lacks python versioning Initial Comment: The "home scheme", as described here: http://docs.python.org/inst/alt-install-windows.html seems to be broken: no version suffix is appended, yet .pyc files are not guaranteed across Python revisions. Thus, breakage can occur. This is quite annoying, as an OS vendor often would like to install stuff into /usr/lib/python2.x/ (not using vendor-packages). -- >Comment By: Martin v. Löwis (loewis) Date: 2006-09-10 02:13 Message: Logged In: YES user_id=21627 I fail to see the problem. Can you please provide a scenario where breakage does occur (instead of merely suggesting that it "can occur")? What is the specific error message that you get? Also, what does that have to do with OS vendors? They shouldn't use the home scheme. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1543467 ] test_tempfile fails on cygwin
Bugs item #1543467, was opened at 2006-08-20 15:18 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543467&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: test_tempfile fails on cygwin Initial Comment: This is RC1: [16:07] ~/src/Python-2.5c1 $./python.exe -c 'from test.test_tempfile import test_main; test_main()' test_exports (test.test_tempfile.test_exports) ... ok test_get_six_char_str (test.test_tempfile.test__RandomNameSequence) ... ok test_many (test.test_tempfile.test__RandomNameSequence) ... ok test_supports_iter (test.test_tempfile.test__RandomNameSequence) ... ok test_nonempty_list (test.test_tempfile.test__candidate_tempdir_list) ... ok test_wanted_dirs (test.test_tempfile.test__candidate_tempdir_list) ... ok test_retval (test.test_tempfile.test__get_candidate_names) ... ok test_same_thing (test.test_tempfile.test__get_candidate_names) ... ok test_basic (test.test_tempfile.test__mkstemp_inner) ... ok test_basic_many (test.test_tempfile.test__mkstemp_inner) ... ok test_choose_directory (test.test_tempfile.test__mkstemp_inner) ... ok test_file_mode (test.test_tempfile.test__mkstemp_inner) ... ok test_noinherit (test.test_tempfile.test__mkstemp_inner) ... FAIL test_textmode (test.test_tempfile.test__mkstemp_inner) ... ok test_sane_template (test.test_tempfile.test_gettempprefix) ... ok test_usable_template (test.test_tempfile.test_gettempprefix) ... ok test_directory_exists (test.test_tempfile.test_gettempdir) ... ok test_directory_writable (test.test_tempfile.test_gettempdir) ... ok test_same_thing (test.test_tempfile.test_gettempdir) ... ok test_basic (test.test_tempfile.test_mkstemp) ... ok test_choose_directory (test.test_tempfile.test_mkstemp) ... ok test_basic (test.test_tempfile.test_mkdtemp) ... ok test_basic_many (test.test_tempfile.test_mkdtemp) ... ok test_choose_directory (test.test_tempfile.test_mkdtemp) ... ok test_mode (test.test_tempfile.test_mkdtemp) ... ok test_basic (test.test_tempfile.test_mktemp) ... ok test_many (test.test_tempfile.test_mktemp) ... ok test_basic (test.test_tempfile.test_NamedTemporaryFile) ... ok test_creates_named (test.test_tempfile.test_NamedTemporaryFile) ... ok test_del_on_close (test.test_tempfile.test_NamedTemporaryFile) ... ok test_multiple_close (test.test_tempfile.test_NamedTemporaryFile) ... ok == FAIL: test_noinherit (test.test_tempfile.test__mkstemp_inner) -- Traceback (most recent call last): File "/home/mtebeka/src/Python-2.5c1/Lib/test/test_tempfile.py", line 310, in test_noinherit self.failIf(retval > 0, "child process reports failure %d"%retval) AssertionError: child process reports failure 127 -- Ran 31 tests in 1.077s FAILED (failures=1) Traceback (most recent call last): File "", line 1, in File "/home/mtebeka/src/Python-2.5c1/Lib/test/test_tempfile.py", line 665, in test_main test_support.run_unittest(*test_classes) File "/home/mtebeka/src/Python-2.5c1/Lib/test/test_support.py", line 441, in run_unittest run_suite(suite, testclass) File "/home/mtebeka/src/Python-2.5c1/Lib/test/test_support.py", line 426, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "/home/mtebeka/src/Python-2.5c1/Lib/test/test_tempfile.py", line 310, in test_noinherit self.failIf(retval > 0, "child process reports failure %d"%retval) AssertionError: child process reports failure 127 [16:12] ~/src/Python-2.5c1 $ -- >Comment By: Martin v. Löwis (loewis) Date: 2006-09-10 02:16 Message: Logged In: YES user_id=21627 The usual way of invoking test_tempfile would be ./python Lib/test/regrtest.py test_tempfile or ./python -mtest.regrtest test_tempfile Do these give you the same error? -- Comment By: Miki Tebeka (tebeka) Date: 2006-08-21 07:55 Message: Logged In: YES user_id=358087 Cygwin version is 1.5.21 (see attached output of cygcheck -s -v -r). What do you mean by "running directly"? I ran the test with the following command line (and it failed): ./python.exe -c 'from test.test_tempfile import test_main; test_main()' -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-21 04:13 Message: Logged In: YES user_id=33168 What version of cygwin? I've been testing with 1.5.1
[ python-Bugs-1543467 ] test_tempfile fails on cygwin
Bugs item #1543467, was opened at 2006-08-20 16:18 Message generated for change (Comment added) made by tebeka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543467&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: test_tempfile fails on cygwin Initial Comment: This is RC1: [16:07] ~/src/Python-2.5c1 $./python.exe -c 'from test.test_tempfile import test_main; test_main()' test_exports (test.test_tempfile.test_exports) ... ok test_get_six_char_str (test.test_tempfile.test__RandomNameSequence) ... ok test_many (test.test_tempfile.test__RandomNameSequence) ... ok test_supports_iter (test.test_tempfile.test__RandomNameSequence) ... ok test_nonempty_list (test.test_tempfile.test__candidate_tempdir_list) ... ok test_wanted_dirs (test.test_tempfile.test__candidate_tempdir_list) ... ok test_retval (test.test_tempfile.test__get_candidate_names) ... ok test_same_thing (test.test_tempfile.test__get_candidate_names) ... ok test_basic (test.test_tempfile.test__mkstemp_inner) ... ok test_basic_many (test.test_tempfile.test__mkstemp_inner) ... ok test_choose_directory (test.test_tempfile.test__mkstemp_inner) ... ok test_file_mode (test.test_tempfile.test__mkstemp_inner) ... ok test_noinherit (test.test_tempfile.test__mkstemp_inner) ... FAIL test_textmode (test.test_tempfile.test__mkstemp_inner) ... ok test_sane_template (test.test_tempfile.test_gettempprefix) ... ok test_usable_template (test.test_tempfile.test_gettempprefix) ... ok test_directory_exists (test.test_tempfile.test_gettempdir) ... ok test_directory_writable (test.test_tempfile.test_gettempdir) ... ok test_same_thing (test.test_tempfile.test_gettempdir) ... ok test_basic (test.test_tempfile.test_mkstemp) ... ok test_choose_directory (test.test_tempfile.test_mkstemp) ... ok test_basic (test.test_tempfile.test_mkdtemp) ... ok test_basic_many (test.test_tempfile.test_mkdtemp) ... ok test_choose_directory (test.test_tempfile.test_mkdtemp) ... ok test_mode (test.test_tempfile.test_mkdtemp) ... ok test_basic (test.test_tempfile.test_mktemp) ... ok test_many (test.test_tempfile.test_mktemp) ... ok test_basic (test.test_tempfile.test_NamedTemporaryFile) ... ok test_creates_named (test.test_tempfile.test_NamedTemporaryFile) ... ok test_del_on_close (test.test_tempfile.test_NamedTemporaryFile) ... ok test_multiple_close (test.test_tempfile.test_NamedTemporaryFile) ... ok == FAIL: test_noinherit (test.test_tempfile.test__mkstemp_inner) -- Traceback (most recent call last): File "/home/mtebeka/src/Python-2.5c1/Lib/test/test_tempfile.py", line 310, in test_noinherit self.failIf(retval > 0, "child process reports failure %d"%retval) AssertionError: child process reports failure 127 -- Ran 31 tests in 1.077s FAILED (failures=1) Traceback (most recent call last): File "", line 1, in File "/home/mtebeka/src/Python-2.5c1/Lib/test/test_tempfile.py", line 665, in test_main test_support.run_unittest(*test_classes) File "/home/mtebeka/src/Python-2.5c1/Lib/test/test_support.py", line 441, in run_unittest run_suite(suite, testclass) File "/home/mtebeka/src/Python-2.5c1/Lib/test/test_support.py", line 426, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "/home/mtebeka/src/Python-2.5c1/Lib/test/test_tempfile.py", line 310, in test_noinherit self.failIf(retval > 0, "child process reports failure %d"%retval) AssertionError: child process reports failure 127 [16:12] ~/src/Python-2.5c1 $ -- >Comment By: Miki Tebeka (tebeka) Date: 2006-09-10 09:36 Message: Logged In: YES user_id=358087 In your way it seems OK :) [09:22] ~ $cd src/Python-2.5c1/ /home/mtebeka/src/Python-2.5c1 [09:23] ~/src/Python-2.5c1 $./python.exe -mtest.regrtest test_tempfile Could not find '/home/mtebeka/src/Python-2.5c1/Lib/test' in sys.path to remove it test_tempfile 1 test OK. [09:23] ~/src/Python-2.5c1 $ -- Comment By: Martin v. Löwis (loewis) Date: 2006-09-10 03:16 Message: Logged In: YES user_id=21627 The usual way of invoking test_tempfile would be ./python Lib/test/regrtest.py test_tempfile or ./python -mtest.regrtest test_tempfile Do these give you the same error? -- Comment By: Miki Tebeka (tebeka) Date: 2006-08-21 08:55 Message: Logged In: YES user_id=358087 Cyg
