Mailman 3 August 2012 - Python-Dev

Re: [Python-Dev] [Python-checkins] cpython: Close #4966: revamp the sequence docs in order to better explain the state of
by Nick Coghlan Aug. 21, 2012

Aug. 21, 2012

On Tue, Aug 21, 2012 at 11:55 AM, Ezio Melotti <ezio.melotti(a)gmail.com> wrote: >> +Sequence Types --- :class:`list`, :class:`tuple`, :class:`range` >> +================================================================ >> + > > > These 3 links in the section title redirect to the functions.html page. I > think it would be better if they linked to the appropriate subsection > instead, and in the case of the subsections (e.g. "Text Sequence Type --- > … [View More]str") they shouldn't be links. The same comment can be applied to other > titles as well. I made a start on moving the info out of functions.html and adding appropriate noindex entries. str, bytes and bytearray haven't been consolidated at all yet. >> ++--------------------------+--------------------------------+----------+ >> +| ``s * n, n * s`` | *n* shallow copies of *s* | (2)(7) | > > > I would use '``s * n`` or ``n * s``' here. Done. >> +| ``s.index(x, [i[, j]])`` | index of the first occurence | \(8) | > > > This should be ``s.index(x[, i[, j]])`` Done. >> + >> + * if concatenating :class:`tuple` objects, extend a :class:`list` >> instead. >> + >> + * for other types, investigate the relevant class documentation >> + > > > The trailing punctuation of the elements in this list is inconsistent. Just removed all trailing punctuation from these bullet points for now. > > You missed clear() from this list. The problem was actually index() and count() were missing from the index for the "common sequence operations" table. Added them there, and moved that index above the table. copy() was missing from the index list for the mutable sequence methods, so I added that. > Also in the "Result" column the descriptions in prose are OK, but I find > some of the "same as ..." ones not very readable (or even fairly obscure). > (I think I saw something similar in the doc of list.append() too.) These are all rather old - much of this patch was just moving things around rather than fixing the prose, although there was plenty of the latter, too :) I tried to improve them a bit. > Is it worth mentioning a function call as an example of syntactic ambiguity? > Someone might wonder if foo(a, b, c) is actually passing a 3-elements tuple > or 3 distinct values. Done. > This claim is maybe a bit too strong. I think the main reason to use > namedtuples is being able to access the elements via t.name, rather than > t[pos], and while this can be useful for basically every heterogeneous > tuple, I think that plain tuples are still preferred. Reworded. > On a separate note, should tuple unpacking be mentioned here? (a link to a > separate section of the doc is enough.) Not really - despite the name, tuple unpacking isn't especially closely related to tuples these days. > I would mention explicitly "in :keyword:`for` loops" -- ranges don't loop on > their own (I think people familiar with Ruby and/or JQuery might get > confused here). Done. > I thought that these two paragraphs were talking about positive and negative > start/stop/step until I reached the middle of the second paragraph (the word > "indices" wasn't enough to realize that these paragraphs are about > indexing/slicing, probably because they are rarely used and I wasn't > expecting to find them at this point of the doc). Maybe it's better to move > the paragraphs at the bottom of the section. For the moment, I've just dumped the old range builtin docs into this section. They need a pass to remove the duplication and ensure everything makes sense in context. >> +String literals that are part of a single expression and have only >> whitespace >> +between them will be implicitly converted to a single string literal. >> + > > > Is it a string /literal/ they are converted to? Yup: >>> ast.dump(compile('"hello world"', '', 'eval', flags=ast.PyCF_ONLY_AST)) "Expression(body=Str(s='hello world'))" >>> ast.dump(compile('"hello" " world"', '', 'eval', flags=ast.PyCF_ONLY_AST)) "Expression(body=Str(s='hello world'))" > Anyway a simple ('foo' 'bar') == 'foobar' example might make this sentence > more understandable. Added. >> +There is also no mutable string type, but :meth:`str.join` or >> +:class:`io.StringIO` can be used to efficiently construct strings from >> +multiple fragments. >> + > > str.format() deserves to be mentioned here too. For the kinds of strings where quadratic growth is a problem, str.format is unlikely to be appropriate. > I noticed that here there's this fairly long section about the "old" string > formatting and nothing about the "new" formatting. Maybe this should be > moved together with the new formatting doc, so that all the detailed > formatting docs are in the same place. (This would also help making this > less noticeable) Probably. There are a lot of structural problems in the current docs, because the layout hasn't previously changed to suit the language design changes. >> +While bytes literals and representations are based on ASCII text, bytes >> +objects actually behave like immutable sequences of integers, with each >> +value in the sequence restricted such that ``0 <= x < 256`` (attempts to > > Earlier you used 0 <= x <= 255. The current docs are the result of many merges, much of which I didn't write. This is only the start of improving them by breaking away from the old 1.x structure with a few autocratic decisions on my part to establish a new layout that makes more sense given the evolution of the language, especially the big changes in 2.2 and 3.0 :) > Using ``'abc'.replace('a', 'f')`` and ``b'abc'.replace(b'a', b'f')`` inline > would be better IMHO, given that the current note takes lot of space to > explain a trivial concept. Stylistics edits are always fair game, they don't have to be made by me. While I skipped a lot of your specific suggestions that weren't correcting actual errors, that doesn't mean I'm especially opposed to them, just that I didn't like them enough to implement myself :) Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia [View Less]

2 2

Re: [Python-Dev] [Python-checkins] cpython: s/path importer/path based finder/ (because the path based finder is not an
by Brett Cannon Aug. 20, 2012

Aug. 20, 2012

Should that be "path-based"? On Sun, Aug 19, 2012 at 11:49 PM, nick.coghlan <python-checkins(a)python.org>wrote: > http://hg.python.org/cpython/rev/2f9f5ab3d754 > changeset: 78664:2f9f5ab3d754 > user: Nick Coghlan <ncoghlan(a)gmail.com> > date: Mon Aug 20 13:49:08 2012 +1000 > summary: > s/path importer/path based finder/ (because the path based finder is not > an importer and the simpler 'path finder' is too ambiguous) > > files: > … [View More] Doc/glossary.rst | 6 +- > Doc/reference/import.rst | 95 ++++++++++++++------------- > Misc/NEWS | 4 + > 3 files changed, 57 insertions(+), 48 deletions(-) > > > diff --git a/Doc/glossary.rst b/Doc/glossary.rst > --- a/Doc/glossary.rst > +++ b/Doc/glossary.rst > @@ -317,7 +317,7 @@ > > import path > A list of locations (or :term:`path entries <path entry>`) that are > - searched by the :term:`path importer` for modules to import. During > + searched by the :term:`path based finder` for modules to import. > During > import, this list of locations usually comes from :data:`sys.path`, > but > for subpackages it may also come from the parent package's > ``__path__`` > attribute. > @@ -550,7 +550,7 @@ > > path entry > A single location on the :term:`import path` which the :term:`path > - importer` consults to find modules for importing. > + based finder` consults to find modules for importing. > > path entry finder > A :term:`finder` returned by a callable on :data:`sys.path_hooks` > @@ -562,7 +562,7 @@ > entry finder` if it knows how to find modules on a specific > :term:`path > entry`. > > - path importer > + path based finder > One of the default :term:`meta path finders <meta path finder>` > which > searches an :term:`import path` for modules. > > diff --git a/Doc/reference/import.rst b/Doc/reference/import.rst > --- a/Doc/reference/import.rst > +++ b/Doc/reference/import.rst > @@ -42,6 +42,12 @@ > invoked. These strategies can be modified and extended by using various > hooks > described in the sections below. > > +.. versionchanged:: 3.3 > + The import system has been updated to fully implement the second phase > + of PEP 302. There is no longer any implicit import machinery - the full > + import system is exposed through :data:`sys.meta_path`. In addition, > + native namespace package support has been implemented (see PEP 420). > + > > :mod:`importlib` > ================ > @@ -213,7 +219,7 @@ > interfaces are referred to as :term:`importers <importer>` - they return > themselves when they find that they can load the requested module. > > -By default, Python comes with several default finders and importers. One > +Python includes a number of default finders and importers. One > knows how to locate frozen modules, and another knows how to locate > built-in modules. A third default finder searches an :term:`import path` > for modules. The :term:`import path` is a list of locations that may > @@ -307,7 +313,7 @@ > Python's default :data:`sys.meta_path` has three meta path finders, one > that > knows how to import built-in modules, one that knows how to import frozen > modules, and one that knows how to import modules from an :term:`import > path` > -(i.e. the :term:`path importer`). > +(i.e. the :term:`path based finder`). > > > Loaders > @@ -356,14 +362,14 @@ > * If the module is a package (either regular or namespace), the loader > must > set the module object's ``__path__`` attribute. The value must be > iterable, but may be empty if ``__path__`` has no further significance > - to the importer. If ``__path__`` is not empty, it must produce strings > + to the loader. If ``__path__`` is not empty, it must produce strings > when iterated over. More details on the semantics of ``__path__`` are > given :ref:`below <package-path-rules>`. > > * The ``__loader__`` attribute must be set to the loader object that > loaded > the module. This is mostly for introspection and reloading, but can be > - used for additional importer-specific functionality, for example > getting > - data associated with an importer. > + used for additional loader-specific functionality, for example getting > + data associated with a loader. > > * The module's ``__package__`` attribute should be set. Its value must > be a > string, but it can be the same value as its ``__name__``. If the > attribute > @@ -456,18 +462,18 @@ > correctly for the namespace package. > > > -The Path Importer > -================= > +The Path Based Finder > +===================== > > .. index:: > - single: path importer > + single: path based finder > > As mentioned previously, Python comes with several default meta path > finders. > -One of these, called the :term:`path importer`, searches an :term:`import > +One of these, called the :term:`path based finder`, searches an > :term:`import > path`, which contains a list of :term:`path entries <path entry>`. Each > path > entry names a location to search for modules. > > -The path importer itself doesn't know how to import anything. Instead, it > +The path based finder itself doesn't know how to import anything. > Instead, it > traverses the individual path entries, associating each of them with a > path entry finder that knows how to handle that particular kind of path. > > @@ -479,10 +485,10 @@ > loading all of these file types (other than shared libraries) from > zipfiles. > > Path entries need not be limited to file system locations. They can > refer to > -the URLs, database queries, or any other location that can be specified > as a > +URLs, database queries, or any other location that can be specified as a > string. > > -The :term:`path importer` provides additional hooks and protocols so that > you > +The path based finder provides additional hooks and protocols so that you > can extend and customize the types of searchable path entries. For > example, > if you wanted to support path entries as network URLs, you could write a > hook > that implements HTTP semantics to find modules on the web. This hook (a > @@ -498,8 +504,8 @@ > In particular, meta path finders operate at the beginning of the import > process, as keyed off the :data:`sys.meta_path` traversal. > > -On the other hand, path entry finders are in a sense an implementation > detail > -of the :term:`path importer`, and in fact, if the path importer were to be > +By contrast, path entry finders are in a sense an implementation detail > +of the path based finder, and in fact, if the path based finder were to be > removed from :data:`sys.meta_path`, none of the path entry finder > semantics > would be invoked. > > @@ -513,17 +519,17 @@ > single: sys.path_importer_cache > single: PYTHONPATH > > -The :term:`path importer` is responsible for finding and loading Python > +The :term:`path based finder` is responsible for finding and loading > Python > modules and packages whose location is specified with a string :term:`path > entry`. Most path entries name locations in the file system, but they > need > not be limited to this. > > -As a meta path finder, the :term:`path importer` implements the > +As a meta path finder, the :term:`path based finder` implements the > :meth:`find_module()` protocol previously described, however it exposes > additional hooks that can be used to customize how modules are found and > loaded from the :term:`import path`. > > -Three variables are used by the :term:`path importer`, :data:`sys.path`, > +Three variables are used by the :term:`path based finder`, > :data:`sys.path`, > :data:`sys.path_hooks` and :data:`sys.path_importer_cache`. The > ``__path__`` > attributes on package objects are also used. These provide additional > ways > that the import machinery can be customized. > @@ -536,38 +542,40 @@ > (see the :mod:`site` module) that should be searched for modules, such as > URLs, or database queries. > > -The :term:`path importer` is a :term:`meta path finder`, so the import > +The :term:`path based finder` is a :term:`meta path finder`, so the import > machinery begins the :term:`import path` search by calling the path > -importer's :meth:`find_module()` method as described previously. When > +based finder's :meth:`find_module()` method as described previously. When > the ``path`` argument to :meth:`find_module()` is given, it will be a > list of string paths to traverse - typically a package's ``__path__`` > attribute for an import within that package. If the ``path`` argument > is ``None``, this indicates a top level import and :data:`sys.path` is > used. > > -The :term:`path importer` iterates over every entry in the search path, > and > +The path based finder iterates over every entry in the search path, and > for each of these, looks for an appropriate :term:`path entry finder` for > the > path entry. Because this can be an expensive operation (e.g. there may be > -`stat()` call overheads for this search), the :term:`path importer` > maintains > +`stat()` call overheads for this search), the path based finder maintains > a cache mapping path entries to path entry finders. This cache is > maintained > -in :data:`sys.path_importer_cache`. In this way, the expensive search > for a > -particular :term:`path entry` location's :term:`path entry finder` need > only > -be done once. User code is free to remove cache entries from > -:data:`sys.path_importer_cache` forcing the :term:`path importer` to > perform > -the path entry search again [#fnpic]_. > +in :data:`sys.path_importer_cache` (despite the name, this cache actually > +stores finder objects rather than being limited to :term:`importer` > objects). > +In this way, the expensive search for a particular :term:`path entry` > +location's :term:`path entry finder` need only be done once. User code is > +free to remove cache entries from :data:`sys.path_importer_cache` forcing > +the path based finder to perform the path entry search again [#fnpic]_. > > -If the path entry is not present in the cache, the path importer iterates > over > -every callable in :data:`sys.path_hooks`. Each of the :term:`path entry > hooks > -<path entry hook>` in this list is called with a single argument, the path > -entry being searched. This callable may either return a :term:`path entry > -finder` that can handle the path entry, or it may raise > :exc:`ImportError`. > -An :exc:`ImportError` is used by the path importer to signal that the hook > +If the path entry is not present in the cache, the path based finder > iterates > +over every callable in :data:`sys.path_hooks`. Each of the > +:term:`path entry hooks <path entry hook>` in this list is called with a > +single argument, the path entry to be searched. This callable may either > +return a :term:`path entry finder` that can handle the path entry, or it > may > +raise :exc:`ImportError`. > +An :exc:`ImportError` is used by the path based finder to signal that the > hook > cannot find a :term:`path entry finder` for that :term:`path entry`. The > exception is ignored and :term:`import path` iteration continues. > > If :data:`sys.path_hooks` iteration ends with no :term:`path entry finder` > -being returned, then the path importer's :meth:`find_module()` method will > -store ``None`` in :data:`sys.path_importer_cache` (to indicate that there > -is no finder for this path entry) and return ``None``, indicating that > +being returned, then the path based finder's :meth:`find_module()` method > +will store ``None`` in :data:`sys.path_importer_cache` (to indicate that > +there is no finder for this path entry) and return ``None``, indicating > that > this :term:`meta path finder` could not find the module. > > If a :term:`path entry finder` *is* returned by one of the :term:`path > entry > @@ -594,8 +602,8 @@ > must be a sequence, although it can be empty. > > If :meth:`find_loader()` returns a non-``None`` loader value, the portion > is > -ignored and the loader is returned from the path importer, terminating the > -search through the path entries. > +ignored and the loader is returned from the path based finder, terminating > +the search through the path entries. > > For backwards compatibility with other implementations of the import > protocol, many path entry finders also support the same, > @@ -645,9 +653,6 @@ > XXX runpy, pkgutil, et al in the library manual should all get "See Also" > links at the top pointing to the new import system section. > > -XXX The :term:`path importer` is not, in fact, an :term:`importer`. That's > -why the corresponding implementation class is > :class:`importlib.PathFinder`. > - > > References > ========== > @@ -667,8 +672,8 @@ > :pep:`366` describes the addition of the ``__package__`` attribute for > explicit relative imports in main modules. > > -:pep:`328` introduced absolute and relative imports and initially proposed > -``__name__`` for semantics :pep:`366` would eventually specify for > +:pep:`328` introduced absolute and explicit relative imports and initially > +proposed ``__name__`` for semantics :pep:`366` would eventually specify > for > ``__package__``. > > :pep:`338` defines executing modules as scripts. > @@ -679,14 +684,14 @@ > > .. [#fnmo] See :class:`types.ModuleType`. > > -.. [#fnlo] The importlib implementation appears not to use the return > value > +.. [#fnlo] The importlib implementation avoids using the return value > directly. Instead, it gets the module object by looking the module > name up > - in :data:`sys.modules`.) The indirect effect of this is that an > imported > + in :data:`sys.modules`. The indirect effect of this is that an > imported > module may replace itself in :data:`sys.modules`. This is > implementation-specific behavior that is not guaranteed to work in > other > Python implementations. > > .. [#fnpic] In legacy code, it is possible to find instances of > :class:`imp.NullImporter` in the :data:`sys.path_importer_cache`. It > - recommended that code be changed to use ``None`` instead. See > + is recommended that code be changed to use ``None`` instead. See > :ref:`portingpythoncode` for more details. > diff --git a/Misc/NEWS b/Misc/NEWS > --- a/Misc/NEWS > +++ b/Misc/NEWS > @@ -55,6 +55,10 @@ > Documentation > ------------- > > +- The "path importer" misnomer has been replaced with Eric Snow's > + more-awkward-but-at-least-not-wrong suggestion of "path based finder" in > + the import system reference docs > + > - Issue #15640: Document importlib.abc.Finder as deprecated. > > - Issue #15630: Add an example for "continue" stmt in the tutorial. Patch > by > > -- > Repository URL: http://hg.python.org/cpython > > _______________________________________________ > Python-checkins mailing list > Python-checkins(a)python.org > http://mail.python.org/mailman/listinfo/python-checkins > > [View Less]

2 1

Re: [Python-Dev] [Python-checkins] cpython: Close #4966: revamp the sequence docs in order to better explain the state of
by Nick Coghlan Aug. 20, 2012

Aug. 20, 2012

On Tue, Aug 21, 2012 at 3:01 AM, Terry Reedy <tjreedy(a)udel.edu> wrote: > > > On 8/20/2012 3:14 AM, nick.coghlan wrote: >> >> +(5) >> + :meth:`clear` and :meth:`!copy` are included for consistency with the >> + interfaces of mutable containers that don't support slicing operations >> + (such as :class:`dict` and :class:`set`) >> + >> + .. versionadded:: 3.3 >> + :meth:`clear` and :meth:`!copy` methods. > > > … [View More]

1 0

Raw I/O writelines() broken
by Antoine Pitrou Aug. 20, 2012

Aug. 20, 2012

Hello, I was considering a FileIO.writelines() implementation based on writev() and I noticed that the current RawIO.writelines() implementation is broken: RawIO.write() can return a partial write but writelines() ignores the result and happily proceeds to the next iterator item (and None is returned at the end). (it's probably broken with non-blocking streams too, for the same reason) In the spirit of RawIO.write(), I think RawIO.writelines() could return the number of bytes written (… [View More]

4 4

Re: [Python-Dev] [Python-checkins] cpython: s/path importer/path based finder/ (because the path based finder is not an
by Barry Warsaw Aug. 20, 2012

Aug. 20, 2012

On Aug 20, 2012, at 05:49 AM, nick.coghlan wrote: > s/path importer/path based finder/ (because the path based finder is not an > importer and the simpler 'path finder' is too ambiguous) +1! -Barry

1 0

Re: [Python-Dev] PyPy 1.9 - Yard Wolf
by Lehtonen Miko Aug. 20, 2012

Aug. 20, 2012

moro

1 0

hg verify warnings
by Stefan Krah Aug. 19, 2012

Aug. 19, 2012

Hello, In a fresh clone, I'm getting a couple of warnings in `hg verify`. Perhaps someone familiar with Mercurial could take a brief look: repository uses revlog format 1 checking changesets checking manifests crosschecking files in changesets and manifests checking files warning: copy source of 'Modules/_threadmodule.c' not in parents of 60ad83716733 warning: copy source of 'Objects/bytesobject.c' not in parents of 64bb1d258322 warning: copy source of 'Objects/stringobject.c' not in parents … [View More]

3 3

Should urlencode() sort the query parameters (if they come from a dict)?
by Guido van Rossum Aug. 19, 2012

Aug. 19, 2012

I just fixed a unittest for some code used at Google that was comparing a url generated by urllib.encode() to a fixed string. The problem was caused by turning on PYTHONHASHSEED=1. Because of this, the code under test would generate a textually different URL each time the test was run, but the intention of the test was just to check that all the query parameters were present and equal to the expected values. The solution was somewhat painful, I had to parse the url, split the query parameters, … [View More]

12 18

Mountain Lion drops sign of zero, breaks test_cmath...
by Trent Nelson Aug. 17, 2012

Aug. 17, 2012

The Mountain Lion build slave I set up earlier this evening fails on test_cmath: ====================================================================== FAIL: test_specific_values (test.test_cmath.CMathTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Volumes/bay2/buildslave/cpython/2.7.snakebite-mountainlion-amd64/build/Lib/test/test_cmath.py", line 352, in test_specific_values … [View More] msg=error_message) File "/Volumes/bay2/buildslave/cpython/2.7.snakebite-mountainlion-amd64/build/Lib/test/test_cmath.py", line 94, in rAssertAlmostEqual 'got {!r}'.format(a, b)) AssertionError: atan0000: atan(complex(0.0, 0.0)) Expected: complex(0.0, 0.0) Received: complex(0.0, -0.0) Received value insufficiently close to expected value. Mountain Lion's atan/log1p appear to drop the negative sign when passed in -0.0, whereas previous versions of OS X didn't: Mountain Lion: % ~/log1p-viper log1p_drops_zero_sign_test: atan2(log1p(-0.), -1.) != atan2(-0., -1.) 3.14159 vs -3.14159 atan_drops_zero_sign_test: atan2(-0., 0.): -0.00000 atan2( 0., -0.): 3.14159 atan2(-0., -0.): -3.14159 atan2( 0., 0.): 0.00000 log1p(-0.): 0.00000 log1p( 0.): 0.00000 Lion: % ./log1p log1p_drops_zero_sign_test: atan2(log1p(-0.), -1.) == atan2(-0., -1.) -3.14159 vs -3.14159 atan_drops_zero_sign_test: atan2(-0., 0.): -0.00000 atan2( 0., -0.): 3.14159 atan2(-0., -0.): -3.14159 atan2( 0., 0.): 0.00000 log1p(-0.): -0.00000 log1p( 0.): 0.00000 (The C code for that is below.) configure.ac already has a test for this (it makes mention of AIX having similar behaviour), and the corresponding sysconfig entry named 'LOG1P_DROPS_ZERO_SIGN' is already being used on a few tests, i.e.: # The algorithm used for atan and atanh makes use of the system # log1p function; If that system function doesn't respect the sign # of zero, then atan and atanh will also have difficulties with # the sign of complex zeros. @requires_IEEE_754 @unittest.skipIf(sysconfig.get_config_var('LOG1P_DROPS_ZERO_SIGN'), "system log1p() function doesn't preserve the sign") def testAtanSign(self): for z in complex_zeros: self.assertComplexIdentical(cmath.atan(z), z) @requires_IEEE_754 @unittest.skipIf(sysconfig.get_config_var('LOG1P_DROPS_ZERO_SIGN'), "system log1p() function doesn't preserve the sign") def testAtanhSign(self): for z in complex_zeros: self.assertComplexIdentical(cmath.atanh(z), z) Taking a look at cmath_testcases.txt, and we can see this: -- These are tested in testAtanSign in test_cmath.py -- atan0000 atan 0.0 0.0 -> 0.0 0.0 -- atan0001 atan 0.0 -0.0 -> 0.0 -0.0 -- atan0002 atan -0.0 0.0 -> -0.0 0.0 -- atan0003 atan -0.0 -0.0 -> -0.0 -0.0 However, a few lines down, those tests crop up again: -- special values atan1000 atan -0.0 0.0 -> -0.0 0.0 <snip> atan1014 atan 0.0 0.0 -> 0.0 0.0 ....which is what causes the current test failures. I hacked test_cmath.py a bit to spit out all the errors it finds after it's finished parsing the test file (instead of bombing out on the first one), and it yielded this: FAIL: test_specific_values (test.test_cmath.CMathTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Volumes/bay2/buildslave/cpython/3.2.snakebite-mountainlion-amd64/build/Lib/test/test_cmath.py", line 446, in test_specific_values self.fail("\n".join(failures)) AssertionError: atan1000: atan(complex(-0.0, 0.0)) Expected: complex(-0.0, 0.0) Received: complex(-0.0, -0.0) Received value insufficiently close to expected value. atan1014: atan(complex(0.0, 0.0)) Expected: complex(0.0, 0.0) Received: complex(0.0, -0.0) Received value insufficiently close to expected value. atanh0225: atanh(complex(-0.0, 5.6067e-320)) Expected: complex(-0.0, 5.6067e-320) Received: complex(0.0, 5.6067e-320) Received value insufficiently close to expected value. atanh0227: atanh(complex(-0.0, -3.0861101e-316)) Expected: complex(-0.0, -3.0861101e-316) Received: complex(0.0, -3.0861101e-316) Received value insufficiently close to expected value. atanh1024: atanh(complex(-0.0, -0.0)) Expected: complex(-0.0, -0.0) Received: complex(0.0, -0.0) Received value insufficiently close to expected value. atanh1034: atanh(complex(-0.0, 0.0)) Expected: complex(-0.0, 0.0) Received: complex(0.0, 0.0) Received value insufficiently close to expected value. This is the patch I came up with against test_cmath.py: xenon% hg diff Lib/test/test_cmath.py diff -r ce49599b9fdf Lib/test/test_cmath.py --- a/Lib/test/test_cmath.py Thu Aug 16 22:14:43 2012 +0200 +++ b/Lib/test/test_cmath.py Fri Aug 17 07:54:05 2012 +0000 @@ -121,8 +121,10 @@ # if both a and b are zero, check whether they have the same sign # (in theory there are examples where it would be legitimate for a # and b to have opposite signs; in practice these hardly ever - # occur). - if not a and not b: + # occur) -- the exception to this is if we're on a system that drops + # the sign on zeros. + drops_zero_sign = sysconfig.get_config_var('LOG1P_DROPS_ZERO_SIGN') + if not drops_zero_sign and not a and not b: if math.copysign(1., a) != math.copysign(1., b): self.fail(msg or 'zero has wrong sign: expected {!r}, ' 'got {!r}'.format(a, b)) With that applied, all the test_cmath tests pass again (without any changes to the test file). Thoughts? Trent. -- C code for the example earlier: #include <math.h> #include <stdlib.h> int main(int argc, char **argv) { printf("\nlog1p_drops_zero_sign_test:\n"); if (atan2(log1p(-0.), -1.) == atan2(-0., -1.)) printf(" atan2(log1p(-0.), -1.) == atan2(-0., -1.)\n"); else printf(" atan2(log1p(-0.), -1.) != atan2(-0., -1.)\n"); printf( " %.5f vs %.5f\n", atan2(log1p(-0.), -1.), atan2(-0., -1.) ); printf("\natan_drops_zero_sign_test:\n"); printf(" atan2(-0., 0.): %0.5f\n", atan2(-0., 0.)); printf(" atan2( 0., -0.): %0.5f\n", atan2( 0., -0.)); printf(" atan2(-0., -0.): %0.5f\n", atan2(-0., -0.)); printf(" atan2( 0., 0.): %0.5f\n", atan2( 0., 0.)); printf(" log1p(-0.): %0.5f\n", log1p(-0.)); printf(" log1p( 0.): %0.5f\n", log1p( 0.)); } /* vim:set ts=8 sw=4 sts=4 tw=78 et: */ [View Less]

3 3

Summary of Python tracker Issues
by Python tracker Aug. 17, 2012

Aug. 17, 2012

ACTIVITY SUMMARY (2012-08-10 - 2012-08-17) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 3640 (+52) closed 23856 (+48) total 27496 (+100) Open issues with patches: 1584 Issues opened (80) ================== #15623: Init time relative imports no longer work from __init__.so mod http://bugs.python.org/issue15623 opened by scoder #15625: Support u … [View More]

1 0