[issue12914] Add cram function to textwrap
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- resolution: - rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12914 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12917] Make visiblename and allmethods functions public
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- assignee: - rhettinger nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12917 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12916] Add inspect.splitdoc
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- assignee: - rhettinger nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12916 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12958] test_socket failures on Mac OS X
Changes by Ned Deily n...@acm.org: -- nosy: +ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12958 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1172711] long long support for array module
Stefan Krah stefan-use...@bytereef.org added the comment: I left some remarks on Rietveld. -- nosy: +skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1172711 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7798] Make generally useful pydoc functions public
Raymond Hettinger raymond.hettin...@gmail.com added the comment: Resist the urge to fatten APIs until you're sure that: * they are needed * they are well developed (many internal utils fail this test) * they are worth the extra time it takes to learn what is in a module (adding rarely needed tools has the side-effect of obscuring things people actually need) Georg's advice is spot on. There are a lot of little internal routines in the standard library that aren't sufficiently fit to be exposed (perhaps a little too ad-hoc or special purpose, perhaps the API isn't sufficiently general, perhaps the routines rely on non-guaranteed aspects of the implementation). For example, visiblename() is more heuristic than algorithmic -- right now, we can change that as needed (for instance, the recent updates to accommodate named tuples), but as soon as the method or function becomes public, its API freezes and it is hard for us to make changes. The pager functions are interesting and non-trivial. Before making them public in the standard library though, it would be best if it had some life as third-party module to let it mature (i.e. making sure it works as well in other contexts as it does in pydoc). Also consider whether other documentation tools have already encountered and addressed these use cases, perhaps in a different and better way. -- nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7798 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12936] armv5tejl: random segfaults in getaddrinfo()
Stefan Krah stefan-use...@bytereef.org added the comment: Traceback with faulthandler disabled: Core was generated by `./python -m test -uall -r --randseed=8304772'. Program terminated with signal 11, Segmentation fault. [New process 3948] #0 0x40011d20 in __tls_get_addr () from /lib/ld-linux.so.2 (gdb) bt #0 0x40011d20 in __tls_get_addr () from /lib/ld-linux.so.2 #1 0x40011d10 in __tls_get_addr () from /lib/ld-linux.so.2 Backtrace stopped: frame did not save the PC -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12936 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12936] armv5tejl: random segfaults in getaddrinfo()
Charles-François Natali neolo...@free.fr added the comment: Traceback with faulthandler disabled: It crashes when trying to look up TLS (which explains why it doesn't crash when built ``without-threads`). Looks like a libc bug, but would it be possible to have a backtrace with Python built with `with-pydebug`? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12936 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12958] test_socket failures on Mac OS X
Nick Coghlan ncogh...@gmail.com added the comment: First attempt didn't quite work - the FD passing tests somehow seem to be reporting both 'ERROR' *and* 'expected failure', which is causing the test overall to remain red. http://www.python.org/dev/buildbot/all/builders/AMD64%20Snow%20Leopard%202%20custom/builds/41/steps/test/logs/stdio -- hgrepos: +67 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12958 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12945] ctypes works incorrectly with _swappedbytes_ = 1
Pavel Boldin boldin.pa...@gmail.com added the comment: OK. So, it seems just like ctypes work, but don't for my needs. Thing that bothers me anyway is the strange code, where size contains either size (when bitsize==0) or bitsize in upper 16 bits and bitoffset in lower 16 bits. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12945 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12936] armv5tejl: random segfaults in getaddrinfo()
Changes by Meador Inge mead...@gmail.com: -- nosy: +meadori ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12936 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12959] Add 'ChainMap' to collections.__all__
New submission from July Tikhonov july.t...@gmail.com: ChainMap is the only item from collections module, that is described in docs, but is not included in collections.__all__ -- components: Library (Lib) files: chainmap_in___all__.diff keywords: patch messages: 143862 nosy: july priority: normal severity: normal status: open title: Add 'ChainMap' to collections.__all__ type: feature request versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file23128/chainmap_in___all__.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12958] test_socket failures on Mac OS X
Nick Coghlan ncogh...@gmail.com added the comment: Ah, I believe I see why the expected failure isn't working properly - the failing testFDPass* tests are causing the subsequent tear down code to also fail. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12958 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12960] threading.Condition is not a class
New submission from Nikolaus Rath nikol...@rath.org: According to http://docs.python.org/library/threading.html#condition-objects, threading.Condition is a class. However, in fact it turns out to be function that constructs a _Condition instance. I don't know the reason for that, but it seems to me that either Condition should be a class, or the reason for it being a function should be documented so that people who I would like to inherit from Conditionknow if that is not supported, or if they can safely inherit from _Condition instead. -- assignee: docs@python components: Documentation messages: 143864 nosy: Nikratio, docs@python priority: normal severity: normal status: open title: threading.Condition is not a class type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12960 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12704] Language References does not specify exception raised by final yield()
Changes by Nikolaus Rath nikol...@rath.org: -- versions: +Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12704 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12936] armv5tejl: random segfaults in getaddrinfo()
Stefan Krah stefan-use...@bytereef.org added the comment: Curiously enough python *is* built --with-pydebug. Version 9d658f000419, which is pre-faulthandler, runs without segfaults. Could faulthandler cause problems like these: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=370060 -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12936 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11457] Expose nanosecond precision from system calls
Larry Hastings la...@hastings.org added the comment: Mark Dickinson: I realize a new float type would be a major undertaking That's an understatement and a half. The only way this could ever be viable is if float128 support becomes widespread enough that we don't have to write our own algorithms for basic float128 operations As I mentioned earlier in this thread, GCC has supported __float128 since 4.3, Clang added support within the last year, and Intel has a _Quad type. All are purported to be IEEE 754-2008 quad-precision floats. Glibc added quadmath.h recently (maybe in 4.6), which defines sinq() / tanq() / etc. Is that not sufficient? The Windows compilers don't seem to support a float128 yet. But Windows only supports 100ns resolution for mtime/atime anyway. The bad news: according to my back-of-the-envelope calcuations, doubles will stop accurately representing 100ns timestamps in less than a year; they'll lose another bit of precision somewhere around 2019. Alexander Belopolsky How is this superior to using either Decimal or float128? It is explicit about the units of time used. Why is that a feature? I'd rather that was abstracted away for me, like the os module currently does. And familiarity with C API is expected from users of os module, IMO. As you say, that's your opinion. But I've never heard of that as an official policy. Therefore it is irrelevant as a design constraint for the API. I've drawn an ASCII table summarizing the proposals so far. You did not mention closely matches C API as an upside. By C API, you mean the POSIX-2008 compatible C API. This would not match * POSIX platforms that don't meet the 2008 spec * Windows * Java * CLR all of which are supported platforms for Python. The documentation for the os module states: This module provides a portable way of using operating system dependent functionality. [...] The design of all built-in operating system dependent modules of Python is such that as long as the same functionality is available, it uses the same interface Since the most recent modification time / access time of a file is available on all platforms Python supports, it follows that Python should use the same interface to represent it on all those platforms. Tying the representation to that of one particular platform is therefore poor API design, particularly when there are representations that abstract away such details within easy reach. So I don't consider it a compelling upside--in fact I consider it a disadvantage. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11457 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11457] Expose nanosecond precision from system calls
STINNER Victor victor.stin...@haypocalc.com added the comment: As I mentioned earlier in this thread, GCC has supported __float128 since 4.3, Clang added support within the last year, and Intel has a _Quad type. All are purported to be IEEE 754-2008 quad-precision floats. Glibc added quadmath.h recently (maybe in 4.6), which defines sinq() / tanq() / etc. Is that not sufficient? Python is compiled using Visual Studio 2008 on Windows. Portability does matter on Python. If a type is not available on *all* platforms (including some old platforms, e.g. FreeBSD 6 or Windows XP), we cannot use it by default. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11457 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11457] Expose nanosecond precision from system calls
Larry Hastings la...@hastings.org added the comment: Victor STINNER: Python is compiled using Visual Studio 2008 on Windows. Portability does matter on Python. If a type is not available on *all* platforms (including some old platforms, e.g. FreeBSD 6 or Windows XP), we cannot use it by default. The quad-precision float would be highly portable, but not 100% guaranteed. The idea is that st_mtime would be a float128 on a recent Linux, but still a double on Windows. Python's duck typing, combined with a judicious implementation of float128, would permit code that performed simple math on a timestamp to run unchanged. That should be sufficient for almost all existing code that deals with these timestamps. But there are obvious, plausible scenarios where this would break. For example: pickling a float128 mtime on one platform and attempting to unpickle it on Windows. I can imagine legitimate reasons why one would want to ship ctime/atime/mtime across platforms. If that's an unacceptable level of portability, then for the proposal to remain viable we'd have to implement our own portable quad-precision floating point type. That's a staggering amount of work, and I doubt it would happen. But short of some quad-precision type, there's no way to preserve existing code and have it get more precise automatically. If float128 isn't viable then the best remaining option is Decimal. But changing st_mtime to Decimal would be an even more violent change than changing it to float was. I propose adding the Decimal fields ctime, atime, and mtime to the named tuple returned by os.stat(). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11457 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12936] armv5tejl: random segfaults in getaddrinfo()
Charles-François Natali neolo...@free.fr added the comment: Could faulthandler cause problems like these: Well, that would explain why it crashes in the TLS lookup code, and why the core dump looks borked. 1) Apparently, Etch on ARM uses linuxthread instead of NPTL: what does $ getconf GNU_LIBPTHREAD_VERSION return on your box? 2) If it's using linxthreads, the culprit is likely the call to PyGILState_GetThisThreadState() from faulthandler_fatal_error(), which does a TLS lookup (which screws up because it's running in a user-allocated stack allocated with sigaltstack). However, this should only happen when a a fatal signal is handled by faulthandler, which should - AFAICT - only happen in test_faulthandler. Rebuilding faulthandler with #undef HAVE_SIGALTSTACK at the top of the file, should do the trick. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12936 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12881] ctypes: segfault with large structure field names
Charles-François Natali neolo...@free.fr added the comment: Looks good to me. -- nosy: +neologix stage: patch review - commit review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12881 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12956] 2.7.2 build fails with --enable-framework and space in pathname on OS X 10.7.1
New submission from Ned Deily n...@acm.org: gcc -o Python.framework/Versions/2.7/Python -dynamiclib \ -all_load libpython2.7.a -Wl,-single_module \ -install_name /tmp/a/empty space/Python.framework/Versions/2.7/Python \ -compatibility_version 2.7 \ -current_version 2.7; i686-apple-darwin11-llvm-gcc-4.2: space/Python.framework/Versions/2.7/Python: No such file or directory -- assignee: - ned.deily components: +Macintosh nosy: +ned.deily stage: - needs patch versions: +Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12956 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12959] Add 'ChainMap' to collections.__all__
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 12bb3cd873c8 by Benjamin Peterson in branch 'default': add ChainMap to __all__ (closes #12959) http://hg.python.org/cpython/rev/12bb3cd873c8 -- nosy: +python-dev resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11457] Expose nanosecond precision from system calls
Martin v. Löwis mar...@v.loewis.de added the comment: The quad-precision float would be highly portable Larry, please stop this discussion in this issue. I believe a PEP would be needed, and would likely be rejected because of the very very very long list of issues that can't be resolved. I think you seriously underestimate the problems. Please trust Mark on this. For example, gcc doesn't support __float128 in 32-bit mode on x86. If float128 isn't viable then the best remaining option is Decimal. But changing st_mtime to Decimal would be an even more violent change than changing it to float was. I propose adding the Decimal fields ctime, atime, and mtime to the named tuple returned by os.stat(). That sounds reasonable to me. While we are at it, I'd rename ctime to creationtime on Windows, to prevent people from believing it is ctime (i.e. inode change time). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11457 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1230540] sys.excepthook doesn't work in threads
Changes by Nikolaus Rath nikol...@rath.org: -- nosy: +Nikratio ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1230540 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12961] unlabelled balls in boxes
New submission from Phillip Feldman phillip.m.feld...@gmail.com: The current set of combinatorial functions in `itertools` does not include unlabelled balls in labeled boxes and unlabelled balls in unlabelled boxes. If the boxes have no capacity limits (i.e., can store an unlimited number of balls), then the unlabelled balls in labelled boxes can be handled with existing tools. But, this is a special case. Various people have developed working Python implementations for the unlabelled balls in labelled boxes with capacity limits problem. I believe that unlabelled balls in unlabelled boxes with capacity limits can be handled with a minor variation on the same algorithm. It would be a great benefit to have this capability in `itertools`. -- messages: 143874 nosy: Phillip.M.Feldman, rhettinger priority: normal severity: normal status: open title: unlabelled balls in boxes type: feature request versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12961 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12853] global name 'r' is not defined in upload.py
dirn d...@dirnonline.com added the comment: Replacing r with result works only when urlopen doesn't raise HTTPError -- nosy: +dirn ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12853 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12958] test_socket failures on Mac OS X
Changes by Brett Cannon br...@python.org: -- nosy: +brett.cannon ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12958 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Changes by Nadeem Vawda nadeem.va...@gmail.com: Added file: http://bugs.python.org/file23129/fe2c9998f329.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Nadeem Vawda nadeem.va...@gmail.com added the comment: I've attached another patch (fe2c9998f329.diff) with a more complete implementation of the lzma module. All that's left now is to write the documentation, and make sure that the module can build on Windows. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12936] armv5tejl: random segfaults in getaddrinfo()
Stefan Krah stefan-use...@bytereef.org added the comment: I completely removed faulthandler from e91ad9669c08 and the problem still occurs (with the same broken backtrace). $ getconf GNU_LIBPTHREAD_VERSION NPTL 2.7 It is a bit unsatisfying that the segfault isn't reproducible with the earlier revision, but there are several glibc issues with __tls_get_addr(): 1) http://www.cygwin.com/ml/libc-hacker/2008-10/msg5.html 2) http://sources.redhat.com/bugzilla/show_bug.cgi?id=12453 If I run the demo script from 2), I get a segfault both on debian-arm as well as on Ubuntu Lucid. So, it may very well be that some recent change in Python exposes a glibc problem. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12936 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12306] zlib: Expose zlibVersion to query runtime version of zlib
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset b21d1de6d78e by Nadeem Vawda in branch 'default': Issue #12306: Add ZLIB_RUNTIME_VERSION to the zlib module. http://hg.python.org/cpython/rev/b21d1de6d78e -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12306 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12306] zlib: Expose zlibVersion to query runtime version of zlib
Nadeem Vawda nadeem.va...@gmail.com added the comment: I've committed your patches. I took the liberty of removing the versionadded tag for ZLIB_VERSION; I don't think many people will need to worry about compatibility with Python 1.5 ;-) Once again, thanks for the patches! -- assignee: - nadeem.vawda resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12306 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12936] armv5tejl: random segfaults in getaddrinfo()
STINNER Victor victor.stin...@haypocalc.com added the comment: Looks like a libc bug ... http://sources.redhat.com/bugzilla/show_bug.cgi?id=12453 Yes, the GNU libc has bugs (as every software!): this one has been fixed only recently (in glibc 2.14, released the 2011-05-31). I don't know if this issue is a duplicate of glibc bug 12453. Could faulthandler cause problems ... faulthandler creates two locks at startup. faulthandler.enable() (e.g. called by regrtest when running the the test suite) creates a thread and changes the signal mask of this thread (to ignore all signals). I don't see how faulthandler can be linked to this issue, but yes, it might be the linked to this issue. In your case, faulthandler only reads a TLS on a crash. So faulthandler is not the cause of the initial crash, but it may cause a new fault :-) -- Apparently, Etch on ARM uses linuxthread instead of NPTL ... FYI you can also try to print sys.thread_info (which should give the same information, NPTL 2.7). NPTL has know issues: see for example the Python issue #4970. NPTL is old and has been replaced by pthread in the glibc on Linux. -- Traceback with faulthandler disabled: ... How did you disabled faulthandler? -- Version 9d658f000419, which is pre-faulthandler, runs without segfaults. If it's a regression, you must try hg bisect! It is slow but it is fully automated! Try something like: hg bisect -r hg bisect -b 9d658f000419 hg bisect -c 'make ./python -m test test_urllib2_localnet test_robotparser test_nntplib' -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12936 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11457] Expose nanosecond precision from system calls
STINNER Victor victor.stin...@haypocalc.com added the comment: If a two-ints representation is considered necessary, I'd favor a rational number (numerator, denominator) over a pair (second, subsecond); this would also support 2**-32 fractions (as used in NTP !!!). Which OS uses NTP timestamps in stat()? Or are you thinking about other functions? As yet another approach, I propose a set of st_[cma]time_nsec fields which always give an int representing the integral part of the time stamp in nanoseconds since the epoch. As I wrote before, I would prefer to keep the same number of fields in the Python structure and in the C structure, but I don't have a strong opinion on this choice. If we want to stay close the C API, we can use a namedtuple: s = os.stat(filename, time_struct=True) ctime = s.ctime.tv_sec + ctime + s.ctime.tv_nsec * 1-e9 Or maybe: s = os.stat(filename, time_struct=True) ctime = s.ctime.sec + ctime + s.ctime.nsec * 1-e9 A namedtuple is not a good idea if we want to support other time resolutions, because some developer may write s.ctime[0] + ctime + s.ctime[1] without taking care of the time resolution. Because Windows uses a resolution of 100 ns and POSIX uses 1 ns, I still don't see why we should support something else. If we use the following API, we can still add other resolutions later (using a new argument): s = os.stat(filename, nanoseconds=True) sec, nsec = s.ctime ctime = sec + nsec * 1e-9 What should be done if the OS only has a resolution of 1 sec? Raise an exception, or use nsec=0? Same question if we add *_nsec fields: these fields are optional, or always present? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11457 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12945] ctypes works incorrectly with _swappedbytes_ = 1
Meador Inge mead...@gmail.com added the comment: Would you mind explaining your use case and why ctypes won't fit it? Maybe there is something that can be fixed. FWIW, I agree that the overloading of 'size' is unnecessary. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12945 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7201] double Endian problem and more on arm
Meador Inge mead...@gmail.com added the comment: I ran the ctypes tests on Debian GNU/Linux 5.0.8 (lenny) on an ARMv5tejl Versatile kernel and everything passed. Is anyone else still seeing errors? -- assignee: theller - nosy: +meadori -theller ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7201 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12959] Add 'ChainMap' to collections.__all__
Raymond Hettinger raymond.hettin...@gmail.com added the comment: Thank you. -- nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
