Re: checking if a list is empty
On May 6, 2:36 am, Jabba Laci wrote: > Hi, > > If I want to check if a list is empty, which is the more pythonic way? > > li = [] > > (1) if len(li) == 0: > ... > or > (2) if not li: > ... > > Thanks, > > Laszlo is there any problem with (3) if li == []: ? Seems to work when I test it and seems to clearly test what you are trying to test. The only problem might be if in some contexts == has the semantics of checking for object identity. -- http://mail.python.org/mailman/listinfo/python-list
Re: if statement multiple or
On May 6, 8:25 am, Christian Heimes wrote:
> Am 06.05.2011 14:09, schrieb scattered:
>
> > sets could also work
>
> > if set('abc') & set(line) == set():
> > print line
>
> Right!
> Sets work in this special case, because the OP just wants to search for
> a single char. It won't work for longer strings, though.
>
> Also I would write the test as:
>
> if set(line).isdisjoint("abc"):
> print line
>
> Christian
Thanks for the tip - I'm still learning Python and was unaware of the
isdisjoint method.
--
http://mail.python.org/mailman/listinfo/python-list
Re: if statement multiple or
On May 6, 7:00 am, Christian Heimes wrote:
> Am 06.05.2011 12:47, schrieb Lutfi Oduncuoglu:
>
> > Hi,
>
> > I am trying to write a script and I realised that I need to use something
> > like
>
> > if ('a' or 'b' or 'c') not in line:
> > print line
>
> > But it does not work for. What may be the problem
>
> if any(s not in line for s in ('a', 'b', 'c')):
> # do something
>
> Christian
sets could also work
if set('abc') & set(line) == set():
print line
--
http://mail.python.org/mailman/listinfo/python-list
Re: Hooking into Python's memory management
On May 4, 12:51 pm, Daniel Neilson wrote: > Hello, > I'm hoping that there will be someone here with sufficient expertise > to answer a question on Python 3 for me. > > I work in the Computer Science department at a large Canadian > University. We are currently doing a feasibility analysis for switching > to using Python in our first year major-stream courses. > > Part of our first year curriculum requires that students be exposed to > explicit dynamic memory allocation in the form of C++'s new/delete, C's > malloc/free, etc. I realize that Python is garbage collected, and that > there is never a need to explicitly allocate & deallocate objects. > However, I am trying to determine whether or not it is possible to > simulate that behaviour within Python via a module for the purposes of > instruction. > > For these purposes, I would like to know whether it is possible within > Python 3 to write a Python-only module that, essentially, hooks into the > "constructor" and "destructor" of many of the Python built-in types > (specifically list, dictionary, set, tuple, and string) so that the > module can: > 1) Maintain a list of object id()'s for objects that have been > created. Ideally, this list would also contain the file & line number > where the object was created. > 2) Provide a "deallocate" function that will remove a given object's > id() from the list from (1). > 3) Print out an error message if the python script terminates with a > non-empty list from (1). Preferably with a list of objects that are > still "allocated." > > Baring a Python-only module, would this behaviour be possible to add > via a C-language module? > > A module that hooked in to all memory allocation, and inspected the > type of the object being allocated to conditionally add the object's > id() to the list would also suffice. > > In either case, if such a module is possible, any pointers you could > provide regarding how to implement such a module would be appreciated. > > Thank you for your time, > Daniel Maybe you can simulate a heap. Create a heap class where a heap-object maintains an internal list of fixed length (whose length is determined by a constructor)for its heap and a list of free blocks in this heap. It can have methods for allocating and deallocating objects in the heap. Perhaps some sort of dictionary with strings representing pointers as keys and indices of corresponding allocated blocks as values. Subscript-out of range errors in the internal heap would correspond to segmentation errors. The heap-class could catch this error and inform the student. It could also have methods which catch things like dangling pointers and memory leaks. Perhaps a method to display a schematic of the heap. Maybe something as simple as printing something like ||||__|||__ where ||| represents used blocks and represents free space. Displaying this could show the problem of heap-fragmentation. Once you get the interface down - assign some homework where the students need to implement a simple algorithm which requires dynamic memory alocation. The catch is that the students are forbidden from using things like Python lists directly in their code but instead have to get by with using a single instance of this heap object for their data storage needs. Make a bit of a game out of it. I obviously haven't worked out the details, but I suspect that this sort of thing is both easier and more pedagogically sound (since you can tailor the error messages) then what you were looking for. -- http://mail.python.org/mailman/listinfo/python-list
Re: Pairwise frequency count from an incidence matrix of group membership
On Apr 22, 6:57 am, Jean-Michel Pichavant
wrote:
> Shafique, M. (UNU-MERIT) wrote:
> > Hi,
> > I have a number of different groups g1, g2, … g100 in my data. Each
> > group is comprised of a known but different set of members (m1, m2,
> > …m1000) from the population. The data has been organized in an
> > incidence matrix:
> > g1 g2 g3 g4 g5
> > m1 1 1 1 0 1
> > m2 1 0 0 1 0
> > m3 0 1 1 0 0
> > m4 1 1 0 1 1
> > m5 0 0 1 1 0
>
> > I need to count how many groups each possible pair of members share
> > (i.e., both are member of).
> > I shall prefer the result in a pairwise edgelist with weight/frequency
> > in a format like the following:
> > m1, m1, 4
> > m1, m2, 1
> > m1, m3, 2
> > m1, m4, 3
> > m1, m5, 1
> > m2, m2, 2
> > ... and so on.
>
> > I shall highly appreciate if anybody could suggest/share some
> > code/tool/module which could help do this.
>
> > Best regards,
> > Muhammad
>
> Here are some clues
>
> m1 = [1,1,1,0,1]
> m2 = [1,0,0,1,0]
>
> def foo(list1, list2):
> return len([ index for index, val in enumerate(list1) if val and
> list2[index]])
>
> > foo(m1, m1)
> < 4
>
> > foo(m1, m2)
> < 1
>
> JM- Hide quoted text -
>
> - Show quoted text -
He seems to have variables named m1,m2, etc. Would make more sense to
have an array m, but given the varables:
def count_matches(i,j):
pairs = zip(eval("m"+str(i)),eval("m"+str(j)))
return sum([x*y for x,y in pairs])
Then:
>>> m3 = [1,0,1,1]
>>> m4 = [1,0,0,1]
>>> count_matches(3,4)
>>> 2
--
http://mail.python.org/mailman/listinfo/python-list
Re: Feature suggestion -- return if true
On Apr 12, 10:05 am, Westley Martínez wrote: > On Tue, 2011-04-12 at 12:44 +1000, Chris Angelico wrote: > > On Tue, Apr 12, 2011 at 12:20 PM, James Mills > > wrote: > > > On Tue, Apr 12, 2011 at 12:18 PM, Jason Swails > > > wrote: > > >> This is only true if n < 5. Otherwise, the first returns None and the > > >> second returns False. > > > > Which is why I said: > > > > return expr or None > > > > But hey let's argue the point to death! > > > That's still not equivalent. "return expr or None" will always > > terminate the function. The OP's request was for something which would > > terminate the function if and only if expr is non-false. > > > Chris Angelico > > def bs(x): > while not x: > > return x > > Am I wrong here?- Hide quoted text - > > - Show quoted text - I don't think that this is equivalent. The OP's original idea doesn't involve a loop, but this does - how could that be equivalent? -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature suggestion -- return if true
On Apr 12, 2:21 am, James Mills wrote: > On Tue, Apr 12, 2011 at 4:08 PM, Nobody wrote: > > It should be abundantly clear that this only returns if the expression is > > considered true, otherwise it continues on to the following statements. > > Uggh come on guys. We've been over this. > You cannot make that assumption. > > cheers > James > > -- > -- James Mills > -- > -- "Problems are solved by method" I'm puzzled as to why you seem to be parsing the OP's statements different from everybody else. The only assumption that people other than you seem to be making is that they are assuming that the OP meant what he said. He *gave* a definition of what he meant by return? and the definition he actually gave has the property that it terminates the function only when the condition is true, whereas your suggested translation *always* terminates the function call. I agree with "Nobody" that the OP's intention was "abundantly clear". Your "return expr or None" suggestion was not an unreasonable try - but it doesn't provide something which is equivalent to what the OP gave. On the other hand, your persistence in defending your original statement as a plausible translation of return? after the difference has been pointed out by various posters *is* starting to become unreasonable. -- http://mail.python.org/mailman/listinfo/python-list
Re: a better way to invert a list?
On Apr 6, 4:48 am, Glazner wrote: > > > def invert(p): > > > inverse = [None] * len(p) > > > for (i, j) in enumerate(p): > > > inverse[j] = i > > > return inverse > > > Elegant. This seems like the best solution, although it isn't as much > > fun to write as a "one-liner". Thanks > >>> invert([1, 2, 3, 1]) > > [None, 3, 1, 2] #blah I'm not sure if your post was meant to be serious, but if it was note that [1,2,3,1] isn't a list which represents a permutation of 0,1,...,n-1 (where n is the length of the list). Ian Kelly's code works correctly for input of the specified form. -- http://mail.python.org/mailman/listinfo/python-list
Re: a better way to invert a list?
On Apr 5, 5:46 pm, Ian Kelly wrote: > On Tue, Apr 5, 2011 at 3:17 PM, scattered wrote: > > Greetings, > > > I've been playing around (in Python 3.1) with permutations of > > 0,1,...,n-1, represented by lists, p, of length n, where p[i] = the > > image of i under the permutation. I wanted to be able to calculate the > > inverse of such a permutation, and came up with the following succint > > but not quite readable function: > > > def invert(p): > > return [ j for (i,j) in sorted(zip(p,range(len(p] > > > I rejected the obvious [p.index(i) for i in range(len(p))] since that > > seems an inefficient way to sort. Is there a better way to do this? > > Instead of zipping up range(len(p)), you could use the more Pythonic > enumerate: > > def invert(p): > return [i for (i, j) in sorted(enumerate(p), key=operator.itemgetter(1))] > Seems a bit kludgy - isn't their any more direct way to sort by the second element in a list of tuples? I gather that this is one area where Python 3 differs from earlier Pythons - but I never had much experience with Python 2 to compare it with. > The main advantage here is that it will accept an iterator for p, not > just a sequence. But it's still O(n log n ) due to the sort. More > efficient would be: > > def invert(p): > inverse = [None] * len(p) > for (i, j) in enumerate(p): > inverse[j] = i > return inverse Elegant. This seems like the best solution, although it isn't as much fun to write as a "one-liner". Thanks > Which is O(n). If that is too verbose, you could also use a dictionary: > > def invert(p): > return dict(map(reversed, enumerate(p))) > > But the disadvantage here is that if you want to iterate over the > result in order, you're back to either having to sort it or doing > something ugly like this: > > q = invert(p) > for i in range(len(q)): > # Do something with q[i] > > > Another question about my code: What is more idiomatic, [ j for (i,j) > > in ...] or [ x[1] for x in ... ]? I find the former more readable. > > But it makes bindings for i and doesn't use them - which can't be very > > efficient. > > I don't know of any reason to prefer one over the other. One > convention for unpacking values that aren't used is to name the > variable '_'. But this doesn't help efficiency at all; it's just a > convention to inform somebody reading the code that the value is > ignored. > > > In Haskell or ML, you can use patterns that contain wild > > cards that play a role in the pattern-matching but don't establish any > > binding. Can that be done in Python? > > No, unfortunately. > > Cheers, > Ian -- http://mail.python.org/mailman/listinfo/python-list
a better way to invert a list?
Greetings, I've been playing around (in Python 3.1) with permutations of 0,1,...,n-1, represented by lists, p, of length n, where p[i] = the image of i under the permutation. I wanted to be able to calculate the inverse of such a permutation, and came up with the following succint but not quite readable function: def invert(p): return [ j for (i,j) in sorted(zip(p,range(len(p] I rejected the obvious [p.index(i) for i in range(len(p))] since that seems an inefficient way to sort. Is there a better way to do this? Another question about my code: What is more idiomatic, [ j for (i,j) in ...] or [ x[1] for x in ... ]? I find the former more readable. But it makes bindings for i and doesn't use them - which can't be very efficient. In Haskell or ML, you can use patterns that contain wild cards that play a role in the pattern-matching but don't establish any binding. Can that be done in Python? Thanks -- http://mail.python.org/mailman/listinfo/python-list
Re: dynamic assigments
On Mar 25, 1:44 am, Steven D'Aprano wrote: > > In my earlier post, I described the dynamic creation of variables as: > > "... something you should *nearly* always avoid doing." [Emphasis added.] > > Congratulations, you've found one of the few exceptions. Of course an > interactive shell must allow you to create variables interactively. It > would hardly be interactive if you couldn't. This is why interactive > shells are often called a REPL: Read Eval (or Exec) Print Loop. > > Note also that I was describing *variables*. Although there are a lot of > similarities between variables and instance attributes (so much so that > some other languages call them both variables), there are some subtle > differences, and those differences are important. Dynamic *attribute* > creation is not anywhere near as bad a code-smell as dynamic variables: > > setattr(instance, name, value) # A slight whiff, but usually okay. > > globals()[name] = value # Smells pretty bad, but very occasionally okay. > > exec(name + " = " + str(value)) # Reeks like Satan's armpit after a long > # day mucking out the pits of excrement with the souls of the Damned. > I realize that I'm in a distinct minority of Python users, but I tend to write scripts which consist of nothing but function definitions intended to be invoked at a REPL. In effect, I used Python as a sort of highly-programmable calculator. When I saw the OP, it struck me as something having obvious utility for the sorts of things that I, in fact, use Python for. I defer to your judgement that such dynamic bindings are a bad idea in any production code. > > solving cryptograms (as a matter of fact - I was doing exactly this > > yesterday in trying to solve some Playfair ciphers). > > If you're interested in ciphers, you might find this useful: > > http://pypi.python.org/pypi/obfuscate > Thanks for the tip > You have a > > > ciphertext that is a stream of letters in the range A...Z. You need to > > consult frequencies of letters, pairs of letters, triples of letters, > > and quadruples of letters that occur. So, you write a script that steps > > through the cipher text, creates a dictionary which records frequencies > > of strings of length <= 4, and, as an added convienence, creates > > bindings of frequencies to these strings. > > I don't call that a convenience. I call that a problem. What happens when > your cipher text includes > > "...aBzNk6YPq7psGNQ1Pj?lenprem1zGWdefmspzzQ..." > > How many problems can you see there? > I specified that the cipher text consists of characters in the range A to Z (note the case). There is a common convention that, when solving traditional text-based ciphers, you write the ciphertext in upper case and the (unkown) plain text in lower case. That way you are dealing with tentative partial decryptions you can keep track of which letters in your partial solution are drawn from the original ciphertext and which are from your guesses > > Thus - if you want to know how > > often, say, EFW occurs in the ciphertext you just type EFW (rather than > > freq["EFW"]) and the Python shell returns the frequency. > > Sounds like a terrible idea. What do you do when you want to know how > often "len" or "1xy" or "???" or "def" occurs? > > -- > Steven- Hide quoted text - > > - Show quoted text - -- http://mail.python.org/mailman/listinfo/python-list
Re: dynamic assigments
On Mar 24, 11:08 pm, Tim Leslie wrote:
> On 25 March 2011 13:51, scattered wrote:
>
> > Here is another possibility: you are using Python *interactively* in
> > solving cryptograms (as a matter of fact - I was doing exactly this
> > yesterday in trying to solve some Playfair ciphers). You have a
> > ciphertext that is a stream of letters in the range A...Z. You need to
> > consult frequencies of letters, pairs of letters, triples of letters,
> > and quadruples of letters that occur. So, you write a script that
> > steps through the cipher text, creates a dictionary which records
> > frequencies of strings of length <= 4, and, as an added convienence,
> > creates bindings of frequencies to these strings. Thus - if you want
> > to know how often, say, EFW occurs in the ciphertext you just type EFW
> > (rather than freq["EFW"])
>
> And what happens when you want to know the frequency of "if", "def",
> "for" or any other variable which matches a keyword?
>
> Tim
>>> IF = 3
>>> if IF > 1: print("No problem")
>>> 'No problem'
In a *program* such things are silly - for interactive use where you
have motivation to have a family of pre-defined bindings available for
possible use, it is perfectly ok. If Python *did* have an upper-case
keyword (does it? I couldn't think of any), e.g. NULL, then of course
you could write your script to check for that, and for those special
cases (which are unlikely to occur as substrings of a cipher text) you
could make the binding to something like fNULL instead.
--
http://mail.python.org/mailman/listinfo/python-list
Re: dynamic assigments
On Mar 24, 10:51 pm, scattered wrote: [snip] > I can easily imagine other > situations in which a user might want to create a large number of > bindings for interactive use. Maybe as a teacher (I'm a math teacher) > you have written a student-class which contains things like methods to > compute averages, return lists of missing assignments, etc. At the > prompt you run a script that creates a binding for each student in a > section to a student object so that you can just type something like > JohnDoe.missing() to get a list of their missing assignments. Just > because exec() *can* be misused doesn't mean that there aren't valid > uses for it. You would be foolish to run exec() on unparsed externally > supplied data - but perhaps you are running it on data that you > yourself have generated. > I think I might actually implement the above. A quick experiment with IDLE's Python shell shows that an assigment generated by exec() is immediately usable with autocomplete. Many of my students have weird names like Victor Jarinski (a made-up but not untypical example). Typing in average["Victor Jarinski"] for a dictionary look-up requires a fair amount of typing, but if I have a top-level binding I can just type Vic and then invoke auto-complete to get to VictorJarinski.average() with a fraction of the key-strokes. -scattered -- http://mail.python.org/mailman/listinfo/python-list
Re: dynamic assigments
On Mar 24, 7:18 pm, Steven D'Aprano wrote:
> On Thu, 24 Mar 2011 14:39:34 -0700, scattered wrote:
> > Could try:
>
> >>>> my_list = [("x", 7), ("y", 8)]
> >>>> for pair in my_list: exec(pair[0] + " = " + str(pair[1]))
> >>>> x,y
> >>>> (7,8)
>
> Please don't ever do such a thing. The world has enough buggy software
> vulnerable to code injection attacks without you encouraging newbies to
> write more.
>
> If (generic) you, the programmer, can write
>
> my_list = [("x", 7), ("y", 8)]
> for pair in my_list:
> exec(pair[0] + " = " + str(pair[1]))
>
> in your code, then you should stop messing about and just write:
>
> x = 7
> y = 8
>
Good question - though presumably the OP had some motivation for
wanting to do this dynamically. Possibly some sort of code-template
(though then it would probably make more sense to create a text file
which contains the bindings you want, which could then be expanded to
a full-fledged program).
> instead. The only time this technique is even *possibly* justified is if
> the contents of my_list comes from external data not known at compile-
> time.
Here is another possibility: you are using Python *interactively* in
solving cryptograms (as a matter of fact - I was doing exactly this
yesterday in trying to solve some Playfair ciphers). You have a
ciphertext that is a stream of letters in the range A...Z. You need to
consult frequencies of letters, pairs of letters, triples of letters,
and quadruples of letters that occur. So, you write a script that
steps through the cipher text, creates a dictionary which records
frequencies of strings of length <= 4, and, as an added convienence,
creates bindings of frequencies to these strings. Thus - if you want
to know how often, say, EFW occurs in the ciphertext you just type EFW
(rather than freq["EFW"]) and the Python shell returns the frequency.
While this example may seem far-fetched, I can easily imagine other
situations in which a user might want to create a large number of
bindings for interactive use. Maybe as a teacher (I'm a math teacher)
you have written a student-class which contains things like methods to
compute averages, return lists of missing assignments, etc. At the
prompt you run a script that creates a binding for each student in a
section to a student object so that you can just type something like
JohnDoe.missing() to get a list of their missing assignments. Just
because exec() *can* be misused doesn't mean that there aren't valid
uses for it. You would be foolish to run exec() on unparsed externally
supplied data - but perhaps you are running it on data that you
yourself have generated.
> But that means you're vulnerable to a hostile user injecting code
> into your data:
>
> my_list = [("import os; os.system('echo \"deleting all files...\"'); x",
> 7), ("y", 8)]
> for pair in my_list:
> exec(pair[0] + " = " + str(pair[1]))
>
> Code injection attacks are some of the most common source of viruses and
> malware, far more common (and much easier to perform!) today than buffer
> overflows. If an unprivileged process can inject code into something that
> a privileged process is running, your computer is compromised.
>
> --
> Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: dynamic assigments
On Mar 24, 2:39 pm, Seldon wrote:
> Hi, I have a question about generating variable assignments dynamically.
>
> I have a list of 2-tuples like this
>
> (
> (var1, value1),
> (var2, value2),
> .. ,
> )
>
> where var1, var2, ecc. are strings and value1, value2 are generic objects.
>
> Now, I would like to use data contained in this list to dynamically
> generate assignments of the form "var1 = value1", ecc where var1 is an
> identifier equal (as a string) to the 'var1' in the list.
>
> Is there a way to achieve this ?
>
> Thanks in advance for any answer.
Could try:
>>> my_list = [("x", 7), ("y", 8)]
>>> for pair in my_list: exec(pair[0] + " = " + str(pair[1]))
>>> x,y
>>> (7,8)
--
http://mail.python.org/mailman/listinfo/python-list
Re: possible to run a python script without installing python?
On Mar 15, 4:58 pm, davidj411 wrote: > it seems that if I copy the python.exe binary and the folders > associated with it to a server without python, i can run python. > does anyone know which files are important to copy and which can be > omitted? > > i know about py2exe and have had no luck with it. Wouldn't figuring out how to use py2exe be, well, *easier* than figuring out what a minimal install would look like? Your question can't be answered in the abstract. Something is important if you use it. Without seeing your code (and without detailed knowledge of Python internals), there is no way to tell what that might be. You can of course omit things that you don't use - but because of various dependencies you might be using a file without knowing it. One of the purposes of a tool like py2exe is to automatically handle such dependencies. -- http://mail.python.org/mailman/listinfo/python-list
Re: I found some very odd behaviour in Python's very basic types
On Mar 10, 12:47 am, Sunjay Varma wrote:
> For some reason, sub-classing and overwriting a built-in type does not
> change the behavior of the literal. Logically speaking, overwriting a
> name, such as str, should delete the basic str type, and replace it
> with the new class or object put in its place. For some reason though,
> even though the interpreter says that str == type("hello"),
> overwriting the str name changes nothing in the literal. Is this a
> bug? I'm not sure.
>
> I also have just started this very discussion (although in more words)
> on Python-Forum.org. Check it out there as
> well:http://python-forum.org/pythonforum/viewtopic.php?f=18&t=24542&p=113404
>
> I know a lot of very experienced Python programmers view these mailing
> lists. It would be fantastic if this could get fixed. Python would get
> momentously more powerful if this feature was implemented. People
> would be able to apply new methods and attributes to strings, lists,
> dictionaries, sets, and all the built-in types. Improving them when
> needed and allowing for extended functionality.
>
> If you prefer to email me directly, just use this email:
> haimunt(at)yahoo(dot)com
>
> Thanks for your help! I hope we can discuss this (possible) bug. :)
>
> -Sunjay03
I agree with the others that this is a desirable feature rather than a
bug. For one thing, most nontrivial scripts import at least one
module. Those modules will implicitly assume that, e.g., string
literals mean what the language specification says that they mean. If
you were able to change the built-in meaning of strings then how would
these modules function? If you say that they are in their own
namespace and wouldn't be effected by your renaming of str - then you
would still have what you call the odd behavior of the original
meaning of built-in types leaking through your attempt to redefine
them. On the other hand - if the change in basic types *did* apply to
the code in imported modules - that would almost certainly break a lot
of modules. At best you would have some of the murky semantics of
dynamic typing, where the actual meaning of code can't be determined
lexically but would depend on the calling sequence.
In any event - why would you want to change the meaning of built-in
types? I've always thought of OOP as a means to extend a language, not
rewrite it.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Running Scripts vs Interactive mode
On Feb 23, 5:22 pm, grobs456 wrote: > Hi, > > I am trying to work through the tutorial at:http://docs.python.org/tutorial/ > > The issue I am facing is with regards to the discussion about > "Invoking the Interpreter" and "Executable Python Scripts". It was > rather hazy in my opinion. > > see:http://docs.python.org/tutorial/interpreter.html > > I realize I can double click on a .py file and Windows treats it as an > executable but the command prompt pops in and out so quickly that I > can't see the results of my script. > > I would prefer to follow along with the tutorial, compiling new ticks > and topics into a growing .py file, that I error check of course(in > case the same variables are used throughout the tutorial), and then > run that file to see the results as if I would have typed each line in > one at a time. This way I have something usable to refer back to for > learning purposes and for future coding projects instead of having to > rely on the tutorial itself for my reference moving forward. Any > ideas? > > Python is installed at: > C:\Python27 > > and I ran: > set path=%path%;C:\python27 > > #do i have to run the above each time I open up a session? > #Also, note that I do not see the any system environment variables > get updated when I run the above. Greetings, I too have been learning Python on Windows in recent months. I have found using IDLE more than adequate for my purposes. When you right- click on a .py file "Edit with IDLE" is one of the options (if you have a standard Python install). Selecting "run" from IDLE opens up a Python shell and runs the script. Alternatitively, you can open IDLE directly then load your script into it. Unless you need to directly enter Windows commands at a DOS prompt, running scripts from IDLE's Python shell makes for a superior command line for Python, since it is syntax aware (e.g. helps with code indentation) and allows for easy cut-and-paste of previously typed commands. IDLE is a bit clunky compared to commerical IDEs, but is excellent for doing quick experiments. -- http://mail.python.org/mailman/listinfo/python-list
Re: simple games w/o pygame
On Dec 22, 11:40 am, William Gill wrote: > I am teaching an 11 year old who wants to learn programming. I chose > Python, and it is working well. I seem to remember lots of simple > script games, like quizzes, number games etc. that would be good for his > tutorial. However, now all I can find is more complex games using > Pygame. Can anyone help me out here? Maybe you can check out the book "Python Programming for the Absolute Beginner, 3rd Edition" by Michael Dawson. Its emphasis is on simple games. My son is (who is older - just turned 17) is working through it now and finding it easy going. -- http://mail.python.org/mailman/listinfo/python-list
Re: Scheme as a virtual machine?
On Nov 22, 9:45 am, Raffael Cavallaro wrote: > On 2010-11-22 08:12:27 -0500, markhanif...@gmail.com said: > > > All opinions are biased. > > All opinions show some bias. Not all opinions represent what is usually > called a "conflict of interest." Since JH makes his living selling > tools and training for certain languages, he has a severe conflict of > interest wrt asessing the value of various other languages. If these > other languages are just as good or better than those he makes his > living from, it would be very damaging to his livlihood for him to > admit this fact. As a result, he is a completely unreliable source on > the question. > And you don't think that Jon Harrop could write a book about Haskell if he honestly came to think that it were a superior all-aroung language? The fact that he *didn't* mindlessly reject F# in favor of O'Caml when F# came out (despite the fact that at the time his company was deeply (exclusively?) invested in O'Caml and arguably had a vested interest in having F# fail to gain support) suggests that he is able to fairly evaluate the merits of other languages. Doubtless he has biases, but there is no reason to think that they are any greater than the bias of any programmer who has invested substantial amounts of time in becoming fluent in a particular language. > This is why judges must recuse themselves from both civil and criminal > trials if they have some significant conflict of interest. But an advocate isn't a judge. Nobody is handing down binding decisions here - they are just advocating their positions. It would be better to compare JH to a defense lawyer. You can't reject the defense's arguments just because the lawyer has a vested interest in the outcome of the trial. > the law recognizes that we cannot expect a fair judgement from someone who > stands to profit significantly if the judgement goes one way or the > other. Similarly, we cannot expect a fair judgement on the relative > value of various language tools from a person whose livlihood depends > on the audience choosing only those certain language tools that he > sells services and training for. > > warmest regards, > > Ralph > > -- > Raffael Cavallaro -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python like VB?
Steve Horsley wrote: > Were you aware that OpenOffice.org version 2.0, which is due out soon > (beta is available for download), can have python macros, as well as > javascript and StarOffice Basic macros? > > Steve That looks promising, though not as tightly integrated as VBA is with Excel. For now I think I will stick to my goal of learning things like Chaco and wxPython. If I ever take the Linux plunge it's nice to know that OpenOffice is closing the gap with Excel as far as programmability is concerned. -scattered -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python like VB?
Tim Roberts wrote: > "Mike Cox" <[EMAIL PROTECTED]> wrote: > > > >As you may or may not know, Microsoft is discontinuing Visual Basic in favor > >of VB.NET and that means I need to find a new easy programming language. I > >heard that Python is an interpreted language similar to VB. > > This statement is a little bit silly. VB.NET is an interpreted language > which is practically indistinguishable from the old VB. Why on earth would > you choose to reimplement your software in a different language, rather > than just do the simple version upgrade? > It is a bit OT for a python group, but calling VB.NET virtually indistinguishable from VB isn't fair to either language. The differences between them are so significant that many VB developers have taken to calling VB.Net "visual fred" instead ( http://vb.mvps.org/vfred/breaks.asp ). VB.Net is both more powerful and less convienent than VB. You are right that VBA isn't being discontinued yet. My own interest in learning python is to find a replacement for Excel VBA. I'm a mathematician who likes to throw quick programs together for things like statistical simulations. I liked the ability to get functioning code quickly in VBA, together with the ability to easily generate graphs of the results, etc., but I finally got tired of the slow speed and verbose syntax. I'm hoping that Python (as packaged by Enthought together with various numerical and graphing modules) will be an appropriate replacement. -scattered -- http://mail.python.org/mailman/listinfo/python-list
