Re: Mouse position values
On Wed, 28 Jun 2017 11:32:46 -0300, jorge.conrado wrote: > Hi, > > I have 3D data array and would like to plot arbitrary cross section by > cliking in my image. I was an IDL user and in IDL we have a cursor.pro > that I used to get the X and Y positions on my image. I would like know > how can I get the values of the X an Y position for two points (A and B) > in my image and save thiese values. Unlike some other languages, Python doesn't support getting the mouse coordinates directly. You will have to tell us what version of Python you are using, what operating system you are using, and the version of the OS. If you are using Linux, you probably should tell us what Window Manager you have (Gnome, XFCE, KDE, etc...). Are you using a GUI toolkit, like tkinter, PyQt or similar? If so you should tell us. I'm sorry if this seems complicated, but Python is a language designed to operate on hardware where there might not even be a mouse, so it doesn't support this function without using an external library, and that will depend on your system. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: How to build a simple neural network in 9 lines of Python code
On Tuesday, June 27, 2017 at 12:34:46 PM UTC-7, Marko Rauhamaa wrote: > John Ladasky : > > OK, that's cheating a bit, using Numpy. It's a nice little program, > > but it leverages a huge, powerful library. > > What would *not* be cheating? A language without a library would be > dead. Python's standard library is huge, and useful. Numpy is not part of Python's STANDARD library. I love Numpy, and use it in almost everything I write. But I see that many people won't need it, would find it overwhelming, and would find its way of doing things rather different than standard Python (vectorized mathematical operations, fancy slicing, broadcasting, etc.). So to use Numpy in a post that says, "implement a neural network in Python with just nine lines of code!" seems a little misleading to me. Python is IMHO the best programming language in use today -- and it's the best one for a beginner to start learning. But I wouldn't want to oversell the language to a novice programmer. It's going to take you a long time to understand exactly what those nine lines of code are doing, if you're new to this. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to build a simple neural network in 9 lines of Python code
On Tuesday, June 27, 2017 at 7:28:58 PM UTC-7, Steve D'Aprano wrote: > On Wed, 28 Jun 2017 06:22 am, Marko Rauhamaa wrote: > > > You saw the APL example, right? APL's standard runtime/library contains > > most of Numpy functionality because that's what APL has been designed > > for. > > > > Is that cheating? > > > Of course not. That demonstrates beautifully (or perhaps "unreadably tersely") > that the APL language primitives are extremely powerful (too powerful?). Interesting how this discussion has detoured into APL. I think that these comments underscore my point that Numpy's way of doing things isn't quite Python's way of doing things, that it's a little esoteric. I don't know APL, but... some years ago, I remember reading that the concept of a scalar did not exist in APL. The equivalent of a scalar in APL is (if I understand correctly) a one-dimensional array with one element in it. When I first read that, I thought it was a needless complication. After ten years of Numpy and three months of TensorFlow, it's starting to dawn on me why that might actually make programming sense... if you're thinking in matrix algebra all the time, which increasingly, I find myself doing. -- https://mail.python.org/mailman/listinfo/python-list
Operations Management 13th E by Stevenson Solution Manuals
Greetings Students, We do have Solution Manuals and Test Bank for OPERATIONS MANAGEMENT 13TH E BY STEVENSON at reasonable price. You can get above mentioned resources by sending email to pro.fast(@)hotmail(dot)com. Send your order queries at PRO.FAST(@)HOTMAIL(DOT)COM Below are details given for this book Book Name: OPERATIONS MANAGEMENT Authors: William J Stevenson Edition: 13th E ISBN-10: 1259667472 ISBN-13: 9781259667473 Product Format: MS Word Total Chapters: 19 Items available : Solution Manuals / Test Bank / PPT,s Please mention complete details for your book so we could send you sample accordingly. Best Regards, P.S : Please do not post your reply here. We do not monitor queries here. Simply send us an email directly to PRO.FAST (@) HOTMAIL (DOT) COM -- https://mail.python.org/mailman/listinfo/python-list
Test Bank for Corrections in the 21st Century 8th Edition by Frank Schmalleger
Greetings Students, We do have Test Bank for CORRECTIONS IN THE 21ST CENTURY 8TH EDITION BY SCHMALLEGER at reasonable price. You can get above mentioned resources by sending email to pro.fast(@)hotmail(dot)com Send your order queries at PRO.FAST(@)HOTMAIL(DOT)COM Below are details given for this book Book Name: CORRECTIONS IN THE 21ST CENTURY Authors: Frank Schmalleger, John Smykla Edition: 8th E ISBN-10: 1259916553 ISBN-13: 9781259916557 Product Format: MS Word Total Chapters: 12 Please mention complete details for your book so we could send you sample accordingly. Best Regards, P.S : Please do not post your reply here. We do not monitor queries here. Simply send us an email directly to PRO.FAST (@) HOTMAIL (DOT) COM -- https://mail.python.org/mailman/listinfo/python-list
Solution Manual Test Bank for Financial and Managerial Accounting for MBAs 5th Edition by Easton
Greetings Students, We do have Solution Manuals and Test Bank for FINANCIAL AND MANAGERIAL ACCOUNTING FOR MBAs 5TH EDITION BY EASTON at reasonable price. You can get above mentioned resources by sending email to pro.fast(@)hotmail(dot)com Send your order queries at PRO.FAST(@)HOTMAIL(DOT)COM Below are details given for this book Book Name: FINANCIAL AND MANAGERIAL ACCOUNTING FOR MBAs Authors: Peter D. Easton, Robert F. Halsey, Mary Lea McAnally, Al L. Hartgraves, Wayne J. Morse Edition: 5th E ISBN-10: 1618532324 ISBN-13: 9781618532329 Product Format: MS Word Total Modules: 25 Please mention complete details for your book so we could send you sample accordingly. Best Regards, P.S : Please do not post your reply here. We do not monitor queries here. Simply send us an email directly to PRO.FAST (@) HOTMAIL (DOT) COM -- https://mail.python.org/mailman/listinfo/python-list
Solution Manual Test Bank for Financial Accounting for MBAs 7th Edition by Easton
Greetings Students, We do have Solution Manuals and Test Bank for FINANCIAL ACCOUNTING FOR MBAs 7th EDITION BY EASTON at reasonable price. You can get above mentioned resources by sending email to pro.fast(@)hotmail(dot)com Send your order queries at PRO.FAST(@)HOTMAIL(DOT)COM Below are details given for this book Book Name: FINANCIAL ACCOUNTING FOR MBAs Authors: Peter D. Easton, John J. Wild, Robert F. Halsey, Mary Lea McAnally Edition: 7th E ISBN-13: 9781618532312 Product Format: MS Word Total Modules: 13 Please mention complete details for your book so we could send you sample accordingly. Best Regards, P.S : Please do not post your reply here. We do not monitor queries here. Simply send us an email directly to PRO.FAST (@) HOTMAIL (DOT) COM -- https://mail.python.org/mailman/listinfo/python-list
Solution Manual Test Bank for Financial Statement Analysis and Valuation 5th Edition by Easton
Greetings Students, We do have Solution Manuals and Test Bank for FINANCIAL STATEMENT ANALYSIS AND VALUATION BY EASTON at reasonable price. You can get above mentioned resources by sending email to pro.fast(@)hotmail(dot)com Send your order queries at PRO.FAST(@)HOTMAIL(DOT)COM Below are details given for this book Book Name: FINANCIAL STATEMENT ANALYSIS AND VALUATION Authors: Peter D. Easton, John J. Wild, Robert F. Halsey, Mary Lea McAnally Edition: 5th E ISBN-10: 1618532332 ISBN-13: 9781618532336 Product Format: MS Word Total Modules: 15 + Appendix A,B,C,D Please mention complete details for your book so we could send you sample accordingly. Best Regards, P.S : Please do not post your reply here. We do not monitor queries here. Simply send us an email directly to PRO.FAST (@) HOTMAIL (DOT) COM -- https://mail.python.org/mailman/listinfo/python-list
Re: Error
On 28/06/17 21:08, Ken R. Lewis wrote:
Traceback (most recent call last):
File "I:/CernerProcesses/ServiceNow/new0628.py", line 31, in
data = response.json()
File "C:\Program
Files\Python36\lib\site-packages\requests-2.18.1-py3.6.egg\requests\models.py", line
894, in json
return complexjson.loads(self.text, **kwargs)
File "C:\Program Files\Python36\lib\json\__init__.py", line 354, in loads
return _default_decoder.decode(s)
File "C:\Program Files\Python36\lib\json\decoder.py", line 339, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "C:\Program Files\Python36\lib\json\decoder.py", line 357, in raw_decode
raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
It looks like your reply doesn't contain any JSON. Have you tried
dumping the response out to see exactly what was sent?
--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list
Development testing without reinstalling egg constantly?
I've forked a copy of https://github.com/Roguelazer/muttdown and have
been adding a few features and fixing a few bugs. It's meant to be
installed using setup tools, and then invoked via /usr/bin/muttdown
which looks like this:
#!/usr/lib/python-exec/python2.7/python2
# EASY-INSTALL-ENTRY-SCRIPT: 'muttdown==0.3','console_scripts','muttdown'
__requires__ = 'muttdown==0.3'
import re
import sys
from pkg_resources import load_entry_point
if __name__ == '__main__':
sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0])
sys.exit(
load_entry_point('muttdown==0.3', 'console_scripts', 'muttdown')()
)
The projects 'main.py' can't be run directly from the command line,
since it contains code like this:
from . import config
from . import __version__
__name__ = 'muttdown'
[ stuff that does real work ]
if __name__ == '__main__':
main()
I've hacked up the main.py bits shown above to allow it to be run
directly in order to test changes without installing, but then I
always have to remember to change it back before committing a change.
This seems like the wrong way to do things, but I can't figure out
what the _right_ way is. What's the Pythonic way to do deal with
this?
--
Grant Edwards grant.b.edwardsYow! How's the wife?
at Is she at home enjoying
gmail.comcapitalism?
--
https://mail.python.org/mailman/listinfo/python-list
Re: Development testing without reinstalling egg constantly?
On Thursday, June 29, 2017 at 10:04:30 AM UTC-4, Grant Edwards wrote:
> I've forked a copy of https://github.com/Roguelazer/muttdown and have
> been adding a few features and fixing a few bugs. It's meant to be
> installed using setup tools, and then invoked via /usr/bin/muttdown
> which looks like this:
>
>#!/usr/lib/python-exec/python2.7/python2
># EASY-INSTALL-ENTRY-SCRIPT: 'muttdown==0.3','console_scripts','muttdown'
>__requires__ = 'muttdown==0.3'
>import re
>import sys
>from pkg_resources import load_entry_point
>
>if __name__ == '__main__':
>sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0])
>sys.exit(
>load_entry_point('muttdown==0.3', 'console_scripts', 'muttdown')()
>)
>
> The projects 'main.py' can't be run directly from the command line,
> since it contains code like this:
>
>from . import config
>from . import __version__
>__name__ = 'muttdown'
>
>[ stuff that does real work ]
>
>if __name__ == '__main__':
>main()
>
> I've hacked up the main.py bits shown above to allow it to be run
> directly in order to test changes without installing, but then I
> always have to remember to change it back before committing a change.
>
> This seems like the wrong way to do things, but I can't figure out
> what the _right_ way is. What's the Pythonic way to do deal with
> this?
$ pip install -e .
This will install the code in the current directory in "editable"
fashion. The files in the current directory *are* the installed
code, so when you edit them, you don't have to re-install.
--Ned.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Development testing without reinstalling egg constantly?
Grant Edwards wrote: > The projects 'main.py' can't be run directly from the command line, > since it contains code like this: > >from . import config >from . import __version__ >__name__ = 'muttdown' > >[ stuff that does real work ] Stupid question: isn't the following > >if __name__ == '__main__': >main() dead code then? Actually, two stupid questions: what is >__name__ = 'muttdown' supposed to achieve in the first place? -- https://mail.python.org/mailman/listinfo/python-list
Re: Development testing without reinstalling egg constantly?
On 2017-06-29, Peter Otten <[email protected]> wrote: > Grant Edwards wrote: > >> The projects 'main.py' can't be run directly from the command line, >> since it contains code like this: >> >>from . import config >>from . import __version__ >>__name__ = 'muttdown' >> >>[ stuff that does real work ] > > Stupid question: isn't the following > >> >>if __name__ == '__main__': >>main() > > dead code then? At appears so. > Actually, two stupid questions: what is > >>__name__ = 'muttdown' > > supposed to achieve in the first place? I don't know. This is somebody else's project I'm hacking on, and my understanding of setup tools is pretty much at the "cargo cult" level. -- Grant Edwards grant.b.edwardsYow! FUN is never having to at say you're SUSHI!! gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Development testing without reinstalling egg constantly?
On 06/29/2017 09:03 AM, Grant Edwards wrote: > I've forked a copy of https://github.com/Roguelazer/muttdown and have > been adding a few features and fixing a few bugs. It's meant to be When doing this sort of thing, I find 'pew' virtual environments immensely helpful. They allow you to control python configs and pip loads in userland without having to fiddle with the system versions of things. Highly recommended: https://github.com/berdario/pew -- https://mail.python.org/mailman/listinfo/python-list
Re: Development testing without reinstalling egg constantly?
On 06/29/2017 09:03 AM, Grant Edwards wrote: > I've forked a copy of https://github.com/Roguelazer/muttdown and have > been adding a few features and fixing a few bugs. It's meant to be When doing this sort of thing, I find 'pew' virtual environments immensely helpful. They allow you to control python configs and pip loads in userland without having to fiddle with the system versions of things. Highly recommended: https://github.com/berdario/pew -- https://mail.python.org/mailman/listinfo/python-list
Re: Development testing without reinstalling egg constantly?
On 06/29/2017 08:32 AM, Grant Edwards wrote: This is somebody else's project I'm hacking on, and my understanding of setup tools is pretty much at the "cargo cult" level. I have a sneaking suspicion that's everyone. Setuptools (and distutils before it) has no underlying rhyme or reason; just a collection of stuff and if you do all the stuff then magic. Eggs and wheels and twine make me feel like I'm playing the world's worst Settlers of Catan knockoff every time I try to make a project all pretty, and the XKCD 927 factor is in full and glorious effect. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix. -- https://mail.python.org/mailman/listinfo/python-list
Re: sys.exc_info
On Thu, Jun 29, 2017 at 6:50 AM, Steven D'Aprano wrote: > try: > something > except: > exc_type, exc, tb = sys.exc_info() > print(traceback.extract_tb(tb)) > raise > > Why does it return the exception type separately from the exception, when > the type can be derived by calling `type(exc)`? I think normally it is redundant. While the type and value do have to be tracked separately for the thread's hot exception state (i.e. curexc_type, curexc_value, curexc_traceback), sys.exc_info() returns a caught exception (i.e. exc_type, exc_value, exc_traceback), which is normalized by PyErr_NormalizeException. In CPython you can trivially force the exception value to be None by calling PyErr_SetExcInfo. For example: import sys import ctypes PyErr_SetExcInfo = ctypes.pythonapi.PyErr_SetExcInfo PyErr_SetExcInfo.restype = None PyErr_SetExcInfo.argtypes = (ctypes.py_object,) * 3 PyErr_SetExcInfo(TypeError, None, None) >>> sys.exc_info() (, None, None) Of course this is a silly example, because C. -- https://mail.python.org/mailman/listinfo/python-list
Re: Development testing without reinstalling egg constantly?
On 2017-06-29, Rob Gaddi wrote: > On 06/29/2017 08:32 AM, Grant Edwards wrote: >> >> This is somebody else's project I'm hacking on, and my understanding >> of setup tools is pretty much at the "cargo cult" level. > > I have a sneaking suspicion that's everyone. Setuptools (and distutils > before it) has no underlying rhyme or reason; just a collection of stuff > and if you do all the stuff then magic. Ah, so it's like git. :) https://xkcd.com/1597/ -- Grant Edwards grant.b.edwardsYow! Let me do my TRIBUTE at to FISHNET STOCKINGS ... gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: sys.exc_info
On 29/06/17 08:50, Steven D'Aprano wrote:
> sys.exc_info() returns three items:
>
> (exception type, exception value, traceback)
>
> https://docs.python.org/2/library/sys.html#sys.exc_info
>
> https://docs.python.org/3/library/sys.html#sys.exc_info
>
>
>
> and may be used something like this example:
>
>
> try:
> something
> except:
> exc_type, exc, tb = sys.exc_info()
> print(traceback.extract_tb(tb))
> raise
>
>
>
> Why does it return the exception type separately from the exception, when
> the type can be derived by calling `type(exc)`?
>
>
Ah, Python history.
Back in the old days, it was possible to raise strings instead of the
classes that took over later.
Python 2.4.6 (#1, Jun 29 2017, 19:23:06)
[GCC 5.4.0 20160609] on linux4
Type "help", "copyright", "credits" or "license" for more information.
>>> try:
... raise 'error', 'message'
... except:
... import sys
... print sys.exc_info()
...
('error', 'message', )
>>>
This was deprecated in 2.5, and (I think?) removed in 2.7.
>From looking at the old documentation, I have a suspicion that until
Python 1.4 (or even earlier than that) the exception "value" was
actually never an exception instance. (I'm afraid I can't find a way to
install 1.4 and test it on my computer. At least not a reasonable one.)
Thomas
--
https://mail.python.org/mailman/listinfo/python-list
Re: sys.exc_info
On 2017-06-29 19:19, Thomas Jollans wrote:
[snip]
Ah, Python history.
Back in the old days, it was possible to raise strings instead of the
classes that took over later.
Python 2.4.6 (#1, Jun 29 2017, 19:23:06)
[GCC 5.4.0 20160609] on linux4
Type "help", "copyright", "credits" or "license" for more information.
try:
... raise 'error', 'message'
... except:
... import sys
... print sys.exc_info()
...
('error', 'message', )
This was deprecated in 2.5, and (I think?) removed in 2.7.
Deprecated in 2.5, gone in 2.6.
From looking at the old documentation, I have a suspicion that until
Python 1.4 (or even earlier than that) the exception "value" was
actually never an exception instance. (I'm afraid I can't find a way to
install 1.4 and test it on my computer. At least not a reasonable one.)
--
https://mail.python.org/mailman/listinfo/python-list
Re: sys.exc_info
On 29/06/17 19:00, eryk sun wrote: > On Thu, Jun 29, 2017 at 6:50 AM, Steven D'Aprano wrote: >> try: >> something >> except: >> exc_type, exc, tb = sys.exc_info() >> print(traceback.extract_tb(tb)) >> raise >> >> Why does it return the exception type separately from the exception, when >> the type can be derived by calling `type(exc)`? > > I think normally it is redundant. While the type and value do have to > be tracked separately for the thread's hot exception state (i.e. > curexc_type, curexc_value, curexc_traceback), sys.exc_info() returns a > caught exception (i.e. exc_type, exc_value, exc_traceback), which is > normalized by PyErr_NormalizeException. > > In CPython you can trivially force the exception value to be None by > calling PyErr_SetExcInfo. For example: > > import sys > import ctypes > > PyErr_SetExcInfo = ctypes.pythonapi.PyErr_SetExcInfo > PyErr_SetExcInfo.restype = None > PyErr_SetExcInfo.argtypes = (ctypes.py_object,) * 3 > > PyErr_SetExcInfo(TypeError, None, None) > > >>> sys.exc_info() > (, None, None) > > Of course this is a silly example, because C. > This is doubly silly, as since 1.5 the stdlib documentation has stated that the value "is always a class instance if the exception type is a class object" (... the formulation was changed in py3) -- https://mail.python.org/mailman/listinfo/python-list
Teaching the "range" function in Python 3
I teach Python at two colleges in Silicon Valley. I currently teach an introductory course on Python and most of my students have no programming background whatsoever. Up until now, my colleges have been using Python 2. But now, one of the colleges has made the jump to Python 3. So I am updating my curriculum to Python 3's syntax and concepts. In general, it's all going fine, the changes from raw_input to input, and print from a keyword/statement to the print function have been very straight-forward. But ... Now I am looking at the change in the range function. I completely understand the differences between, and the reasons for, how range works differently in Python 2 vs Python 3. The problem that I've run into has to do with how to explain what range does in Python 3. In Python 2, I easily demonstrated the range function using a simple print statement: print range(0, 10) I discussed how range returns a list. I gave many examples of different values being passed into range, and printing the resulting lists. Next, I introduced the concept of a for loop and show how you use it to iterate over a list, for example: for number in [12, 93, -45.5, 90]: # Some operation using each number (for example, adding up al the numbers) When that was clear, I would go on to explain how you could incorporate range in a for loop: for someVariable in range(0, 10): explaining that range would return a list, and the for statement iterated over that list. Very clear, very easy for new students to understand. But Python 3's version of the range function has been turned into a generator. Again, I understand why this happened, and I agree that this is a good change. The problem is, how can I explain this concept to students who are just learning lists, function and function calls, etc. The concept of how a generator works would be extremely difficult for them to get. The best approach I have seen so far has been to build a simple for loop where I print out the results, like this: for someVariable in range(0, 10): print(someVariable) However, I'm worried that this might lose a lot of students. From their point of view, it might seem difficult to understand that range, which looks like a simple function call passing in the same values each time, returns a different value every time it is called. I am wondering if other teachers have run into this. Is this a real problem? If so, is there any other way of explaining the concept without getting into the underlying details of how a generator works? Do you think it would be helpful to use the words "sequence of numbers" rather than talking about a list here - or would that be even more confusing to students? Thanks, Irv -- https://mail.python.org/mailman/listinfo/python-list
Re: Teaching the "range" function in Python 3
On Fri, Jun 30, 2017 at 6:57 AM, Irv Kalb wrote:
> I am wondering if other teachers have run into this. Is this a real problem?
> If so, is there any other way of explaining the concept without getting into
> the underlying details of how a generator works? Do you think it would be
> helpful to use the words "sequence of numbers" rather than talking about a
> list here - or would that be even more confusing to students?
>
The easiest way is to use the word "collection" for things you iterate
over (rather than the concrete term "list"). So you can loop through
(or iterate over) a collection of explicitly given numbers:
for number in [12, 93, -45.5, 90]:
or you can loop through a range of numbers:
for number in range(10):
or you can loop through any number of other things:
for file in os.scandir("."):
They're all collections. I'd also use this as a great opportunity to
talk about naming conventions - a collection is named in the plural
("things") whereas individual items are named in the singular
("thing") - which means that it's very common to have a loop that
looks like this:
for thing in things:
for file in files:
for num in numbers:
for key in keyring:
That rule should help people keep things straight, without being
bothered by the difference between lists, ranges, and dictionary
views.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Teaching the "range" function in Python 3
On Thu, Jun 29, 2017 at 2:57 PM, Irv Kalb wrote: > Now I am looking at the change in the range function. I completely > understand the differences between, and the reasons for, how range works > differently in Python 2 vs Python 3. The problem that I've run into has to > do with how to explain what range does in Python 3. In Python 2, I easily > demonstrated the range function using a simple print statement: > > print range(0, 10) > > I discussed how range returns a list. I gave many examples of different > values being passed into range, and printing the resulting lists. In Python 3 you could demonstrate this with: >>> print(list(range(0, 10))) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] > Next, I introduced the concept of a for loop and show how you use it to > iterate over a list, for example: > > for number in [12, 93, -45.5, 90]: > # Some operation using each number (for example, adding up al the numbers) > > When that was clear, I would go on to explain how you could incorporate range > in a for loop: > > for someVariable in range(0, 10): > > explaining that range would return a list, and the for statement iterated > over that list. Very clear, very easy for new students to understand. You can still use the rest of this as is. range no longer returns a list directly but you can demonstrate its contents as a list above, and explain that the for statement iterates over the contents of the range. > But Python 3's version of the range function has been turned into a generator. It's not a generator, although that's a common misunderstanding since range is primarily used for iteration. It's still a sequence type; it just takes advantage of the regularity of its contents to store them efficiently by calculating them on demand rather than keeping them all in one big list. For example, you can still do all this: >>> rng = range(10) >>> print(rng) range(0, 10) >>> len(rng) 10 >>> rng[4] 4 >>> rng[3:5] range(3, 5) >>> rng.index(7) 7 >>> rng.count(4) 1 >>> print(list(reversed(rng[3:5]))) [4, 3] The biggest changes as far as usage goes are that its repr() no longer looks like a list, it's now immutable, and it can't be multiplied or added to other lists -- all of which are resolvable by first converting it to a list. So I don't think that you should really need to alter your approach much to teaching this. -- https://mail.python.org/mailman/listinfo/python-list
Re: Teaching the "range" function in Python 3
On 29Jun2017 13:57, Irv Kalb wrote: Now I am looking at the change in the range function. I completely understand the differences between, and the reasons for, how range works differently in Python 2 vs Python 3. The problem that I've run into has to do with how to explain what range does in Python 3. In Python 2, I easily demonstrated the range function using a simple print statement: print range(0, 10) I discussed how range returns a list. I gave many examples of different values being passed into range, and printing the resulting lists. [... and the teaching path from there ...] But Python 3's version of the range function has been turned into a generator. Again, I understand why this happened, and I agree that this is a good change. The problem is, how can I explain this concept to students who are just learning lists, function and function calls, etc. The concept of how a generator works would be extremely difficult for them to get. The best approach I have seen so far has been to build a simple for loop where I print out the results, like this: for someVariable in range(0, 10): print(someVariable) [...] How feasible is it to try a functional approach (in the "functional programming" sense)? They already have lists I understand. Explain that a list is a concrete explicit expression of a sequence of values. Then that there are other ways to express a sequence of values (and allude that there are many ways to express various things). So that when one speaks the prose "the values from A to B", that implies the values A, A+1, etc up (to B-1 in python). In many cases it doesn't matter wther you actaully compute them unless you need a specific value. So "range(A, B)" is a Python builtin expressing the prose "the values from A to B". It doesn't compute them until you need the specific values. This makes it small (no huge list of things for a huge range) and fast (no need to actually count out all the values). Then show them that you can still use it in iteration situations, with the for loop being the classic example. As a bonus, later you can use this paradigm when talking about generators and classes that implement "large but only computed on demand" things. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: Teaching the "range" function in Python 3
Irv Kalb wrote: In Python 2, I easily demonstrated the range function using a simple print statement: print range(0, 10) I discussed how range returns a list. I gave many examples of different values being passed into range, and printing the resulting lists. Next, I introduced the concept of a for loop and show how you use it to iterate over a list, for example: for number in [12, 93, -45.5, 90]: # Some operation using each number (for example, adding up al the numbers) When that was clear, I would go on to explain how you could incorporate range in a for loop: for someVariable in range(0, 10): Don't start with range(). Start with lists, and introduce the for loop as a way to iterate over lists. Leave range() until much later. You should be able to go a *long* way without it -- it's quite rare to need to iterate over a range of ints in idiomatic Python code. When you do get to range(), just say it returns an object that produces a series of ints when you iterate over it. By now they should have seen enough examples of other iterable objects -- lists, tuples, etc. -- that this will make sense. DON'T call it a "generator", btw -- that term is reserved for a very special kind of iterator, and range() isn't one of them. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Teaching the "range" function in Python 3
On Thursday, June 29, 2017 at 4:01:07 PM UTC-5, Irv Kalb wrote: > > [...] > > But Python 3's version of the range function has been > turned into a generator. Again, I understand why this > happened, and I agree that this is a good change. The > problem is, how can I explain this concept to students who > are just learning lists, function and function calls, etc. > The concept of how a generator works would be extremely > difficult for them to get. The best approach I have seen > so far has been to build a simple for loop where I print > out the results, like this: > > for someVariable in range(0, 10): > print(someVariable) > > However, I'm worried that this might lose a lot of > students. From their point of view, it might seem > difficult to understand that range, which looks like a > simple function call passing in the same values each time, > returns a different value every time it is called. You are making the same fatal mistake that many "too bright for their own good" teachers have made since antiquity, and that is, you are bombarding the student with too many concepts at once. And for the archetypal pythonic example of what *NOT* to do, one need look no further than the grease and semen stained pages of the official python tutorial: [QUOTE] 4.6. Defining Functions >>> def fib(n):# write Fibonacci series up to n ... """Print a Fibonacci series up to n.""" ... a, b = 0, 1 ... while a < n: ... print(a, end=' ') ... a, b = b, a+b ... print() ... >>> # Now call the function we just defined: ... fib(2000) 0 1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597 [/QUOTE] As you can see, the author seems more interested in showboating than teaching. :-( If the purpose of this section is to teach the fundamentals of of functions, then the author has failed miserably. A better *FIRST* example would be something like this: def add(x, y): return x + y When teaching a student about functions, the first step is to help them understand *WHY* they need to use functions, and the second is to teach them how to define a function. In my simplistic example, the practical necessity of functions can be easily intuited by the student without the distractions of (1) doc-strings, (2) tuple unpacking, (3) an inner loop structure, (4) implicitly writing to IO streams using the print function, (5) using advanced features of the print function, (6) more tuple unpacking (this time with a twist of lime), (7) and an implicit newline insertion using the print function (deep breath) Now, would someone please remind me, again, what were we learning about??? GHEEZ! So with that plate of scholastic spaghetti in mind, let's return to your dilemma: > for someVariable in range(0, 10): > print(someVariable) > > However, I'm worried that this might lose a lot of > students. From their point of view, it might seem > difficult to understand that range, which looks like a > simple function call passing in the same values each time, > returns a different value every time it is called. First of all, the range function is only called *ONCE* in your example, which can easily be demonstrated by executing this code... >>> for value in range(10): ... print(value) ... 0 1 2 3 4 5 6 7 8 9 And to further drive home the point, you can manually insert a list literal to prove this: >>> range(10) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> for value in [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]: ... print(value) ... 0 1 2 3 4 5 6 7 8 9 Furthermore, you should not introduce loops and the range function in the same example. Do not follow the lead of the Python tutorial author. Instead, introduce both concepts separately, and using the most simple example you can muster. >>> for char in "abc": ... print(char) ... a b c Followed by... >>> for item in (1,2,3): ... print(item) ... 1 2 3 Now, once the student understands that range simply returns a list of things, and that "for loops" iterate over each _thing_ in a collection of _things_ (be that collection a list, or a tuple, or a string, or whatever...), the student will not be so dumbfounded by this code >>> for value in range(10): ... print(value) ... 0 1 2 3 4 5 6 7 8 9 > I am wondering if other teachers have run into this. Is > this a real problem? If so, is there any other way of > explaining the concept without getting into the underlying > details of how a generator works? Generators are an advanced topic and should not be presented until the student has a firm grasp of general programming fundamentals. In python, the general fundamentals would be a very basic, but confident, understanding of: integers, floats, strings, lists, tuples, dicts, variables, c
Re: Teaching the "range" function in Python 3
On Fri, Jun 30, 2017 at 12:33 PM, Rick Johnson wrote: > A better *FIRST* example would be > something like this: > > def add(x, y): > return x + y > > When teaching a student about functions, the first step is > to help them understand *WHY* they need to use functions, > and the second is to teach them how to define a function. In > my simplistic example, the practical necessity of functions > can be easily intuited by the student without the > distractions... ... except that you've made your first function so trivial that it doesn't need to be a function. How does that help anyone understand why they need functions? What's the point of writing "add(5, 7)" rather than "5 + 7"? So you need something else around the outside to justify even having a function at all. In the example in the tutorial, the details ... > ... of (1) doc-strings, (2) tuple unpacking, (3) an > inner loop structure, (4) implicitly writing to IO streams > using the print function, (5) using advanced features of the > print function, (6) more tuple unpacking (this time with a > twist of lime), (7) and an implicit newline insertion using > the print function don't need to be explained at all! They *just work*. You also don't have to explain in detail how garbage collection works, the way that Python's object and type models work, or how the electrons in your CPU are kept from portalling across in a quantum tunnel. None of that matters. So I support the tutorial's example over yours. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Converting sentences to vector form
On Tuesday, June 27, 2017 at 6:15:31 AM UTC-5, Bhaskar Dhariyal wrote: > You can't train a model on words. https://youtu.be/dSIKBliboIo?t=52 -- https://mail.python.org/mailman/listinfo/python-list
import queue in Python 2 and Python 3
What is the best way to import the synchronized queue class that is compatible with both Python2 and Python3. Right now I am using the following: >if sys.version_info < (3, 0): >import Queue as queue >else: >import queue This seems somewhat unpythonic. Is there a better way without installing extra packages? Thanks, Ben -- https://mail.python.org/mailman/listinfo/python-list
Re: import queue in Python 2 and Python 3
On Fri, Jun 30, 2017 at 2:06 PM, Benjamin Chaney wrote: > What is the best way to import the synchronized queue class that is > compatible with both Python2 and Python3. Right now I am using the > following: > >>if sys.version_info < (3, 0): >>import Queue as queue >>else: >>import queue > > This seems somewhat unpythonic. Is there a better way without > installing extra packages? > try: import queue except ImportError: # Python 2 import Queue as queue ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Teaching the "range" function in Python 3
On Friday, June 30, 2017 at 8:28:23 AM UTC+5:30, Chris Angelico wrote: > On Fri, Jun 30, 2017 at 12:33 PM, Rick Johnson wrote: > > A better *FIRST* example would be > > something like this: > > > > def add(x, y): > > return x + y > > > > When teaching a student about functions, the first step is > > to help them understand *WHY* they need to use functions, > > and the second is to teach them how to define a function. In > > my simplistic example, the practical necessity of functions > > can be easily intuited by the student without the > > distractions... > > ... except that you've made your first function so trivial that it > doesn't need to be a function. How does that help anyone understand > why they need functions? What's the point of writing "add(5, 7)" > rather than "5 + 7"? So you need something else around the outside to > justify even having a function at all. Same logic applies to fibonacci also — “Why the f___ are these old fogies teaching us fibonacci and this other crap instead of IOT/Big-Data/how-to-write-an-app/cloud…” or whatever else is hot And if you think this is a theoretical strawman it just means youve not taught enough to know that motivation is at least big a problem as any specific technique/algorithm/language/technology/etc So yes Rick's example has slightly less motivation than fib But if you are focussing on technique its better than the fib — at least it does not contain a blithering print — a point I am sure you will agree with Chris -- https://mail.python.org/mailman/listinfo/python-list
Re: Teaching the "range" function in Python 3
Gregory Ewing wrote: > Don't start with range(). Start with lists, and introduce the for > loop as a way to iterate over lists. Leave range() until much later. > You should be able to go a *long* way without it -- it's quite > rare to need to iterate over a range of ints in idiomatic Python > code. Indeed. Among beginners the for i in range(len(items)): print(items[i]) idiom is already too common. -- https://mail.python.org/mailman/listinfo/python-list
