Mailman 3 August 2016 - Python-ideas

Re: [Python-ideas] discontinue iterable strings
by Franklin? Lee 20 Aug '16

20 Aug '16

On Aug 20, 2016 2:27 AM, "Alexander Heger" <python(a)2sn.net> wrote: > The point is it does not try to disassemble it into elements as it would do with other iterables > > >>> np.array([1,2,3]) > array([1, 2, 3]) > >>> np.array([1,2,3]).shape > (3,) It isn't so much that strings are special, it's that lists and tuples are special. Very few iterables can be directly converted to Numpy arrays. Try `np.array({1,2})` and you get `array({1, 2}, dtype=object)`, a 0-dimensional array. > But it does deal with strings as monolithic objects, Seems to me that Numpy treats strings as "I, uh, don't really know what you want me to do with this" objects. That kinda makes sense for Numpy, because, uh, what DO you want Numpy to do with strings? Numpy is NOT designed to mess around with strings, and Numpy does NOT have as high a proportion of programmers using it for strings, so Numpy does not have much insight into what's good and what's useful for programmers who need to mess around with strings. In summary, Numpy isn't a good example of "strings done right, through more experience", because they are barely "done" at all. > doing away with many of the pitfalls of strings in Python. Please start listing the pitfalls, and show how alternatives will be an improvement.

2 1

Re: [Python-ideas] Consider having collections.abc.Sequence
by Arek Bulski 20 Aug '16

20 Aug '16

Could use all(a==b for zip(seq,seq2)) -- Arkadiusz Bulski --

5 5

Re: [Python-ideas] Fix default encodings on Windows
by Random832 20 Aug '16

20 Aug '16

On Mon, Aug 15, 2016, at 12:35, Steve Dower wrote: > I'm still not sure we're talking about the same thing right now. > > For `open(path_as_bytes).read()`, are we talking about the way > path_as_bytes is passed to the file system? Or the codec used to decide > the returned string? We are talking about the way path_as_bytes is passed to the filesystem, and in particular what encoding path_as_bytes is *actually* in, when it was obtained from a file or other stream opened in binary mode.

14 62

Consider having collections.abc.Sequence implement __eq__ and __ne__
by Neil Girdhar 19 Aug '16

19 Aug '16

Both Mapping and Set provide __eq__ and __ne__. I was wondering why not have Sequence do the same? class Sequence(Sized, Reversible, Container): def __eq__(self, other): if not isinstance(other, Sequence): return NotImplemented if len(self) != len(other): return False for a, b in self, other: if a != b: return False return True

1 1

Allow manual creation of DirEntry objects
by Brendan Moloney 18 Aug '16

18 Aug '16

Hi, I have been using the 'scandir' package (https://github.com/benhoyt/scandir) for a while now to speed up some directory tree processing code. Since Python 3.5 now includes 'os.scandir' in the stdlib (https://www.python.org/dev/peps/pep-0471/) I decided to try to make my code work with the built-in version if available. The first issue I hit was that the 'DirEntry' class was not actually being exposed (http://bugs.python.org/issue27038). However in the discussion of that bug I noticed that the constructor for the 'DirEntry' class was deliberately being left undocumented and that there was no clear way to manually create a DirEntry object from a path. I brought up my objections to this decision in the bug tracker and was asked to have the discussion over here on python-ideas. I have a bunch of functions that operate on DirEntry objects, typically doing some sort of filtering to select the paths I actually want to process. The overwhelming majority of the time these functions are going to be operating on DirEntry objects produced by the scandir function, but there are some cases where the user will be supplying the path themselves (for example, the root of a directory tree to process). In my current code base that uses the scandir package I just wrap these paths in a 'GenericDirEntry' object and then pass them through the filter functions the same as any results coming from the scandir function. With the decision to not expose any method in the stdlib to manually create a DirEntry object, I am stuck with no good options. The least bad option I guess would be to copy the GenericDirEntry code out of the scandir package into my own code base. This seems rather silly. I really don't understand the rationale for not giving users a way to create these objects themselves, and I haven't actually seen that explained anywhere. I guess people are unhappy with the overlap between pathlib.Path objects and DirEntry objects and this is a misguided attempt to prod people into using pathlib. I think a better approach is to document the differences between DirEntry and pathlib.Path objects and encourage users to default to using pathlib.Path unless they have good reasons for using DirEntry. Thanks, Brendan

6 10

From mailing list to GitHub issues
by Arek Bulski 16 Aug '16

16 Aug '16

I have been a subscriber only for few weeks now but I dont like the mailing list at all. First, I get all the topics even tho Windows encoding is not of my interest. Second, most of the text is auto quotes anyway. Third, editing posts can sometimes be helpful, for correcting typos and such. I think it would be beneficial to use GitHub issues instead, one for each topic and perhaps one for general notifications like announcing new topics or forum wide announcements. Unfortunately it seems that moving away from existing ways always meets with a lot of inertia. On the other hand, python is probably one of most actively developed langs around so maybe it is doable. I put my proposal on the forum floor to discuss. Cheers to all active participants.

15 30

Re: [Python-ideas] Fix default encodings on Windows
by Guido van Rossum 16 Aug '16

16 Aug '16

I am going to mute this thread but I am worried about the outcome. Once there is agreement please check with me first. --Guido (mobile)

1 0

Re: [Python-ideas] Fix default encodings on Windows
by Random832 15 Aug '16

15 Aug '16

On Mon, Aug 15, 2016, at 09:23, Steve Dower wrote: > I guess I'm not sure what your question is then. > > Using text internally is of course the best way to deal with it. But for > those who insist on using bytes, this change at least makes Windows a > feasible target without requiring manual encoding/decoding at every > boundary. Why isn't it already? What's "not feasible" about requiring manual encoding/decoding? Basically your assumption is that people using Python on windows and having to deal with files that contain filename data encoded as bytes are more likely to be dealing with data that is either UTF-8 anyway (coming from Linux or some other platform) or came from the current version of Python (which will encode things in UTF-8 under the change) than they are to deal with data that came from other Windows programs that encoded things in the codepage used by them and by other Windows users in the same country / who speak the same language.

2 1

Re: [Python-ideas] Fix default encodings on Windows
by Stephen J. Turnbull 15 Aug '16

15 Aug '16

Steve Dower writes: > I plan to use only Unicode to interact with the OS and then utf8 > within Python if the caller wants bytes. This doesn't answer Victor's questions, or mine. This proposal requires identifying and transcoding bytes that represent text in encodings other than UTF-8. 1. How do you propose to identify "bytes that represent text (and might be filenames)" if they did *not* originate in a filesystem or console API? 2. How do you propose to identify the non-UTF-8 encoding, if you have forced all variables signifying bytes encodings to UTF-8? Additional considerations: As far as I can see, this is just a recipe for a different way to get mojibake. *The* way to avoid mojibake is to "let text be text" *internally*. Developers who insist on processing text as bytes are going to get what they deserve *in edge cases*. But mostly (ie, in the mono-encoding environments of most users) it just (barely ;-) works. And there are many use cases where you *can* process bytes that happen to encode text as "just bytes" (eg, low-level networking code). These cases have performance issues if the bytes-text-bytes-text-bytes double-round-trip implied for *stream content* (vs the OS APIs you're concerned with, which effectively round-trip text-bytes-text) is imposed on them.

2 1

Re: [Python-ideas] From mailing list to GitHub issues
by Arek Bulski 15 Aug '16

15 Aug '16

One person saying "this thread doesnt belong here" doesnt make it so. I have met too often in my life with a situation where people were chasing others away because they simply didnt like the particular topic. This thread still Has its participants. You are replying on it As well. And until Discuss is no longer broken, no posting for me there . Will file a bug report tho, as suggested. Sorry for etiquette, will do better. I meant that people not using mailing lists are a considerable group and I was asking on their behalf. And I shall add "thou not Ask Guido directly" to the commandments. The repo should be under official python account, i dont see much sense in starting a private one. But fine, there you go. We can migrate it later if you want. https://github.com/arekbulski/python-ideas/issues/1

1 0