[How to change redirect stderr?]
Hello, I would like to be able to change the standard error path. How can I do this in a script if I want to send error messages to /dev/null by example ? Thanks -- Sebastien Moretti -- http://mail.python.org/mailman/listinfo/python-list
Re: [How to change redirect stderr?]
Fredrik Lundh wrote:
> "Moretti" wrote:
>
>> I would like to be able to change the standard error path.
>
> (I'm not sure path is the right word here, really, but never mind...)
>
>> How can I do this in a script if I want to send error messages to
>> /dev/null by example ?
>
> if you're talking about things that Python prints to stderr, all you need
> to do is to replace sys.stderr with something more suitable:
>
> import sys
> sys.stderr = open("/dev/null", "w")
>
> or, more portable:
>
> class NullDevice:
> def write(self, s):
> pass
>
> sys.stderr = NullDevice()
>
> if you want to redirect both things printed via sys.stderr and things
> printed to stderr at the C level, you need to redirect the STDERR file
> handle. here's one way to do that:
>
> import os, sys
>
> sys.stderr.flush()
> err = open('/dev/null', 'a+', 0)
> os.dup2(err.fileno(), sys.stderr.fileno())
>
> hope this helps!
>
>
Thanks
It's exactly what I seek for.
--
Sebastien Moretti
--
http://mail.python.org/mailman/listinfo/python-list
Re: Will python never intend to support private, protected and public?
[EMAIL PROTECTED] wrote: > On Fri, 30 Sep 2005 00:16:02 +1000 > Steven D'Aprano wrote: > >>Say you have written a class, with a private variable. I decide that I >>need access to that variable, for reasons you never foresaw. > > What if the access to that variable was forbidden for reasons you never > foresaw? What if the class author decide to remove the variable in the next > version of the class, because it's not an interface, but only a part of the > class implementation? What if the class author removes a non-private variable or changes a method's documented parameters in the next version of the class, because he think it'll work better, or just because he can? People who think that forbidding access to private variables/methods will save themselves from upgrade woes are deluding themselves. -- http://mail.python.org/mailman/listinfo/python-list
Re: A rather unpythonic way of doing things
fraca7 wrote:
> Richie Hindle a écrit :
>
>> [Peter]
>>
>>> http://www.pick.ucam.org/~ptc24/yvfc.html
>>
>>
>>
>> [Jeff]
>>
>>> Yuma Valley Agricultural Center?
>>> Yaak Valley Forest Council?
>>
>>
>>
>> I went through the same process. My guess is "Yes, Very F'ing Clever."
>> Peter?
>>
>
> print ''.join(map(lambda x: chrord(x) - ord('a')) + 13) % 26) +
> ord('a')), 'yvfc'))
Less pythonic:
__import__('sys').stdout.write(''.join(map(lambda x: chrord(x) -
ord('a')) + 13) % 26) + ord('a')), 'yvfc'))
More Pythonic:
print 'yvfc'.decode('rot13')
--
http://mail.python.org/mailman/listinfo/python-list
Re: Will python never intend to support private, protected and public?
Antoon Pardon wrote: >>What if the class author removes a non-private variable or changes a >>method's documented parameters in the next version of the class, because >>he think it'll work better, or just because he can? > > Changing an interface is different from changing the implementation. > A (documented) interface is like a contract. The implementation is > just one way to follow that contract. Agreed. However, there is also a difference between an interface and "non-private variables." E.g. you have a library, and playing with the code, you notice that by passing an empty string as a filename, you get the last file accessed. Cool. You write your program using this feature. Problem is, it's a quirk of the implementation, and in the next version, the library author fixes this "bug". Preventing access to private variables wouldn't help - the only thing you touched was the public parameter to a public function. Of course, you could have avoided this by only using the documented interface, but if we go that route, you wouldn't have to worry about people accessing private variables, as they wouldn't be documented. There is little in the way of technical problems that are solved by language level enforcement of private variables. The issues in question are mostly social ones, and if you're not reading and following the documented interface, stopping private variable access is not going to prevent most of your problems. >> People who think that forbidding access to private variables/methods >> will save themselves from upgrade woes are deluding themselves. > > It helps, just as locks wont save you from burglars if they really > want to rob you, but the locks do help. Right, but like doors that automatically lock when they close, items which are there to protect you can be a nusaince, especially when you've left your keys on the dining room table. -- http://mail.python.org/mailman/listinfo/python-list
Re: Will python never intend to support private, protected and public?
Paul Rubin wrote: > I don't know of a single program that's actually relying on the > non-enforcement. I've asked for examples but have only gotten > theoretical ones. As far as I can tell, the feature is useless. I'd like to turn the question around on you - can you come up with an instance where the non-enforcement has tripped someone up? Is there a bug you can point to that would have been prevented if Python enforced private member semantics? -- http://mail.python.org/mailman/listinfo/python-list
Re: [Info] PEP 308 accepted - new conditional expressions
Reinhold Birkenfeld wrote: > Hi, > > after Guido's pronouncement yesterday, in one of the next versions of Python > there will be a conditional expression with the following syntax: > > X if C else Y Any word on chaining? That is, what would happen with the following constructs: A if B else C if D else F A if B if C else D else F The first one is the tricky bit - it could be either (A if B else C) if D else F or A if B else (C if D else F) I'd expect the former from left-> right semantics, but reading the unparenthesized form, I'd see "A if B else ..." note that B is true, and conclude the expression evaluated to A (which would be wrong if D is false). -- http://mail.python.org/mailman/listinfo/python-list
Re: Reply-To header
Roel Schroeven wrote: > Peter Decker wrote: > >>On 10/3/05, Roel Schroeven <[EMAIL PROTECTED]> wrote: >> >>On lists like this, where everyone benefits by sharing information, it >>seems pretty lame to hide behind purist arguments about Reply-To: >>headers. The default behavior should be the one most useful to the >>list. Think for a moment how many useful bits of information you've >>missed because the default for this list it to make conversations >>private. > > > The default of this list is not to make conversations private; in fact > the list doesn't have any default. It's you who chooses to send replies > to the original author, to the list, or both, by choosing which button > to press in your mail client. It's a sad but unavoidable fact that most people, in the regular course of emailing, never use (nor have reason to use) the "reply to all" button. In any "normal" email exchange, hitting the reply button does what you want it to. As a consequence of this, a large portion of the e-mail using public never thinks to do more than hit the "reply" button. It's great that *you* and *I* are technically savvy enough to hit the "reply all/list" button when needed, but the other people on the list might not be. I've seen mailing lists reduced to near uselessness because of it: you get people posting questions to the list, but no replies, because all of the people replying are responding by pressing "reply" and sending private messages. FWIW, I use the newsgroup version of this list, and the "reply" button on my mail/newsreader does what I want it too - reply to the list only. (I hate getting an additional personal email for a publicly posted response) -- http://mail.python.org/mailman/listinfo/python-list
Re: When someone from Britain speaks, Americans hear a "British accent"...
Steve Holden wrote: >> On Fri, 07 Oct 2005 00:33:43 -, Grant Edwards <[EMAIL PROTECTED]> >> wrote: >>> For example: In British English one uses a plural verb when the >>> subject consists of more than one person. Sports teams, >>> government departments, states, corporations etc. are grammatically >>> plural. In American, the verb agrees with the >>> word that is the subject, not how many people are denoted by >>> that word. > > There aren't any universal rules, except possibly "British people speak > English while Americans don't". I believe you overgeneralize. :) A Welshman would likely be offended if you implied he spoke English, and the Scots are notorious for only speaking English when they have too. (I remember a news story some years back about a Scottish "lad" who was fined/imprisoned for replying to an official court representative with "Aye" rather than "Yes".) For that matter there are plenty of people in Cornwall and even in London (Cockney) who speak something that is only called "English" for lack of a better term. -- http://mail.python.org/mailman/listinfo/python-list
Re: When someone from Britain speaks, Americans hear a "Britishaccent"...
Duncan Smith wrote: > Steve Holden wrote: > >>There are special rules for the monarchs, who are expected to refer to >>themselves in the first person plural. >> > > Yes, although I'm not actually sure where the 'royal we' comes from; I was under the (probably misinformed) impression that since the King/Queen is the representative of the entire nation, they use the first person plural, because when they speak they speak for the all the (multiple) people in the land. I'm unaware of what term a monarch uses in a private, rather than public, context. (Never having had the opportunity to drink a pint with Lizzie, Chuck, and Cammie. :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Very dumb question
Laszlo Zsolt Nagy wrote: > Laszlo Zsolt Nagy wrote: > >> I have a program with this code fragment: >> >>print len(data) >>print data[:50] >>raise SystemExit >> >> This prints: >> >> 20381 >> > >> But if I change 50 to 51 >> >>print len(data) >>print data[:51] >>raise SystemExit >> >> then it prints >> >> 20381 >> !DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" >> >> After all, only the last 50 bytes are printed. The string is the same >> (length 20381) in both cases. >> >> > Hmm, I checked on Windows now and it is working. But it is bad on > FreeBSD/Python 2.4.1 > Very strange. len(data[:100]) returns 100, but if I try to print it, > only the first 50 characters printed. > > Les Is 'data' a Unicode string, or do you have some terminal control charachters in the string? Most printable ASCII charachters are between 32 and 126. What does this print?: print [i for (i,c) in enumerate(data) if not (32 <= ord(c) <= 126)] -- http://mail.python.org/mailman/listinfo/python-list
Re: Yes, this is a python question, and a serious one at that (moving to Win XP)
James Stroud wrote: > I propose that any time anyone suggests switching to Windows, the reasons for > such should be explicitly described, and not left to interpretation. I propose that any time anyone suggests switching to Linux ... I propose that any time anyone suggests switching to Mac ... I propose that any time anyone suggests switching to Ruby ... I propose that any time anyone suggests switching to Firefox ... I propose that any time anyone suggests switching to Waxed Dental Floss ... People should not feel *required* to justify their decisions to c.l.py, especially if they are not trying to evangelize that choice. (FWIW, even from the original post it's very apparent that he's dissuading people from joining him.) It is true that giving the reasons for a choice will help responders put some perspective on it, and perhaps prompt a few alternatives, but c.l.py is not your mother, and shouldn't require you to justify the validity of your lifestyle to it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Suggestion for (re)try statement
Sori Schwimmer wrote:
> Hi,
>
> I think that would be useful to have an improved
> version of the "try" statement, as follows:
>
> try(retrys=0,timeout=0):
> # things to try
> except:
> # what to do if failed
>
> and having the following semantic:
>
> for i in range(retrys):
> try:
> # things to try
> except:
> if i < retrys:
> i += 1
> sleep(timeout)
> else:
> # what to do if failed
> else:
> break
The gold standard for language syntax changes is "compelling use cases"
- if introduced, how often will the construct be used? Is there a python
program out there (preferably in the standard library) which would be
*markedly* improved by the change? What is so repugnant about the
equivalent, currently valid way of writing it? -- Hypothetical and
theoretical arguments don't carry much weight in the Python community
("Practicality beats purity" and all that.)
And remember - your goal isn't ultimately to convince me or someother
person on comp.lang.python, it's to convince Guido.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python's website does a great disservice to the language
[EMAIL PROTECTED] wrote: > So the first thing you do when you go to a web page is to google if > they are going to redesign it? I think the implication was "The first thing to do before *suggesting that a redesign is nessasary* is to Google to see if such a redesign is taking place." -- http://mail.python.org/mailman/listinfo/python-list
Re: Suggestion for (re)try statement
Sori Schwimmer wrote: > 0) Sorry, I don't know how to post a reply in the same > thread. Usually it is simply hitting the "Reply" button/link/key combination on your mail/news reader when the post you want to reply to in view. (If you want reply to multiple people, you can always reply to the original post, or reply to one, and just treat the topics from all of them.) > 2) Rocco Morreti wrote: First off, let me say that my message wasn't meant to scare you off - it was constructive criticism, appraising you of what would be necessary if you actually want the construct in the language. If you're just shooting the breeze/navel gazing, I apologize for harshing your cool. >>What is so repugnant about the equivalent, currently >>valid way of writing it? > > Nothing "repugnant". "Repugnant" was probably too strong a word. The point I was trying to make was: If you want such a construct added to the language, you need to justify all the hassle & effort of introducing the new syntax. Given that there is a way to accomplish the same thing now, you would need to show that your way is not just as good, but better than the current way. > It's all about convenience, not about > getting to bare bone equivalents. Nothing wrong with convenience - you just have to show that the convenience would be used often enough to justify the hassle. It'd be awfully convenient to have a passenger jet parked in your garage - but you probably wouldn't use it frequently enough to justify the expense of maintaining, fueling, and licensing it. >> And remember - your goal isn't ultimately to >> convince me or someother >> person on comp.lang.python, it's to convince Guido > > I'm not trying to convince anybody. In the democratic > state-of-mind in which I live, the idea will be taken > in consideration if it is found useful by many, not by > one, even if the one is the almighty Guido. My comment made with the assumption that you were trying to actively promote the construct, rather than floating it as a trial balloon. I was aiming at keeping you from getting annoyed later on when your petition with hundreds of signatures gets shot down by Guido. Despite your state-of-mind, in practicality, Python is not a democracy - language constructs live or die by the will of Guido. If you actually want the construct in the language, a comp.lang.python plebiscite isn't going to do it - you'll need to convince the BDFL that it's a good idea. Now, Guido isn't totally ambivalent to the masses - if a large number of people are for it, there's a good chance Guido will be for it too. But you're not aiming for a popularity contest - what'll convince people (including Guido) is good arguments as to *why this construct is better than what we have now,* and *why it will be worth the hassle of implementing and maintaining it*. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's website does a great disservice to the language
Alex Martelli wrote: > The Eternal Squire <[EMAIL PROTECTED]> wrote: >... > >>2) Consider what he really wants for a supervisor of software >>engineers. Ideally such a person should be a software engineer with >>at least 3 times the experience of the most junior member. Such a > > > I like the general idea but not your formula. If the most junior team > member was 1 month out of school, would it really be OK for the > supervisor to be somebody who graduated 3 months ago?-) FWIW, when I read it, I took "experience" as a semi-qualitative measure, more than just "time since graduation." Hence someone out of school only three months could have more "experience", than someone who has worked for ten years, if the recent grad has been heavily involved in pre-graduation projects (e.g. open source), or if the ten-year veteran has done nothing constructive with his time, besides raking in a paycheck. -- http://mail.python.org/mailman/listinfo/python-list
Re: I Need Motivation Part 2
[EMAIL PROTECTED] wrote: > i m losing my motivation with python because there are sooo many > modules, that i cant just learn them all, As other's have said, don't bother. If you ever need to use a module that you don't know, just go to http://docs.python.org/lib/lib.html (easily accessable from the "Documentation" link on the Python Home page), or a local copy, and scrounge around. I might suggest skimming it once, to see what is possible, but it isn't nessasary to "learn" it. -- Knowing that there is a Python module in the standard library to do CSV/Date manipulation/MD5/etc is sufficient. You don't even need to know what the module is called - a minute skimming the TOC will point you in the right direction. -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Map of email origins to Python list
Paul McGuire wrote: > "Claire McLister" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > We've been working with Google Maps, and have created a web service to > map origins of emails to a group. As a trial, we've developed a map of > emails to this group at: > > http://www.zeesource.net/maps/map.do?group=668 > > This represents emails sent to the group since October 27. > > Would like to hear what you think of it. > -- > > > Another sleepless camera pointed at the fishbowl that is my online life. > It's also a testament to the limited value of physically locating people by internet addresses - If you zoom in on the San Fransico bay area, and click on the southern most bubble (south of San Jose), you'll see the entry for the Mountain View postal code (94043) - a massive list which contains mostly gmail.com accounts, but also contains accounts with .de .ca .uk .pl .it .tw and .za domains. I doubt all of the people in that list live in sunny California, let alone in Mountain View proper. -- http://mail.python.org/mailman/listinfo/python-list
Re: Map of email origins to Python list
[EMAIL PROTECTED] wrote: > Rocco Moretti wrote: > >>It's also a testament to the limited value of physically locating people >>by internet addresses - If you zoom in on the San Fransico bay area, and >>click on the southern most bubble (south of San Jose), you'll see the >>entry for the Mountain View postal code (94043) - a massive list which >>contains mostly gmail.com accounts, but also contains accounts with .de >>.ca .uk .pl .it .tw and .za domains. I doubt all of the people in that >>list live in sunny California, let alone in Mountain View proper. > > > North of that bubble is a second massive list also labeled Mountain > View > 94043. I found my name on that list and I live in the Chicago area. > Moutain View is, perhaps, where aol.com is located? These bubbles are > showing the location of the server that's registered under the domain > name? Actually, it looks like they are the *same* list. I haven't gone through all of the names, but I spot checked a few, and it looks like yours, among others, are listed in both spots. (The southern one looks like it is a mislocated duplicate, as it is nowhere close to Mountain View, and is stuck in the middle of a golf course.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal for adding symbols within Python
Pierre Barbier de Reuille wrote: > Please, note that I am entirely open for every points on this proposal > (which I do not dare yet to call PEP). I still don't see why you can't just use strings. The only two issues I see you might have with them are a) two identical strings might not be identical by id(), b) they aren't local in scope. The objection a) is minor. One, all of your examples use equality for testing already, and two, short strings are interned and identical in most cases anyway (they only differ if you go to lengths to create them, or they aren't sufficiently "variable like") - at most you would have to standardize the rules. The objection b) is a little harder to dismiss. But I'm not sure if you've completely thought what it means for a symbol to be "local to a module". What happens when you assign a variable containing a symbol to a variable in another module? For that matter, what does it mean to be "in a module". Which module is a class instance (and associated sybols) "in" if the class is defined in one module, instantiated in another, and then passed as a return value to a third? What about from ... imports? If you need a symbol "from another class" what's the mechanism of obtaining it? Can you import symbols? Since you advocate storing symbols internally as integers, I suppose you would have a program-global table to keep symbols from different modules from having the same internal representation. How do you pickle a symbol and have it go to a different Python program, which may have a massive symbol table of it's own? It's been said before, and I'll say it again - the key to successful Python language changes is compelling use cases. Find an existing Python program or library (the stdlib is best) which would be markedly improved by your language change. Not only will Guido be more likely to be convinced, but what you're proposing will likely be clearer to everyone else, if it's grounded in practical use cases. -- http://mail.python.org/mailman/listinfo/python-list
Re: is parameter an iterable?
marduk wrote: > On Tue, 2005-11-15 at 11:01 -0800, py wrote: > >>I have function which takes an argument. My code needs that argument >>to be an iterable (something i can loop over)...so I dont care if its a >>list, tuple, etc. So I need a way to make sure that the argument is an >>iterable before using it. I know I could do... >> >>def foo(inputVal): >>if isinstance(inputVal, (list, tuple)): >>for val in inputVal: >># do stuff >> >>...however I want to cover any iterable since i just need to loop over >>it. >> >>any suggestions? > > You could probably get away with > > if hasattr(inputVal, '__getitem__') No, you probably couldn't. ## >>> def g(s): for i in xrange(s): yield i+s >>> m = g(5) >>> hasattr(m, '__getitem__') False ### I'd do something like: # def foo(inputVal): try: iter(inputVal) # Can you change it into an interator? except TypeError: # Return Error Code else: for val in inputVal: # do stuff ### Again, you'll have to be careful about strings. -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal for adding symbols within Python
Björn Lindström wrote:
> Steven D'Aprano <[EMAIL PROTECTED]> writes:
>
>
>>Why does the byte string "\x6f\x70\x65\x6e\x65\x64" have intrinsic
>>meaning when the int 0 doesn't? It certainly doesn't mean anything to
>>non-English speakers.
>>
>>If all you want is human readable byte strings, then just use them:
>>
>>class MyFile:
>>def open(self):
>>self.state = "opened"
>>def close(self):
>>self.state = "closed"
>
>
> So, I guess no one read my explanation of why this an issue about more
> than implementing enums (which is fairly trivial, as we have seen).
I did, but I still don't see why it is an argument against using
strings. The point you may not appreciate is that (C)Python already uses
strings to represent names, as an important part of its introspective
abilities.
##
>>> import dis
>>> def f():
module.klass.method()
>>> dis.dis(f)
2 0 LOAD_GLOBAL 0 (module)
3 LOAD_ATTR1 (klass)
6 LOAD_ATTR2 (method)
9 CALL_FUNCTION0
12 POP_TOP
13 LOAD_CONST 0 (None)
16 RETURN_VALUE
>>> f.func_code.co_names
('module', 'klass', 'method')
>>> type(f.func_code.co_names[1]) is type('a')
True
##
I'll let you dig through the interpreter source to convince yourself
that, indeed, the names module, klass, and method are stored internally
as true python strings. The same holds for other namespaces - the names
are stored as real python strings, in a real python dictionary.
>>> class c:
def foo(self):
pass
def bar(self):
pass
def baz(self):
pass
>>> type(c.__dict__) is type({})
True
>>> c.__dict__.keys()
['baz', '__module__', 'foo', 'bar', '__doc__']
>>> type(c.__dict__.keys()[0]) is type('a')
True
##
P.S. This may change for other implementations of Python, but the fact
remains - there is less difference between names and strings than you
may first think.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Proposal for adding symbols within Python
Pierre Barbier de Reuille wrote: > Rocco Moretti a écrit : > [...] > >> >>I did, but I still don't see why it is an argument against using >>strings. The point you may not appreciate is that (C)Python already uses >>strings to represent names, as an important part of its introspective >>abilities. >> > > > Well, I'm well aware of that, but I'm also well aware that's (as you > said yourself) specific to C-Python, so can just *cannot* rely on > strings being used as symbols in the language. It's true that a different implementation of Python may use a different internal storage system for names, but as long as the semantics are the same as CPython, it really doesn't doesn't matter what the internal storage is. That is to say, as long as the other implementation of Python has __getattr__ and __dict__, you can use strings to represent names, regardless of how the interpreter stores them internally. > The point is, why don't provide the programmer to express just what he > needs (that is, some symbolic value like "opened", "blocked", ...) and > let the interpreter use whatever he think is more efficient for him ? It's just that, for the current interpreters and usage of "symbol-like" construct, the efficiency gained by the interpreter choosing how to represent symbols is probably *far* outweighed by the inefficiency and hassle of implementing and maintaining the symbol syntax in the existing interpreters. Besides, "have the programmer specify intent, and allow the interpreter to substitute a more efficient implementation on the off chance that interpreter can or wants to" doesn't have much cache in the Python community.(1) The interpreter could get more efficiency if it knew a list was fixed length, or contained only ints, or knew that a for loop was looping over consecutive integers, instead of a random list. But despite the possibility that there might exist, at some time in the future, a Python interpreter which *might* optimize such things, we haven't thrown in variable declarations or integer loop syntaxes yet. As I've mentioned before, the key to getting feature put into the language is compelling use cases. Find a (non-hypothetical) Python program or library which would be improved by addition of , and where the existing alternatives are inadequate. Lacking that, any attempt to get a feature into the language is an uphill battle. > But why say a name is a > *string* when it is just an implementation detail ??? Isn't Python > mainly about allowing the programmer to concentrate on important stuff ? One could flip it around and say that names *not* being strings are an implementation detail - after all, what is a name in your source code, besides just a string of ASCII characters? Having just names and strings simplifies things as well - you have only two items to convert between, as opposed to three items (names, symbols and strings). - (1) The future of Python seems to be towards the PyPy way, where the interpreter will analyze your code, and automagically determine the most efficient implementation for your particular use case. -- http://mail.python.org/mailman/listinfo/python-list
Re: Adding through recursion
[EMAIL PROTECTED] wrote: > There is problaly a really simple answer to this, but why does this > function print the correct result but return "None": > > def add(x, y): > if x == 0: > print y > return y > else: > x -= 1 > y += 1 > add(x, y) > > print add(2, 4) One of the best things to do when you don't understand how a function is working is to geneously sprinkle the code with tracing print statements: >>> def add(x, y): params = (x, y) print "Starting Function", params if x == 0: print "x is zero", params print y return y print "After Return", params else: print "Non-zero x", params x -= 1 y += 1 print "Updated x & y", params, '->', (x,y) add(x, y) print "Should I be here?", params print "Falling off end.", params >>> print add(2, 4) Starting Function (2, 4) Non-zero x (2, 4) Updated x & y (2, 4) -> (1, 5) Starting Function (1, 5) Non-zero x (1, 5) Updated x & y (1, 5) -> (0, 6) Starting Function (0, 6) x is zero (0, 6) 6 Should I be here? (1, 5) Falling off end. (1, 5) Should I be here? (2, 4) Falling off end. (2, 4) None -- http://mail.python.org/mailman/listinfo/python-list
Re: [Fwd: Re: hex string to hex value]
tim wrote: > ok, but if i do > > >>> n=66 > >>> m=hex(n) > >>> m > '0x42' > >>> h=int(m,16) > >>> h > 66 > >>> > > I end up with 66 again, back where I started, a decimal, right? > I want to end up with 0x42 as being a hex value, not a string, so i can > pas it as an argument to a function that needs a hex value. > (i am trying to replace the 0x42 in the line midi.note_off(channel=0, > note=0x42) with a variable) >>> note = 0x42 >>> print note 66 >>> note is 66 True There is no such thing as a "hex value"- only hex *representations* of a value. midi.note_off() doesn't take a "hex value", it takes an integer, and, for whatever reason, it happens to be listed in your example in a hexidecimal representation. -- http://mail.python.org/mailman/listinfo/python-list
Re: Which License Should I Use?
Steven D'Aprano wrote: > On Fri, 25 Nov 2005 11:30:46 -0800, mojosam wrote: > >>I guess I don't care too much about how other people use it. > > Then probably the best licence to use is just to follow the lead of > Python. For that sort of small program of limited value, I put something > like this in the code: > > Copyright (c) 2005 Steven D'Aprano. > Released under the same license as used by Python 2.3.2 itself. > See http://www.python.org/psf/license.html for details, and > http://www.python.org/2.3.2/license.html for the full text of the license. Gaak! No! The Python license you point to contains horrible amounts of cruft due to the ownership ping-pong game. (And just using the hyperlink like you did leaves it vauge as to who is doing the liscensing - Steven D'Aprano? the PSF? BeOpen? CNRI? Stichting Mathematisch Centrum?) As I understand it, the PSF's official position is that the Python license (even just the top most one) is not appropriate for any program besides Python itself. http://wiki.python.org/moin/PythonSoftwareFoundationLicenseFaq Note that the Python license is not even appropriate for third party code that's intended to be contributed to the Python standard library or core! If you want a "like Python" license, try the MIT or "new-BSD" license instead: http://www.opensource.org/licenses/mit-license.php http://www.opensource.org/licenses/bsd-license.php -- http://mail.python.org/mailman/listinfo/python-list
Re: Which License Should I Use?
mojosam wrote: > I've been watching the flame war about licenses with some interest. > There are many motivations for those who participate in this sector, so > disagreements over licenses reflect those agendas. One point that frequently gets ignored in licensing debates: The value of a license is directly proportional to the amount of time, effort, and money you are willing to spend enforcing it. It doesn't matter how fancy the legal wording is - it is up to you, as the copyright holder, to bring legal action against infringers (or at least send a cease-and-desist letter). If you're not going to bother, any and all clauses in the license, no matter how artfully crafted, won't do you any (legal) good. People using your program are left acting on the honor system. Which may be just fine - but you don't need a fancy, legalistic license to accomplish that. -- http://mail.python.org/mailman/listinfo/python-list
Re: General question about Python design goals
Fredrik Lundh wrote: > Rick Wotnaz wrote: > > >>I'm sure Antoon wouldn't object if lists were to be allowed as >>dictionary keys, which would eliminate the multiple castings for >>that situation. I wouldn't, either. > > so what algorithm do you suggest for the new dictionary im- > plementation? One option is to create a new "frozen list" type, a` la frozen sets. People who argue that "frozen list" is not needed because we already have the tuple type, while simultaneously arguing that tuples shouldn't grow list methods because they are conceptually different from lists will be bludgeoned to death with a paradox. :) -- http://mail.python.org/mailman/listinfo/python-list
Re: General question about Python design goals
Fredrik Lundh wrote: > Rocco Moretti wrote: > >>>>I'm sure Antoon wouldn't object if lists were to be allowed as >>>>dictionary keys, which would eliminate the multiple castings for >>>>that situation. I wouldn't, either. >>> >>>so what algorithm do you suggest for the new dictionary im- >>>plementation? >> >> One option is to create a new "frozen list" type, a` >>la frozen sets. > > doesn't frozenset make a copy? As does the current "cast as tuple" technique. (I'm certainly not advocating it, but ...) Certain implementations of "frozen list" could possibly do the list->frozenlist conversion without a copy. (e.g. by flipping an "immutable" bit) > http://www.python.org/peps/pep-0351.html > > This PEP describes a simple protocol for requesting a frozen, > immutable copy of a mutable object. Perhaps Barry has been borrowing Guido's time machine? -- http://mail.python.org/mailman/listinfo/python-list
Re: python university search
josh wrote: > > hello, > > i am interested in doing an undergraduate major in computer science > that mainly focuses on python as a programming language.. It's your life, so you can live it as you choose, but I think you're missing the point of an undergraduate education if you focus too much on Python programming at this point. Undergraduate education is (should be) about breadth. Python has a place there, but it isn't the be-all, end-all. There are some concepts for which Python isn't well suited in teaching (functional programing, logic programing, operating system programing, etc.). I'd hope that you go to a high-quality University that understands this, and teaches *concepts*, not programing languages. In the long run, it will (likely) be better for you to go to a University where they don't even use Python, but solidly teach concepts, rather than one that's so into Python that they neglect topics that are taught poorly in Python. Even if you never use Python as an undergraduate, if you have a good grounding in the fundamental concepts, it should be (relatively) easy for you to take what you've learned in (scheme/ML/prolog/assembly/forth) and apply it to Python. You'll have plenty of time to specialize on Python as a graduate student/young professional. Just my two cents. -- http://mail.python.org/mailman/listinfo/python-list
Re: Documentation suggestions
A.M. Kuchling wrote: > There's another struggle within the LibRef: is it a reference or a > tutorial? Does it list methods in alphabetical order so you can look > them up, or does it list them in a pedagogically useful order? I > think it has to be a reference; if each section were to be a tutorial, > the manual would be huge. Here I think the solution is to encourage > separate tutorials and HOWTOs, and link to them from the LibRef. I actually like the conversational, tutorial style the current LibRef has -- in fact I consider that style one of the Python Docs strengths. All too often I see manuals that consist of only fuction by fuction & class by class breakdowns. That's fine if the module is just a collection of independant functions, but falls short whenever you want to use multiple functions & classes in a module together. Function by function documentation tends to ignore the "big picture," how all the functions & classes work together, and the philosophy behind their use. *That's* what I feel it is important to document - if I want to know parameters, return values and side-effects, I'll just look at the doc strings. Certainly you could go for the User Manual/Reference Manual dichotomy, but in my experience, the User Manual tends to get short shrift - the experts writing it tend to think that it's just for "n00bs", and leave out the complex and esoteric items, thinking that the Reference Manual suffices. Unfortunately, the background and philosophy are needed *more* for the complex/esoteric functions than for the simple ones, merely because you're less likely to understand them from a "takes a,b,c, sets the froz flag, and returns x,y,z" type description. And to expand on what Michael Spencer said, a lot of the time when I'm digging throught the LibRef, I'm looking for a module that'll help me do 'X'. Most of the "Reference Manuals" I've seen tend to assume you know what fuction you're looking for, and don't give you any direction in the forest of function descriptions. With the current tone/level and categorical grouping of the LibRef, it's easy to browse through and look for things that might help (at least easier than it would be with, say, a strict alphabetical list). -- http://mail.python.org/mailman/listinfo/python-list
Re: Bitching about the documentation...
>>>One of my favourite examples of obfuscated English is this grammatically >>>correct sentence: >>> >>>"Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo." > > The punctuation is important. Reminds me of this old classic: Insert punctuation & capitalization to make the following a correct and coherent (if not a little tourtured). fred where guido had had had had had had had had had had had a better effect on the reader -- http://mail.python.org/mailman/listinfo/python-list
Re: Bitching about the documentation...
Fredrik Lundh wrote: > Rocco Moretti wrote: > > >>Insert punctuation & capitalization to make the following a correct and >>coherent (if not a little tourtured). >> >>fred where guido had had had had had had had had had had had a better >>effect on the reader > > > punctuation, including quote marks, I presume? Quote marks are acceptable, but no more than two words are inside each set. B A D G E R . . . E R S P O I L E R W A R N I N G The "accepted" way to do it is: Fred, where Guido had had "had", had had "had had." "Had had" had had a better effect on the reader. meaning approximately In the place where Guido previously put the word "had", Fred had previously put the phrase "had had." Fred's choice of phrasing was more appreciated by the reder. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to find the type ...
[EMAIL PROTECTED] wrote: thisisastring = "1" thisisanint = 1 type(thisisastring) > > > type(thisisanint) > > > thisisastring = int(thisisastring) thisisanint = str(thisisanint) type(thisisastring) > > > type(thisisanint) > > >>> print repr(thisisastring) 1 >>> print repr(thisisanint) '1' >>> thisisastring = 'a' >>> thisisanint = 98 >>> thisisastring = ord(thisisastring) #Using ASCII rep. >>> thisisanint = chr(thisisanint) >>> type(thisisastring) >>> type(thisisanint) >>> print repr(thisisastring) 97 >>> print repr(thisisanint) 'b' -- http://mail.python.org/mailman/listinfo/python-list
Re: Another scripting language implemented into Python itself?
Roy Smith wrote: In article <[EMAIL PROTECTED]>, Quest Master <[EMAIL PROTECTED]> wrote: So, my question is simply this: is there an implementation of another scripting language into Python? Python *is* a scripting language. Why not just let your users write Python modules which you them import and execute via some defined API? I can think of a couple of reasons off the top of my head: The OP doesn't mention his application, but there is something to be said about domain specific scripting languages. A well designed domain-specific scripting language(*) with the appropriate high level constructs can make script writing simpler. There's also an audience factor. Python is easy to learn, but it's still a programming language. A well designed domain-specific scripting language(*) can make it very easy to get work done in a particular case without having to learn the Python mind frame. (How assignments work, mutable/immutable, Python's call passing system, etc.) Python's also dangerous. Every time you do an "import module", you put your system at risk of crashing, having the hard-drive wiped, sending incorrect signal codes to peripherals, etc. A well-designed specialty language(*) minimizes those risks - don't need disk access? Don't allow it in your language. There's also the valuable learning experience of designing and implementing a scripting language. (*) Note that I keep saying "well-designed". A poorly designed scripting language is very bad - you can feel shackled by the restrictions it imposes, and find yourself unable to do what you want without laborious contortions, if at all. I also say "domain specific" because, at this time, there are enough general purpose scripting languages that you are likely to find what you need already existing, unless you are experimeting with a completely new programing paradigm. To answer the OP's question: Yes - sort of. Currently work is underway to implement the Python scripting language in Python. Cleverly called "PyPy", the website is "http://www.codespeak.net/pypy";. -- http://mail.python.org/mailman/listinfo/python-list
Re: Another scripting language implemented into Python itself?
Bob Smith wrote: Rocco Moretti wrote: Python's also dangerous. Every time you do an "import module", you put your system at risk of crashing, having the hard-drive wiped Have you been drinking again? No, not really. The "every time" comment should be viewed in the same light as "Every time you step outside, you risk being hit by a bus." "import module" executes Python code. As such it can do anything Python can do. Crash your system, wipe the hard drive, etc. And there is nothing the importing code can do to stop it. Now, if you limit yourself to known and trusted modules, that risk virtually disappears, just like staying on the sidewalk virtually eliminates the chances of getting hit by a bus. Not completely, mind you, since someone could have altered the standard library modules/changed the import path such that you're importing an unknown module. But most people would argue if someone has that power, they probably can do anything they want with your system without you doing "import module." Bottom line: Don't exec or eval untrusted code. Don't import untrusted modules. -- http://mail.python.org/mailman/listinfo/python-list
Re: Another scripting language implemented into Python itself?
Orlando Vazquez wrote:
Jeff Shannon wrote:
Because you cannot make Python secure against a malicious (or
ignorant) user -- there's too much flexibility to be able to guard
against every possible way in which user-code could harm the system.
Parsing your own (limited) scripting language allows much better
control over what user-code is capable of doing, and therefore allows
(at least some measure of) security against malicious code.
I don't see how that would equate to something that the original
programmer should be concerned about. You could include a bit in your
licensing scheme that voids all support on code that has been modified
in any way. You shouldn't be obligated and no one expects you to support
something the end-user has mucked with.
You could trivially enforce this by keeping checksums of all the system
files.
You're thinking of two different situations. My guess is that Jeff
Shannon is not referring to situations where the end user makes
modifications to existing code, but rather, where the end user write
*completely new* scripts in your new scripting language. As such, you
can't enforce checksums - the code hasn't been written yet.
The use cases probably are also different. You're thinking of delivering
a completed application to an end-user's machine, but given the OP's
user name ("Quest Master"), my guess is that he's looking for a
server-side deployment like in an on-line game, where users script the
game environment. Not only do you have a problem with a malicious user
potentially crashing the game machine, but you also have issues where
the user may be able to grab his "character object" and give himself
infinite money or life, or whatever. Since it's a shared server, you
can't just say "I'm not supporting it" when someone mucks with the server.
> In any case, there's nothing you can really do to "secure" your code.
> This is true of any language, C, C++, and especially scripting languages
> like Python. Anyone who has the determination get at and modify the code
> probably will.
Well, if you don't provide mechanisms for disk access, there is no way
to overwrite files, short of a bug in the interpreter (or some extension
interface to a general purpose programing language). Python is just to
flexible to work like that. Even if you don't provide an open function
to user code, and eliminate questionable modules, you can still get a
file object, even if all you are provided with is an integer object.
That's why restricted execution was eliminated from the standard library.
--
http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Tao Scripting Language 0.8.5 beta released!
Limin Fu wrote: Dear all, I am glad to announce in this mailing list that the lastest version of a new scripting language has come out. Since you chose to announce it in this mailing list/newsgroup, may I suggest that a comparison with Python is in order? Since it is a new scripting language, I'm not suggesting a language war, but rather a simple statement of how Tao differs from Python, and what "itch" you were trying to scratch when you designed your new language. Basically, how does your design philosophy differ from that of Guido? Where did you go left when Python went right? (Congrats on beating the technical challenge of designing and implementing a programming language - now's your chance to sell us on it. :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: What is different with Python ?
Andrea Griffini wrote: > Indeed when talking about if learning "C" can hinder > or help learning "C++" I remember thinking that to > learn "C++" *superficially* learning "C" first is > surely pointless or can even hinder. > But to learn "C++" deeply (with all its quirks) I > think that learning "C" first helps. I think you are mistakingly bringing order into the picture, when extent is more likely the case. If you want to master C++, I think that most would agree you need to understand C. But there are many who would disagree that the path to C++ must *start* at C. (In fact, many people argue that a lot of bad C++ is due to people programming C in C++.) Instead they would argue that you should start by learning C++ "superficially", then learn C, and re-evaluate you C++ practices in light of the lessons learned from C. The example I'll pull out is natural languages - I understood the grammar & construction of my native tounge *much* better after learning a foreign language. From people I've talked to, this is a common occurance. But there would be few people who would advocate that one should learn a foreign language before learning one's native tounge. -- http://mail.python.org/mailman/listinfo/python-list
Re: how to use more than 1 __init__ constructor in a class ?
scott wrote: > hi people, > > can someone tell me, how to use a class like that* (or "simulate" more > than 1 constructor) : > #-- > class myPointClass: > def __init__(self, x=0, y=0): > self.x = x > self.y = y > def __init__(self, x=0, y=0, z=0): > self.__init__(self, x, y) > self.z = z > #-- > You might try: #-- class myPointClass: def __init__(self, x=0, y=0, z=None): self.x = x self.y = y if z is not None: self.z = z #-- You could also turn __init__ into a dispatch fuction: #-- class myPointClass: def __init__(self, *args): if len(args) <= 2: self.__init_two(*args) if len(args) == 3: self.__init_three(*args) def __init_two(self, x=0, y=0): self.x = x self.y = y def __init_three(self, x=0, y=0, z=0): self.__init_two(x, y) self.z = z #-- But I would definitely recommend looking at your algorithm to determine if there is a better way to do what you want, that doesn't require an initilizer with two different signatures. -- http://mail.python.org/mailman/listinfo/python-list
Re: how to use more than 1 __init__ constructor in a class ?
Steven D'Aprano wrote: > On Wed, 22 Jun 2005 12:34:21 -0500, Rocco Moretti wrote: > > >>You could also turn __init__ into a dispatch fuction: >> >>#-- >>class myPointClass: >> def __init__(self, *args): >> if len(args) <= 2: >> self.__init_two(*args) >> if len(args) == 3: >> self.__init_three(*args) > > > Oh wow, so that's what I've been doing for years. Dispatching. > > And I thought I was just calling other functions :-) I think the distinction between just calling other functions and dispatching is that with dispatching, the function doesn't do any actual work by itself, but just hands off the work to a different function. http://www.c2.com/cgi/wiki?DispatchingForDummies > That's the joys of a mostly self-taught programming knowledge: you miss > out on all the buzzwords. Being mostly self taught myself, I have a tendancy to use infrequently encountered terms in related but technically inappropriate contexts, confusing the better informed people I deal with. ;-) -- http://mail.python.org/mailman/listinfo/python-list
Re: OT: Re: Looking For Geodetic Python Software
Tim Daneliuk wrote: > Diez B. Roggisch wrote: > >> Tim Daneliuk wrote: >> >>> Casey Hawthorne wrote: >>> Do your planes fly over the earth's surface or through the ground? >>> >>> >>> >>> >>> Why do you presume this has anything to do with airplanes? >>> >> >> That was supposed to be a funny remark regarding that your >> "straight-line-distance" makes no sense at all - because that would >> mean that you'd have to go underground. So it has no >> real-world-application - unless you actually have underground-planes ;) >> >> Diez > > > Huh? When traversing along the surface of the earth, it's curvature > is relevant in computing total distance. An airplane flies more-or-less > in a straight line above that curvature. For sufficiently long airplane > routes (where the ascent/descent distance is trivial compared to the > overall horizontal distance traversed), a straight line path shorter > than the over-earth path is possible. That's why I specified the > desire to compute both path lengths. Where's the humor? If you re-read what you wrote you'll see the phrase "straight line flying distance.": > 1) Given the latitude/longitude of two locations, compute the distance >between them. "Distance" in this case would be either the > straight-line >flying distance, or the actual over-ground distance that accounts > for the earth's curvature. Casey was pointing out that, due to the convex curvature of the Earth, a "straight line" between, say, Hong Kong and New York would happen to pass several miles below the surface of California. For an extreme example, a Euclidean straight line from the North pole to the south pole would pass through the center of the earth. Note that you've attached "Flying distance" to the phrase "Straight line" - Hollywood not withstanding, there isn't a machine able to "fly" through the center of the earth. The fact that it might be an unintentional error only adds to the humor. (c.f Freudian Slips) Given the relative thinness of the atmosphere (~10-20 km) in comparison with the radius of the earth (~6,400 km), any plane flight of a considerable distance will be curved in the Euclidean sense, no matter how they changed their altitude inbetween. -- http://mail.python.org/mailman/listinfo/python-list
Re: Thanks for PIL (and other stuff)
jean-marc wrote: > PS If I knew that Python had a anniversary date, I'd also write to > thanks our BDFL (and authors)! But no such luck, so I'm restaining > myself! > ;-)) From the FAQ: > Here's a very brief summary of what started it all, written by Guido van > Rossum: > > > > During the 1989 Christmas holidays, I had a lot of time on my hand, so I > decided to give it a try. During the next year, while still mostly working on > it in my own time, Python was used in the Amoeba project with increasing > success, and the feedback from colleagues made me add many early improvements. > > In February 1991, after just over a year of development, I decided to post to > USENET. The rest is in the Misc/HISTORY file. Misc/HISTORY notes the source was uploaded to alt.sources Google Searching alt.sources gives a posting date of Feb 20 1991, 11:22 am for the message "Python 0.9.1 part 01/21", and the rest of the posts are spread out over 19-21 Feb 1991, according to Google. The text description in the body of the message gives a date of 19 February 1991. If you're looking for an official "Birthday" of Python, you probably couldn't do much better than 19 February 1991. (Happy 14th & 1/3ish Birthday Python!) -- http://mail.python.org/mailman/listinfo/python-list
Re: a dictionary from a list
David Bear wrote: > I know there must be a better way to phrase this so google understands, but > I don't know how.. So I'll ask people. > > Assume I have a list object called 'alist'. > > Is there an easy way to create a dictionary object with the members of > 'alist' being the keys in the dictionary, and the value of the keys set to > null? Are you sure you need a dictionary? You may want to look at the Set module instead, if the values aren't important. -- http://mail.python.org/mailman/listinfo/python-list
Re: Which kid's beginners programming - Python or Forth?
BORT wrote: > I am toying with the idea of teaching my ten year old a little about > programming. I started my search with something like "best FREE > programming language for kids." After MUCH clicking and high-level > scanning, I am looking at Python and Forth. Both have advocates that > say each is a great approach to learning computers. Call me biased, but I'd recommend Python, and it all comes down to a single concept: Transferability. As others have mentioned, Forth programming is in somewhat of it's own class. It's not really imperative, object oriented, or declarative. It's based on an interesting, but rarely used, principle of stack programing. Great for someone who is expanding their horizons, but not a lot of value for a beginning programmer who might want to branch out to C/Visual Basic/Java/etc. Also, due to the stack-based nature of the beast, the base way of specifying mathematical operations doesn't transfer to/from elsewhere, unless you're talking about old HP calculators. Python uses the standard mathematical notation, and even uses mathematical precedents (i.e. multiplication before division). So for Math you'd do something like: y = b + mx + cx^2 (Where ^2 is a superscript 2) For Python it would be: y = b + m*x + c*x**2 IIRC, for Forth it would be something like (please excuse the mistakes in operator notation): x 2 ^ c * m x * + b + 'y' setvar Where you read from left to right, and imagine pushing items onto a stack, and when you encounter an operator, you pop the appropriate number of items, act on them, and push the result back onto the stack. Granted, you can get Forth dialects with the ability to do infix (mathematical) notation, but that leads to another transferability issue, that between interpreters. There is one "official" Python interpreter, and the developers work dang hard to make sure it runs on every commonly used platform. The other interpreters are usually special purpose, and tend to be up front about where they differ from the "official" Python. Thus, if you see Python code somewhere, it is highly likely it will run on your Python interpreter Forth, as it has been around much longer, is a much more fragmented community, with many more interpreters. What works on one may not work on another, and a particular interpreter is likely to be available only for a single platform. With Forth it is *very* easy to extend the language, and so an interpreter-specific piece of code that someone posts may not work for you on your interpreter, especially if you're using a free interpreter for Windows, which tends to be the bastard step child of free stuff. There are ANS and IEEE standards for Forth, but official standards tend to leave things implementation dependent, especially in platform specific things like file access. To further compound the issue, a Forth system tends to be self contained and insular - interaction with the surrounding environment may be minimal at best. Python, where possible, tries to shield the user from platform specifics, while still allowing full access to the environment. There are a number of Python bindings to C libraries which give near complete control to the desktop/screen/sound system, etc. Forth-bound libraries will likely be rarer, and again, interpreter specific. It's been quite some time since I've looked at Forth, and the reference material that I used then was probably outdated anyway, so someone with more recent experience can correct me if I'm wrong. However, I would think it's highly likely that the experience you receive with Forth is going to depend heavily on which interpreter you choose to use. P.S. Any 10 year old getting into programing would likely love a library like PyGame (www.pygame.org) - I'd suggest seeing if the Forth you're considering has something similar before deciding. -- http://mail.python.org/mailman/listinfo/python-list
Re: Which kid's beginners programming - Python or Forth?
Rocco Moretti wrote: > It's been quite some time since I've looked at Forth, and the reference > material that I used then was probably outdated anyway. Sorry, thought of one more thing Python has going for it vs. Forth - reference material. Check the catalog of your local library. I'd guess that there is more choice for Python programming books vs. Forth programming books. If your local library does have a Forth book, it's likely that it'll be discussing some 1970's interpreter that ran on a now-defunct timesharing system, if mine is any indication. If you can afford to buy books, the selection at a new or used bookseller is going to be *much* better with Python than with Forth. My local new bookseller has at least a shelf of Python books. I don't think I saw any Forth ones last time I was there - they might have had a single title that I missed. -- http://mail.python.org/mailman/listinfo/python-list
Re: Which kid's beginners programming - Python or Forth?
BORT wrote: > Gentle folk of comp.lang.python, I heartily thank you all for your > input. I think I'm taking the boys through the door marked "Logo." We > may be back this way, though. We will likely need MORE in the nebulous > future. I am impressed with the outpouring of support here! Others in the thread mentioned it briefly, but when you do come back to the door marked "Python", someone has eased the transition slightly: http://pylogo.org/ '''PyLogo is a Logo interpreter written in Python. Its implementation is small, and is based on the language as implemented by UCBLogo. The Logo language is a learning language, intended for children for which more "complete" languages aren't appropriate. Many of Logos language design choices are driven by this, and differ from Python.''' Although given it's 0.1 version status, it may be a little rough around the edges. -- http://mail.python.org/mailman/listinfo/python-list
Re: Modules for inclusion in standard library?
Paul Rubin wrote: > Gregory Piñero <[EMAIL PROTECTED]> writes: > >>I'd like to see some database API's to the most common databases >>included. > > Yes, certainly, this is a serious deficiency with Python. Except that (please correct me if I'm wrong) there is somewhat of a policy for not including interface code for third party programs which are not part of the operating system. (I.e. the modules in the standard libary should all be usable for anyone with a default OS + Python install.) A notable exception is the dbm modules, but I seem to recall hearing that the official position is that it was a mistake. (Now only kept for backward compatability.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Add methods to string objects.
Roy Smith wrote:
> In article <[EMAIL PROTECTED]>,
> "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>
>
>>You can even get closer, but it is NOT recommended
>>
>>class foostr(str):
>> def plural (self):
>>if self.value[-1] in "sz":
>>return self.value + "es"
>>else:
>>return self.value + "s"
>>
>>
>>#ugly hack
>>setattr(__builtins__, "str", foostr)
>>
>>print str("apple").plural()
>>
>># this however does not work
>># print "apple".plural()
>
>
> It's fascinating that the setattr() works (and I agree with you that it's a
> bad idea), but given that it does work, why doesn't it work with a string
> literal?
Because the string literal is the *actual* C-level builtin string type,
not whatever type happens to be in __builtins__.str at the time. ("At
the time" is also a tricky proposition - string literals are made into
obects at compile time, before __builtins__ is twiddled with.)
BTW, on setattr():
'''
setattr( object, name, value)
This is the counterpart of getattr(). The arguments are an object, a
string and an arbitrary value. The string may name an existing attribute
or a new attribute. The function assigns the value to the attribute,
provided the object allows it. For example, setattr(x, 'foobar', 123) is
equivalent to x.foobar = 123.
'''
i.e. '''setattr(__builtins__, "str", foostr)''' is the same as
'''__builtins__.str = foostr''', but I would agree that the setattr
gives more of a "black magic" warning.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Question about Python
Jan Danielsson wrote: >However, when I look at the various Python modules/libraries, I see > that there are several versions of them, for different versions of > python. I've seen everything from "for python 1.5" up to "for python > 2.4" with all versions in between. This scares me a little bit. I assume > that the reason for the different versions is because of new language > features? Please be aware that although Python tries to be compatible at the source level, compatibility at the binary level is only guaranteed at the minor revision level (the third number in the dotted triple version number.) So when most libraries have "for Python 1.5" and "for Python 2.4" downloads, those are usually for precompiled binaries *only*. If you download and compile the source itself, the same files can run on all versions of Python listed. For good or bad, Python expects you to have access to the source code Note however, that programs taking advantage of features introduced in a more recent version of Python won't run on older versions (obviously), even at the source level. They will, however, usually run on any newer version, unless the author took advantage of a bug, or did something perverse, like reassigning None. So when a Python program says "Python 2.1 required", that usually means "Python 2.1 or later required". At any rate, all older versions of Python are still availible, and probably will be for the forseable future, and multiple (major) versions of Python can coexist happily with each other on the same machine, so if you need to use an older version, you can. -- http://mail.python.org/mailman/listinfo/python-list
Re: Modules for inclusion in standard library?
Paul Rubin wrote: > Rocco Moretti <[EMAIL PROTECTED]> writes: > >>Except that (please correct me if I'm wrong) there is somewhat of a >>policy for not including interface code for third party programs which >>are not part of the operating system. (I.e. the modules in the >>standard libary should all be usable for anyone with a default OS + >>Python install.) > > > I've never heard of Python having such a policy and I don't understand > how such a stupid policy could be considered compatible with a > proclaimed "batteries included" philosophy. Why would Python > advocates want to make Python deliberately uncompetitive with PHP, > Java, and other languages that do include database modules? Well, since there seems to be an outpouring of disgust at my statement, and no official confirmation/rejection, it's probably a figment of my prematurely failing mind. However, if there was such a policy, it would not be unequivocally "stupid." First off, there is a bit of flexibility in what is considered part of the OS. E.g, Linux may properly refer to just the kernel, but rarely is just the kernel installed. Various utilities and programs might be considered part of the OS because they are ubiquitously installed, or are included with the Python distribution itself (as Tk is with windows Python). For those programs which aren't ubiquitously installed, or even for ones that are, but require significant configuration, it is reasonable to expect that if someone has the ability and goes to the effort of locating, obtaining, installing, and configuring a third party program, they can just as easily obtain and install the python module, especially as it's usually as easy as "python setup.py install". At any rate, I'm not advocating such a policy, I'm just saying it can make a bit of sense if you look at it from a certain angle. -- http://mail.python.org/mailman/listinfo/python-list
Re: Assigning to None
Mike Meyer wrote: > Peter Hansen <[EMAIL PROTECTED]> writes: > > >>Mike Meyer wrote: >> >>>Yes. I once grabbed an old program that did assignments to None. But >>>that's always been a bad idea. >> >>What was the use case!? > > > Unpacking a tuple. Something like this: > > (foo, bar, None) = gen_tuple(stuff) Goodness, that's bad form. I can just see someone copying it and doing: (foo, bar, None) = gen_tuple(stuff) if foo is None: .. and wondering why the program doesn't work properly. If you had to do that, you might try: foo, bar, _ = gen_tuple(stuff) or in a more complex case. foo, _, _, bar, _, baz, _ = gen_tuple(stuff) as '_' is already special cased (last result in interactive mode), and is already used for "don't care" sematics in Prolog. -- http://mail.python.org/mailman/listinfo/python-list
Re: Favorite non-python language trick?
Joseph Garvin wrote: > I'm curious -- what is everyone's favorite trick from a non-python > language? And -- why isn't it in Python? I'm not aware of a language that allows it, but recently I've found myself wanting the ability to transparently replace objects. For example, if you have a transparent wrapper class around a certain object, and then determine that you no longer need to wrap the object, you can say the magic incantation, and the wrapper instance is replaced by what it is wrapping everywhere in the program. Or you have a complex math object, and you realize you can reduce it to a simple integer, you can substitue the integer for the math object, everywhere. I mainly look for it in the "object replaces self" form, but I guess you could also have it for arbitrary objects, e.g. to wrap a logging object around a function, even if you don't have access to all references of that function. Why isn't it in Python? It's completely counter to the conventional object semantics. -- http://mail.python.org/mailman/listinfo/python-list
Re: Assigning to None
François Pinard wrote: > [Rocco Moretti] > > >>foo, bar, _ = gen_tuple(stuff) > > >>as '_' is already special cased (last result in interactive mode), and >>is already used for "don't care" sematics in Prolog. > > > `_' is also the `gettext' function in internationalised programs. It so > seems that `_' is in great demand! :-) Hm, then assigning to '_' might not be the best idea in internationalized programs, then. Well, you still have '_'*2, '_'*3, '_'*4, etc. -- http://mail.python.org/mailman/listinfo/python-list
Re: Favorite non-python language trick?
Jp Calderone wrote: > On Fri, 01 Jul 2005 15:02:10 -0500, Rocco Moretti > <[EMAIL PROTECTED]> wrote: > >> >> I'm not aware of a language that allows it, but recently I've found >> myself wanting the ability to transparently replace objects. > > > Smalltalk supports this with the "become" message. I have also done an > implementation of this for Python. As a pure Python module, or do you have to recompile the interpreter? -- http://mail.python.org/mailman/listinfo/python-list
Re: Will Guido's "Python Regrets" ever get implemented/fixed?
John Roth wrote: > "Peter Maas" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > >> George Sakkis schrieb: >> >>> Given that the latest 2.x python will be 2.9 >> >> >> Why not 2.13 or 2.4711? Version strings are sequences of arbitrary >> integers separated by dots and not decimal numbers, or are they? > > > Because Guido said (somewhere) that he didn't want to go over > release 2.9. It's actually (repeated) in the talk linked to earlier. The rationale is not touched on, though. George Sakkis wrote: > Given that the latest 2.x python will be 2.9 and that 3.0 may be > released in parallel with 2.5-2.9 > (http://www.python.org/doc/essays/ppt/euro2004/euro2004.ppt), I guess > this *someday* will be no later than 2015-16, probably sooner than > that. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp development with macros faster than Python development?..
Raymond Hettinger wrote: > [EMAIL PROTECTED] wrote: > >>The problem is that questions like 'What lang is fastest to develop >>in?' >>are hard to answer definitively. > > > FWIW, Google's answer to that question is C++, Java, and Python. For > any given problem, any of the three are acceptable. Each programmer or > engineering team gets to decide based on his or her language > expertise.* Actually, Google's answer to that question is something called "ILOG CPLEX", followed by Visual Basic, English as a second language, PHP, and "Holt Software Associates". ;-) http://www.google.com/search?hl=en&q=What+language+is+fastest+to+develop+in%3F&btnG=Google+Search Given this finding, I'm not sure I should put much weight into Google search results anymore ... -- http://mail.python.org/mailman/listinfo/python-list
Re: HELP!
Ert Ert wrote: > Please help me i down loaded python nd itplays on MS-DOS mode and not on > normal please help Python itself is a command line program. "MS-DOS mode" *is* it's normal mode. As other's have mentioned, there are graphical front ends to Python which you may be more comforatble with. You can either download something extra, or on the standard windows installer there is an Integrated Development Environment (IDE) called Idle. If you go: Start Menu->(All Programs)->Python2.4 one of the icons should be for "IDLE 2.4 (Python GUI)" You may also be interested in the python tutor mailing list. You'll find that info, along with a bunch of other great stuff, on the python website (www.python.org). If I've misunderstood you, you'll have to clarify what you want. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Module Exposure
Robert Kern wrote: > Jacob Page wrote: > >> Does this newsgroup find attachments acceptable? > > No. Please put files somewhere on the web and post a URL. This would be > a good forum to informally announce and discuss your module. To add to what Robert said, keep in mind this newsgroup is also mirrored to a mailing list, so posting anything but example code snippets would quickly fill up people's inboxes. -- http://mail.python.org/mailman/listinfo/python-list
Re: f*cking re module
François Pinard wrote: > I once worked with a PL/I compiler (on a big IBM mainframe), which was > trying to be helpful by spitting pages of: > > Error SUCH AND SUCH, assuming that THIS AND THIS was meant. > > and continuing compilation nevertheless. It was a common joke to say > that PL/I would compile some random valid program out of any garbage! We may laugh now (and then), but it was likely a valid design decision at the time. If you're running a job on "big iron", depending on the situation, you might have had only a block of a few hours on a timeshared system, perhaps unattended. If the compiler refused to continue, the rest of your block might have been wasted. (At the very least, you would have had to sign up for an additional block later.) If your program had only minor errors, there was likely a good chance that the compiler might guess correctly, and your program would compile to what you wanted in the first place. If not, by continuing on, the compiler can flag additional errors later in your code, allowing you to fix those bugs sooner. (Instead of choking on the first one and refusing to continue.) Error-checking-by-compiling only "works" if you have cheap computing power you can run attended. (Can you imagine what TDD would be like if you had to wait 24+ hrs between code executions?) -- http://mail.python.org/mailman/listinfo/python-list
Re: How does this code works:
vch wrote: > Here's an example from some book: > > def foo(n): > s = [n] > def bar(i): > s[0] += i > return s[0] > return bar > > what I don't understand is how this example works, taking into account > the LGB rule. I thought that s is not accessible from bar, but it is, > apparently. Why? Nested Scopes (Since Python 2.1): http://www.python.org/peps/pep-0227.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does reply to messages on this list put the sender in the To
Peter Decker wrote: > On 7/12/05, Dark Cowherd <[EMAIL PROTECTED]> wrote: > > >>Most lists when i hit reply it puts the list address back in the To >>address and some lists allow you to configure this. >> >>But in this list reply sends the mail back as a private mail and there >>seems to be no option to configure this. >> > In cases where people are discussing problems and supplying solutions, > replying to the list is essential so that as many people as possible > can benefit from the knowledge contained in the reply. Private replies > only benefit the lone recipient, while list replies benefit everyone > on the list and everyone who later searches the archives. There have been some q&a lists I've been on where the sole content of the list is people posting questions. Questions rarely get a response on-list. It makes the list practically worthless. To top it off, the archive of the mailing list only lists the questions, but never the (private) answers. It makes Google a pain to use, as you get hits to people asking the same question you want, but never the answers. Sorry, had to vent. -- http://mail.python.org/mailman/listinfo/python-list
Re: Porting from Python 2.3 to 2.4
Joseph Garvin wrote: > Anand wrote: > >> Hi >> >> Are there any tools that would help in porting code from >> Pyton 2.3 to 2.4 ? I have gone through the whatsnew documents >> and created a document comparing Python 2.4 to 2.3. But so far >> has not been able to find any tool that will signal code in >> Python 2.3 that can cause errors in Python 2.4 . >> >> rgds >> >> -Anand >> >> >> > All 2.x versions are backwards compatible. Porting just means taking > advantage of new features. Unless you've been naughty and are accessing > private methods in stdlib, you're probably fine. Not strictly speaking true - if your program is taking advantage of some of the dark corners of the language, there is a chance your program might not work. Be aware though, that programs that take advantage of "features" which change between 2.x releases likely aren't using best practices anyway. (The Python team strongly hesitates to change behavior if it breaks backward compatibility for a large number of programs.) See http://www.python.org/doc/2.4.1/whatsnew/whatsnew24.html for details on what changes. Possible non-backward compatible changes for 2.3->2.4 transition: *Int/long operations no longer produces FutureWarnings that can be suppressed. (Uses new behavior instead.) *Integer operations will no longer trigger an OverflowWarning. *You can't rebind None. *New modules/builtin functions added - if you've used the same names, you may get the wrong module/function in corner cases. Minor issues all, but if you happen to rely on that behavior, your code will now fail, sometimes silently. -- http://mail.python.org/mailman/listinfo/python-list
Re: all possible combinations
rbt wrote: > Say I have a list that has 3 letters in it: > > ['a', 'b', 'c'] > > I want to print all the possible 4 digit combinations of those 3 > letters: When I have occasion to do an iteration of iterations, I either use recursion (already posted) or use an accumulator type loop: items = ['a','b','c'] accume = [[],] for pos in range(4): old_accume, accume = accume, [] for comb in old_accume: for item in items: accume.append(comb + [item]) accume = [''.join(x) for x in accume] print accume ['', 'aaab', 'aaac', 'aaba', 'aabb', 'aabc', 'aaca', 'aacb', 'aacc', 'abaa', 'abab', 'abac', 'abba', 'abbb', 'abbc', 'abca', 'abcb', 'abcc', 'acaa', 'acab', 'acac', 'acba', 'acbb', 'acbc', 'acca', 'accb', 'accc', 'baaa', 'baab', 'baac', 'baba', 'babb', 'babc', 'baca', 'bacb', 'bacc', 'bbaa', 'bbab', 'bbac', 'bbba', '', 'bbbc', 'bbca', 'bbcb', 'bbcc', 'bcaa', 'bcab', 'bcac', 'bcba', 'bcbb', 'bcbc', 'bcca', 'bccb', 'bccc', 'caaa', 'caab', 'caac', 'caba', 'cabb', 'cabc', 'caca', 'cacb', 'cacc', 'cbaa', 'cbab', 'cbac', 'cbba', 'cbbb', 'cbbc', 'cbca', 'cbcb', 'cbcc', 'ccaa', 'ccab', 'ccac', 'ccba', 'ccbb', 'ccbc', 'ccca', 'cccb', ''] Optimize as you see fit. -- http://mail.python.org/mailman/listinfo/python-list
Re: python certification
[EMAIL PROTECTED] wrote: > i want to get a small certificate or diploma in python. > it should be online cuz i live in pakistan and wont have teast centers > near me. > it should be low cost as i am not rich. > and hopefully it would be something like a a begginer certification cuz > i am new to python. Just print out the certificate below and paste on your wall ;) #--# | | | | | Comp.Lang.Python does hereby certify that | | | | LORD VERMINARD | | | | is a bona fide Pythonista, | |with all rights and privileges| | assigned thereto.| | | | Presented This Day | | | | 18th of July, 2005 | | | | | #--# Or, you could give some indication of why you would need such a thing. If it's for your own satisfation, use the certificate above when you're gone through the tutorial and have written an actual program you feel is useful. (That's what's of value with Python - using it to make your life better, not being able to fill out the correct bubbles on some multiple choice test.) -- http://mail.python.org/mailman/listinfo/python-list
Re: goto
Leif K-Brooks wrote: > rbt wrote: > >>IMO, most of the people who deride goto do so because they heard or read >>where someone else did. > > > 1 GOTO 17 > 2 mean,GOTO 5 > 3 couldGOTO 6 > 4 with GOTO 7 > 5 what GOTO 3 > 6 possibly GOTO 24 > 7 you! GOTO 21 > 8 that GOTO 18 > 9 really, GOTO 23 > 10 understandable? > 11 neat.GOTO 16 > 12 and GOTO 25 > 13 are GOTO 9 > 14 IGOTO 26 > 15 wrongGOTO 20 > 16 IGOTO 2 > 17 Yes, GOTO 14 > 18 simple GOTO 12 > 19 agreeGOTO 4 > 20 with GOTO 22 > 21 GotosGOTO 13 > 22 somethingGOTO 8 > 23 really GOTO 11 > 24 be GOTO 15 > 25 easily GOTO 10 > 26 totally GOTO 19 I dislike gotos because it is too easy to inadvertently create infinite loops. <10 WINK; 20 GOTO 10> -- http://mail.python.org/mailman/listinfo/python-list
Re: Documentation bug: Python console behaviour changed
Tim Golden wrote: > Usually means you have a readline package installed: Should the readline package be twiddled to change the "quit" string in builtins to document the correct behavior? -- http://mail.python.org/mailman/listinfo/python-list
Re: goto
> My "favorite" infinte loop with while is: > >i = 0 >while i < 20: > do_process(i) > > Note the prominent *lack* of any change to i here? > > Oh, for: > > from i = 0 > invariant 0 <= i <= 20 > variant 21 - i > until i > 19 > loop > do_process(i) > > which throws an exception at the beginning of the second loop. What language is that from? I take it the exception is from the "21-i" not changing as it goes around the loop, right? (But why can't "variant i" work just as well?) -- http://mail.python.org/mailman/listinfo/python-list
Re: SciPy and NetCDF
[EMAIL PROTECTED] wrote: > I am going to be doing a lot of work with large data sets stored in > various netCDF files, and after checking out the alternatives, I would > really like to go with SciPy. The problem is that SciPy offers no > native netCDF support. You may be having an issue because there is a difference between SciPy [http://www.scipy.org/] and ScientificPython [http://starship.python.net/~hinsen/ScientificPython/] - despite the name similarity, they are not the same thing. -- http://mail.python.org/mailman/listinfo/python-list
Re: SciPy and NetCDF
Scott Kilpatrick wrote: > So wherever pycdf does a: > > from Numeric import * > > what is the equivalent for SciPy? i.e. where is the full Numeric module > in SciPy? Python packages are in a pretty flat hierarchy. There really isn't a "SciPy Numeric" and a "pycdf Numeric" - Numeric, as an independant module, installs to pretty much the same location regardless of what module has it as a dependancy. So "from Numeric import *" isn't importing Numeric as a subpackage of pycdf, it is importing it from the top level global package namespace. That was a long way of saying that "from Numeric import *" in pycdf is exactly the same as "from Numeric import *" in SciPy. Note that the local/global import issue is subject to a clarification/alteration in the near future - but for now we have to live with a little ambiguity. -- http://mail.python.org/mailman/listinfo/python-list
Re: On fighting fire with fire...
projecktzero wrote: > but..but...It's so much more fun to unleash your anger and fire back > with all guns blazing fanning the flame war that most discussion groups > degenerate into after a couple of responses. =) > > Actually, I had some self restraint yesterday. I wanted to write a > ripping response to an antagonistic flame bait message on another > group. I wrote it, decided it wouldn't help much, and deleted it. I > guess I got it out of my system by just writing it. That's what I do. I sometimes have something I want to say, so I write my rant. Once I get it out of my system, I realize that it isn't adding anything to the discussion, and delete it. The part of my brain that wants to rant is happy because it got its say in, and the rest of the world is happier for not having to read it. I highly recommend that people try it. It works wonders. -- http://mail.python.org/mailman/listinfo/python-list
Re: On fighting fire with fire...
Asad Habib wrote: > I agree with Mustafa. After all, we are a bunch of professionals and not > vagabonds hired to take pot shots at one another. Except that we're not all professionals. There are a large number of hobbyists who use Python and this list. At any rate, my suggestion was not to forswear gentle corrections toward better list behavior, (emphasis on gentle) but to address the case where one would be tempted to "fight fire with fire", and answer a potshot with another potshot. Professionals (and even decent hobbyists) don't escalate flame wars, even unintentionally. -- http://mail.python.org/mailman/listinfo/python-list
Re: On fighting fire with fire...
Asad Habib wrote: > Well, even if you are a hobbyist, that does not excuse you from being > civil. After all, we are all humans beings that deserve to be treated with > respect. Professional, hobbyist, vagabond, ogre, instigator, troll ... > THERE IS NO EXCUSE ... please treat others with respect. I really don't think we're disagreeing. I agree that it is inappropriate, regardless of position or experience, to be rude, hostile, or vitriolic on this newsgroup. And it should be made clear to people who are, that it isn't appropriate. However, in doing so, it is also inappropriate to become rude, hostile, or vitriolic oneself - as Skip mentioned in the post that started all this, the appropriate way of handling it is by demonstrating proper behavior yourself. If, for whatever reason, you do find the desire to be rude, hostile, or vitriolic, you can satisfy your urge by writing out your rant and then deleting it. You'll feel better by getting it off your chest, and you won't have escalated anything. The reason I point out the hobbyist issue is to disabuse people of the misperception that everyone on this list is adhering to some professional code of conduct that they should be ostracized for breaching. This isn't to excuse their behavior - I'm just pointing out that people are coming from different backgrounds, and that we should treat them with consideration and respect, even when they aren't showing us any. -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
Adriano Varoli Piazza wrote:
> As far as I recall from Math Analysis, which I studied two months ago,
> you can't sort complex numbers. It makes no sense. The reason being
> (reading from my book), it's not possible to define an order that
> preserves the properties of arithmetical operations on complex numbers.
> So you can't order them, and you can't compare them.
Debate the merits of Python's method of sorting all you want, but for
the love of all that is good and holy, please do not claim that the
current way of doing things is somehow mathematically pure. The best
explanation of the current method is that it is a compromise borne out
of the best use cases encountered as the language grew in it's infancy,
and we're stuck with it currently because it would break too much to
change things right now.
E.g.:
1 < '2' => True
'1' < 2 => False
20 < 'Five' => True
None < 0 => True
[1,2] < (1,2) => True
(1,2) < [100,200] => False
(None,) < None => False
{1:None,2:None} < [1,2] => True
[None, 1, 'five', open('README'), (1,2,3)].sort() => works just fine
[None, 1, 'five', open('README'), (1,2,3), 1j].sort() => crashes and burns
None of these make sense mathematically, nor were they motivated
primarily by mathematical arguments. Why is [1,2] < (1,2)? Because
'list' < 'tuple' - No more, no less.
One could argue that you could think of complex numbers as tuples of
values - but then why does
[(1,2),(4,1),(4,-3),(7.2,-1.2)].sort() work and
[(1+2j),(4+1j),(4-3j),(7.2-1.2j)].sort() fail?
"Practicality beats purity." Python has it's current ordering/sorting
scheme not because it is theoretically pure, but because it seemed like
the best option at the time. Please don't pretend it's perfect - it's
even been admitted that things are going to change in the future,
although I haven't yet seen a conversation where it has been made clear
exactly what will change.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Passing arguments to function - (The fundamentals are confusing me)
Christopher Subich wrote: > Gregory Piñero wrote: > >> Hey guys, would someone mind giving me a quick rundown of how >> references work in Python when passing arguments into functions? The >> code below should highlight my specific confusion: This URL is always tossed out: http://starship.python.net/crew/mwh/hacks/objectthink.html > All arguments are passed by reference, but in Python equality rebinds > the name. Bingo >> Why does my list variable get changed for the rest of the program, but >> my boolean variable doesn't. What am I not understanding? Booleans are immutable, lists are mutable. You change (mutate) the same list, but you are referencing a different (immutable) Bool > In Python, "x = y" has a very definite meaning of "y is assigned to the > name of x." Change it to "the object referenced by y is assigned to the name of x", and you're closer to the truth. -- http://mail.python.org/mailman/listinfo/python-list
Re: Passing arguments to function - (The fundamentals are confusing me)
Gregory Piñero wrote: > Ahh, so it's a mutable thing. That makes sense that I can't change a > mutable object and thus can't affect it outside of the function. If you meant "immutable" for the second mutable, you're right. > Does > that mean Python functions aren't always byref, but are sometimes > byval for nonmutables? It'd probably do you good to get away from the by reference/by value thinking. Python isn't C/Basic/Fortran/etc. Variables in Python are names. They aren't the cubbyholes into which you put values, they are sticky notes on the front of the cubby hole. Parameter passing in Python always work the same way - you create a new name pointing to the passed object. Fin. The confusion you're having isn't in parameter passing, it's in the difference between assignment and mutation. Mutation changes the object itself (what's in the cubby hole), so it doesn't matter what or how many names/variables it has (what sticky notes are on the front). Assigment just changes where names point, not the contents of objects. (It's moving that sticky note, and only that sticky note, from one cubby to a different one.) Assignment justs affects that name, not any other name which point to the same object, including the variables in the passing scope. -- http://mail.python.org/mailman/listinfo/python-list
Re: Passing arguments to function - (The fundamentals are confusing me)
Dennis Lee Bieber wrote: > On Tue, 09 Aug 2005 10:39:29 -0500, Rocco Moretti > <[EMAIL PROTECTED]> declaimed the following in comp.lang.python: > > >>Change it to "the object referenced by y is assigned to the name of x", >>and you're closer to the truth. > > In a more simplistic view, I'd reverse the phrasing... The name > "x" is assigned to the object "y" (implying it is no longer attached to > whatever used to have the name) I guess I was too subtle - my point was lost. The key thing is not to think of "the object 'y'" but to think of "the object referenced by (named) 'y'" There is a distinction between the object (object) and the name (variable), which is essential to eliminating the OP's conundrum. -- http://mail.python.org/mailman/listinfo/python-list
Re: Passing arguments to function - (The fundamentals are confusing me)
Christopher Subich wrote: > Rocco Moretti wrote: > >> Variables in Python are names. They aren't the cubbyholes into which >> you put values, they are sticky notes on the front of the cubby hole. > > > +1 MOTW (Metaphor of the Week) Thanks, but please note it's not really mine - I've seen it somewhere else before. I thought it was from the website I linked earlier[1], but now I'm a little embarrased to find out that isn't, and I have no clue where it's from. [1] http://starship.python.net/crew/mwh/hacks/objectthink.html -- http://mail.python.org/mailman/listinfo/python-list
Library vs Framework (was Dr. Dobb's Python-URL!)
Cameron Laird wrote: > Andy Smith rails against "frameworks": > http://an9.org/devdev/why_frameworks_suck?sxip-homesite=&checked=1 > Slapdash Summary: Libraries good, frameworks bad - they are a straightjackets and limit sharing. Which lead me to the question - what's the difference between a library and a framework? -- http://mail.python.org/mailman/listinfo/python-list
Re: Library vs Framework (was Dr. Dobb's Python-URL!)
Simon Brunning wrote: > On 8/15/05, Rocco Moretti <[EMAIL PROTECTED]> wrote: > >>Which lead me to the question - what's the difference between a library >>and a framework? > > > If you call its code, it's a library. If it calls yours, it's a framework. Although that definition probably makes sense from a pure C perspective, where practically everything you deal with is a primitive, I'm not sure how much use the distinction is with a OO/duck typing language like Python. Say you have a "library" of objects - you (as a user) subclass one and change one of it's functions subtly (say to add logging). Now when the library code runs, it'll call into your code. Voila! Framework. Or say you have a library function which takes a file object as a parameter. Instead of feeding it a Python file, you feed it your own file-like object. Now it'll call your code whenever you do a read/write/seek etc. In fact, since the parameter was probably documented just as "takes a file", you're never quite sure which functions in your objects will get called, short of reading the source of the library - excuse me, it's a framework now. In fact, since Python works with duck typing, and even basic operations like addition and element access can be customized for any parameter, there is no guarantee that users' code won't get called when they use your "library." So is the library/framework distinction useful in Python, especially w/r/t Andy Smith's remarks? -- http://mail.python.org/mailman/listinfo/python-list
Re: Library vs Framework (was Dr. Dobb's Python-URL!)
Simon Brunning wrote: > On 8/15/05, Terry Hancock <[EMAIL PROTECTED]> wrote: > >>On Monday 15 August 2005 09:54 am, Simon Brunning wrote: >> >>>If you call its code, it's a library. If it calls yours, it's a framework. >> >>Such concision deserves applause. ;-) > > > Thank you. ;-) > > As others have pointed out, this is a *drastic* simplification, > perhaps an oversimplification. You will inevitably need to call a > framework's code in addition to it calling yours, and a callback > argument or two won't turn a library into a framework. But I think it > captures the essence of the difference. The point that passed me by the first time, and which Magnus et al. helped me realize, is that it's referring not to an instantaneous, mechanical view of calling, but to a more general, philosophical view of calling. With a library, the user's code is "in charge" of the program structure, and calls the library to fill in the details and help out. With a framework, the framework is "in charge", and the user code is filling in with a supporting role. With this in mind, it's easy to see why Andy Smith feels frameworks are restricting - after all, it's the framework, not the user, who is "in charge" of program structure. But I'm not sure if library vs. framework a fair comparison - the two are doing different things. With a framework, you're not really writing your own program, you're customizing someone else's. Sort of a vastly more flexible version of command line options. Saying you can't reuse code written for a framework is kind of like saying that it's difficult to use an Apache config file with the Gimp. -- http://mail.python.org/mailman/listinfo/python-list
Re: Module Name Conflicts
[EMAIL PROTECTED] wrote: > I have a java program in a package called 'cmd'. This of course > conflicts with the builtin python package of the same name. The thing > is, I need to be able to import from both of these packages in the same > script. I can import either one first, but any future attempt to import > from cmd.* will look up the first cmd that was imported, so the second > package is essentially eclipsed. I've tried fiddling with sys.path and > sys.packageManager.searchPath, to no avail. To answer the obvious first > suggestion, no I can't rename the java package to 'Cmd' or anything > like that. Any ideas? > > -Smurf Never used it myself, but you can try to use the builtin 'imp' module. Python Library Reference 3.21 imp -- Access the import internals This module provides an interface to the mechanisms used to implement the import statement. It defines the following constants and functions: ... -- http://mail.python.org/mailman/listinfo/python-list
Re: OpenSource documentation problems
Steve Holden wrote: > Every page of the docs links to "About this document", which contains > the following: """If you are able to provide suggested text, either to > replace existing incorrect or unclear material, or additional text to > supplement what's already available, we'd appreciate the contribution. > There's no need to worry about text markup; our documentation team will > gladly take care of that.""" There is just one giant roadblock to that suggestion - Sourceforge requires a login to post bugs/patches. It doesn't seem like much, but as Paul Rubin mentioned, most people who find bugs/unclear passages in the docs aren't scanning the docs explicitly to edit them - they've uncovered the bug after working on some other project, and likely only after banging their head against the wall a few times trying to get it to work. If they have to go through the song and dance of signing up for another website to report the problem, they might just say "forget it." Sure, it's not hard to sign up for Sourceforge, but even a little barrier can stop you from contributing if you're not enthusiastic about it in the first place. Something a simple as allowing doc bugs to be submitted from a webform w/o login would reduce the barrier to contribute. - Increasing the size of the "About" text wouldn't hurt either. (To be honest, I've never noticed that text before, and it never occurred to me look at the "About" page for information on error reports.) That said, I think the Python manuals are great. But saying that they are perfect, or that the editing process couldn't be improved is just deluding yourself. -- http://mail.python.org/mailman/listinfo/python-list
Re: Well, Python is hard to learn...
wen wrote: > due to the work reason, i have to learn python since last month. i have > spent 1 week on learning python tutorial and felt good. but i still don't > understand most part of sourcecode of PYMOL(http://pymol.sourceforge.net/) > as before. Well, last time I checked, a good chunk of PyMol was written in C. Knowing Python may help you to learn C, but I doubt that one week is going to be sufficient. But I agree that Python is deceptive. It's so easy to learn and use, you can easily convince yourself you're a better programmer than you actually are. -- http://mail.python.org/mailman/listinfo/python-list
Re: 'isa' keyword
Terry Hancock wrote: > On Thursday 01 September 2005 07:28 am, Fuzzyman wrote: > >>What's the difference between this and ``isinstance`` ? > > I must confess that an "isa" operator sounds like it would > have been slightly nicer syntax than the isinstance() built-in > function. But not enough nicer to change, IMHO. Especially conidering that checking parameters with "isinstance" is considered bad form with Python's duck typing. -- http://mail.python.org/mailman/listinfo/python-list
Re: 'isa' keyword
Colin J. Williams wrote:
> Rocco Moretti wrote:
>
>> Terry Hancock wrote:
>>
>>> On Thursday 01 September 2005 07:28 am, Fuzzyman wrote:
>>>
>>>> What's the difference between this and ``isinstance`` ?
>>>
>>> I must confess that an "isa" operator sounds like it would
>>> have been slightly nicer syntax than the isinstance() built-in
>>> function. But not enough nicer to change, IMHO.
>>
>> Especially conidering that checking parameters with "isinstance" is
>> considered bad form with Python's duck typing.
>
> Could you elaborate on that please?
I'm not sure if you're familiar with duck typing or not, so I'll
summarize it briefly. (More detail can be found by others in the c.l.py
archive.)
"Duck typing" takes its name from the expression "If it looks like a
duck, walks like a duck, and quacks like a duck, it's a duck." That is,
the essence of an object is not its provenance, but its behaviour. This
arises in part from Python being dynamically typed - you don't have to
match the type of an object in order to pass it as a parameter.
For example, say you had a function:
def fun(alist):
for item in alist:
doworkon(item)
The intended use of the function is for it to be passed a list, but you
don't have to pass a list - it works just fine with a tuple, an
iterator, a generator, a file object, a dictionary, or in fact any user
defined class - all that's needed is for an appropriately defined
__iter__ or __getitem__ member.
Now if you use isinstance, you mess that up:
def boring(alist):
if isinstance(alist, list):
for item in alist:
doworkon(item)
else:
raise TypeError
This will only work with a bona fide list, and choke on the other
objects - even objects intended by the programmer to act like a list.
Python functions are much more flexible if you don't go checking if an
object is of a particular type. It makes things like using proxies,
wrappers and mock objects much easier.
Best practices in Python call for using a parameter and catching when it
doesn't behave properly, not prophylactically checking types. Python
programmers can go months to years without using isinstance. It doesn't
make sense to make it any easier.
P.S. In the OP's case, where it was desired to distinguish between being
passed a string and being passed a list of strings, the approach used is
probably sub-optimal. It would likely be better to have the function
always take a "list", and convert all the fun('string') calls to
fun(['string']) calls.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Replacement for lambda - 'def' as an expression?
[EMAIL PROTECTED] wrote: > On Tue, 06 Sep 2005 12:19:21 +0200 > Torsten Bronger wrote: > > >>"talin at acm dot org" <[EMAIL PROTECTED]> writes: >> >>>Anyway, here's an example, then, of how 'def' could be used: >>> >>>add = def( a, b ): >>> return a + b >> >>I'm really not an expert in functional programming, so I wonder >>what's the difference between "add = def" (assumed that it worked) >>and "def add"? > > > In the former case one could write > > self.add[0] = def(a, b) > # etc. If that's the issue, it might make more sense to extend def to take any lvalue. def self.add[0](a, b): return a + b -- http://mail.python.org/mailman/listinfo/python-list
Re: Removing duplicates from a list
Rubinho wrote: > I can't imagine one being much faster than the other except in the case > of a huge list and mine's going to typically have less than 1000 > elements. To add to what others said, I'd imagine that the technique that's going to be fastest is going to depend not only on the length of the list, but also the estimated redundancy. (i.e. a technique that gives good performance with a list that has only one or two elements duplicated might be painfully slow when there is 10-100 copies of each element.) There really is no substitute for profiling with representitive data sets. -- http://mail.python.org/mailman/listinfo/python-list
Re: Software bugs aren't inevitable
Terry Reedy wrote: > But that, I admit, would be an invalid conclusion. And that, I claim, is > also invalid when 'iteration' and 'recursion' are reversed, no matter how > often repeated in texts and articles. The difference is between the > algorithms, not the differing syntactic expressions thereof. There is a comparison in there about iteration vs. recursion, but it's probably not the one intended. The algorithm one uses sometimes depends quite heavily on which mindset you're using. Some algorithms require much more mental effort to understand when in their recursive form versus the iterative form, and vice versa. If you're stuck thinking in only one form, you might miss the better algorithm because it is not as "simple" in that form. The ideal case would be a programming language that allows you to write the algorithm in whatever form is simplest/most comfortable, and then automagically transforms it to the form that works the fastest under the hood. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to tell if an exception has been caught ( from inside the exception )?
Paul Dale wrote: > > Hi everyone, > > I'm writing an exception that will open a trouble ticket for certain > events. Things like network failure. I thought I would like to have it > only open a ticket if the exception is not caught. Is there a way to do > this inside the Exception? As far as I can see there are only two events > called on the exception, __init__ and __del__, both of which will be > called wether or not an exception is caught (right?) > > Am I missing something, or is there a way to do this with exceptions? Is there some reason you can't wrap your entry point with a try:except? e.g. if __name__ == "__main__": try: main() except OpenTicket, e: process_open_ticket(e) -- http://mail.python.org/mailman/listinfo/python-list
Re: Indexed variables
[EMAIL PROTECTED] wrote: > So how do I define the function such as to discrimate wheter I call it by > f(a1) or f(a2) ? I don't want to sound rude, but I think you'll be better served by telling us why you would want to do such a thing - ten to one someone can suggest a better way to acomplish you end goal, rather than discriminating on which variable is passed to a function. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
Jeff Shannon wrote: news.sydney.pipenetworks.com wrote: Fredrik Lundh wrote: a certain "princess bride" quote would fit here, I think. I'm not really familiar with it, can you enlighten please. (Taking a guess at which quote /F had in mind...) Vezzini: "Inconceivable!" Inigo:"You keep using that word. I do not think that it means what you think it means." Jeff Shannon With all the talk about "never"s, my initial thought was: Vezzini: Haha.. you fool! You fell victim to one of the classic blunders. The most famous is: Never get involved in a land war in Asia. Only slightly less well know is this: Never go in against a Sicilian when death is on the line! Ha ha, Ha ha, Ha I think yours makes more sense in context, though. -- http://mail.python.org/mailman/listinfo/python-list
Re: Dr. Dobb's Python-URL! - weekly Python news and links (Dec 2)
For some reason I can't seem to make use of the google links. When I use the above eg http://groups.google.com/groups?frame=right&th=e562a771d1c827c9 I get a not found google page with url http://groups-beta.google.com/groups?frame=right&th=e562a771d1c827c9 really wanted to spell file in a sickly manner :) It seems Google recently redid their groups interface. By searching for "group:comp.lang.python Coghlan" on http://groups.google.com, I was able to find the probable post (Sort by Date, titled "Restricted Execution on the cheap", about four down) I'm sorry I'm not able to give a direct URL, but it seems they've switched over to a horrendously long, stateful URL system which doesn't lend itself to direct linkage. -- http://mail.python.org/mailman/listinfo/python-list
Re: How did you learn Python?
Shawn Milo wrote: > How did you learn Python? > I was just wondering what the best books were for learning Python. If you're open to options besides ink-on-tree, this is how I did it: I read the official tutorial, trying stuff out in the interactive interpreter when I didn't get something/had questions. Read the first couple of sections of the Library Reference (especially the Built-in objects/functions), skimming when you get to those long lists of functions/objects. Decided "for language lawyers" was likely a joke; read/skimmed the Language Reference (turns out it's half a joke). Then I lurked on comp.lang.python. I've since picked up a few books & looked at highly recommended on-line tutorials. For the most part, they mainly repeat the stuff in the official documentation and the stuff that isn't in there gets brought up on c.l.py eventually. But YMMV, and you may prefer other tutorials to the official one. BTW, I've found the trickiest part of learning python really can't be taught in books. I mean, it's stated in the books, but the words don't really help. It's understanding the philosophy behind the way Python does things, like the object/assignment model and object orientation, that's key. This understanding comes from experience, and I think it's something we're all still working on. P.S. I haven't said yet how much I've appreciated the excellent documetation the Python crew has put out. It was literally only an afternoon before I had completed the tutorial and had a good impression of what this "Python thing" was all about. I've since tried to do the same with other languages (eg. OCaml & TCL), but haven't had as much success. Kudos to Guido, Fred, and the others. -- http://mail.python.org/mailman/listinfo/python-list
Re: Optional Static Typing
John Roth wrote: One of the comments on Artima asks a rather profound question: static typing is an answer. What's the question? (That's a paraphrase.) The answer that everyone seems to give is that it prevents errors and clarifies the program. It might just be me, but I thought it was to simplify code analysis and compilation. (That is, for the use of static typing in general, not for Python in particular.) Looking at C, it's doubtful error prevention and program clarification was a serious objective in the static typing system. It's more reasonable to conclude that C is statically typed because it allows the compiler to more easily allocate 1 vs 2 vs 8 bytes for a particular variable, and to make sure the proper addition opcodes get put down. Now whether this would be useful for Python is an open question. Many of the supposed advantages simply aren't there when you go to the discipline of writing a test and then writing exactly the code needed to make the test pass, and not one keystroke more. ... This isn't to say TDD is the be-all and end-all of correctness. Right. And unit tests don't do anything for people who don't use them. The question is, should Guido state "TDD is the one true way to program in Python.", or should concessions be made in the language design for those who don't "drink the TDD Kool-aide". So the conclusion here is that static typing is an attempt to make programming safe for people that shouldn't be programming in the first place. I rebut it thusly: "elitist bastard." One of the draws of Python is that it's welcoming to newcomers and programmers of all talents. You don't have to be an "uber-programmer" to use it and use it well. Should we hobble it to suit poor programmers? No. But that's no reason why it can't be made to be easier and safer to use for the hobbyist when it doesn't compromise usefulness for the power-programmer. (My opinion) Python shouldn't have a sign on the door saying: "You must be this 'leet to enter." Will static typing be a boon for Python? Is it necessary? Or is it the trailhead on the road to Hades? Only time will tell. -- http://mail.python.org/mailman/listinfo/python-list
Re: Optional Static Typing
John Roth wrote: "Rocco Moretti" <[EMAIL PROTECTED]> wrote > Looking at C, it's doubtful error prevention and program clarification was a serious objective in the static typing system. It's more reasonable to conclude that C is statically typed because it allows the compiler to more easily allocate 1 vs 2 vs 8 bytes for a particular variable, and to make sure the proper addition opcodes get put down. The C language does not have strong typing in the sense that most people use the term today. Strong != Static As I understand it, strong typing means an object (variable) is what it is, and can't be changed to a different type without explicit conversion - weak typing being that an object can be any type, depending on which functions you use to look at it. Static typing is that a variable has a specific type, and can't hold a variable of a different type. This is opposed to dynamic typing, where the type of an (object in a) variable is flexible and determined at run time. Python - Strong, Dynamic C - Weak, Static Perl - Weak, Dynamic This is how I understand it. Could be wrong - wouldn't be surprised if I was, as it's a rather confusing issue at times. The question is, should Guido state "TDD is the one true way to program in Python.", or should concessions be made in the language design for those who don't "drink the TDD Kool-aide". Neither one. I hope you didn't mean that people who advocate TDD are suicidal fanatics, because that's exactly what "drink the kool-aid" means. The irony didn't travel well. All I meant is that in all the advocacy, it may get ignored that reasonable people might disagree about the value of TDD, that TDD is not a "be-all, end-all" for all people. "Concessions" also probably wasn't the right choice of word, as it implies the TDD people are giving something up. My point was, if Python is not going to be solely targeted at TDD, facilities that make other ways of doing things easier are likely (should) be included, as long as they don't negatively affect how the majority of the people who use Python do things. So the conclusion here is that static typing is an attempt to make programming safe for people that shouldn't be programming in the first place. I rebut it thusly: "elitist bastard." Bullshit. Where did you get your certificate in mind reading? Sorry. I didn't mean to imply that *you* were an elitist bastard. I merely meant that someone who would dismiss something as for "people that shouldn't be doing X in the first place" is likely biased by snobbery. You were merely restating someone else's opinion, and if I accidentally accused you of also holding it, I'm sorry. From the rest of your post, it seems we pretty much agree on the key point - different people have different ways of doing things, none of which are necessarily "wrong" in and of themselves. Python tries to be open and inclusive towards all who want to program, without sacrificing power for it's core users. Is there a group of people for whom static typing truly helps? I don't know. What I do know is that saying that you don't need static typing if you use TDD doesn't say anything about the helpfulness of static typing for those who don't use TDD. Whether the latter group is worth Python worrying about is a philosophical question on the future direction of Python best left to Guido. -- http://mail.python.org/mailman/listinfo/python-list
Re: argument type
"It's me" wrote: > No, that was just an example. I actually have additional arguments > that are similar to arg2. It's not like I can do: > > def abc(arg1, arg3, *arg2s, *arg3s, *arg4s) ... Now, what if arg2 is not a string but either a number or a bunch of numbers? Using your method, can I say something to the effect of "if arg2 is *not* an instance of a simple number"? Methinks you are trying to shove a 5 bushel problem in a 2 bushel sack. Take a deep breath. Get a cup of coffee. Read the newspaper. Come back in 10-15 min and re-examine the problem with a fresh mind. Do you really have to pass multiple, variable sized lists of varying types to the same function? Is there some way to break the function into simpler pieces? Is there some better way to organize the program as a whole so that you avoid the issue altogether - perhaps by defining a new class? It's been my experience that whenever I'm confused on how I'm going to pass a number of parameters to a function, the function is too complex and needs to be simplified, either by splitting it up into simpler functions, or by moving functionality into object methods. In the end, the program not only does what I want, but is also easier to understand. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuples use parentheses ()'s instead of something else like <>'s?
[EMAIL PROTECTED] wrote: Why tuples use parentheses ()'s instead of something else like <>'s? > > Please enlighten me as I really want to know. So to summarize: Commas define tuples, except when they don't, and parentheses are only required when they are necessary. I hope that clears up any confusion. -- http://mail.python.org/mailman/listinfo/python-list
Re: Compiled bytecode
Peter Hansen wrote: The main script is generally not compiled, but all imported scripts are generally compiled automatically, the first time they are imported, and never again unless the source changes. Someone please correct me if I'm wrong, but I'm under the impression that the main script *is* compiled, but the byte-code compiled file is kept in memory, and not written to disk. That's what makes this work: -- file1.py - import dis def f(): a = 1 print a dis.dis(f) - > python file1.py 4 0 LOAD_CONST 1 (1) 3 STORE_FAST 0 (a) 5 6 LOAD_FAST0 (a) 9 PRINT_ITEM 10 PRINT_NEWLINE 11 LOAD_CONST 0 (None) 14 RETURN_VALUE > -- -- http://mail.python.org/mailman/listinfo/python-list
Re: Grouping code by indentation - feature or ******?
Antoon Pardon wrote: I have problems with all languages currently available, so I use those which rub me wrong the least. ... [I]t doesn't weight heavy enough to go and use an other language, although I keeping looking at the other languages. I think the operational definition of a "zealot" is someone who thinks what they have is absolutely perfect, and refuses to examine the alternatives. Not a very inspiring slogan though: "Python - the least of 1,000+ evils." -- http://mail.python.org/mailman/listinfo/python-list
