| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Python warning which can be catched by means of the Python warning
framework.
It also adds two new APIs which hopefully make it easier for Python
to switch to buffer overflow safe [v]snprintf() APIs for error
reporting et al. The two new APIs are PyOS_snprintf() and
PyOS_vsnprintf() and work just like the standard ones in many
C libs. On platforms which have snprintf(), the native APIs are used,
on all other an emulation with snprintf() tries to do its best.
|
|
|
|
|
| |
Namely, an exception is raised if the second arg to hasattr() is not a
string or Unicode.
|
|
|
|
|
|
|
| |
Fix suggested by Michael Hudson: Raise TypeError if attribute name
passed to getattr() is not a string or Unicode. There is some
unfortunate duplication of code between builtin_getattr() and
PyObject_GetAttr(), but it appears to be unavoidable.
|
|
|
|
|
|
|
| |
And remove all the extern decls in the middle of .c files.
Apparently, it was excluded from the header file because it is
intended for internal use by the interpreter. It's still intended for
internal use and documented as such in the header file.
|
|
|
|
| |
If the code object has free variables, raise TypeError.
|
| |
|
|
|
|
|
| |
surrogates for Unicode code points outside range(0x10000) on narrow
Python builds.
|
| |
|
|
|
|
| |
and PYTHONPATH).
|
|
|
|
|
|
|
| |
fault in sys.displayhook.
Please check this in on the 2.2a1 branch (or whatever is necessary
to get it working next release)
|
|
|
|
|
|
|
| |
exception in the execution of bar, ensure that foo.bar exists.
(Previously, while sys.modules['foo.bar'] would exist, foo.bar would
only be created upon successful execution of bar. This is
inconvenient; some would say wrong. :-)
|
|
|
|
| |
SF patch #436376.
|
|
|
|
| |
Add dlopenflags to PyInterpreterState, and use it in dlopen calls.
|
| |
|