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 patch for one file because I'd like to have feedback
before tackling the second. However, the patches are independent so
unless there are other problems this is ready for commit.
Best,
Nikolaus
--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
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` claims right there in the name to implement POSIX behavior, and POSIX specifies that `foo` and `foo/` refer (in some cases) to different directory entries. Therefore, `foo` and `foo/` can't be the same path. Moreover, `PosixPath` implements several methods that have the same name as syscalls that POSIX specifies to depend on whether their path arguments end in trailing slashes. (Even `stat` [http://pubs.opengroup.org/onlinepubs/9699919799/functions/stat.html], which explicitly follows symbolic links regardless of the presence of a trailing slash, fails with ENOTDIR if given "path/to/existing/file/".) It feels pathological for `pathlib.PosixPath` to be so almost-compliant.
-ijs
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
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,
which is not implemented for T. As the item attribute is missing at this time, the ininfite recursion starts.
The infinite recursion disappears if I attach a default implementation for __setstate__ to T:
def __setstate__(self, dd):
self.__dict__ = dd
This could be fixed by using „hasattr“ in pickle before trying to call „getattr“.
Is this a bug or did I miss something ?
Kind Regards,
Uwe
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 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.htmlhttps://docs.python.org/3/tutorial/classes.html
[3]: https://docs.python.org/3/tutorial/classes.html
[4]: https://www.python.org/doc/newstyle/
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 least one non- <slash> character and that ends with one or more trailing <slash> characters shall not be resolved successfully unless the last pathname component before the trailing <slash> characters names an existing directory or a directory entry that is to be created for a directory immediately after the pathname is resolved. Interfaces using pathname resolution may specify additional constraints[1] when a pathname that does not name an existing directory contains at least one non- <slash> character and contains one or more trailing <slash> characters.
>
> If a symbolic link is encountered during pathname resolution, the behavior shall depend on whether the pathname component is at the end of the pathname and on the function being performed. If all of the following are true, then pathname resolution is complete:
>
> 1. This is the last pathname component of the pathname.
> 2. The pathname has no trailing <slash>.
> 3. The function is required to act on the symbolic link itself, or certain arguments direct that the function act on the symbolic link itself.
>
> In all other cases, the system shall prefix the remaining pathname, if any, with the contents of the symbolic link. [...]
The following sentence appeared in an earlier version of POSIX (http://pubs.opengroup.org/onlinepubs/009604499/basedefs/xbd_chap04.html#tag…) but has since been removed:
> A pathname that contains at least one non-slash character and that ends with one or more trailing slashes shall be resolved as if a single dot character ( '.' ) were appended to the pathname.
Is this important enough to preserve trailing slashes?
- Isaac Schwabacher
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 modules can do no such check, and are left wondering how to figure out if the platform they are currently running on is an Android one. To my knowledge there is no reliable way to detect if one is using Android as a vehicle for their journey using any other way.
Now, the main question is: what would be the best way to ‘expose’ the indication that Android is being ran on to Python-living modules? My own thought was to add sys.getlinuxuserland(), or platform.linux_userland(), in similar vein to sys.getwindowsversion() and platform.linux_distribution(), which could return information about the userland of running CPython instance, instead of knowing merely the kernel and the distribution.
This way, code could trivially check if it ran on the GNU(+associates) userland, or under a BSD-ish userland, or Android… and adjust its behaviour accordingly.
I would be delighted to hear comments on this proposal, or better yet, alternative solutions. :)
Kind regards,
Shiz
P.S.: I am well aware that Android might as well never be officially supported in CPython. In that case, consider this a thought experiment of how it /would/ be handled. :)
I'd like to point out a couple of compiler warnings on Windows:
On Tue, Jul 29, 2014 at 6:45 PM, antoine.pitrou
<python-checkins(a)python.org> wrote:
> diff --git a/Modules/_io/bytesio.c b/Modules/_io/bytesio.c
> --- a/Modules/_io/bytesio.c
> +++ b/Modules/_io/bytesio.c
> @@ -33,6 +37,45 @@
> return NULL; \
> }
>
> +/* Ensure we have a buffer suitable for writing, in the case that an initvalue
> + * object was provided, and we're currently borrowing its buffer. `size'
> + * indicates the new buffer size allocated as part of unsharing, to avoid a
> + * redundant reallocation caused by any subsequent mutation. `truncate'
> + * indicates whether truncation should occur if `size` < self->string_size.
> + *
> + * Do nothing if the buffer wasn't shared. Returns 0 on success, or sets an
> + * exception and returns -1 on failure. Existing state is preserved on failure.
> + */
> +static int
> +unshare(bytesio *self, size_t preferred_size, int truncate)
> +{
> + if (self->initvalue) {
> + Py_ssize_t copy_size;
> + char *new_buf;
> +
> + if((! truncate) && preferred_size < self->string_size) {
..\Modules\_io\bytesio.c(56): warning C4018: '<' : signed/unsigned mismatch
> + preferred_size = self->string_size;
> + }
> +
> + new_buf = (char *)PyMem_Malloc(preferred_size);
> + if (new_buf == NULL) {
> + PyErr_NoMemory();
> + return -1;
> + }
> +
> + copy_size = self->string_size;
> + if (copy_size > preferred_size) {
..\Modules\_io\bytesio.c(67): warning C4018: '>' : signed/unsigned mismatch
> + copy_size = preferred_size;
> + }
> +
> + memcpy(new_buf, self->buf, copy_size);
> + Py_CLEAR(self->initvalue);
> + self->buf = new_buf;
> + self->buf_size = preferred_size;
> + self->string_size = (Py_ssize_t) copy_size;
> + }
> + return 0;
> +}
>
> /* Internal routine to get a line from the buffer of a BytesIO
> object. Returns the length between the current position to the
--
Zach