[issue7164] pickle test failure after test_imp/test_import (_make_stat_result is not the same object as os._make_stat_result)
Peter Williams added the comment: I'm experiencing a variation of this problem on a project where I'm trying to make an application that will work with both 2.7.x and 3.4.x and am mostly successful. The application uses a number of pickle files and I want to make it so that it doesn't matter which version created the pickle files the other can read it. By limiting the 3.4 version to pickle protocol 2 I've succeeded in having 2.7.x read 3.4.x pickle files but encountered a problem going the other way with the following error message: Traceback (most recent call last): File "/home/peter/SRC/GITHUB/epygibus.git/epygibus3", line 25, in sys.exit(ARGS.run_cmd(ARGS)) File "/home/peter/SRC/GITHUB/epygibus.git/epygibus_pkg/cli/subcmd_restore.py", line 70, in run_cmd snapshot.restore_subdir(args.archive_name, os.sep, seln_fn=lambda l: l[-1-args.back]) File "/home/peter/SRC/GITHUB/epygibus.git/epygibus_pkg/snapshot.py", line 699, in restore_subdir snapshot_fs = get_snapshot_fs(archive_name, seln_fn).get_subdir(abs_subdir_path) File "/home/peter/SRC/GITHUB/epygibus.git/epygibus_pkg/snapshot.py", line 595, in get_snapshot_fs snapshot = read_snapshot(os.path.join(archive.snapshot_dir_path, snapshot_name)) File "/home/peter/SRC/GITHUB/epygibus.git/epygibus_pkg/snapshot.py", line 236, in read_snapshot return pickle.load(fobj) AttributeError: Can't get attribute '_make_stat_result' on I'm pretty sure that this is a result of that pickle file containing instances of the output from os.lstat() generated by 2.7.x which 3.4.x is having trouble instantiating. The source code for the application with the problem is available on github as repo "epygibus" for user "pwil3058". -- nosy: +Peter Williams ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue7164> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12713] argparse: allow abbreviation of sub commands by users
New submission from Peter Williams pwil3...@bigpond.net.au: Quite often the names of subcommands are quite long so that their meaning is clear. However, the downside to this is the increased typing the user of the command must make. A compromise between clarity and brevity can be realized if abbreviation of subcommands is allowed with the proviso that the abbreviation must be long enough to remove any ambiguity. So that this feature is not foisted on every programmer that uses argparse it could be made an option to the ArgumentParser class with the (possible) additional refinement of specifying a minimum number of characters for the abbreviations. -- components: Library (Lib) messages: 141805 nosy: pwil3058 priority: normal severity: normal status: open title: argparse: allow abbreviation of sub commands by users type: feature request ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12713 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12457] type() returns incorrect type for nested classes
Peter Williams pwil3...@bigpond.net.au added the comment: The class I was pickling was a top level class but a field inside that class had an instance of a nested class set as its value. The error message produced indicated that the reason for failure was the inability of pickle to find the class definition and (I think) that was caused by the problem with type()'s returned value. Perhaps fixing the problem with type() would allow the restriction on pickling nested classes to be removed? Was that restriction a deliberate design decision (illogical) or the result of not being able to get it to work? Re whether the behaviour of type() is a problem: I believe it is as, in addition to the inconsistencies between type() and isinstance() that I described in my original report, there is the confusion that arises if two separate classes have nested classes with the same name (see mini program confusion.py as an example). This seems to compromise the whole purpose of namespaces and is inconsistent with the way modules are treated in determining the name reported by type(). -- type: behavior - crash Added file: http://bugs.python.org/file22544/confusion.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12457 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12457] type() returns incorrect type for nested classes
New submission from Peter Williams pwil3...@bigpond.net.au: The built in type() function returns incorrect type names for nested classes which in turn causes pickle to crash when used with nested classes as it cannot find the nested class definitions from the using the string returned by type(). e.g. if I have an instance inner of class Inner which is defined inside (nested in) the class Outer: type(inner) returns class '__main__.Inner' instead of class '__main__.Outer.Inner' The isinstance() function, as expected, returns True for isinstance(inner, Outer.Inner) and raises a NameError exception for isinstance(inner, Inner). However, isinstance(inner, type(inner)) returns True which indicates the core functionality is OK and this conforms to the fact that no problems were encountered until I tried to pickle an object containing nested classes. My system is Fedora 15 x86_64 and Python versions are 2.7.1 and 3.2. A short program illustrating the problem is attached. -- components: None files: nested_class_bug.py messages: 139542 nosy: pwil3058 priority: normal severity: normal status: open title: type() returns incorrect type for nested classes type: crash versions: Python 2.7, Python 3.2 Added file: http://bugs.python.org/file22531/nested_class_bug.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12457 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11708] argparse: suggestion for formatting optional positional args
New submission from Peter Williams pwil3...@bigpond.net.au: At present, if a number (e.g. 2) of optional positional arguments are defined (e.g. arg1 and arg2) argparse formats them as follows: usage: program [arg1] [arg2] in the usage message. I would like to suggest that a better format would be: usage: program [arg1 [arg2]] as this more accurately reflects the way argparse treats them during parsing of the command line. This formatting would be consistent with the way argparse currently formats a single optional positional argument with nargs='*', namely: usage: program [arg [arg ...]] -- components: Library (Lib) messages: 132462 nosy: pwil3058 priority: normal severity: normal status: open title: argparse: suggestion for formatting optional positional args type: feature request versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11708 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
