On Thu, Oct 20, 2016 at 11:48 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
> >>>>> len(get_builtin_methods()) > >> 230 > > > > So what? No one looks in all the methods of builtins at once. > > Yes, Python implementation developers do, which is why it's a useful > part of defining the overall "size" of Python and how that is growing > over time. > sure -- but of course, the trick is that adding *one" new method is never a big deal by itself. I'm confused though -- IIUC, you are proposing adding a `iobuffers` module to the std lib -- how is that not growing the "size" of Python? I'm still confused about the "io" in "iobuffers" -- I've used buffers a lot -- for passing data around between various C libs -- numpy, image processing, etc... I never really thought of it as IO though. which is why a simple frombuffer() seems to make a lot of sense to me, without any other stuff. (to be honest, I reach for Cyton these days for that sort of thing though) > and we make it easier for educators to decide whether or not they should be > introducing their students to the new capabilities. > advanced domain specific use cases (see > http://learning-python.com/books/python-changes-2014-plus.html for one > generalist author's perspective on the vast gulf that can arise > between "What professional programmers want" and "What's relevant to > new programmers") > thanks for the link -- I'll need to read the whole thing through -- though from a glance, I have a slightly different perspective, as an educator as well: Python 3, in general, is harder to learn and less suited to scripting, while potentially more suited to building larer systems. I came to this conclusion last year when I converted my introductory class to py3. Some of it is the redundancy and whatnot talked about in that link -- yes, those are issue or me. But more of it is real, maybe important change. Interestingly, the biggest issue with the transition: Unicode, is one thing that has made life much easier for newbies :-) But the big ones are things like: The more to be iterable focused rather than sequence focused -- iterables really are harder to wrap one's head around when you are first learning. And I was surprised at how often I had to wrap list() around stuff when converting my examples and exercise solutions. I've decided to teach the format() method for string formatting -- but it is harder to wrap your head around as a newbie. Even the extra parens in print() makes it a bit harder to script() well. Use with: -- now I have to explain context managers before they can even read a file.. (or gloss over it and jsut say " copy this code to open a file" Anyway, I've been meaning to write a Blog post about this, that would be better formed, but you get the idea. In short, I really appreciate the issues here -- though I really don't see how adding one method to a fairily obscure builtin really applies -- this is nothing like having three(!) ways to format strings. Which is more comprehensible and discoverable, dict.setdefault(), or > collections.defaultdict()? > Well, setdefault is Definitively more discoverable! not sure what your point is. As it happens, the homework for my intro class this week can greatly benefit from setdefault() (or defaultdict() ) -- and in the last few years, far fewer newbies have discovered defaultdict() for their solutions. Empirical evidence for discoverability. As for comprehensible -- I give a slight nod to .setdefault() - my solution to the HW uses that. I can't say I have a strong argument as to why -- but having (what looks like) a whole new class for this one extra feature seems a bit odd, and makes one look carefully to see what else might be different about it... > Micro-optimisations like dict.setdefault() typically don't make sense > in isolation - they only make sense in the context of a particular > pattern of thought. Now, one approach to such patterns is to say "We > just need to do a better job of teaching people to recognise and use > the pattern!". This approach tends not to work very well - you're > often better off extracting the entire pattern out to a higher level > construct, giving that construct a name, and teaching that, and > letting people worry about how it works internally later. > hmm -- maybe -- but to me, that example isn't really a pattern of thought (to me) -- I actually remember my history of learning about setdefault(). I found myself writing a bunch of code something like: if key not in a_dict: a_dict[key] = something a_dict['key'].somethign_or_other() Once I had written that code a few times, I thought: "There has got to be a cleaner way to do this", looked at the dict methods and eventually found setdefault() (took an embarrassingly long time). I did think -- "this has got to be a common enough pattern to be somehow supported" but I will say that it never, ever dawned on me to think: "this is got to be a common enough pattern that someone would have made a special kind of dictionary for it" -- I thought of it as a feature you'd want with a dict -- into a different kind of dict. So in the end, if one were to ask ME whether Python should have a .setdefault() method on dict, or an DefaultDict object -- I'd say the method. > bytes and bytarray are already low-level objects -- adding low-level > > functionality to them makes perfect sense. > > They're not really that low level. They're *relatively* low level > (especially for Python), sure -- but that is the context here. > > And no, this is not just for asycio at all -- it's potentially useful > > for any byte manipulation. > Anyway, I think frombuffer() would be a very nice thing to have, and where it goes is secondary. > Yes, which is why I think the end goal should be a public `iobuffers` > module in the standard library. I guess I'd need to see a proposal for what would go in that module to have any opinion on whether it would be a good idea. Is anyone actually working on such a proposal? -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
