summaryrefslogtreecommitdiffstats
path: root/Python/bltinmodule.c
Commit message (Collapse)AuthorAgeFilesLines
* Backport:Michael W. Hudson2002-10-071-34/+1
| | | | | | | | | | | | | | 2002/08/11 12:23:04 lemburg Python/bltinmodule.c 2.262 2002/08/11 12:23:04 lemburg Objects/unicodeobject.c 2.162 2002/08/11 12:23:03 lemburg Misc/NEWS 1.461 2002/08/11 12:23:03 lemburg Lib/test/test_unicode.py 1.65 2002/08/11 12:23:03 lemburg Include/unicodeobject.h 2.39 Add C API PyUnicode_FromOrdinal() which exposes unichr() at C level. u'%c' will now raise a ValueError in case the argument is an integer outside the valid range of Unicode code point ordinals. Closes SF bug #593581.
* backport nowonder's checkin ofMichael W. Hudson2002-09-241-1/+1
| | | | | | | | | | | revision 2.265 of bltinmodule.c date: 2002/08/27 16:58:00; author: nowonder; state: Exp; lines: +1 -1 execfile should call PyErr_SetFromErrnoWithFilename instead of simply PyErr_SetFromErrno This closes bug 599163.
* backport tim_one's patch:Anthony Baxter2002-04-301-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Repair widespread misuse of _PyString_Resize. Since it's clear people don't understand how this function works, also beefed up the docs. The most common usage error is of this form (often spread out across gotos): if (_PyString_Resize(&s, n) < 0) { Py_DECREF(s); s = NULL; goto outtahere; } The error is that if _PyString_Resize runs out of memory, it automatically decrefs the input string object s (which also deallocates it, since its refcount must be 1 upon entry), and sets s to NULL. So if the "if" branch ever triggers, it's an error to call Py_DECREF(s): s is already NULL! A correct way to write the above is the simpler (and intended) if (_PyString_Resize(&s, n) < 0) goto outtahere; Bugfix candidate. Original patch(es): python/dist/src/Python/bltinmodule.c:2.253
* Add bool(), True, False (as ints) for backwards compatibility.Guido van Rossum2002-04-081-0/+23
|
* backport tim_one's checkin ofMichael W. Hudson2002-03-111-5/+5
| | | | | | | | revision 2.248 of bltinmodule.c Docstring for filter(): Someone on the Tutor list reasonably complained that it didn't tell enough of the truth. Bugfix candidate (I guess -- it helps and it's harmless).
* Include <unistd.h> in Python.h. Fixes #500924.Martin v. Löwis2002-01-121-4/+0
|
* Fix for SF bug [ #492403 ] exec() segfaults on closure's func_codeJeremy Hylton2001-12-131-1/+1
| | | | | | | | Based on the patch from Danny Yoo. The fix is in exec_statement() in ceval.c. There are also changes to introduce use of PyCode_GetNumFree() in several places.
* Use PyOS_snprintf instead of sprintf.Jeremy Hylton2001-11-281-1/+1
|
* SF patch 473749 compile under OS/2 VA C++, from Michael Muller.Tim Peters2001-11-051-0/+4
| | | | Changes enabling Python to compile under OS/2 Visual Age C++.
* Rename "dictionary" (type and constructor) to "dict".Tim Peters2001-10-291-1/+1
|
* SF patch #474590 -- RISC OS supportGuido van Rossum2001-10-241-0/+15
|
* SF patch #471852 (anonymous) notes that getattr(obj, name, default)Guido van Rossum2001-10-161-1/+3
| | | | masks any exception, not just AttributeError. Fix this.
* Implement isinstance(x, (A, B, ...)). Note that we only allow tuples,Guido van Rossum2001-10-071-2/+4
| | | | | not other sequences (then we'd have to except strings, and we'd still be susceptible to recursive attacks).
* Get rid of builtin_open() entirely (the C code and docstring, not theTim Peters2001-09-131-20/+3
| | | | | builtin function); Guido pointed out that it could be just another name in the __builtin__ dict for the file constructor now.
* _PyBuiltin_Init(): For clarity, macroize this purely repetitive code.Tim Peters2001-09-131-49/+25
|
* SF bug [#460467] file objects should be subclassable.Tim Peters2001-09-131-22/+13
| | | | Preliminary support. What's here works, but needs fine-tuning.
* Rename 'getset' to 'property'.Guido van Rossum2001-09-061-2/+2
|
* builtin_execfile(): initialize another local that the GCC on leroyGuido van Rossum2001-09-051-1/+1
| | | | found it necessary to warn about.
* At Guido's suggestion, here's a new C API function, PyObject_Dir(), likeTim Peters2001-09-041-137/+1
| | | | __builtin__.dir(). Moved the guts from bltinmodule.c to object.c.
* builtin_dir(): Treat classic classes like types. Use PyDict_Keys insteadTim Peters2001-09-041-17/+20
| | | | | | | | | | | | | | 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.).
* Make dir() wordier (see the new docstring). The new behavior is a mixedTim Peters2001-09-031-53/+134
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Add 'super' builtin type.Guido van Rossum2001-08-241-0/+3
|
* Add new built-in type 'getset' (PyGetSet_Type).Guido van Rossum2001-08-231-0/+3
| | | | This implements the 'getset' class from test_binop.py.
* Fix for bug [#452230] future division isn't propagated.Tim Peters2001-08-171-1/+8
| | | | | | | 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).
* A fiddled version of the rest of Michael Hudson's SF patchTim Peters2001-08-171-8/+26
| | | | | #449043 supporting __future__ in simulated shells which implements PEP 264.
* Patch #445762: Support --disable-unicodeMartin v. Löwis2001-08-171-0/+12
| | | | | | | | - 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.
* Patch #427190: Implement and use METH_NOARGS and METH_O.Martin v. Löwis2001-08-161-100/+59
|
* Put conditional S_ISDIR definition(s) into pyport.h.Martin v. Löwis2001-08-081-1/+1
|
* Repair the Windows build (S_ISDIR() macro doesn't exist).Tim Peters2001-08-081-1/+1
| | | | | Somebody else should feel free to repair this a different way; see Python- Dev for discussion.
* Patch #448227: Raise an exception when a directory is passed to execfile.Martin v. Löwis2001-08-081-4/+23
|
* Merge of descr-branch back into trunk.Tim Peters2001-08-021-437/+38
|
* Do for hasattr() what was done for getattr()Jeremy Hylton2001-07-301-0/+11
| | | | | Namely, an exception is raised if the second arg to hasattr() is not a string or Unicode.
* Fix for SF byg [ #420304 ] getattr function w/ defaultJeremy Hylton2001-07-301-0/+11
| | | | | | | 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.
* Fix for SF bug [ #443866 ] Evaluating func_code causing core dumpJeremy Hylton2001-07-301-1/+7
| | | | If the code object has free variables, raise TypeError.
* Undoing the UCS-4 patch addition which caused unichr() to returnMarc-André Lemburg2001-07-261-1/+11
| | | | | surrogates for Unicode code points outside range(0x10000) on narrow Python builds.
* Part way to allowing "from __future__ import generators" to communicateTim Peters2001-07-161-8/+8
| | | | | | | | | | that info to code dynamically compiled *by* code compiled with generators enabled. Doesn't yet work because there's still no way to tell the parser that "yield" is OK (unlike nested_scopes, the parser has its fingers in this too). Replaced PyEval_GetNestedScopes by a more-general PyEval_MergeCompilerFlags. Perhaps I should not have? I doubted it was *intended* to be part of the public API, so just did.
* Re-add 'advanced' xrange features, adding DeprecationWarnings as discussedThomas Wouters2001-07-091-1/+1
| | | | | on python-dev. The features will still vanish, however, just one release later.
* Complete the xrange-simplification checkins: call PyRange_New() withGuido van Rossum2001-07-051-1/+1
| | | | fewer arguments.
* use Py_UNICODE_WIDE instead of USE_UCS4_STORAGE and Py_UNICODE_SIZEFredrik Lundh2001-06-271-1/+1
| | | | tests.
* Cosmetic changes to MvL's change to unichr():Guido van Rossum2001-06-261-4/+6
| | | | | | | | | | | | - the correct range for the error message is range(0x110000); - put the 4-byte Unicode-size code inside the same else branch as the 2-byte code, rather generating unreachable code in the 2-byte case. - Don't hide the 'else' behine the '}'. (I would prefer that in 4-byte mode, any value should be accepted, but reasonable people can argue about that, so I'll put that off.)
* Support using UCS-4 as the Py_UNICODE type:Martin v. Löwis2001-06-261-0/+4
| | | | | | | | | | Add configure option --enable-unicode. Add config.h macros Py_USING_UNICODE, PY_UNICODE_TYPE, Py_UNICODE_SIZE, SIZEOF_WCHAR_T. Define Py_UCS2. Encode and decode large UTF-8 characters into single Py_UNICODE values for wide Unicode types; likewise for UTF-16. Remove test whether sizeof Py_UNICODE is two.
* more unicode tweaks: make unichr(0xdddddddd) behave like u"\Udddddddd"Fredrik Lundh2001-06-261-6/+17
| | | | wrt surrogates. (this extends the valid range from 65535 to 1114111)
* experimental UCS-4 support: don't assume that MS_WIN32 impliesFredrik Lundh2001-06-261-1/+1
| | | | HAVE_USABLE_WCHAR_T
* Cruft cleanup: Removed the unused last_is_sticky argument from the internalTim Peters2001-05-281-1/+1
| | | | _PyTuple_Resize().
* SF bug #425836: Reference leak in filter().Tim Peters2001-05-211-0/+1
| | | | | Mark Hammond claimed that the iterized filter() forgot to decref the iterator upon return. He was right!
* Fix the Py_FileSystemDefaultEncoding checkin - declare the variable in a ↵Mark Hammond2001-05-141-1/+8
| | | | fileobject.h, and initialize it in bltinmodule.
* Add support for Windows using "mbcs" as the default Unicode encoding when ↵Mark Hammond2001-05-131-2/+6
| | | | dealing with the file system. As discussed on python-dev and in patch 410465.
* Generalize zip() to work with iterators.Tim Peters2001-05-061-18/+44
| | | | | | | | NEEDS DOC CHANGES. More AttributeErrors transmuted into TypeErrors, in test_b2.py, and, again, this strikes me as a good thing. This checkin completes the iterator generalization work that obviously needed to be done. Can anyone think of others that should be changed?
* Make PyIter_Next() a little smarter (wrt its knowledge of iteratorTim Peters2001-05-051-47/+14
| | | | internals) so clients can be a lot dumber (wrt their knowledge).
* Generalize reduce() to work with iterators.Tim Peters2001-05-041-12/+19
| | | | NEEDS DOC CHANGES.
generated by cgit v0.12 at 2025-12-26 23:03:59 (GMT)