ect the effect of the heuristic, but should be, with whatever
> additional change is made.
True - and always was.
> In the commit message for revision 26661, which added the heuristic, Tim
> Peters wrote "While I like what I've seen of the effects so far, I still
> consider this
[Nick Coghlan]
> ...
> Hmm, I've been using difflib.SequenceMatcher for years in a serial bit
> error rate tester (with typical message sizes ranging from tens of
> bytes to tens of thousands of bytes) that occasionally gives
> unexpected results. I'd been blaming hardware glitches (and, to be
> fa
[Antoine Pitrou]
> I don't think 2.7 should get any change at all here. Only 3.2 should be
> modified. As Tim said, difflib works ok for its intended use (regular
> text diffs).
That was the use case that drove the implementation, but it's going
too far to say that was the only "intended" case. I
[Terry Reedy]
> I had considered the possibility of option A for 2.7 and A & C for 3.2. But
> see below.
>
> Since posting, I did an experiment with a 700 char paragraph of text (the
> summary from the post) compared to an 'edited' version. I did the
> comparision with and without the current heuri
[Tim]
>> ...
>> BTW, it's not clear whether ratio() computes a _useful_ value in the
>> presence of junk, however that may be defined.
[Terry Reedy]
> I agree, which is one reason why one should be to disable auto-junking.
Yup.
> There are a number of statistical methods for analyzing similarity
[Steven D'Aprano]
>> 4. I normally dislike global flags, but this is one time it might be
>> less-worse than the alternatives.
>>
>> Modify SequenceMatcher to test for the value of a global flag,
>> defaulting to False if it doesn't exist.
>> ...
>> The flag will only exist if the caller explicitly
[Nick Coghlan]
> You're right, I was misremembering how SequenceMatcher works.
>
> Terry's summary of the situation seems correct to me - adding a new
> flag to the constructor signature would mean we're taking a silent
> failure ("the heuristic makes my code give the wrong answer on 2.7.0")
> and
Yikes - Mark has done terrific work in some very demanding areas, &
I'd hate to see him feel unwelcome. So that's my advice: find a way
to smooth this over. You're welcome ;-)
[Guido]
>> ...
>> I understand the desire to keep dirty laundry in. I would like to keep
>> it in too. Unfortunately th
Looks like 2.7 changes introduced to exempt dicts and tuples from
cyclic gc if they obviously can't be in cycles has some unintended
consequences. Specifically, if an extension module calls
PyObject_GC_UnTrack() on a dict it _does not want tracked_, Python can
start tracking the dict again.
I ass
[Tim]
>> I assume this is unintended because (a) the docs weren't changed to
>> warn about this; and, (b) it's wrong ;-)
[Martin v. Löwis]
> It seems Jim is happy with (or has at least accepted) the behavior
> change. Would you still like to see it fixed (or, rather, have the
> 2.6 state restored)
[Anthony Baxter]
> Hm. Would it be a smaller change to expose head_mutex so that the
> external module could use it?
No, in part because `head_mutex` may not exist (depends on the build
type). What an external module would actually need is 3 new public C
API functions, callable workalikes for pys
[Neil Schemenauer]
> The bug was reported by Armin in SF #1333982:
>
> the literal -2147483648 (i.e. the value of -sys.maxint-1) gives
> a long in 2.5, but an int in <= 2.4.
That actually depends on how far back you go. It was also a long "at
the start". IIRC, Fred or I added hackery to
Just to make life harder ;-), I should note that code, docs and tests
for sys._current_frames() are done, on the tim-current_frames branch.
All tests pass, and there are no leaks in the new code. It's just a
NEWS blurb away from being just another hectic release memory :-)
[Neal Norwitz]
> There hasn't been much positive response (in the original thread or
> here).
Do note that there was little response of any kind, but all it got was
positive. It's not sexy, but is essential for debugging deadlocks.
If you ask for positive response, you'll get some -- the use is
o
As noted in
http://mail.python.org/pipermail/python-dev/2006-May/065478.html
it looks like we need a new Python C API function to make new warnings
from the struct module non-useless. For example, runnning
test_zipfile on Windows now yields
"""
test_zipfile
C:\Code\python\lib\struct.py:63: D
[Raymond]
>> FWIW, I think this patch should go in. The benefits are
>> obvious and real.
[Anthony Baxter]
> Yep. I'm going to check it in, unless someone else beats me to it in
> the next couple of hours before the b2 freeze.
I'll merge it from my branch right after I send this email. It still
[Scott Dial]
> Wouldn't this function be better named sys._getframes since we already
> have a sys._getframe for getting the current frame?
http://mail.python.org/pipermail/python-dev/2005-March/051887.html
The first & only name suggested won. As it says there, I usually have
no appetite for
[Neal Norwitz]
> ...
> That leaves 1 unexplained failure on a Windows bot.
It wasn't my Windows bot, but I believe test_profile has failed
(rarely) on several of the bots, and in the same (or very similar)
way. Note that the failure went away on the Windows bot in question
the next time the tests
[Raymond Hettinger]
> ...
> If the current approach gets in their way, the C implementers should feel
> free to
> make an alternate design choice.
I expect they will, eventually. Converting this to C is a big job,
and at the NFS sprint we settled on an "incremental" strategy allowing
most of the
...
[Raymond]
>> Even then, we need to drop the concept of having the flags as counters
>> rather than booleans.
[Georg Brandl]
> Yes. Given that even Tim couldn't imagine a use case for counting the
> exceptions, I think it's sensible.
That's not it -- someone will "find a use" for anything. I
Rarely I'll be running the Python tests in my sandbox from a DOS box,
and the test run will just end. Like so:
C:\Code\python\PCbuild>python -E -tt ../lib/test/regrtest.py -uall -rw
test_softspace
test_codecmaps_kr
...
test_float
test_userdict
C:\Code\python\PCbuild>
No indication of success o
[Martin v. Löwis]
> Didn't you know that you signed in to run arbitrary viruses, worms, and
> trojan horses when you added your machine to the buildbot infrastructure
> :-?
Hey, I signed up for that when I bought a Windows box :-)
> You just haven't seen buildbot erasing your hard disk and fillin
Georg discovered that test_uuid didn't run any tests, and fixed that
on Thursday. A number of buildbots have failed that test since then.
My XP box appears unique among the Windows buildbots in failing. It
always fails like so:
AssertionError: different sources disagree on node:
from source
[Tim]
> ... uuid.getnode() tries things in this order on Windows:
>
> getters = [_windll_getnode, _netbios_getnode, _ipconfig_getnode]
>
> It's only the first one that returns the bogus 0x00038a15; both of
> the latter return 0x00B2B7BF [the correct MAC address for my
> network card
[Armin Rigo]
> There is an oversight in the design of __index__() that only just
> surfaced :-( It is responsible for the following behavior, on a 32-bit
> machine with >= 2GB of RAM:
>
> >>> s = 'x' * (2**100) # works!
> >>> len(s)
> 2147483647
>
> This is because PySequence_Rep
[Tim]
>>> ...
>>> This is a mess :-)
[Nick Coghlan]
>> I've been trawling through the code a bit, and I don't think it's as bad as
>> all that.
[also Nick, but older & wiser ;-)]
> Damn, it really is a mess. . . nb_index returns the Pyssize_t directly,
Bingo. It's a /conceptual/ mess. Best I c
[Bruce Christensen]
> We seem to have stumbled upon some strange behavior in cPickle's memo
> use when pickling instances.
>
> Here's the repro:
>
> [mymodule.py]
> class C:
> def __getstate__(self): return ('s1', 's2', 's3')
>
> [interactive interpreter]
> Python 2.4.3 (#69, Mar 29 2006, 17:35
[Neal Norwitz]
> I'm wondering if the following change should be made to
> Include/weakrefobject.h:
Yes.
> -PyAPI_FUNC(long) _PyWeakref_GetWeakrefCount(PyWeakReference *head);
> +PyAPI_FUNC(Py_ssize_t) _PyWeakref_GetWeakrefCount(PyWeakReference *head);
>
> And the 2 other files which use this (w
[Brett Cannon]
> My [EMAIL PROTECTED] SSH key should be removed since my internship is now
> over.
Thank you for being conscientious. While it feared death, your key
didn't complain about being deleted, and right before it vanished I
saw the most astonishing look of profound peace passing over it
[Chris McDonough, on 7/28/06]
> From the initial bugreport
> (http://sourceforge.net/tracker/index.php?
> func=detail&aid=1112549&group_id=5470&atid=105470)
>
> """
> Various parts of cgi.FieldStorage call its
> "read_lines_to_outerboundary", "read_lines" and
> "skip_lines" methods. These methods
[Armin]
>> Maybe the user should just be able to return any integer value from a
>> custom __hash__() without having to worry about not exceeding
>> sys.maxint.
>>
>> After all the returned value has no real meaning. If a long is returned
>> we could take its hash again, and use that number intern
[Georg Brandl, on
http://python.org/sf/1523610 - PyArg_ParseTupleAndKeywords
potential core dump
]
> This one's almost fixed if we can decide what to do with "levels".
> I wrote some time ago:
>
> """
> With respect to this bug (which is about stack issues in Python/getargs.c
> involving misus
[tomer filiba]
> while working on a library for raising exceptions in the context
> of another thread, i've come across a bug in PyThreadState_SetAsyncExc.
> if i raise an instance, sys.exc_info() confuses the exception value for
> the exception type, and the exception value is set None. if i raise
We're getting an awful lot of these turds at the ends of test runs now:
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
File "C:\Code\bb_slave\trunk.peters-windows\build\lib\atexit.py",
line 24, in _run_exitfuncs
func(*targs, **kargs)
File "C:\Code\bb_slave\trunk.peters-
[Travis E. Oliphant]
> Right now throughout the Python code it is assumed that
> sizeof(Py_ssize_t) <= sizeof(long).
If you find any code like that, it's a bug. Win64 is a platform where
it's false.
___
Python-Dev mailing list
Python-Dev@python.org
http
[Greg Ewing]
> Surely there's some compromise that would allow
> recently-used ints to be kept around, but reclaimed
> if memory becomes low?
Not without losing /something/ we currently enjoy. The current int
scheme has theoretically optimal memory use too, consuming 12 bytes
per int object on a
[Steve Holden]
>> Reasonable enough, but I suspect that Thomas' suggestion might save us
>> from raising false hopes. I'd suggest that the final release
>> announcement point out that this is the first release containing
>> specific support for 64-bit architectures (if indeed it is)
[Martin v. Löw
Note that there are already three PEPs related to speeding dict-based
namespace access; start with:
http://www.python.org/dev/peps/pep-0280/
which references the other two.
The "normal path" through dict lookups got faster since there was a
rash of those, to the extent that more complication
[Guido]
> There's a unit test "test_mutants" which I don't understand. If anyone
> remembers what it's doing, please contact me -- after ripping out
> dictionary ordering in Py3k,
Is any form of dictionary comparison still supported, and, if so, what
does "dict1 cmp_op dict2" mean now?
> it stops
[David Hopwood]
>> CPython should be fixed anyway. The correct fix is
>> "if (y == -1 && x < 0 && (unsigned long)x == -(unsigned long)x)".
Note that this was already suggested in the bug report.
[Thomas Wouters]
> Why not just "... && x == LONG_MIN"?
In full,
if (y == -1 && x == LONG_MIN)
[David Hopwood]
> (CPython has probably only been tested on 2's complement systems anyway,
Definitely so. Are there any boxes using 1's-comp or sign-magnitude
integers anymore? Python assumes 2's-comp in many places.
> but if we're going to be pedantic about depending only on things in the
> C
[Anthony Baxter]
> Regardless of whether we consider gcc's behaviour to be correct or not,
It is correct, but more to the point it's, umm, /there/ ;-)
> I do agree we need a fix for this in 2.5 final. That should also be
> backported to
> release24-maint for the 2.4.4 release, and maybe release2
[Thomas Wouters]
>>> Why not just "... && x == LONG_MIN"?
[Tim Peters]
>> it's better (when possible) not to tie the code to that `x` was
>> specifically declared as type "long" (e.g., just more stuff that will
>> break if Python d
[Laszlo (Laca) Peter]
> I work in the team that delivers python on Solaris. Recently we've
> been getting requests for delivering python in 64-bit as well
> as in 32-bit. As you probably know, Solaris can run 64-bit and
> 32-bit binaries on the same system, but of course you can't mix and
> match
[Andreas Raab]
> I'm curious if there is any interest in the Python community to achieve
> better cross-platform math behavior. A quick test[1] shows a
> non-surprising difference between the platform implementations.
> Question: Is there any interest in changing the behavior to produce
> identical
[Tim Peters]
>> Speaking of which, I saw no feedback on the proposed patch in
>>
>> http://mail.python.org/pipermail/python-dev/2006-August/068502.html
>>
>> so I'll just check that in tomorrow.
[Anthony Baxter]
> This should also be backported to relea
upto, sep, rest
in whatever order they apply. I think of a partition-like function as
starting at some position and matching "up to" the first occurence of
the separator (be that left or right or diagonally, "up to" is
relative to the search direction), and leaving "the rest" alone. The
docs
[Tim Peters]
>> Package a Python wrapper and see how popular it becomes. Some reasons
>> against trying to standardize on fdlibm were explained here:
>>
>>http://mail.python.org/pipermail/python-list/2005-July/290164.html
[Andreas Raab]
> Thanks, these are good
[Eric V. Smith]
> [I hope this belongs on python-dev, since it's about the design of
> something. But if not, let me know and I'll post to c.l.py.]
>
> I'm willing to file a bug report and patch on this, but I'd like to know
> if it's by design or not.
>
> In datetimemodule.c, the function wrap_st
[Dino Viehland]
> We've noticed a strange occurance on Python 2.4.3 w/ the floating point
> value 1.79769313486232e+308 and how it interacts w/ a .pyc. Given x.py:
>
> def foo():
> print str(1.79769313486232e+308)
> print str(1.79769313486232e+308) == "1.#INF"
>
>
> The 1st time yo
[Dino Viehland]
> FYI I've opened a bug against the VC++ team to fix their round tripping on
> floating
> point values (doesn't sound like it'll make the next release, but hopefully
> it'll make it
> someday).
Cool! That would be helpful to many languages implemented in C/C++
relying on the pla
[Martin v. Löwis]
> ...
> Can somebody remember what the reason is to invoke cmd.exe (or COMSPEC)
> in os.popen?
Absolutely necessary, as any number of shell gimmicks can be used in
the passed string, same as on non-Windows boxes; .e.g.,
>>> import os
>>> os.environ['STR'] = 'SSL'
>>> p = os.pope
[Armin Rigo]
>> There are more cases of signed integer overflows in the CPython source
>> code base...
>>
>> That's on a 64-bits machine:
>>
>> [GCC 4.1.2 20060715 (prerelease) (Debian 4.1.1-9)] on linux2
>> abs(-sys.maxint-1) == -sys.maxint-1
><
>> Humpf! Looks like one person or two need
[Neal Norwitz]
>> I'm getting a crash when running test_builtin and test_calendar (at
>> least) with gcc 4.1.1 on amd64. It's happening in pymalloc, though I
>> don't know what the cause is. I thought I tested with gcc 4.1 before,
>> but probably would have been in debug mode.
Neil, in context i
[Neal Norwitz]
> It looks like %zd of a negative number is treated as an unsigned
> number on OS X, even though the man page says it should be signed.
>
> """
> The z modifier, when applied to a d or i conversion, indicates that
> the argument is of a signed type equivalent in size to a size_t.
> "
[EMAIL PROTECTED]
> If C90 doesn't distinguish -0.0 and +0.0, how can Python?
With liberal applications of piss & vinegar ;-)
> Can you give a simple example where the difference between the two is apparent
> to the Python programmer?
Perhaps surprsingly, many (well, comparatively many, compared
[EMAIL PROTECTED]
> Can you give a simple example where the difference between the two is apparent
> to the Python programmer?
BTW, I don't recall the details and don't care enough to reconstruct
them, but when Python's front end was first changed to recognize
"negative literals", it treated +0.0
[Tim]
>> Someone (Fred, I think) introduced a front-end optimization to
>> collapse that to plain LOAD_CONST, doing the negation at compile time.
> I did the original change to make negative integers use just LOAD_CONST, but I
> don't think I changed what was generated for float literals. That co
[Skip]
> I checked in a change to Doc/lib/libcsv.tex on the trunk yesterday, then
> tried backporting it to the release25-maint branch but failed due to
> permission problems. Thinking it might be lock contention, I waited a few
> minutes and tried a couple more times. Same result. I just tried
[Skip]
> Thanks Georg & Tim. That was indeed the problem. I don't know why I've had
> such a hard time wrapping my head around Subversion.
I have a theory about that: it's software <0.5 wink>. If it's any
consolation, at the NFS sprint earlier this year, I totally blanked
out on how to do a me
I just noticed that the bsddb portion of Python fails to compile on
the 2.4 Windows buildbots, but for some reason the buildbot machinery
doesn't notice the failure:
"""
Compiling...
_bsddb.c
Linking...
Creating library .\./_bsddb_d.lib and object .\./_bsddb_d.exp
_bsddb.obj : warning LNK4217:
[Tim Peters]
>> I just noticed that the bsddb portion of Python fails to compile on
>> the 2.4 Windows buildbots, but for some reason the buildbot machinery
>> doesn't notice the failure:
[Martin v. Löwis]
> It's been a while that a failure to build some extens
[Tim]
> I just noticed that the bsddb portion of Python fails to compile on
> the 2.4 Windows buildbots, but for some reason the buildbot machinery
> doesn't notice the failure:
But it does now. This is the revision that broke the Windows build:
"""
r52170 | andrew.kuchling | 2006-10-05 14:49:36
[Gregory P. Smith]
> It seems bad form to C assert() within a python extension. crashing
> is bad. Just code it to not copy the string in that case. The
> exception type should convey enough info alone and if someone actually
> looks at the string description of the exception they're welcome to
[Tim]
>> Given that, the assert() in question looks fine to me:
>> ...
|>> Either that, or the original author (and me, just above) made an error
>> in analyzing what must be true at this point.
|
[David Hopwood]
> You omitted to state an assumption that sizeof(errTxt) >= 4, since size_t
> (and t
[Alexey Borzenkov]
>>> Umm... do you mean that spawn*p* on python 2.5 is an absolute no?
[Martin v. Löwis]
>> Yes. No new features can be added to Python 2.5.x; Python 2.5 has
>> already been released.
[Alexey Borzenkov]
> Ugh... that's just not fair. Because of this there will be no spawn*p*
> i
[Thomas Heller]
>> Yes. But I've switched machines since I last build an installer,
and I do not
>> have all of the needed software installed any longer, for example the Wise
>> Installer.
[Martin v. Löwis]
> Ok. So we are technically incapable of producing the Windows binaries of
> another 2.3.
[Michael Hudson]
>> I've been reading the bug report with interest, but unless I can
>> reproduce it it's mighty hard for me to debug, as I'm sure you know.
[Mike Klaas]
> Indeed.
Note that I just attached a much simpler pure-Python script that fails
very quickly, on Windows, using a debug build.
[Raymond Hettinger]
> My colleague got an odd result today that is reproducible on his build
> of Python (RedHat's distribution of Py2.4.2) but not any other builds
> I've checked (including an Ubuntu Py2.4.2 built with a later version of
> GCC). I hypothesized that this was a bug in the underlyin
[Herman Geza]
>> Here python reads from an already-freed memory area, right?
[Martin v. Löwis]
> It looks like it, yes. Of course, it could be a flaw in valgrind, too.
> To find out, one would have to understand what the memory block is,
> and what part of PyObject_Free accesses it.
When PyObject
[Kristján V. Jónsson]
> ...
> Actually, obmalloc could be improved in this aspect. Similar code that I
> once wrote
> computed the block base address, but than looked in its tables to see if it
> was
> actually a known block before accessing it.
Several such schemes were tried (based on, e.g.,
[Martin v. Löwis]
Thanks for explaining all this! One counterpoint:
> Notice that on a system with limited memory, you probably don't
> want to use obmalloc, even if it worked. obmalloc uses arenas
> of 256kiB, which might be expensive on the target system.
OTOH, Python allocates a lot of small
[Martin v. Löwis]
> In bug #1566280 somebody reported that he gets an
> exception where the logging module tries to write
> to closed file descriptor.
>
> Upon investigation, it turns out that the file descriptor
> is closed because the logging atexit handler is invoked.
> This is surprising, as th
[Martin v. Löwis]
>>> Upon investigation, it turns out that the file descriptor
>>> is closed because the logging atexit handler is invoked.
>>> This is surprising, as the program is far from exiting at
>>> this point.
[Tim Peters]
>> But the main thread
[Tim Peters]
>> Sorry, I couldn't follow the intent there. Not obvious to me how
>> moving this stuff from `threading` into `thread` would make it
>> easier(?) for the implementation to wait for non-daemon threads to
>> finish.
[Martin v. Löwis]
> Currently, if
[Raymond Hettinger]
> I bumped into an oddity today:
>
> 6.0 // 0.001 != math.floor(6.0 / 0.001)
>
> In looking at Objects/floatobject.c, I was surprised to find that
> float_floor_division() is implemented in terms of float_divmod(). Does anyone
> know why it takes such a circuitous path? I
[Tim Peters]
>> ...
>> >>> decimal.Decimal(-1) % decimal.Decimal("1e100")
>> Decimal("-1")
[Armin Rigo]
> BTW - isn't that case in contradiction with the general Python rule that
> if b > 0, then a % b should return a number between
...
[Tim]
>> It's just a fact that different definitions of mod are most useful
>> most often depending on data type. Python's is good for integers and
>> often sucks for floats. The C99 and `decimal` definition(s) is/are
>> good for floats and often suck(s) for integers. Trying to pretend
>> t
[Guido]
> ...
> So you are proposing that Decimal also rip out the % and // operators
> and __divmod__? WFM, but I don't know what Decimal users say (I'm not
> one).
Yes: it's just as much a floating type as HW binary floats, and all
the same issues come up. For example, decimal floats are just
[Guido]
>> That really sucks, especially since the whole point of making int
>> division return a float was to make the integers embedded in the
>> floats... I think the best solution would be to remove the definition
>> of % (and then also for divmod()) for floats altogether, deferring to
>> math.
[Guido]
>> The ints aren't really embedded in Decimal, so we don't have to do
>> that there (but we could).
[Facundo Batista]
> -0.
>
> If we can't achieve it without disturbing the rest of Python, I'll try
> as much as possible to keep what the Spec proposes.
Which "Spec"? For example, floor di
[Anders J. Munch]
> What design error? float.__mod__ works perfectly.
>
> >>> -1 % 50
> 49
> >>> -1.0 % 50.0
> 49.0
> >>>
Please read the whole thread. Maybe you did, but you said nothing
here that indicated you had. The issues aren't about tiny integers
that happen to be in float format, where
[Guido]
>>> I guess the conjugate() function could also just return self (although I see
>>> that conjugate() for a complex with a zero imaginary part returns
>>> something whose imaginary part is -0; is that intentional?
[TIm Peters]
>> That's wrong, if true
[Tim Peters]
>> Please read the whole thread. Maybe you did, but you said nothing
>> here that indicated you had. The issues aren't about tiny integers
>> that happen to be in float format, where the result is exactly
>> representable as a float too. Those
...
[Facundo]
>> We'll have to deprecate that functionality, with proper warnings (take
>> not I'm not following the thread that discuss the migration path to 3k).
>>
>> And we'll have to add the method "remainder" to decimal objects (right
>> now we have only "remainder_near" in decimal objects,
[Armin]
>>> BTW - isn't that case in contradiction with the general Python rule that
>>> if b > 0, then a % b should return a number between 0 included and b
>>> excluded?
[Tim]
>> Sure.
[Armin]
> You're not addressing my point, though, so I was probably not clear
> enough.
"Sure" is the answer
[Brett Cannon]
> I am trying to commit to the 2.5 branch and I am getting an error:
>
> svn: Commit failed (details follow):
> svn: Can't create directory
> '/data/repos/projects/db/transactions/53566-1.txn': Permission denied
>
> Anyone know what is going on?
Did you do `svn info` in that directo
[Guido]
> The only thing I would miss about this is that I am used to write
> certain timing loops that like to sync on whole seconds, by taking
> time.time() % 1.0 which nicely gives me the milliseconds in the
> current second. E.g.
>
> while True:
> do_something_expensive_once_a_second_on_the_s
[Guido]
> ...
> I don't care about the speed, but having to import math (which I
> otherwise almost never need) is a distraction, and (perhaps more so) I
> can never remember whether it's modf() or fmod() that I want.
fractional part of x == fmod(x, 1.0) == modf(x)[0], so you could use
either. Si
[Armin]
> Thanks for the clarification. Yes, it makes sense that __mod__,
> __divmod__ and __floordiv__ on float and decimal would eventually follow
> the same path as for complex (where they make even less sense and
> already raise a DeprecationWarning).
This truly has nothing to do with complex
...
[Tim]
>> fractional part of x == fmod(x, 1.0) == modf(x)[0], so you could use
>> either.
[Anders J. Munch]
> Actually, on the off chance that time.time() is negative, he can use
> neither. It has to be math.ceil, float.__mod__ or divmod.
If time.time() is negative, I expect this would be th
[Armin Rigo]
>> Thanks for the clarification. Yes, it makes sense that __mod__,
>> __divmod__ and __floordiv__ on float and decimal would eventually follow
>> the same path as for complex (where they make even less sense and
>> already raise a DeprecationWarning).
[Nick Maclaren]
> Yes. Though t
[Tim Peters]
>> ...
>> Maybe we could introduce "%" as a unary prefix operator, where
>> %x means "the fractional part of x" ;-)
[Anders J. Munch]
> What'ya talking about? Obviously it should be a suffix operator ;-)
Na -- that would be confusing ;-
[Tim (misattributed to Guido)]
>> "(int)float_or_double" truncates in C (even in K&R C) /provided that/
>> the true result is representable as an int. Else behavior is
>> undefined (may return -1, may cause a HW fault, ...).
[Nick Maclaren]
> Actually, I have used Cs that didn't, but haven't seen
[Tim Peters]
>> ...
>> [it would be possible for float.__divmod__ to return the exact
>> quotient], but who would have a (sane) use for a possibly 2000-bit
>> quotient?
[Nick Maclaren]
> Well, the 'exact rounding' camp in IEEE 754 seem to think that there
[Nick Maclaren]
> ...
> 2) _PyLong_FromByteArray and _PyLong_AsByteArray aren't in
> the API
They're not in the public API, which is equivalent to that their names
begin with a leading underscore. They're in the private API :-)
> and have no comments.
The behavior of these functions, including
[Jeremy Hylton]
> I was wondering today how I could convince myself that a sequence of
> Py_CLEAR() calls in a tp_clear function was safe. Take for example a
> really trivial sequence of code on frame_clear():
>
> Py_CLEAR(f->f_exc_type);
> Py_CLEAR(f->f_exc_value);
> Py_CL
[Raymond Hettinger]
> After thinking more about Py_ssize_t, I'm surprised that we're not hearing
> about
> 64 bit users having a couple of major problems.
>
> If I'm understanding what was done for dictionaries, the hash table can grow
> larger than the range of hash values. Accordingly, I would
[Mark Dickinson]
> The current cmath module has some significant numerical problems,
> particularly in the inverse trig and inverse hyperbolic trig
> functions.
IIRC, cmath was essentially whipped up over a weekend by a scientist,
transcribing formulas from a math reference. Such an approach is
b
[Raymond Hettinger]
> ...
> Likewise, consider soliciting Tim's input on how to implement the ln()
> operation. That one will be tricky to get done efficiently and correctly.
One low-effort approach is to use a general root-finding algorithm and
build ln(x) on top of exp() via (numerically) solvi
401 - 500 of 1049 matches
Mail list logo
