[Tutor] Learning to program, not code.
Hello All, Programming has always been a passion of mine, however, I'm frequently frustrated at simple fact that I've been learning python for 8 months, and I have yet to start, and finish, a simple project. I find difficult to not only visualize the execution, but to figure out when and where to use data structure 'x'.Any suggestions on how to approach programming from a different angle? ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] lottery problem (Was Re: (no subject))
Adam Jensen wrote: > Side note: if one were to only import specific functions from a module, > would the load time and memory consumption be smaller? Example, is: > > from random import randint, seed > > smaller and faster than: > > import random Basically from random import randint, seed is equivalent to import random randint = random.randint seed = random.seed del random >From that you can deduce that the whole random module is loaded into memory in both cases. A small speed advantage may be caused when the attribute lookup is avoided in a tight loop $ python3 -m timeit -s 'import random' 'random.randint' 1000 loops, best of 3: 0.0925 usec per loop $ python3 -m timeit -s 'from random import randint' 'randint' 1000 loops, best of 3: 0.0356 usec per loop but the actual randint() function call is so "heavy" that this speedup is lost in the noise when you actually invoke the function: $ python3 -m timeit -s 'from random import randint' 'randint(0, 42)' 10 loops, best of 3: 3.73 usec per loop $ python3 -m timeit -s 'import random' 'random.randint(0, 42)' 10 loops, best of 3: 3.82 usec per loop > Side side note: since 'i' isn't being used, is there a way to loop (within > the list comprehension) without the 'i'? For example, to generate three > random numbers: > > [randint(1,10) for i in range(3)] # This works. > [randint(1,10) for range(3)] # This does not work. No, but in numpy you can express it directly numpy.random.randint(1, 10, 3) or -- if you go back to the original problem -- with some effort: >>> N = 3 >>> numpy.random.randint(1, 10, N) + numpy.arange(0, N*10, 10) array([ 5, 11, 27]) In return the latter is likely significantly more efficient for large N than the generic list comprehension. ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
[Tutor] FW: Learning to program, not code.
Oops, sent it to the original poster only. -Original Message- From: Joseph Lee [mailto:joseph.lee22...@gmail.com] Sent: Friday, December 19, 2014 1:43 AM To: 'Brandon Dorsey' Subject: RE: [Tutor] Learning to program, not code. Hi Brandon, Answers are below. -Original Message- From: Tutor [mailto:tutor-bounces+joseph.lee22590=gmail@python.org] On Behalf Of Brandon Dorsey Sent: Thursday, December 18, 2014 6:10 PM To: tutor@python.org Subject: [Tutor] Learning to program, not code. Hello All, Programming has always been a passion of mine, however, I'm frequently frustrated at simple fact that I've been learning python for 8 months, and I have yet to start, and finish, a simple project. I find difficult to not only visualize the execution, but to figure out when and where to use data structure 'x'.Any suggestions on how to approach programming from a different angle? JL: A very good question. I come from C++ background and have been using Python since 2012. After speaking Python for a while, I realize that programming can be best described as writing a story or an essay. The English-like syntax of Python, coupled with use of indentation and good number of tools helped me appreciate how a program works (for me, from machine level mostly, as I'm working on a project that uses PyWin32 extensions and Win32 API a lot). Another way to approach programming a project is playing a musical piece or watching a play. When you play a song, you know when and how to play a given melody, or when watching a play, you get an idea as to how an actor portrays a particular character. For me, I sometimes view programming as writing a play (rather, a musical), with data structures being props and functions being actors (believe it or not, many geeks are good at arts, including myself - I use my fingers to type the latest screen reading algorithms in Python and play show tunes and video game themes on piano). Good luck. Cheers, Joseph ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Learning to program, not code.
Hello All I am also facing write a code in python please help me for this i read all concepts of python but whem i will started this i am facing lot of problems . -- Forwarded message -- From: Brandon Dorsey Date: Fri, Dec 19, 2014 at 7:39 AM Subject: [Tutor] Learning to program, not code. To: tutor@python.org Hello All, Programming has always been a passion of mine, however, I'm frequently frustrated at simple fact that I've been learning python for 8 months, and I have yet to start, and finish, a simple project. I find difficult to not only visualize the execution, but to figure out when and where to use data structure 'x'.Any suggestions on how to approach programming from a different angle? ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor -- ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Learning to program, not code.
On 19/12/14 02:09, Brandon Dorsey wrote: simple fact that I've been learning python for 8 months, and I have yet to start, and finish, a simple project. That's a pity because the detail involved in completing a project is often where you learn most. Maybe you should take time out from "learning" to concentrate on finishing one simple project. Make a start and when you get stuck, ask here. I find difficult to not only visualize the execution, but to figure out when and where to use data structure 'x'. The base data structures of list, tuple, set, dictionary all have fairly specific uses. - Sets are collections of unique values - Lists are numerically indexed, mutable collections of values - Tuples are numerically indexed, immutable collections of values - Dictionaries are keyed, mutable collections of values. Often you can use any one of list, tuple or dictionary... Use a tuple if it won't be changing. Use a dictionary if you have a natural key value Otherwise use a list Classes are a special case and are best discussed separately if that's where you are struggling. You don't need classes for most simple projects. Any suggestions on how to approach programming from a different angle? You could try designing the program before you start. Often jumping into code too soon leads to confusion. Do you have any method of structuring your code before you start? (For example using pdeudo-code or flow charts?) For a completely different approach to designing code (using Scheme but applicable to Python too) take a look at the web site/ebook "How to Design Programs" http://www.htdp.org/ This is particularly helpful if your problems tend to be algorithmic in nature rather than data store focused. HTH -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Learning to program, not code.
On 19/12/14 09:38, Sarika Shrivastava wrote: I am also facing write a code in python please help me for this i read all concepts of python but whem i will started this i am facing lot of problems . Feel free to ask questions here. But please be specific. We need to know what kind of program you are writing; what its inputs and outputs should look like. If you get error messages you don't understand post the entire error message and at least some of the code from the place where it occurs. (If the code is short (less than 100 lines?) post all of it) Finally, tell us the OS and Python version. -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Learning to program, not code.
On 12/18/2014 09:09 PM, Brandon Dorsey wrote: Hello All, Programming has always been a passion of mine, A great start. Can you tell us a little more about yourself? Is Python the first language you've tried, or are you successful at other languages? Are you in school, at what level, do you already have some other career and this is a hobby? Do you have some hobbies that programming might synergize with? > however, I'm frequently frustrated at simple fact that I've been learning python for 8 months, and I have yet to start, and finish, a simple project. How are you learning python? Are you in a class, did you buy a book, download a tutorial, what? I find difficult to not only visualize the execution, There are tools that may help with that, but it's not clear to me whether that would really help. If you want to play, you could look at: ttp://www.pythontutor.com/visualize.html#mode=edit but to figure out when and where to use data structure 'x'. Alan gave some brief descriptions. You should realize that those are just the particular collections that are in the builtin section of python. There are many more in the standard library, MANY more out on the internet (eg. pypi), and many more in your head, just aching to come out. Any suggestions on how to approach programming from a different angle? That's a great perspective. We're now drowning in a sea of riches, information on any topic. But in most cases, you have to be introduced to a topic systematically, with controlled flow, in order to understand what the fancier concepts are all about. When I "started" programming in 1966, it was with a borrowed Fortran book over spring break. I wrote a number of programs on sheets of paper, but had no machine to execute them on. (I also expect there were more errors than useful statements, but I didn't know anything about that either) I went on a field trip to the nearest computer, which was at Yale. I got to see the actual machinery through some large windows, but didn't have a chance to run anything till almost a year later, at my own college. Even then, freshmen weren't taught anything about them, and I had to learn from another student how to submit punched cards to the computer. And how to run jobs without having a legitimate account. Frequently when people develop an interest in programming now, it's in order to write a game, design a website, or to solve some fairly complex problem. If they then try to research the tools, they get overwhelmed with the possibilities. And without a narrower focus, they never get that satisfaction that comes with finishing a project. Without knowing anything at all about you really, I'd suggest you either take a course, or really *do* a tutorial. Many people just read a book (or site) about the subject, and don't actually try the exercises. In my case it was excusable, since I didn't have the several million dollars necessary to buy a computer, but the principle still holds. Start small, and systematically build up your abilities. If you're disciplined enough to do that on your own, there are many Python tutorials that you can download. And when you get stuck, you'll have a manageable problem that somebody can help with. If you've done all that, and you're still stuck, then be much more specific in your question here. Pick a project (or exercise, or assignment) that you've started working on, and describe the following: 1) python version and OS version 2) project description 3) code fragment that shows your present difficulty 4) what happens, and what you hoped would happen 5) any error messages (show the full stack trace) you get 6) meaningful subject line Python is a fabulous language for learning. You can get feedback a few seconds after you run the code, and you can make a change and try again in under a minute. I worked in one environment where the turnaround for a compile was about a day and a half. And in another where the compile of the complete application was done only once a week, and making it was a half-time job for the build-master. I've also worked in environments where I had to build my own programming tools, starting with a text editor. And in environments where we entered the code in hex. And generating the hex was a pencil/paper exercise. Looseleaf notebook was the source code. -- DaveA ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] lottery problem (Was Re: (no subject))
On Fri, 19 Dec 2014 10:32:15 +0100 Peter Otten <__pete...@web.de> wrote: > Basically > > from random import randint, seed > > is equivalent to > > import random > randint = random.randint > seed = random.seed > del random > > From that you can deduce that the whole random module is loaded into memory > in both cases. A small speed advantage may be caused when the attribute > lookup is avoided in a tight loop Thanks for the clarification, that's really helpful. So I guess the import style is more about name space management than controlling the details of what gets loaded... > or -- if you go back to the original problem -- with some effort: > > >>> N = 3 > >>> numpy.random.randint(1, 10, N) + numpy.arange(0, N*10, 10) > array([ 5, 11, 27]) > > In return the latter is likely significantly more efficient for large N than > the generic list comprehension. Ha! That's fun. Seven seems to be a magic number in the original problem, so maybe a little tweak: import numpy as np N=7 (np.random.randint(1,N,N) + np.arange(0,N*N,N)).tolist() ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Learning to program, not code. [LONG RESPONSE!]
On Thu, Dec 18, 2014 at 8:09 PM, Brandon Dorsey wrote: > > Hello All, > > Programming has always been a passion of mine, however, I'm frequently > frustrated at > > simple fact that I've been learning python for 8 months, and I have yet to > start, and finish, a simple > > project. I find difficult to not only visualize the execution, but to > figure out when and where to > > use data structure 'x'.Any suggestions on how to approach programming > from a different angle? I am going to take a stab at this. Perhaps the perspective from a non-professional in the world of computer programming might be of help. Like you I have had an ongoing fascination with computers and programming ever since I encountered punch cards, FORTRAN and an IBM mainframe in a computer science 101-like course in 1975. Ever since I've from time to time had encounters with programming, that have become more prevalent of late. Perhaps it might be helpful to view programming more simply as computer-aided problem solving, even though, at times, the computer seems to be a major stumbling block if not the outright problem itself. Thinking about it this way means that whatever techniques you know that have proven fruitful for solving other intellectual problems should be useful for programming conundrums as well. A major starting point is to make sure you understand the problem you are trying to tackle, or, at least have a useful overall appreciation of the task before you. As the problems get more challenging, your initial understanding may not be as deep as you would like, but you need to know enough to at least make some sort of start. Next, make sure the problem you chose is likely to be solvable in the domain you choose to approach it. An example of what I mean is that sending all of your program's output to a textual command line interface may not prove very fruitful if you are trying to write a graphical dungeons and dragon game. However, even here there might be possibilities. Some people use to do very interesting ASCII art and graphical like images with those non-alphanumeric ASCII characters. But more than likely you will not be pleased (at least nowadays) creating a final product that runs in the command line. But note that you could fully develop the logic of the adventure itself in this environment and once you had that done, design the GUI/graphical/audio elements. Next, when initially approaching the design of the program, don't get hung up on details! When I used to teach math and physics classes, even at the university level students would get so hung up on the details of the problem as stated, that they could not see the underlying important principles necessary for the problem's solution. Word problems of any kind is a classic example of this. I could window dress up problems that are all solvable using the simple formula distance equals speed multiplied by time, and students would get so confused by the details of the window dressing that they could not see that problems one through a gazillion and one were all solved using this same underlying formula. I think a similar thing happens with learning a programming language and the programming process. Especially in the area of technical vocabulary. Instead of focusing on what program statements, functions, whatever actually DO and cannot do, the student is awash in a sea of technical verbosity. Computer science people, in my personal experience, often have a difficult time saying things SIMPLY. When I was in college I mostly hung out with computer science types, and they were forever speaking in technical acronyms, technical slang, ..., and sometimes even technical profanity! But even though such things as subroutines, functions, methods, and perhaps other names may be precisely defined in somewhat different ways (and even might mean different things to a greater or lesser extent in different programming languages), what they all DO is usually quite similar. Perhaps more importantly when tackling a challenging problem it is easy to get lost in thinking about implementation details that you will have to eventually worry about. But save that sort of worry for later. I like to brainstorm on paper what my expectations are for a program, the overall functionality, what might be "nice" to do, what should be essential to do, ... I try to decompose the overall problem into obvious subunits and might even break these down as well. Then I consider what I already know how to do and how it relates to my brainstorming. An example from circa 1977: I was recently introduced to backgammon and was trying to get as good as possible at it. At the same time I found out about a new room in the computer science building called the software lab. I got permission to hang out there and noticed that they had a relatively new minicomputer that had an experimental monitor hooked up to it. Bear in mind that the most advanced visual display interaction I had had to date was with an IBM S
