| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
way it's called each time a generator is resumed. The tracing of normal
functions should be unaffected by this change.
|
| |
|
| |
|
|
|
|
| |
This closes SF bug #458223.
|
|
|
|
|
| |
Fixed a markup error which caused an em dash to be presented as a minus sign.
This closes SF bug #458350.
|
|
|
|
|
| |
change their basic behavior: When parsing something that cannot possibly
be valid in either HTML or XHTML, raise an exception.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
operators per line or statement are now on by default, and -m turns
these warnings off.
- Change the way multiple / operators are reported; a regular
recommendation is always emitted after the warning.
- Report ambiguous warnings (both int|long and float|complex used for
the same operator).
- Update the doc string again to clarify all this and describe the
possible messages more precisely.
|
|
|
|
|
| |
the -Qwarnall option, so I've changed this to only filter out the one
warning that's a problem in practice.
|
| |
|
|
|
|
| |
broken declaration-like things.
|
|
|
|
| |
regarding bare ampersands in content.
|
|
|
|
| |
Fixed.
|
|
|
|
| |
curses, far too old for _cursesmodule.c.
|
| |
|
| |
|
|
|
|
| |
e.g., (1L << 40000)/(1L << 40001) returns 0.5, not Inf or NaN or whatever.
|
| |
|
| |
|
|
|
|
|
|
|
| |
the fiddling is simply due to that no caller of PyLong_AsDouble ever
checked for failure (so that's fixing old bugs). PyLong_AsDouble is much
faster for big inputs now too, but that's more of a happy consequence
than a design goal.
|
|
|
|
|
| |
division, and this makes sense. Add -Qwarnall to warn for all
classic divisions, as required by the fixdiv.py tool.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
but will be the foundation for Good Things:
+ Speed PyLong_AsDouble.
+ Give PyLong_AsDouble the ability to detect overflow.
+ Make true division of long/long nearly as accurate as possible (no
spurious infinities or NaNs).
+ Return non-insane results from math.log and math.log10 when passing a
long that can't be approximated by a double better than HUGE_VAL.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of PyMapping_Keys because we know we have a real dict. Tolerate that
objects may have an attr named "__dict__" that's not a dict (Py_None
popped up during testing).
test_descr.py, test_dir(): Test the new classic-class behavior; beef up
the new-style class test similarly.
test_pyclbr.py, checkModule(): dir(C) is no longer a synonym for
C.__dict__.keys() when C is a classic class (looks like the same thing
that burned distutils! -- should it be *made* a synoym again? Then it
would be inconsistent with new-style class behavior.).
|
| |
|
|
|
|
| |
disabled. Obviously everyone enables the GC. :-)
|
| |
|
|
|
|
|
| |
integer types, and y must be >= 0. See discussion at
http://sf.net/tracker/index.php?func=detail&aid=457066&group_id=5470&atid=105470
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
bag. It's clearly wrong for classic classes, at heart because a classic
class doesn't have a __class__ attribute, and I'm unclear on whether
that's feature or bug. I'll repair this once I find out (in the
meantime, dir() applied to classic classes won't find the base classes,
while dir() applied to a classic-class instance *will* find the base
classes but not *their* base classes).
Please give the new dir() a try and see whether you love it or hate it.
The new dir([]) behavior is something I could come to love. Here's
something to hate:
>>> class C:
... pass
...
>>> c = C()
>>> dir(c)
['__doc__', '__module__']
>>>
The idea that an instance has a __doc__ attribute is jarring (of course
it's really c.__class__.__doc__ == C.__doc__; likewise for __module__).
OTOH, the code already has too many special cases, and dir(x) doesn't
have a compelling or clear purpose when x isn't a module.
|
| |
|
| |
|
| |
|
|
|
|
| |
Tested, too:-)
|
|
|
|
|
| |
treated the same as single ones by default. Added -m option to issue
a warning for this case instead.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
mapping object", in the same sense dict.update(x) requires of x (that x
has a keys() method and a getitem).
Questionable: The other type constructors accept a keyword argument, so I
did that here too (e.g., dictionary(mapping={1:2}) works). But type_call
doesn't pass the keyword args to the tp_new slot (it passes NULL), it only
passes them to the tp_init slot, so getting at them required adding a
tp_init slot to dicts. Looks like that makes the normal case (i.e., no
args at all) a little slower (the time it takes to call dict.tp_init and
have it figure out there's nothing to do).
|
| |
|
| |
|
|
|
|
|
|
| |
right thing with page breaks in long examples, while the verbatim
environment does not. This causes the example to wrap to the next page
instead of overwriting the page footer and bottom margin.
|
| |
|
|
|
|
|
|
|
| |
percolated out, and some general cleanup. The output is still the
same, except it now prints "Index: <file>" instead of "Processing:
<file>", so that the output can be used as input for patch (but only
the diff-style parts of it).
|
| |
|
| |
|
|
|
|
|
|
| |
Stephen Hansen reported via email that he didn't finish the port to
Borland C, so remove the old item saying it worked and add a new item
saying what I know; I've asked Stephen for more details.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Moved the declarations to pymactoolbox.h.
|
| |
|