| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
affect nodes without another operator. This was causing negated
exponentiations to drop the exponentiation. This closes SF bug #456756.
|
|
|
|
|
| |
PyInt_Check() succeeds. That returns true for subtypes of int, which
may override __add__ or __sub__.
|
|
|
|
| |
restricted execution mode.
|
| |
|
| |
|
|
|
|
| |
when that test is doomed to deadlock.
|
|
|
|
|
|
|
|
|
|
|
| |
pyport.h: typedef a new Py_intptr_t type.
DELICATE ASSUMPTION: That HAVE_UINTPTR_T implies intptr_t is
available as well as uintptr_t. If that turns out not to be
true, things must get uglier (C99 wants both, so I think it's
an assumption we're *likely* to get away with).
thread_nt.h, PyThread_start_new_thread: MS _beginthread is documented
as returning unsigned long; no idea why uintptr_t was being used.
Others: Always use Py_[u]intptr_t, never [u]intptr_t directly.
|
|
|
|
|
| |
not enough for Python. Increased the stacksize to a (somewhat arbitrary)
64KB.
|
|
|
|
| |
ints, convert to PyLong (rather than throwing away the high-order 32 bits).
|
|
|
|
| |
rather than a type equality test.
|
|
|
|
| |
because of overflow, generate a long instead.
|
|
|
|
| |
internal name (_AE). This can slow things down (once) but it's the only way I can get things to work on OSX, OS9 dynamically loaded and OS9 frozen.
|
|
|
|
|
| |
PyString_FromFormat() since it's much more generally useful than
just for exceptions.
|
| |
|
|
|
|
| |
This implements the 'getset' class from test_binop.py.
|
| |
|
|
|
|
|
| |
raise the exception here -- call the generic function (which may
convert the arguments to long and try again).
|
|
|
|
| |
are overflowing and a long int operation is substituted.
|
|
|
|
|
|
|
|
|
| |
Check return value from future_parse() in for loop for file_input to
accomodate multiple future statements on separate lines.
Add several comments explaining how the code works.
Remove out-dated XXX comment.
|
|
|
|
|
|
|
|
| |
Change to get/set/del slice operations so that if the object doesn't
support slicing, *or* if either of the slice arguments is not an int
or long, we construct a slice object and call the get/set/del item
operation instead. This makes it possible to design classes that
support slice arguments of non-integral types.
|
|
|
|
|
|
|
| |
builtin_eval wasn't merging in the compiler flags from the current frame;
I suppose we never noticed this before because future division is the
first future-feature that can affect expressions (nested_scopes and
generators had only statement-level effects).
|
|
|
|
|
| |
#449043 supporting __future__ in simulated shells
which implements PEP 264.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CO_FUTURE_DIVISION flag. Redid this to use Jeremy's PyCF_MASK #define
instead, so we dont have to remember to fiddle individual feature names
here again.
pythonrun.h: Also #define a PyCF_MASK_OBSOLETE mask. This isn't used
yet, but will be as part of the PEP 264 implementation (compile() mustn't
raise an error just because old code uses a flag name that's become
obsolete; a warning may be appropriate, but not an error; so compile() has
to know about obsolete flags too, but nobody is going to remember to
update compile() with individual obsolete flag names across releases either
-- i.e., this is the flip side of PyEval_MergeCompilerFlags's oversight).
|
|
|
|
|
|
|
|
| |
- Do not compile unicodeobject, unicodectype, and unicodedata if Unicode is disabled
- check for Py_USING_UNICODE in all places that use Unicode functions
- disables unicode literals, and the builtin functions
- add the types.StringTypes list
- remove Unicode literals from most tests.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
- initsigs(): Ignore SIGXFZ so writing files beyond the file system
size limit won't kill us.
- Py_Initialize(): call _Py_ReadyTypes() instead of readying types
here.
- Py_Initialize(): call _PyImport_FixupExtension() for module
"extensions". (SF bug #422004.)
|
|
|
|
|
|
| |
When code is compiled and compiler flags are passed in, be sure to
update cf_flags with any features defined by future statements in the
compiled code.
|
| |
|
|
|
|
|
|
|
|
| |
_PyImport_FixupExtension() on the exceptions module. Now
reload(exceptions) acts just like reload(sys) instead of raising
an ImportError.
This closes SF bug #422004.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The descr changes moved the dispatch for calling objects from
call_object() in ceval.c to PyObject_Call() in abstract.c.
call_object() and the many functions it used in ceval.c were no longer
used, but were not removed.
Rename meth_call() as PyCFunction_Call() so that it can be called by
the CALL_FUNCTION opcode in ceval.c.
Also, fix error message that referred to PyEval_EvalCodeEx() by its
old name eval_code2(). (I'll probably refer to it by its old name,
too.)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Revised version of Fred's patch, including support for ~ operator.
If the unary +, -, or ~ operator is applied to a constant, don't
generate a UNARY_xxx opcode. Just store the approriate value as a
constant. If the value is negative, extend the string containing the
constant and insert a negative in the 0th position.
For ~, compute the inverse of int and longs and use them directly, but
be prepared to generate code for all other possibilities (invalid
numbers, floats, complex).
|
|
|
|
|
|
|
|
| |
same module twice, which apparently crashes Python. I could not test the
error condition, but in normal life it seems to have no adverse effects.
Also removed an unsued variable, and corrected 2 glaring errors (missing
'case' in front of a label).
|
|
|
|
|
|
|
| |
because nested scopes are always enabled.
(Accidentally checked in one small change along this path yesterday,
wreaking havoc in the Windows build.)
|
|
|
|
| |
way; see code comments.
|
|
|
|
|
|
|
|
|
|
|
| |
Replace uses of PyCF_xxx with CO_xxx.
Replace individual feature slots in PyFutureFeatures with single
bitmask ff_features.
When flags must be transfered among the three parts of the interpreter
that care about them -- the pythonrun layer, the compiler, and the
future feature parser -- can simply or (|) the definitions.
|
|
|
|
| |
asking to print the references.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
with functionality needed for both unix-Python and MacPython and a
new smaller ./Mac/Python/macglue.c which contains MacPython stuff only.
pymactoolbox.h has moved to ./Include from ./Mac/Include and now also
contains the relevant stuff from macglue.h.
The net effect of this is that the ./Mac subdirectory is not needed
anymore for building the unix-Python core on MacOSX (it is needed
for building the extension modules).
|
| |
|
| |
|
|
|
|
|
| |
Somebody else should feel free to repair this a different way; see Python-
Dev for discussion.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This introduces:
- A new operator // that means floor division (the kind of division
where 1/2 is 0).
- The "future division" statement ("from __future__ import division)
which changes the meaning of the / operator to implement "true
division" (where 1/2 is 0.5).
- New overloadable operators __truediv__ and __floordiv__.
- New slots in the PyNumberMethods struct for true and floor division,
new abstract APIs for them, new opcodes, and so on.
I emphasize that without the future division statement, the semantics
of / will remain unchanged until Python 3.0.
Not yet implemented are warnings (default off) when / is used with int
or long arguments.
This has been on display since 7/31 as SF patch #443474.
Flames to /dev/null.
|
|
|
|
|
|
| |
- Add an explicit call to PyType_Ready(&PyList_Type) to pythonrun.c
(just for the heck of it, really -- we should either explicitly
ready all types, or none).
|
|
|
|
|
| |
Only return if symtable_warn() returns -1, indicating that the warning
was turned into an error.
|
| |
|
|
|
|
| |
Reported by the Man himself.
|
|
|
|
| |
David Bolen.
|
|
|
|
|
|
| |
the object being inserted was not being DECREFed.
This closes SF bug #444486.
|