ignore tuple.
The line, "from _random import Random as CoreGenerator", fools the test
code which expects CoreGenerator.__name__ to be "CoreGenerator" instead
of "Random".
* channels() -> devices()
* stereochannels() -> stereodevices()
* recchannels() -> recdevices()
* getvol() -> get()
* setvol() -> set()
This is for (slightly) more consistency with the OSS ioctl names
(READ_DEVMASK, READ_RECMASK, READ_STEREODEVS).
Also make sure the C function names correspond more closely to the
Python method names for mixer methods.
Guido has in mind an easier way for users to code this stuff, but the
only tests we have now are for fixed-offset tzinfo classes, and this
stuff is extremely delicate in the endcases (read the new test code
for why: there are holes in time <wink>).
M PyShell.py
1. PyShell Rev 1.39, EditorWindow Rev 1.37 fix was not handling a
multiline prompt.
2. The same fix introduced a bug where hitting <enter> at a previous
prompt-only line would copy the prompt to the iomark.
3. Move the setting of sys.ps1 earlier, into PyShell.main(), to allow
this code to work before a shell is started up.
4. If cursor is on the input line in the prompt, and you hit <enter>,
process the line instead of complaining.
5. If line has no stdin range (this includes the last line before shell
restart) strip any prompt before recalling.
equality. Note, there is another flavor that compares to a given
number of significant digits rather than decimal places. If there
is a demand, that could be added at a later date.
Obtain cleaner coding and a system wide
performance boost by using the fast, pre-parsed
PyArg_Unpack function instead of PyArg_ParseTuple
function which is driven by a format string.
This can cause core dumps when Python runs. Python relies on the 754-
(and C99-) mandated default "non-stop" mode for FP exceptions. This
patch from Ben Laurie disables at least one FP exception on FreeBSD at
Python startup time.
operands have identical tzinfo members (meaning object identity -- "is").
I misunderstood the intent here, reading wrong conclusion into
conflicting clues.
subtraction, work as documented. In the Python implementation,
they weren't calling utcoffset() if both operands had the same
tzinfo object. That's fine if it so happens that the shared
tzinfo object returns a fixed offset (independent of operand),
but can give wrong results if that's not so, and the latter
obtains in a tzinfo subclass instance trying to model both
standard and daylight times. The C implementation was already
doing this "correctly", so we're just adding tests to verify it.
Barry Warsaw
Andrew M. Kuchling
Marc-André Lemburg
Raymond Hettinger
Greg Ward
Tim Peters
Kurt B. Kaiser
Martin v. Löwis
Eric S. Raymond
Jack Jansen
Guido van Rossum
Neal Norwitz