Mailman 3 August 2014 - Python-Dev

Re: [Python-Dev] sum(...) limitation
by Stephen J. Turnbull Aug. 14, 2014

Aug. 14, 2014

Glenn Linderman writes: > On 8/10/2014 1:24 AM, Stephen J. Turnbull wrote: > > Actually ... if I were a fan of the "".join() idiom, I'd seriously > > propose 0.sum(numeric_iterable) as the RightThang{tm]. Then we could > > deprecate "".join(string_iterable) in favor of "".sum(string_iterable) > > (with the same efficient semantics). > Actually, there is no need to wait for 0.sum() to propose "".sum... but > it is only a spelling change, so no real … [View More]

12 17

Commit-ready patches in need of review
by Nikolaus Rath Aug. 12, 2014

Aug. 12, 2014

Hello, The following commit-ready patches have been waiting for review since May and earlier.It'd be great if someone could find the time to take a look. I'll be happy to incorporate feedback as necessary: * http://bugs.python.org/issue1738 (filecmp.dircmp does exact match only) * http://bugs.python.org/issue15955 (gzip, bz2, lzma: add option to limit output size) * http://bugs.python.org/issue20177 (Derby #8: Convert 28 sites to Argument Clinic across 2 files) I only wrote the … [View More]

1 0

pathlib handling of trailing slash (Issue #21039)
by Isaac Schwabacher Aug. 12, 2014

Aug. 12, 2014

I see this as a parallel to the question of `pathlib.PurePath.resolve()`, about which `pathlib` is (rightly!) very opinionated. Just as `foo/../bar` shouldn't resolve to `bar`, `foo/` shouldn't be truncated to `foo`. And if `PurePath` doesn't do this, `Path` shouldn't either, because the difference between a `Path` and a `PurePath` is the availability of filesystem operations, not the identities of the objects involved. On another level, I think that this is a simple decision: `PosixPath` … [View More]

1 0

sum(...) limitation
by Andrea Griffini Aug. 12, 2014

Aug. 12, 2014

help(sum) tells clearly that it should be used to sum numbers and not strings, and with strings actually fails. However sum([[1,2,3],[4],[],[5,6]], []) concatenates the lists. Is this to be considered a bug? Andrea

22 40

python2.7 infinite recursion when loading pickled object
by Schmitt Uwe (ID SIS) Aug. 11, 2014

Aug. 11, 2014

Dear all, I discovered a problem using cPickle.loads from CPython 2.7.6. The last line in the following code raises an infinite recursion class T(object): def __init__(self): self.item = list() def __getattr__(self, name): return getattr(self.item, name) import cPickle t = T() l = cPickle.dumps(t) cPickle.loads(l) loads triggers T.__getattr__ using "getattr(inst, "__setstate__", None)" for looking up a "__setstate__" method, … [View More]

6 6

class Foo(object) vs class Foo: should be clearly explained in python 2 and 3 doc
by John Yeuk Hon Wong Aug. 11, 2014

Aug. 11, 2014

Hi. Referring to my discussion on [1] and then on #python this afternoon. A little background would help people to understand where this was coming from. 1. I write Python 2 code and have done zero Python-3 specific code. 2. I have always been using class Foo(object) so I do not know the new style is no longer required in Python 3. I feel "stupid" and "wrong" by thinking (object) is still a convention in Python 3. 3. Many Python 2 tutorials do not use object as the base class whether for … [View More]historical reason, or lack of information/education, and can cause confusing to newcomers searching for answers when they consult the official documentation. While Python 3 code no longer requires object be the base class for the new-style class definition, I believe (object) is still required if one has to write a 2-3 compatible code. But this was not explained or warned anywhere in Python 2 and Python 3 code, AFAIK. (if I am wrong, please correct me) I propose the followings: * It is desirable to state boldly to users that (object) is no longer needed in Python-3 **only** code and warn users to revert to (object) style if the code needs to be 2 and 3 compatible. * In addition, Python 2 doc [2] should be fixed by introducing the new-style classes. This problem was noted a long long time ago according to [4]. * I would like to see warnings from suggested action item 1 on [2] and [3], for python 2 and 3 documentations. Possible objections(s): * We are pushing toward Python 3, some years later we don't need to maintain both Python 2 and 3 code. And many people, especially the newcomers will probably have no need to maintain Python 2 and 3 compatible codes. My answer to that is we need to be careful with marketing. First, it is a little embarrassing to assume and to find out the assumption is not entirely accurate. Secondly, Python 2 will not go away any time soon and most tutorials available on the Internet today are still written for Python 2. Furthermore, this CAN be a "gotcha" for new developers knowing only Python 3 writing Python 2 & 3 compatible code. * Books can do a better job I haven't actually reviewed/read any Python 3 books knowing most of my code should work without bothering Python 3-2 incompatibility yet. So I don't have an accurate answer, but a very very quick glance over a popular Python 3 book (I am not sure if naming it out is ethical or not so I am going to grey it out here) the book just writes class Foo: and doesn't note the different between 2 and 3 with classes. It is not wrong since the book is about programming in Python 3, NOT writing 2 and 3, but this is where the communication breaks. Docs and books don't give all the answers needed. P.S. Sorry if I should've have asked on #python-dev first or made a ticket but I've decided to send to mailing list before making a bug ticket. First time! Thanks. Best, Yeuk Hon [1]: https://news.ycombinator.com/item?id=8154471 [2]: https://docs.python.org/2/tutorial/classes.html https://docs.python.org/3/tutorial/classes.html [3]: https://docs.python.org/3/tutorial/classes.html [4]: https://www.python.org/doc/newstyle/ [View Less]

7 7

Summary of Python tracker Issues
by Python tracker Aug. 8, 2014

Aug. 8, 2014

ACTIVITY SUMMARY (2014-08-01 - 2014-08-08) 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 4602 (+10) closed 29340 (+43) total 33942 (+53) Open issues with patches: 2177 Issues opened (39) ================== #21039: pathlib strips trailing slash http://bugs.python.org/issue21039 reopened by pitrou #21591: "exec(a, b, c)" not the same as "exec a in … [View More]

1 0

pathlib handling of trailing slash (Issue #21039)
by Isaac Schwabacher Aug. 8, 2014

Aug. 8, 2014

pathlib.Path currently strips trailing slashes from pathnames, but this behavior contradicts POSIX (http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag…), which specifies that the resolution of the pathname of a symbolic link to a directory in the context of a function that operates on symbolic links shall depend on whether the pathname has a trailing slash: > 4.12 Pathname Resolution > ======================== > > [...] > > A pathname that contains at … [View More]

6 8

Re: [Python-Dev] [Python-checkins] Daily reference leaks (09f56fdcacf1): sum=21004
by Brett Cannon Aug. 8, 2014

Aug. 8, 2014

test_codecs is not happy. Looking at the subject lines of commit emails from the past day I don't see any obvious cause. On Thu Aug 07 2014 at 4:35:05 AM <solipsis(a)pitrou.net> wrote: > results for 09f56fdcacf1 on branch "default" > -------------------------------------------- > > test_codecs leaked [5825, 5825, 5825] references, sum=17475 > test_codecs leaked [1172, 1174, 1174] memory blocks, sum=3520 > test_collections leaked [0, 2, 0] references, sum=2 > … [View More]

2 2

Exposing the Android platform existence to Python modules
by Shiz Aug. 4, 2014

Aug. 4, 2014

Hi folks, I’m working on porting CPython to the Android platform, and while making decent progress, I’m currently stuck at a higher-level issue than adding #ifdefs for __ANDROID__ to C extension modules. The idea is, not only CPython extension modules have some assumptions that don’t seem to fit Android’s mold, some default Python-written modules do as well. However, whereas CPython extensions can trivially check if we’re building for Android by checking the __ANDROID__ compiler macro, Python … [View More]

11 28