summaryrefslogtreecommitdiffstats
path: root/Python/bltinmodule.c
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* Generalize map() to work with iterators.Tim Peters2001-05-031-66/+68
| | | | | | | | | | | NEEDS DOC CHANGES. Possibly contentious: The first time s.next() yields StopIteration (for a given map argument s) is the last time map() *tries* s.next(). That is, if other sequence args are longer, s will never again contribute anything but None values to the result, even if trying s.next() again could yield another result. This is the same behavior map() used to have wrt IndexError, so it's the only way to be wholly backward-compatible. I'm not a fan of letting StopIteration mean "try again later" anyway.
* Generalize max(seq) and min(seq) to work with iterators.Tim Peters2001-05-031-15/+24
| | | | NEEDS DOC CHANGES.
* Generalize filter(f, seq) to work with iterators. This also generalizesTim Peters2001-05-021-40/+54
| | | | | filter() to no longer insist that len(seq) be defined. NEEDS DOC CHANGES.
* Fix buglet reported on c.l.py: map(fnc, file.xreadlines()) blows up.Tim Peters2001-04-281-9/+19
| | | | | | | | | Also a 2.1 bugfix candidate (am I supposed to do something with those?). Took away map()'s insistence that sequences support __len__, and cleaned up the convoluted code that made it *look* like it really cared about __len__ (in fact the old ->len field was only *used* as a flag bit, as the main loop only looked at its sign bit, setting the field to -1 when IndexError got raised; renamed the field to ->saw_IndexError instead).
* Iterators phase 1. This comprises:Guido van Rossum2001-04-201-0/+27
| | | | | | | | | | | | | | | | | | | | | | new slot tp_iter in type object, plus new flag Py_TPFLAGS_HAVE_ITER new C API PyObject_GetIter(), calls tp_iter new builtin iter(), with two forms: iter(obj), and iter(function, sentinel) new internal object types iterobject and calliterobject new exception StopIteration new opcodes for "for" loops, GET_ITER and FOR_ITER (also supported by dis.py) new magic number for .pyc files new special method for instances: __iter__() returns an iterator iteration over dictionaries: "for x in dict" iterates over the keys iteration over files: "for x in file" iterates over lines TODO: documentation test suite decide whether to use a different way to spell iter(function, sentinal) decide whether "for key in dict" is a good idea use iterators in map/filter/reduce, min/max, and elsewhere (in/not in?) speed tuning (make next() a slot tp_next???)
* SF patch #413552 - Premature decref on objectTim Peters2001-04-071-3/+7
| | | | | | | | | Jeffery Collins pointed out that filterstring decrefs a character object before it's done using it. This works by accident today because another module always happens to have an active reference too at the time. The accident doesn't work after his Pippy modifications, and since it *is* an accident even in the mainline Python, it should work by design there too. The patch accomplishes that.
generated by cgit v0.12 at 2024-11-29 21:00:02 (GMT)