[issue8300] Allow struct.pack to handle objects with an __index__ method.

Mark Dickinson added the comment: Committed (with some tabs in test_struct.py changed to spaces) to trunk in r79745. -- ___ Python tracker <http://bugs.python.org/issue8

[issue8300] Allow struct.pack to handle objects with an __index__ method.

Mark Dickinson added the comment: Merged to py3k in r79746. Meador, does this all look okay, now? -- resolution: -> accepted stage: patch review -> committed/rejected status: open -> pending ___ Python tracker <http://bugs.python.o

[issue8307] test_pep263 failure on OS X

Mark Dickinson added the comment: Yes, Benjamin's checkin seems to have fixed it for me, too. Thanks, Benjamin! There's still the issue of the Tkinter import changing the locale, but that seems to be out of Python's control. As far as I can tell, it happens when the module

[issue8309] Sin(x) is Wrong

Mark Dickinson added the comment: > Python 3.1.2 -- 32 bit gives sin(2^60) = -0.7391806966492228 Interesting. I get >>> sin(2.**60) -0.83064921763725463 On both OS X 10.6.3 (64-bit build) and OS X 10.5.something (32-bit build). But this is all down to the platform math librar

[issue8188] Unified hash for numeric types.

Mark Dickinson added the comment: New patch: - document and test sys.hash_info - document numeric hash definition (in Doc/library/stdtypes.rst; I'm not sure whether this is the best place for it) - document Decimal change (Decimal instances are now comparable with instances of

[issue8188] Unified hash for numeric types.

Mark Dickinson added the comment: I've refreshed the Rietveld patch as well: http://codereview.appspot.com/660042 -- ___ Python tracker <http://bugs.python.org/i

[issue8309] Sin(x) is Wrong

Mark Dickinson added the comment: > We could similarly take on porting and maintaining KC Ng's fdlibm Gulp. If we did that, I'd definitely want to push for dropping Python support for non-IEEE 754 systems. I'm not sure I've fully recovered from

[issue8188] Unified hash for numeric types.

Mark Dickinson added the comment: Yes, hash values are C longs, regardless of platform. I think that's probably too ingrained to consider changing it (we'd have to change hashes of all the non-numeric types, too). -- ___ Python trac

[issue8300] Allow struct.pack to handle objects with an __index__ method.

Mark Dickinson added the comment: Thanks. -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue8300> ___ ___ Python-bugs-list mai

[issue5479] Add an easy way to provide total ordering now that __cmp__ is deprecated/gone

Mark Dickinson added the comment: Yes, it's a standard mathematics term. http://en.wikipedia.org/wiki/Total_order -- nosy: +mark.dickinson ___ Python tracker <http://bugs.python.org/i

[issue7772] test_py3kwarn fails when running the whole test suite

Mark Dickinson added the comment: I very much appreciate flox's efforts here, but IMO we really need some more robust solution to the problem of (testing + global warning state). See also issue 4180. -- ___ Python tracker <http://bugs.py

[issue8257] Decimal constructor to accept float

Mark Dickinson added the comment: The decimal changes were implemented by Raymond in r79609 (trunk) and r79602 (py3k). For the fractions module changes, see issue 8294. -- assignee: mark.dickinson -> resolution: -> accepted stage: patch review -> committed/rejected sta

[issue5198] Strange DeprecationWarning behaviour in module struct

Mark Dickinson added the comment: The wrong location for the DeprecationWarnings was also fixed in trunk in r78690. I've backported the fix to release26-maint in r79834. I don't dare mess further with the warnings in a bugfix release; as Georg points out, the issues are fixe

[issue8014] Setting a T_INT attribute raises internal error

Mark Dickinson added the comment: Backported to 3.1 in r79838. -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/

[issue8259] left shift operator doesn't accepts long as second argument

Mark Dickinson added the comment: Patch that unoutrages Python attached: it allows shift counts of up to sys.maxsize in both left shift and right shift. I don't have a test for this, since the only tests I can think of (e.g. actually doing 1 << (2**31)) require > 270Mb of RAM

[issue8259] left shift operator doesn't accepts long as second argument

Mark Dickinson added the comment: Patch applied in r79843 (and added forgotten Misc/NEWS entry in r79844); merged to py3k in r79845. -- assignee: mark.dickinson -> type: -> feature request ___ Python tracker <http://bugs.python.org/

[issue8259] left shift operator doesn't accepts long as second argument

Mark Dickinson added the comment: By the way, this has nothing to do with int versus long (unless I'm misunderstanding the original issue); it's simply that large shift counts cause an OverflowError. I've added a note about this to the docs in r79852. -- resolu

[issue8328] longobject.c: silence warnings (Visual Studio)

Mark Dickinson added the comment: These all look fine to me. Please apply! -- assignee: -> skrah resolution: -> accepted ___ Python tracker <http://bugs.python.org/

[issue7947] Documentation of math.pow, math.hypot, and complex.__abs__

Mark Dickinson added the comment: Proposed update to math docs. -- keywords: +patch Added file: http://bugs.python.org/file16788/math_docs.patch ___ Python tracker <http://bugs.python.org/issue7

[issue7947] Documentation of math.pow, math.hypot, and complex.__abs__

Mark Dickinson added the comment: Thanks, Georg. Yes and No. Yes: Perhaps I should say something about signaling nans, but what was there was just nonsense. No: I'll drop the 'u' from behaviour, for the sake of consistency. -- ___

[issue7947] Documentation of math.pow, math.hypot, and complex.__abs__

Mark Dickinson added the comment: Too late! Committed in r79858 (trunk) through r79861 (release31-maint). I added a couple of sentences about signaling nans. Thanks for reviewing! -- resolution: -> fixed stage: -> committed/rejected status: open -&g

[issue7947] Documentation of math.pow, math.hypot, and complex.__abs__

Mark Dickinson added the comment: Rats. nan->NaN in r79871 through r79874. Then I reread your message... *NaN* -> Nan in r79875 (trunk); will merge to other branches tomorrow when my brain might be working again. -- status: closed -

[issue8314] test_ctypes fails in test_ulonglong on sparc buildbots

Mark Dickinson added the comment: It's surprising that test_ulonglong fails, while test_longlong passes: can the Linux Sparc ABI really be treating these two types differently? Maybe more information could be gained by supplying a more interesting test value than 42---some 8-byte value

[issue4484] struct: per item endianess specification

Mark Dickinson added the comment: I agree that this seems like something that would rarely be needed. If it's really necessary, it's possible to break up the format and do the packing/unpacking in fixed-endian pieces. -- nosy: +mark.dickinson resolution: -> rejected

[issue3081] Py_(X)SETREF macros

Mark Dickinson added the comment: I agree with Raymond about the Py_INCREF. I could see more uses for this macro without the Py_INCREF, especially for things like in-place arithmetic operations. The following pattern appears a lot in code like Objects/longobject.c: Old code: /* add one

[issue7355] Struct incorrectly compiles format strings

Mark Dickinson added the comment: > When and why things are padded usually depends on the compiler, OS, > and computer architecture. [...] Sure. The struct module has a rather simplistic set of rules for adding padding, but I believe that it manages to match the platform's C rules

[issue7947] Documentation of math.pow, math.hypot, and complex.__abs__

Changes by Mark Dickinson : -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue7947> ___ ___ Python-bugs-list mailing list Unsubscri

[issue7355] Struct incorrectly compiles format strings

Mark Dickinson added the comment: Many thanks for the patch. Applied (minus trailing whitespace :) in r80013. Leaving open to remind me to merge to other branches. -- versions: -Python 2.7 ___ Python tracker <http://bugs.python.org/issue7

[issue7355] Struct incorrectly compiles format strings

Mark Dickinson added the comment: Hmm. I note that the examples are for a big-endian machine. I wonder whether they should be converted to little-endian, given that most users are on x86 or x86_64 hardware these days. -- ___ Python tracker

[issue7355] Struct incorrectly compiles format strings

Mark Dickinson added the comment: Sure, if you want to. [Then I won't be able to reproduce what's in the docs on either of my machines. :) One's 32-bit big-endian; the other's 64-bit little-endian.] Merged your changes and subsequent twea

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Mark Dickinson added the comment: > This type of failure appears again in current builds: Unfortunately, I think you mean 'still' rather than 'again'. :) As far as I can tell, the failure's never gone away, though it may have been obscured by other failures fr

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Mark Dickinson added the comment: Should also modify regrtest to print out the result of the command getconf GNU_LIBPTHREAD_VERSION that Antoine suggested. -- ___ Python tracker <http://bugs.python.org/issue4

[issue6090] zipfile DeprecationWarning Python in 2.6, failure in 2.7

Mark Dickinson added the comment: [Martin] > I think the error message could be better, though; it should probably be a > ValueError. Do you mean a ValueError at the level of the struct module, or the zipfile module. I'd quite like to change all the exceptions raised by the struc

[issue5377] Strange behavior when performing int on a Decimal made from -sys.maxint-1

Mark Dickinson added the comment: Closing: it's too late for Python 2.x. -- resolution: -> out of date status: open -> closed ___ Python tracker <http://bugs.python

[issue7873] Remove precision restriction for integer formatting.

Mark Dickinson added the comment: Closing: it's too late for 2.x. -- resolution: -> out of date status: open -> closed ___ Python tracker <http://bugs.python

[issue3451] Asymptotically faster divmod and str(long)

Mark Dickinson added the comment: Unassigning myself for now. The most recent patch still needs work before it can be considered for inclusion. -- assignee: mark.dickinson -> status: open -> languishing versions: -Python 2.7 ___ Python t

[issue8188] Unified hash for numeric types.

Mark Dickinson added the comment: Many thanks for reviewing, Stefan, and for the patch. Here's an updated patch: - specify 32-bit/64-bit C long rather than 32-bit/64-bit machine - apply hash->hash_ fix to Python hash recipe - use _PyHASH_MODULUS instead of _PyHASH_MASK througho

[issue8188] Unified hash for numeric types.

Changes by Mark Dickinson : -- assignee: -> mark.dickinson ___ Python tracker <http://bugs.python.org/issue8188> ___ ___ Python-bugs-list mailing list Un

[issue8188] Unified hash for numeric types.

Mark Dickinson added the comment: ... and here's the actual patch... Forget my own head next. :) -- Added file: http://bugs.python.org/file16907/numeric_hash7.patch ___ Python tracker <http://bugs.python.org/i

[issue8188] Unified hash for numeric types.

Changes by Mark Dickinson : -- priority: -> normal ___ Python tracker <http://bugs.python.org/issue8188> ___ ___ Python-bugs-list mailing list Unsubscri

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Mark Dickinson added the comment: > Since linuxthreads is no longer maintained, I'm afraid we can't do much > about this. Agreed. But I think it's still worth trying to narrow down (and possibly work around) the cause of failure, just so that we can make this buildbot

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Mark Dickinson added the comment: Results of my simple-minded strategy (see r80033-4, r80037, r80042, r80045, r80047-51): test_execvpe_with_bad_program in ExecTests by itself is enough to trigger the signal 32 error (in combination with test_wait3). See: http://www.python.org/dev/buildbot

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Mark Dickinson added the comment: Here's some fairly minimal Python code that produces the signal: ### begin example ### import os import time import _thread try: os.execv('/usr/bin/dorothyq', ['dorothyq']) except OSError: pass def f(): time.sleep(1.0)

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Mark Dickinson added the comment: Okay, I think I've got as far as I can, but if anyone else wants to hack on this, please do. The branch name is py3k-issue4970 In that branch: - there's an extra test Lib/test/test_issue4970 that demonstrates the signal 32 failure

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Mark Dickinson added the comment: Skipping test_execvpe_with_bad_program sounds good to me. I'd ideally like to understand why 3.x is failing where 2.x is happy, but life's too short to stuff a mushroom. -- ___ Python trac

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Mark Dickinson added the comment: > I think it's simply because we didn't test a wrong program path with execve > in 2.X version of test_os. D'oh! Thank you very much. I'm happy now: my mushroom's stuffed. :) -- __

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Mark Dickinson added the comment: Victor, that patch looks fine to me. Do you want to go ahead and apply it, and add the skip to test_execvpe_with_bad_program ? The fix should be backported to 3.1, but not to 2.x (I think), since we don't have a problem there, and arguably th

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Mark Dickinson added the comment: And just for reference, http://www.python.org/dev/buildbot/builders/x86%20gentoo%203.x/builds/2192 shows that the relevant versions on this machine are: glibc 2.3.4 linuxthreads-0.10 and from http://www.python.org/dev/buildbot/builders/x86%20gentoo%203.x

[issue8326] Cannot import name SemLock on Ubuntu lucid

Mark Dickinson added the comment: As an aside, I don't really understand why the sem_open check is failing on the build machine. 'man sem_overview' says: "On a system with Linux 2.6 and a glibc that provides the NPTL threading implementation, a complete implementation of

[issue7384] curses crash on FreeBSD

Mark Dickinson added the comment: I'm looking at this again, after installing FreeBSD 8.0/amd64 in a VM. I've reduced Lib/test/test_curses.py to the following 9 lines: import rlcompleter import curses f = open('mytempfile', 'w+b') stdscr = curses.inits

[issue7384] curses crash on FreeBSD

Mark Dickinson added the comment: Here's the top of the backtrace. (Thanks asmodai for helping me out with working out how to build a FreeBSD system ncurses with debugging information.) #0 0x000801460714 in cannot_delete (win=0x80116b1d0) at /usr/src/lib/ncurses/ncu

[issue7384] curses crash on FreeBSD

Mark Dickinson added the comment: > Could I get a login on the buildbot to make a fix? I think David Bolen (db3l) is the maintainer. David? -- ___ Python tracker <http://bugs.python.org/iss

[issue7384] curses crash on FreeBSD

Mark Dickinson added the comment: > Here's a possible patch Thanks. I'll give it a try on my FreeBSD VM and report back. BTW, did you mean to include the threading change in that patch? -- ___ Python tracker <http://bugs.pyth

[issue7384] curses crash on FreeBSD

Mark Dickinson added the comment: With that patch, I'm still getting the core dump (with the traceback looking pretty much as it did before). When I traced through this with gdb, I didn't see stdscr getting set to 0 at any point. Unless I missed any, the only curses library call

[issue1766304] improve xrange.__contains__

Mark Dickinson added the comment: I suggest closing this: it's been implemented (for range) in Python 3.x, and I think it's too late for 2.x now. -- ___ Python tracker <http://bugs.python.org

[issue1766304] improve xrange.__contains__

Changes by Mark Dickinson : -- versions: -Python 3.2 ___ Python tracker <http://bugs.python.org/issue1766304> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue7384] curses crash on FreeBSD

Mark Dickinson added the comment: > Mark, did your initial backtrace look like this: No; the segfault was definitely happening in delwin rather than putwin. But I did see something like your backtrace when I tried to use ncurses from ports (installed in /usr/local) rather than the sys

[issue8419] dict constructor allows invalid identifiers in **kwargs

New submission from Mark Dickinson : In all versions of CPython right now, the following works. >>> dict({1:2}, **{3:4}) {1: 2, 3: 4} Other Python implementations raise TypeError for this; CPython should probably do the same, beginning with deprecating this behaviour in Pytho

[issue8417] bytes and bytearray constructors raise TypeError for very large ints

Changes by Mark Dickinson : -- nosy: +mark.dickinson ___ Python tracker <http://bugs.python.org/issue8417> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue8419] dict constructor allows invalid identifiers in **kwargs

Mark Dickinson added the comment: The issue applies to dict.update as well: >>> d = {1:2} >>> d.update({3:4}, **{5:6}) >>> d {1: 2, 3: 4, 5: 6} -- ___ Python tracker <ht

[issue8419] dict constructor allows invalid identifiers in **kwargs

Mark Dickinson added the comment: Update: IronPython also produces a TypeError here (thanks Michael Foord and Dino Viehland). -- ___ Python tracker <http://bugs.python.org/issue8

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Mark Dickinson added the comment: Fix merged to release31-maint in r80119. Thanks, Victor. -- components: +Tests resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> crash ___ Python tracker <http://

[issue7811] [decimal] ValueError -> TypeError in from_tuple

Mark Dickinson added the comment: It's a bit ambiguous: the object being supplied to the Decimal constructor does have the right type (tuple), but the wrong contents (i.e., value). So you could argue either way on this, I guess. -- assignee: -> mark.d

[issue8419] dict constructor allows invalid identifiers in **kwargs

Mark Dickinson added the comment: > I agree with Guido that we just call this an undefined, implementation > specific behavior. Actually I think that was exactly what Guido was *disagreeing* with. :) -- ___ Python tracker <http://bugs.p

[issue7811] [decimal] ValueError -> TypeError in from_tuple

Mark Dickinson added the comment: >From both practical and purity points of view I think I prefer TypeError for >the cases Stefan gives: if you're passing a float for the sign, then you've >somehow ended up with the wrong type for that sign, and that's a TypeError &

[issue7811] [decimal] ValueError -> TypeError in from_tuple

Mark Dickinson added the comment: Given the lack of agreement here, I propose that we just leave the current code as it is; it doesn't seem like a big issue to me, and we should resist messing with code that isn't clearly broken. -- resolution: -> wont fix status: op

[issue7384] curses crash on FreeBSD

Mark Dickinson added the comment: That patch works for me, too. Nice! > It seems that FreeBSD has problems with the fact that readline.so is > linked with -lreadline and -lncursesw (why?). Good question... -- ___ Python tracker

[issue8424] Test assumptions for test_itimer_virtual and test_itimer_prof

Mark Dickinson added the comment: > test_itimer_virtual assumes that a process must get 0.3s of virtual > time within 5s of real time. This is not true [...] I agree it's not a good test, especially when run on machines that are heavily loaded, or on an OS running in VM. I can

[issue8424] Test assumptions for test_itimer_virtual and test_itimer_prof

Mark Dickinson added the comment: > Can't we try to increase the timeout step by step? Eg. 5 sec => 10 sec, > > then 15 sec, etc. until the buildbots turn green? I think you'd need an increase of an order of magnitude or two (possibly more) in some cases to make this

[issue2706] datetime: define division timedelta/timedelta

Mark Dickinson added the comment: Why is divmod(timedelta, timedelta) supported but not timedelta % timedelta? I think if one is implemented, the other should be too. -- ___ Python tracker <http://bugs.python.org/issue2

[issue2706] datetime: define division timedelta/timedelta

Mark Dickinson added the comment: By the way, the patch looks good to me, as far as it goes, and I'm +1 on adding all this. I only have the tiniest of nits: - the patch deletes a line at the top of Lib/test/test_datetime.py, for no apparent reason - in delta_add, I think the adde

[issue2706] datetime: define division timedelta/timedelta

Mark Dickinson added the comment: Tennessee, are you still tracking this issue? If not, can I steal it from you. :) > I found out that timedelta % int is not supported in the > released versions while timedelta // int is. Mmm. Interesting. :) I think it would be fine to add tim

[issue2706] datetime: define division timedelta/timedelta

Changes by Mark Dickinson : Removed file: http://bugs.python.org/file16995/unnamed ___ Python tracker <http://bugs.python.org/issue2706> ___ ___ Python-bugs-list mailin

[issue2706] datetime: define division timedelta/timedelta

Mark Dickinson added the comment: Hmm. Having timedelta // int work is *really* peculiar, since it can only be made sense of with reference to some implicit particular chosen unit of time; in this case, that unit of time is apparently microseconds, as far as I can tell. Surely there

[issue8424] Test assumptions for test_itimer_virtual and test_itimer_prof

Mark Dickinson added the comment: Stefan, you move too fast! I was going to review that second patch, honest! I'm not 100% sure (David can probably confirm), but I think your sys.stdout.write should be a sys.stderr.write. -- status: pending -&

[issue8469] struct - please make sizes explicit

Mark Dickinson added the comment: As Alexander says, *all* the sizes except those for bytes are platform-dependent: there are platforms where sizeof(short) isn't 2, for example, or where sizeof(int) isn't 4. It would be possible to add the 'standard' sizes to that t

[issue1289118] timedelta multiply and divide by floating point

Mark Dickinson added the comment: > The timedelta type is fundamentally an integer type. I disagree strongly with this, and find this a bizarre point of view. Regardless of how the timedelta is stored internally, it's used to represent physical times. I doubt there are many appl

[issue1083] Confusing error message when dividing timedelta using /

Mark Dickinson added the comment: I think it's fine to do the division and round the result to the nearest whole number of microseconds. I don't see any good reason for disallowing timedelta / int (or even timedelta / float). -- nosy: +mark

[issue1083] Confusing error message when dividing timedelta using /

Changes by Mark Dickinson : -- type: behavior -> feature request versions: +Python 3.2 -Python 2.7, Python 3.0 ___ Python tracker <http://bugs.python.org/iss

[issue1289118] timedelta multiply and divide by floating point

Mark Dickinson added the comment: Not sure why this is marked for 3.3. -- versions: +Python 3.2 -Python 3.3 ___ Python tracker <http://bugs.python.org/issue1289

[issue1289118] timedelta multiply and divide by floating point

Mark Dickinson added the comment: I'll take a look at Skip's patch. -- assignee: -> skip.montanaro ___ Python tracker <http://bugs.python.

[issue1289118] timedelta multiply and divide by floating point

Mark Dickinson added the comment: Whoops. I meant to assign this to me, not Skip. -- assignee: skip.montanaro -> mark.dickinson ___ Python tracker <http://bugs.python.org/issue1

[issue2706] datetime: define division timedelta/timedelta

Mark Dickinson added the comment: Stealing from Tennessee... Patch committed to py3k in r80290, r80291, with some minor tweaks and fixes: - rename delta_remailder to delta_remainder - fix memory leak in delta_remainder - add whatsnew entry for docs - note that timedelta // timedelta

[issue2706] datetime: define division timedelta/timedelta

Mark Dickinson added the comment: Grr. s/whatsnew/versionadded/ -- ___ Python tracker <http://bugs.python.org/issue2706> ___ ___ Python-bugs-list mailin

[issue8469] struct - please make sizes explicit

Mark Dickinson added the comment: Thanks for the doc suggestions. Actually, the current docs were revised recently; this issue is a helpful reminder to me that those doc revisions need to be backported. :) If you want to see the current docs, look at: http://docs.python.org/dev/library

[issue7384] curses crash on FreeBSD

Mark Dickinson added the comment: This patch looks good to me, assuming that the buildbots are happy. I agree that this seems like a sensible solution for now, even if it means limiting users to ncurses rather than ncursesw. I was initially a bit surprised that it works on OS X, since OS X

[issue8188] Unified hash for numeric types.

Mark Dickinson added the comment: > Regarding a hash function for complex types, I think documenting the > existing behavior for PyComplex is sufficient. The magic number 103 > > could be documented in hash_info as 'multiplier' and _PyHASH_MULTIPLIER. Seems reaso

[issue2706] datetime: define division timedelta/timedelta

Mark Dickinson added the comment: Ah, yes. Sorry, Victor! There's actually no acknowledgement in Misc/NEWS: it's not *that* common to put acknowledgements there, and I'm not sure it's necessary here, but I've

[issue1673409] datetime module missing some important methods

Mark Dickinson added the comment: Closing this as a duplicate of issue 2736, as suggested. I'll combine the nosy lists. (BTW, as well as the newly introduced division methods, td.tosecs already exists, except that it's spelt td.total_seconds.) -- resolution: -> dup

[issue2736] datetime needs an "epoch" method

Mark Dickinson added the comment: Close issue 1673409 as a duplicate of this one; combining nosy lists. -- nosy: +catlee, erik.stephens, guettli, jribbens, mark.dickinson, pitrou, skip.montanaro, srittau, steve.roberts, tim_one, tomster ___ Python

[issue2736] datetime needs an "epoch" method

Changes by Mark Dickinson : -- nosy: +amaury.forgeotdarc ___ Python tracker <http://bugs.python.org/issue2736> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue8314] test_ctypes fails in test_ulonglong on sparc buildbots

Mark Dickinson added the comment: I was going to say that I think that this issue can be closed now... ... but the src/sparc/v8.S file still looks wrong to me: Martin fixed one missing FFI_TYPE_UINT64 case, but it looks to me as though there's another one, in ffi_call_v8. The code sta

[issue1673409] datetime module missing some important methods

Mark Dickinson added the comment: > Aggrrr! How did that slip in? :-) Blame Antoine. :) (See issue 5788 and revision 76529.) > Shouldn't td.total_seconds() return Decimal? Maybe in py4k ... Yes, that would have been nice. I'm not sure that the Decimal type is well-establ

[issue8540] Make Context._clamp public in decimal module

New submission from Mark Dickinson : The Context class in the decimal module has a hidden _clamp attribute, that controls whether to clamp values with large exponents. (Clamping a Decimal value involves adding extra significant zeros to decrease its exponent, while not altering the numeric

[issue8540] Make Context._clamp public in decimal module

Changes by Mark Dickinson : -- priority: -> normal ___ Python tracker <http://bugs.python.org/issue8540> ___ ___ Python-bugs-list mailing list Unsubscri

[issue7833] Bdist_wininst installers fail to load extensions built with Issue4120 patch

Changes by Mark Hammond : -- nosy: +mhammond ___ Python tracker <http://bugs.python.org/issue7833> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue8005] datetime's comparison methods do not return NotImplemented when they should

Mark Dickinson added the comment: See issue 5516 for a related issue. -- nosy: +belopolsky, mark.dickinson ___ Python tracker <http://bugs.python.org/issue8

[issue8540] Make Context._clamp public in decimal module

Mark Dickinson added the comment: Hmm. Yes, the spec itself is rather vague on the subject of clamping, so I withdraw my claim that clamping is necessary for compliance with the spec. It *is* necessary to make the those testcases with 'clamp=1' pass, though. So from the point

[issue8540] Make Context._clamp public in decimal module

Mark Dickinson added the comment: Re: ExtendedContext, the comments in decimal.py say: # Pre-made alternate contexts offered by the specification # Don't change these; the user should be able to select these # contexts and be able to reproduce results from other implementations # of the

[issue8060] PEP 3101 string formatting missing engineering presentation type for floating point

Mark Dickinson added the comment: After the all-important issue of what letter to use (the folks on the python-list thread suggested 'm', and it seems as good a letter as any, so I'll use it in the examples below), there are some open questions: (1) The exact form of the out

<    15   16   17   18   19   20   21   22   23   24   >