From kirby.urner at gmail.com Mon Jan 4 15:29:55 2016 From: kirby.urner at gmail.com (kirby urner) Date: Mon, 4 Jan 2016 12:29:55 -0800 Subject: [Edu-sig] pep380: yield from Message-ID: I working through Luciano's Fluent Python, which I really appreciate reading in Safari On-Line as so many of the links are live and relevant. Luciano packs his 'For Further Reading' with links directly in Google groups, where we can see Guido studying Twisted so to better communicate his alternative vision in asyncio (formerly tulip). Here's a tiny test module I'm using, based on Gregory Ewing's PEP 380. https://www.python.org/dev/peps/pep-0380/ from itertools import takewhile def fibo(a,b): "Fibonacci Numbers with any seed" while True: yield a a, b = a + b, a def pep380(EXPR): _i = iter(EXPR) try: _y = next(_i) except StopIteration as _e: _r = _e.value else: while 1: try: _s = yield _y except GeneratorExit as _e: try: _m = _i.close except AttributeError: pass else: _m() raise _e except BaseException as _e: _x = sys.exc_info() try: _m = _i.throw except AttributeError: raise _e else: try: _y = _m(*_x) except StopIteration as _e: _r = _e.value break else: try: if _s is None: _y = next(_i) else: _y = _i.send(_s) except StopIteration as _e: _r = _e.value break return _r def get_em(): # fibs = fibo(0,1) # yield from fibs # delegates to subgenerator # return fibs return pep380(fibo(0,1)) g = get_em() print(tuple(takewhile(lambda n: n < 1000, g))) Console output: (0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987) Now if I comment out differently: def get_em(): fibs = fibo(0,1) yield from fibs # delegates to subgenerator # return fibs # return pep380(fibo(0,1)) Same answer: (0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987) One may also return fibs directly from get_em, showing that 'yield from' is driving the same process i.e. delegation is happening. Just scratching the (itchy) surface. Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirby.urner at gmail.com Mon Jan 4 15:34:59 2016 From: kirby.urner at gmail.com (kirby urner) Date: Mon, 4 Jan 2016 12:34:59 -0800 Subject: [Edu-sig] pep380: yield from In-Reply-To: References: Message-ID: Erratum: 'Luciano packs his 'For Further Reading' with links directly TO Google groups' ETC. FoxPro refugees (Microsoft has stopped supporting that language) will remember READ EVENTS as a last call to get a GUI going, akin to Tk's mainloop(). Quoting from Fluent Python: Dino Viehland showed how asyncio can be integrated with the Tkinter event > loop in his ?Using futures for async GUI programming in Python 3.3? talk > at PyCon US 2013. Viehland shows how easy it is > to implement the essential parts of the asyncio.AbstractEventLoop > interface on top of another event loop. His code was written with Tulip, > prior to the addition of asyncio to the standard library; I adapted it to > work with the Python 3.4 release of asyncio. My updated refactoring is on > GitHub . > Chapter 18, Further Reading Interesting stuff. I have a lot of catching up to do. Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirby.urner at gmail.com Mon Jan 4 17:39:14 2016 From: kirby.urner at gmail.com (kirby urner) Date: Mon, 4 Jan 2016 14:39:14 -0800 Subject: [Edu-sig] continuing with coroutines Message-ID: This code is practical mainly in the trivial sense that it runs to completion. # -*- coding: utf-8 -*- """ Created on Sun Jan 3 13:51:20 2016 @author: kurner """ import itertools def assemble(): drv = yield None drv.result = 1 drv = yield drv drv.result += 1 drv.name = "Alvin" drv = yield drv drv.result += 1 drv.color = "Red" drv = yield drv drv.result += 1 drv.age = 100 return drv class Driver: def __init__(self, g): self.g = g self.g.send(None) # primed self.counter = 1 def go(self): while True: try: self.counter *= 10 self = self.g.send(self) except StopIteration as exc: return exc.args[0].__dict__ d = Driver(assemble()) r = d.go() print(r) Console output: {'name': 'Alvin', 'color': 'Red', 'age': 100, 'counter': 10000, 'g': , 'result': 4} The tractor classes I posted earlier should more properly by referred to as co-routines, as they were driven by a "tick" loop. Python itself is growing more powerful in this area. What stands out about assemble() is it has yields, so is clearly a generator, but also it returns, and the StopIteration value is not only recoverable, but what we expect more generally from a 'yield from'. What assemble returns is a thing that keeps pushing the coroutine with a send(), actually sending itself, meaning it grows attributes from both inside and outside the coroutine. I dump the state of said "thing" as the end result. One starts to see the relevance to concurrency when imagining many coroutines such as assemble() that keep relinquishing control while holding their place, each advancing as driven to do so by a "driver" (task) that whips in on. Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirby.urner at gmail.com Wed Jan 6 18:02:43 2016 From: kirby.urner at gmail.com (kirby urner) Date: Wed, 6 Jan 2016 15:02:43 -0800 Subject: [Edu-sig] continuing with coroutines In-Reply-To: References: Message-ID: # -*- coding: utf-8 -*- """ Created on Sun Jan 6 14:17:00 2016 @author: kurner Demonstrates a driver-along-road pattern where the Driver(road) instance runs to completion when the target of 'yield from'. This is not about interweaving event processing asynchonously. It's about 'yield from' and how the iterator pattern lends itself to setting up coroutines, wherein a driver (future, task) experiences "maturation" (evolving state) based on traversing a road that keeps continuing where it left off. """ from random import choice from time import sleep import sys def road(co_id): """a bumpy road... keeps relinquishing control back to the driver """ drv = yield None drv.result = 1 drv.co_id = co_id drv = yield drv sleep(0.5) drv.result += 1 drv.name = choice(["Alvin", "Eric", "Gwen"]) drv = yield drv drv.result += 1 drv.color = choice(["Red", "Purple", "Orange"]) drv = yield drv drv.result += 1 drv.age = 100 sleep(0.5) return drv # the driver registers changes made along the way class Driver: """Iterator for driving along a road""" def __init__(self, r): self.g = r # on your mark... self.g.send(None) # get set... self.counter = 1 def __iter__(self): return self def __next__(self): while True: # go! ...drive to end of road try: self.counter *= 10 self = self.g.send(self) # expect delays except StopIteration as exc: return exc.value # returned by yield from tasks = [Driver(road(n)) for n in range(4)] # a Driver is instanced per road def delegator(task): return (yield from task) # delegating to a task (blocking once started) coroutines = (delegator(x) for x in tasks) # each based on yield from print("Non-blocking to here.") sys.stdout.flush() results = [ ] for co in coroutines: results.append(co.send(None)) # go! drives each task to completion for result in results: print("Result: {co_id}: {name} {color}".format(**result.__dict__)) -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirby.urner at gmail.com Wed Jan 6 19:43:03 2016 From: kirby.urner at gmail.com (kirby urner) Date: Wed, 6 Jan 2016 16:43:03 -0800 Subject: [Edu-sig] continuing with coroutines In-Reply-To: References: Message-ID: On Wed, Jan 6, 2016 at 3:02 PM, kirby urner wrote: > # -*- coding: utf-8 -*- > """ > Created on Sun Jan 6 14:17:00 2016 > > Jan 6 was not a Sunday -- my bad. Continuing on the topic of concurrency, a switched to mathfuture: bit.ly/1O5VpoB Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniele.gianni at gmail.com Sat Jan 9 05:10:42 2016 From: daniele.gianni at gmail.com (Daniele Gianni) Date: Sat, 9 Jan 2016 11:10:42 +0100 Subject: [Edu-sig] [CfP] 5th IEEE Track on Collaborative Modeling and Simulation (Comets 2016) Message-ID: (Please accept our apologies if you receive multiple copies of this message) ################################################################# IEEE WETICE 2016 5th IEEE Track on Collaborative Modeling and Simulation (Comets 2016) in cooperation with (approval pending) INCOSE Italy MIMOS (Italian Association for M&S) CALL FOR PAPERS ################################################################# June 13-16, 2016 - Paris (France) http://www.sel.uniroma2.it/comets16 ################################################################# # Papers Due: February 15, 2016 # Accepted papers will be published in the conference proceedings # by the IEEE Computer Society Press and will be submitted for # indexing through INSPEC, Compendex, Scopus, Thomson Reuters, # DBLP, Google Scholar and EI Index. ################################################################# Modeling and Simulation (M&S) is increasingly becoming a central activity in the design of new systems and in the analysis of existing systems because it enables designers and researchers to investigate systems behavior through virtual representations. For this reason, M&S is gaining a primary role in many industrial and research fields, such as space, critical infrastructures, manufacturing, emergency management, biomedical systems and sustainable future. However, as the complexity of the investigated systems increases and the types of investigations widens, the cost of M&S activities increases for the more complex models and for the communications among a wider number and variety of M&S stakeholders (e.g., sub-domain experts, simulator users, simulator engineers, and final system users). To address the increasing costs of M&S activities, collaborative technologies must be introduced to support these activities by fostering the sharing and reuse of models, by facilitating the communications among M&S stakeholders, and more generally by integrating processes, tools and platforms. Aside from seeking applications of collaborative technologies to M&S activities, the track seeks innovative contributions that deal with the application of M&S practices in the field of collaborative engineering platforms. These platforms are continuously becoming more complex, and therefore their design requires systematic approaches to meet the required quality of collaboration. This is important for two reasons: to reduce rework activities on the actual collaborative environment, and to maximize the productivity and the quality of the process the collaborative environment supports. M&S offers the methodologies and tools for such investigations and therefore it can be used to improve the quality of collaborative environments. A non-exhaustive list of topics of interest includes: * collaborative requirements modeling * collaborative environments for M&S * collaborative Systems of Systems M&S * business process modeling for collaborative environments * agent-based M&S * collaborative distributed simulation * collaborative component-based M&S * net-centric M&S * web-based M&S * model sharing and reuse * model building and evaluation * modeling and simulation of business processes * modeling for collaboration * simulation-based performance analysis of collaborative engineering platforms * model-driven approaches for collaborative engineering * domain specific languages for collaborative M&S * databases and repositories for M&S * distributed virtual environments * virtual research environment for M&S * collaborative DEVS M&S * multi-method M&S To stimulate creativity, however, the track maintains a wider scope and invites interested researchers to present contributions that offer original perspectives on collaboration and M&S. +++++++++++++++++++++++++++++++++++ On-Line Submissions and Publication +++++++++++++++++++++++++++++++++++ CoMetS'16 intends to bring together researchers and practitioners to discuss key issues, approaches, open problems, innovative applications and trends in the track research area. Papers should contain original contributions not published or submitted elsewhere. Papers up to six pages (including figures, tables and references) can be submitted. Papers should follow the IEEE format (http://www.ieee.org/conferences_events/conferences/ publishing/templates.html). All submissions should be submitted in PDF format and will be peer-reviewed by at least three program committee members. Accepted papers will be included in the proceedings and published by the IEEE Computer Society Press. Please note that at least one author for each accepted paper should register to attend WETICE 2016 (http://www.wetice.org) to have the paper published in the proceedings. Interested authors and participants may contact the organizers for expression of interests and content appropriateness at any time. Papers and posters can be submitted in PDF format at the conference submission site (https://www.easychair.org/conferences/? conf=wetice2016), by selecting the ?Collaborative Modeling and Simulation? track. +++++++++++++++ Important Dates +++++++++++++++ * Submission Deadline: February 15, 2016 * Notification to authors: March 28, 2016 * Camera Ready to IEEE: April 11, 2016 * Conference date: June 13-16, 2016 +++++++++++++++++ Program co-chairs +++++++++++++++++ Andrea D'Ambrogio, University of Roma TorVergata, Italy Gregory Zacharewicz, University of Bordeaux, France Daniele Gianni, Guglielmo Marconi University, Italy *** Contact Information *** Andrea D'Ambrogio (track co-chair) Email: dambro at uniroma2.it -------------- next part -------------- An HTML attachment was scrubbed... URL: From ntoll at ntoll.org Sat Jan 9 20:21:38 2016 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Sun, 10 Jan 2016 01:21:38 +0000 Subject: [Edu-sig] MicroPython and BBC micro:bit things Message-ID: <5691B222.6070305@ntoll.org> Hi Folks, Happy new year everyone! Apologies for cross-posting. Here's hoping it's worth it. We're getting close to a version 1.0 of MicroPython for the BBC's micro:bit device (a small programmable device that'll be given out to the UK's 11 year olds later this year - that's around 1 million devices). You can learn more about the project here: http://ntoll.org/article/story-micropython-on-microbit Damien George (the creator of MicroPython) has really delivered on this and demonstrated what a gifted developer he is. We've also been lucky to have help from a small band of talented developers who have contributed some really great work. But that's not all! Over the autumn I visited lots of UK based Python user groups and teacher led events (mainly CAS related) to show people the work that has been done so far and so we can get feedback from teachers. The bottom line is that we need a *simple* and easy to set-up editor that exposes MicroPython in the best possible way (while the official web-based "TouchDevelop" is great, it doesn't allow you to automatically flash the device, doesn't include a REPL connection for live coding and requires that you're always connected to the internet). Since December I've been working on an alternative solution, called "Mu". It's almost feature complete while still being a work in progress. Check out this video for the current state of affairs: https://www.youtube.com/watch?v=zmOxOusMvjo We need testers for this! If you're a teacher, programmer or developer I'd love to hear from you for help, feedback and bug reporting. You'll get to use the editor and I'll "loan" you a micro:bit (although there will be some caveats that apply because of BBC bureaucracy). If you're interested drop me a line. It's definitely a work in progress, but progress is fast. My autumnal research demonstrated that we also needed resources. To this end I've been running the micro-world-tour ~ an international community of Python developers have been building and sharing cool stuff that uses MicroPython on the micro:bit. Have a read here, I especially love the robots: http://microworldtour.github.io/ We also realised that teachers, developers and kids will need some easy way to share micro:bit output. With the help of the amazingly talented designer, Steve Hawkes I've done two things: 1) A very Wallace and Grommit "micro:bit-o-matic" hosted here: http://pycomic.github.io/microbit.html This lets you easily create and share simulations of the *outputs" from a micro:bit for demonstrative purposes (note - THIS IS NOT A FULL SIMULATOR - rather, it's a quick JavaScript hack so people can create, share and embed demos of micro:bit-y things). 2) We also had a batshit crazy idea to create a fun user-generated PyComic that can be included in educational resources. We want our resources to appeal to the 11yo target age group. So those with more of an affinity with visual rather than verbal instructions are catered for, we've decided to create some of our resources as comics. Our comics will feature "Yellow" and "Blue", the Python snakes..! (Yes, we've had approval from the PSF's trademark committee to use the modified snakes). Check out a proof of concept here (apologies to Guido - but it's such a lovely photograph): http://pycomic.github.io/?title=Testing%201,%202,%203...&author=@ntoll&bg1=bg/bbc_basic.gif&bg2=bg/guido.jpg&bg3=bg/doradus.jpg&h2=Meanwhile,%20somewhere%20in%20Holland...&s1=blue&s3=yellow&rb1=In%20the%20old%20days,%20programming%20looked%20like%20this..!&lb2=Hi,%20I%27m%20Guido%20van%20Rossum%20and%20I%20invented%20the%20Python%20programming%20language.<3=Now%20Python%20is%20even%20used%20in%20space,%20onboard%20the%20International%20Space%20Station%20on%20a%20Raspberry%20Pi Notice how the comic is specified in the URL (it's a static website so there's no backend and state is stored in the query string). You're probably asking, "that's a bit of a long URL isn't it?" to which I'd reply http://bit.ly/ have an API I'm going to use. Again, another work in progress... I'm waiting on some design work from Steve before releasing the "editor" that'll allow you to create your own comics in a simple and easy to share way. It's important to note that these comics are not micro:bit specific - they could be used for any Python related resource and for comedic effect. Finally, we need teacher and student focussed resources (i.e. lesson plans and kid friendly how-tos). We already have developer documentation as a work in progress here: http://microbit-micropython.readthedocs.org/en/latest/ If anyone is interested in helping create these resources I'd love to hear from you. We have plans afoot to help you generate such things in, once again, an easy to create and share manner. As always, comments, constructive critique and ideas are most welcome! Best wishes, Nicholas. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From kirby.urner at gmail.com Sun Jan 10 17:35:14 2016 From: kirby.urner at gmail.com (kirby urner) Date: Sun, 10 Jan 2016 14:35:14 -0800 Subject: [Edu-sig] MicroPython and BBC micro:bit things In-Reply-To: <5691B222.6070305@ntoll.org> References: <5691B222.6070305@ntoll.org> Message-ID: On Sat, Jan 9, 2016 at 5:21 PM, Nicholas H.Tollervey wrote: > Hi Folks, > > Happy new year everyone! > > Apologies for cross-posting. Here's hoping it's worth it. > > Totally worth it. Thank you. I'm learning a lot. Here in the US, we have nothing quite like the BBC. Thanks for the comic with the insanely long URL. The Youtubes I got to watch about this new technology were most intriguing. Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirby.urner at gmail.com Tue Jan 12 15:22:09 2016 From: kirby.urner at gmail.com (kirby urner) Date: Tue, 12 Jan 2016 12:22:09 -0800 Subject: [Edu-sig] greetings from ; looking forward to pep 0498 Message-ID: I've started to pick up some new Python students (adult age) through PDX Code Guild (). http://worldgame.blogspot.com/2016/01/bootcamp.html I was there last night watching their lead instructor coax them into gamely tackling the game of Zombie Dice, which has some pretty simple rules, not unlike Black Jack. https://flic.kr/p/CwcxzH (I assume the rule are Googleble) Tiffany is an accomplished instructor who inspires confidence in her team. https://flic.kr/p/CXDmZ4 ("duck typing" -- inside joke) Here's a snapshot of the kind of 'intro to classes' material we're using at , I'm sure reminiscent of what you've seen elsewhere, that you've written yourself: https://github.com/4dsolutions/Python5/blob/master/intro_classes.py I'm also planning to use this little quiz idea I picked up at Portland Python User Group (PPUG) -- code appended. That'll be when I guest lecture @ on Wednesday, included in the Bootcamp course I'm aiming to pick up, after Intro to Python (starting soon InshaAllah). I'll also share some of the odyssey of our little gem of a School @ O'Reilly, not a sales pitch as we've decided on a different tack ("we" as in ORM, for whom I'm still working even as we speak, marathon runner students rushing to the finish line). Hey, I'm really looking forward to this new PEP being in 3.6: https://mail.python.org/pipermail/portland/2016-January/001733.html (re 0498) My other gig is teaching State of California folks enrolled in an enlightened professional development program. Saisoft.net -- some of you may already know that outfit. That's using Internet, but in real time, whereas School job is / was asynchronous (it's not either / or). Aside: I'm finding Lynda.com has some dynamite content around JavaScript / JQuery I'm thinking. Yes, that's a commercial. Safari Online is dynamite too, a perk I get to keep as a thank you (our faculty was dynamite). http://mybizmo.blogspot.com/2016/01/what-is-jquery.html (the Joe Marini movies are great!) Looking forward to Pycon in Portland! Kirby ==== # -*- coding: utf-8 -*- """ Created on Sun Jan 10 21:15:06 2016 @author: kurner Keywords Quiz Can you think of them all? """ import keyword all_kw = keyword.kwlist[:] # make a copy found = [ ] while len(all_kw) > 0: print("{} keywords left to guess".format(len(all_kw))) guess = input("What is your guess? (q to quit): ") if guess == 'q': print("You gave up!") print("Unguessed: ", all_kw) print("Guessed: ", found) break if guess in all_kw: print("Yes, that's one of them") all_kw.remove(guess) found.append(guess) elif guess in found: print("You got that one already") print("Found:", found) else: print("{} is not a keyword in Python.".format(guess)) else: print("Congratulations; you got them all!") Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirby.urner at gmail.com Sat Jan 23 12:03:25 2016 From: kirby.urner at gmail.com (kirby urner) Date: Sat, 23 Jan 2016 09:03:25 -0800 Subject: [Edu-sig] a common misconception Message-ID: A common misconception in communicating Python is that range() and even list() are "function calls". That's correct for range() in 2.x: >>> type(range) but has never been correct terminology regarding list(). Example: """ >From Chapter 9 of Inventing in Python: The range() and list() Functions When called with one argument, range() will return a range object of integers from 0 up to (but not including) the argument. This range object can be converted to the more familiar list data type with the list() function. Try entering list(range(10)) into the interactive shell: """ The author knows a range object is returned, however that's our clue that range() is calling a type (a class) and returning an instance of that class, ditto list( ). I'd like to see the Python 3.x teaching literature not muddying the waters by referring to range() and list() -- and zip() and enumerate() -- as "function calls". Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirby.urner at gmail.com Sat Jan 23 15:14:31 2016 From: kirby.urner at gmail.com (kirby urner) Date: Sat, 23 Jan 2016 12:14:31 -0800 Subject: [Edu-sig] a common misconception In-Reply-To: <3EFB1CC619385749B99D8B4B22B243FA34B05AE6@MSEXCHMB01.wartburg.edu> References: <3EFB1CC619385749B99D8B4B22B243FA34B05AE6@MSEXCHMB01.wartburg.edu> Message-ID: On Sat, Jan 23, 2016 at 11:58 AM, John Zelle wrote: > Kirby, > > This is an interesting and subtle point. I understand the distinction > that you are making, but syntactically and pragmatically, the call to a > class constructor IS a function call in Python (unlike languages such as > Java where one needs "new" to call a constructor). As support for this > point of view, I would point to the Python documentation: > > https://docs.python.org/3/library/functions.html > > Both the section heading and the table in which "range" and "list" occur > have the heading "Built-in Functions." Yes, it says there are both > built-in functions and types, but they are lumped together under this > broader category. If I tell my students that "list is not a built-in > function," I guarantee some smart aleck is going to pull up that table of > built-in functions to "prove" me wrong. > Great to hear from you John! I've just started working at one PDX Code Guild in downtown Portland and was pleased to find numerous copies of your book scattered about, clearly one of the favorite resources of this tiny academy (connected to Portland State and its "business accelerator / incubator" program). You'll notice the documentation *does* draw attention to the distinction, twixt function call and type call, when you go to list() or range() from the table at the top at the web page you sight. class list([iterable]) > > Rather than being a function, list is actually a mutable sequence type, as > documented in Lists and Sequence Types ? list, tuple, range. > > range(start, stop[, step]) > > Rather than being a function, range is actually an immutable sequence > type, as documented in Ranges and Sequence Types ? list, tuple, range. I think I'd make the distinction between "formal" or "High Church" Python (yes, there's a slight mocking Monty Pythonic spin) versus The Vernacular (or even "vulgar") Python. When teaching, we can treat these as modes e.g. "Just to get High Church about it, range( ) is not a function call but a call to a type: not all callables are functions, even though all functions are callables." pow( ) and sqrt( ) and like that are true functions, as indicated by feeding them to type( ). I want the output to type( ) to make sense to students. I want a lot of "type awareness" i.e. every object has a type. In explaining the transition from Python 2.x to 3.x I like to say "some of what used to be functions, like zip, became types in their own right". For contrast: Python 2.7.3 (v2.7.3:70274d53c1dd, Apr 9 2012, 20:32:06) [GCC 4.0.1 (Apple Inc. build 5493)] on darwin Type "copyright", "credits" or "license()" for more information. >>> type(range) >>> type(zip) >>> ---- Python 3.2.3 (v3.2.3:3d0686d90f55, Apr 10 2012, 11:09:56) [GCC 4.0.1 (Apple Inc. build 5493)] on darwin Type "copyright", "credits" or "license()" for more information. >>> type(range) >>> type(zip) >>> Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.zelle at wartburg.edu Sat Jan 23 14:58:21 2016 From: john.zelle at wartburg.edu (John Zelle) Date: Sat, 23 Jan 2016 19:58:21 +0000 Subject: [Edu-sig] a common misconception In-Reply-To: References: Message-ID: <3EFB1CC619385749B99D8B4B22B243FA34B05AE6@MSEXCHMB01.wartburg.edu> Kirby, This is an interesting and subtle point. I understand the distinction that you are making, but syntactically and pragmatically, the call to a class constructor IS a function call in Python (unlike languages such as Java where one needs "new" to call a constructor). As support for this point of view, I would point to the Python documentation: https://docs.python.org/3/library/functions.html Both the section heading and the table in which "range" and "list" occur have the heading "Built-in Functions." Yes, it says there are both built-in functions and types, but they are lumped together under this broader category. If I tell my students that "list is not a built-in function," I guarantee some smart aleck is going to pull up that table of built-in functions to "prove" me wrong. This is an issue I thought about when writing the Python 3 version of my textbook. In the end, it seemed more awkward/muddying to pedantically separate the call to a constructor (invoked by the type name) vs. a call to a "normal" function. They look, feel, and act the same to the user. Just as I would consider any method invocation a "function call", I consider the constructor invocation to be a function call. I concede your technical point, but I stand by my (and other authors') decision on how to treat this. Cheers, --John John Zelle, PhD Professor of Computer Science Wartburg College ________________________________ From: Edu-sig [edu-sig-bounces+john.zelle=wartburg.edu at python.org] on behalf of kirby urner [kirby.urner at gmail.com] Sent: Saturday, January 23, 2016 11:03 AM To: edu-sig at python.org Subject: [Edu-sig] a common misconception A common misconception in communicating Python is that range() and even list() are "function calls". That's correct for range() in 2.x: >>> type(range) but has never been correct terminology regarding list(). Example: """ >From Chapter 9 of Inventing in Python: The range() and list() Functions When called with one argument, range() will return a range object of integers from 0 up to (but not including) the argument. This range object can be converted to the more familiar list data type with the list() function. Try entering list(range(10)) into the interactive shell: """ The author knows a range object is returned, however that's our clue that range() is calling a type (a class) and returning an instance of that class, ditto list( ). I'd like to see the Python 3.x teaching literature not muddying the waters by referring to range() and list() -- and zip() and enumerate() -- as "function calls". Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: