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
> 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
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
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
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
Well, setdefault is Definitively more discoverable! not sure what your
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
> 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
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
> 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?
Christopher Barker, Ph.D.
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
Python-Dev mailing list