Re: ANN: Dao Language v.0.9.6-beta is release!
Antoon Pardon [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: Op 2005-12-11, Rick Wotnaz schreef [EMAIL PROTECTED]: Because you're accustomed to one set of conventions, you may find Python's set strange at first. Please try it, and don't fight it. See if your objections don't fade away. If you're like most Python newbies, you'll stop thinking about brackets before long, and if you're like a lot of us, you'll wonder what those funny squiggles mean when you are forced to revert to one of those more primitive languages. I think the suggestion that those who have some problem with how python deals with compound statements - obligated indentation, no end markers - are newbees, is getting stale. I am not a newbee and I have problems with it. I had problems with it when I was a newbee, grew used to it and even liked it at some point and now again have problems with it. Well problems is probably too strong, would prefer differently seems closer. You're right that I should not have assumed newbie status, but I most often see posts complaining about lack of braces from those newly exposed to Python's way of doing things. The post I responded to considered whitespace indention a design defect. I would be surprised to hear an experienced Python programmer say that, but maybe I'm just naive. I am not a fanatic about structuring via whitespace. From time to time, code arrives at this group with leading whitespace removed, which makes me think it might be nice to have bracketing, so the original logic could (maybe) be recreated. That's most of the downside, though, and an artificial problem at that. It has nothing to do with Python, but with hostile software along the way. The upside is clarity of code (and a little less typing, too), and that makes up for the occasional artificial problem. -- rzed -- http://mail.python.org/mailman/listinfo/python-list
Re: Using XML w/ Python...
[EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: Spoke too soon, i get this error when running amara in ActivePython import amara amara.parse(http://www.digg.com/rss/index.xml;) Traceback (most recent call last): File interactive input, line 1, in ? File C:\Python23\Lib\site-packages\amara\__init__.py, line 50, in parse if IsXml(source): NameError: global name 'IsXml' is not defined So im guessing theres an error with one of the files... IsXml is imported conditionally, so this is an indicator that somethign about your module setup is still not agreeing with ActivePython. What do you see as the output of: python -c import amara; print dir(amara) ? I get: ['InputSource', 'IsXml', 'Uri', 'Uuid', '__builtins__', '__doc__', '__file__', '__name__', '__path__', '__version__', 'bindery', 'binderytools', 'binderyxpath', 'create_document', 'dateutil_standins', 'domtools', 'os', 'parse', 'pushbind', 'pushdom', 'pyxml_standins', 'saxtools'] Not wanting to hijack this thread, but it got me interested in installing amara. I downloaded Amara-allinone-1.0.win32-py2.4.exe and ran it. It professed that the installation directory was to be D:\Python24\Lib\site-packages\ ... but it placed FT and amara in D: \Python24\Python24\Lib\site-packages . Possibly the installer is part of the problem here? -- rzed -- http://mail.python.org/mailman/listinfo/python-list
Re: IsString
Tuvas [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: I need a function that will tell if a given variable is a character or a number. Is there a way to do this? Thanks! If you really need to, you can test for type: for x in ['3',3,3.1,3j]: ... print type(x) type 'str' type 'int' type 'float' type 'complex' for x in ['3',3,3.1,3j]: ... if type(x) is str: print it's a string ... elif type(x) is int: print it's an int ... elif type(x) is float: print it's a float ... elif type(x) is complex: print it's a complex number it's a string it's an int it's a float it's a complex number -- rzed -- http://mail.python.org/mailman/listinfo/python-list
Re: Using XML w/ Python...
[EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: Not wanting to hijack this thread, but it got me interested in installing amara. I downloaded Amara-allinone-1.0.win32-py2.4.exe and ran it. It professed that the installation directory was to be D:\Python24\Lib\site-packages\ ... but it placed FT and amara in D: \Python24\Python24\Lib\site-packages . Possibly the installer is part of the problem here? That's really good to know. Someone else builds the Windows installer package for Amara (I'm a near Windows illiterate), but I definitely want to help be sure the installer works properly. In fact, your message rings a bell that this specifically came up before: http://lists.fourthought.com/pipermail/4suite/2005-November/00761 0.html I'll have to ask some of the Windows gurus on the 4Suite list whether they know why this might be. Do you mind if I cc you on those messages, so that you can perhaps try out any solutions we come up with? Thanks. I'd be delighted to run them. Bring 'em on! If this is useful information: the opening screen of the installer correctly shows D:\Python24\ as my Python directory, and correctly shows (on my computer): D:\Python24\Lib\site-packages\ as the Installation Directory. The file names as it installs are of the form Python24\Lib\site-packages\..., which to me hints that it takes that generated name and appends it to the Python directory to produce the actual file path it then uses. -- rzed -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Zeljko Vrba [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: On 2005-12-10, Tom Anderson [EMAIL PROTECTED] wrote: ED IS THE STANDARD TEXT EDITOR. And: INDENTATION SUCKS BIG TIME. Using indentation without block termination markers is opposite of the way we write spoken language, terminating each sentence with . Ever wondered why we use such things in written language, when people are much better in guessing what the writer wanted to say then computers? I believe I may have seen cases in written spoken language where paragraphs were indented, or otherwise separated with whitespace. It's even possible that I've seen some examples of written languages that use no periods at all! And what's more, I've seen more than one *computer* language that uses no terminating periods! Why, it boggles the mind. Despite the arguments advanced by those whose previous computer languages used braces and semicolons, there actually are more ways to separate complete statements than with punctuation. Make a grocery list. Do you terminate each item with punctuation? Write a headline for a newspaper. Is punctuation always included? Read a mediaeval manuscript. Do you find punctuation? Whitespace? How about Egyptian hieroglyphs, Chinese ideograms, Ogham runes? Because you're accustomed to one set of conventions, you may find Python's set strange at first. Please try it, and don't fight it. See if your objections don't fade away. If you're like most Python newbies, you'll stop thinking about brackets before long, and if you're like a lot of us, you'll wonder what those funny squiggles mean when you are forced to revert to one of those more primitive languages. -- rzed -- http://mail.python.org/mailman/listinfo/python-list
Re: subset permutations
Jay Parlar [EMAIL PROTECTED] wrote in
news:[EMAIL PROTECTED]:
http://www.bigbold.com/snippets/posts/show/753
A string is also iterable, so whether s is the string (as shown) or
list('ACDEFGHIKLMNPQRSTVWY'), as you have it above, this should
generate the 16 permutations, as a list of 4-character strings.
s = 'ACDEFGHIKLMNPQRSTVWY'
x = ['%s%s%s%s' % (v,w,x,y) for v in s
for w in s for x in s for y in s]
--
rzed
--
http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
[EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: a decent description or tutorial... is better Sound good but... we're programmers, not documentation specialist or motivational speakers. Why, when I suggest fixing a design defect with code, do so many programmers want to respond with... documentation and arguments instead of code? From The Design of Everyday Things, docs are a sign of poor design. Even a single word, such as the word Push on the face of a door, is an indication that the design can be improved. Please, rethink the design instead of trying to compensate with more documentation. So, for instance, even a single character (like an opening or closing bracket or a semicolon) is an indication that the design can be improved. Please, rethink your opposition instead of trying to impose your design defect on a better, cleaner design. Seriously. What you call a design defect and what other call a design feature are one and the same. I will concede this much: I would like a guarantee that helpful software would not strip leading whitespace (as has happened with some mail clients), which trashes logic-by-indention. Alternatively, it might be useful to have brackets and semicolons to overcome sadistic software interactions, but I don't *really* expect Python to be willing and able to predict and prevent all the crazy things other programs might do. And I certainly hope that Python doesn't ever *require* the brackets and semicolons that add so little value and so much clutter. -- rzed -- http://mail.python.org/mailman/listinfo/python-list
Re: General question about Python design goals
Donn Cave [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: [...] Tuples and lists really are intended to serve two fundamentally different purposes. We might guess that just from the fact that both are included in Python, in fact we hear it from Guido van Rossum, and one might add that other languages also make this distinction (more clearly than Python.) As I'm sure everyone still reading has already heard, the natural usage of a tuple is as a heterogenous sequence. I would like to explain this using the concept of an application type, by which I mean the set of values that would be valid when applied to a particular context. For example, os.spawnv() takes as one of its arguments a list of command arguments, time.mktime() takes a tuple of time values. A homogeneous sequence is one where a and a[x:y] (where x:y is not 0:-1) have the same application type. A list of command arguments is clearly homogeneous in this sense - any sequence of strings is a valid input, so any slice of this sequence must also be valid. (Valid in the type sense, obviously the value and thus the result must change.) A tuple of time values, though, must have exactly 9 elements, so it's heterogeneous in this sense, even though all the values are integer. One doesn't count elements in this kind of a tuple, because it's presumed to have a natural predefined number of elements. One doesn't search for values in this kind of a tuple, because the occurrence of a value has meaning only in conjunction with its location, e.g., t[4] is how many minutes past the hour, but t[5] is how many seconds, etc. I have to confess that this wasn't obvious to me, either, at first, and in fact probably about half of my extant code is burdened with the idea that a tuple is a smart way to economize on the overhead of a list. Somewhere along the line, I guess about 5 years ago? maybe from reading about it here, I saw the light on this, and since then my code has gotten easier to read and more robust. Lists really are better for all the kinds of things that lists are for -- just for example, [1] reads a lot better than (1,) -- and the savings on overhead is not worth the cost to exploit it. My tendency to seize on this foolish optimization is however pretty natural, as is the human tendency to try to make two similar things interchangeable. So we're happy to see that tuple does not have the features it doesn't need, because it helps in a small way to make Python code better. If only by giving us a chance to have this little chat once in a while. Donn, this is a reasonable argument, and in general I don't have a problem with the distinction between tuples and lists. I have heard and understand the argument that the intended purpose of tuple creation is to mimic C structs, so it seems reasonable to suppose that one knows what was placed in them. Lists are dynamic by nature, so you need a little more help getting information about their current state. However, there is at least one area where this distinction is bogus. Lists cannot be used as dictionary keys (as it now stands). But in practice, it is often useful to create a list of values, cast the list to a tuple, and use that as a dictionary key. It makes little sense to keep a list of that same information around, so in practice, the tuple/key is the container that retains the original information. But that tuple was dynamically created, and it isn't always true that items were placed in it deliberately. In other words, the fact that the key is now a tuple is unrelated to the essential nature of tuples. Not all of the tools used in examining lists are available to the key as a tuple, though it is really nothing more than a frozen list. Sure, you can cast it to a list to use the list methods, but that requires creating objects just to throw away, which seems a little wasteful, especially since that's what you had to do to create the key to begin with. 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. I'd extend this a little to say that tuples are (at least potentially) created dynamically quite often in other contexts as well, so that despite their designed intent, in practice they are used a little differently a good bit of the time. So why not adjust the available features to the practice? -- rzed -- http://mail.python.org/mailman/listinfo/python-list
RE: Making immutable instances
Delaney, Timothy (Tim) [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: Was it *really* necessary to send 4 separate emails to reply to four sections of the same email? Good netiquette is to intersperse your comments with quoted sections in a single email. Tim Delaney Good netiquette might also suggest quoting what you're replying to, wouldn't you think? -- rzed -- http://mail.python.org/mailman/listinfo/python-list
Re: General question about Python design goals
Fredrik Lundh [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: 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? Beats the heck outta me. I seem to remember that Antoon supplied one awhile ago (for allowing lists to serve as dictionary keys, that is). That's why I mentioned him in the first place. I didn't pay much attention to it at the time, and I imagine it would raise some issues, like everything does. I'm fairly indifferent to the idea in any case; I'm just saying I wouldn't object if lists could function as dictionary keys. It would save that casting step I was talking about. -- rzed -- http://mail.python.org/mailman/listinfo/python-list
Re: Why I need to declare import as global in function
Dennis Lee Bieber [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: On 30 Nov 2005 00:58:45 -0800, [EMAIL PROTECTED] declaimed the following in comp.lang.python: yes I have imported math in the file I want to use it. But the imported module math is not visible in function without a global instruction. The code you just posted shows it, yes... My reading of an earlier message seemed to imply you had a nested import chain with the import math at the wrong level... Something like: #file 1 execfile(file 2) #file 2 import math import file_3 #file_3 print math.pi But the solutions already proposed seems to work file for my sample program. I will try on my project soon :) Looking at the documentation for execfile, I can see /how/ the problem occurs -- but can't determine if this can be considered expected. -=-=-=-=-=-=- execfile( filename[, globals[, locals]]) This function is similar to the exec statement, but parses a file instead of a string. It is different from the import statement in that it does not use the module administration -- it reads the file unconditionally and does not create a new module.2.2 -=-=-=-=-=-=- I'm guessing that the intent was only that file 1 not become an entry on the module list, but it seems to be applying ...not create a new module recursively to the imported math... Maybe an expert with the Python byte-code can verify. My hypothesis is something on the order of: Outer (file level) references to math (math.pi) are being handled during the byte-code compilation phase of execfile, so even if math isn't in the module list, it is still in local scope for the outer math.pi... Inner (function) references to math become dynamic look-ups evaluated at function execution; at that point math is not in scope and is not in the module list. Interestingly, I note that is the file calling execfile has imported math (so math is in the module list), the called file works... #no import in run E:\UserData\Dennis Lee Bieber\My Documents\Python Progspython run.py in module: module 'math' (built-in) Traceback (most recent call last): File run.py, line 5, in ? run_ut(ut_00.py) File run.py, line 3, in run_ut execfile(test) File ut_00.py, line 8, in ? f() File ut_00.py, line 5, in f print in function: \t %s % math NameError: global name 'math' is not defined #import is in run E:\UserData\Dennis Lee Bieber\My Documents\Python Progspython run.py module 'math' (built-in) module 'math' (built-in) in module: module 'math' (built-in) in function: module 'math' (built-in) This may be saying what you said, but it seems to depend on where the import occurs: # File: runt2.py def Bobo(): import math execfile( ut_00.py ) b = Bobo() runt2 First access : 3.14159265359 Second access : Traceback (most recent call last): File D:\pyWork\test\runt2.py, line 5, in ? b = Bobo() File D:\pyWork\test\runt2.py, line 3, in Bobo execfile( ut_00.py ) File ut_00.py, line 10, in ? f() File ut_00.py, line 6, in f print \t,math.pi # ERROR NameError: global name 'math' is not defined # File: runt.py import math def Bobo(): execfile( ut_00.py ) b = Bobo() runt First access : 3.14159265359 Second access : 3.14159265359 So the import at the module level of the caller works, but an import at the function level of the caller doesn't. I don't see why the namespace would be significantly different by the time execfile is executed, though it apparently is. -- rzed -- http://mail.python.org/mailman/listinfo/python-list
Re: Why are there no ordered dictionaries?
Fuzzyman [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: Christoph Zwerschke wrote: - the internal keys list should be hidden I disagree. It is exposed so that you can manually change the order (e.g. to create a sorted dict, rather than one ordered by key insertion). What do you *gain* by hiding it ? The internal list should be 'hidden' in the sense that it itself would not be modifiable, though it should be routine to obtain a copy of it at any time. That copy could then be arranged as needed. Any rearrangement of the original list's order destroys the reason for having an entry- or change-ordered dict in the first place. -- rzed -- http://mail.python.org/mailman/listinfo/python-list
Re: about lambda
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote in
news:[EMAIL PROTECTED]:
Shi Mu wrote:
what does the following code mean? It is said to be used in the
calculation of the overlaid area size between two polygons.
map(lambda x:b.setdefault(x,[]),a)
The equivalent of :
def oh_my_yet_another_function_name_why_not_use_lambda(x):
b.setdefault(x,[])
map(oh_my_yet_another_function_name_why_not_use_lambda, a)
Or
for x in a:
b.setdefault(x,[])
Or even:
[b.setdefault(x,[]) for x in a]
The effect of the code is this: if you have b, a dictionary of
values, and a, a list or tuple of indexes to the dictionary, you
can generate a list that will contain just the values associated
with the indices in the list. If the index is not found in the
dictionary, the default value will be used; in this case, that is
an empty list.
So, for example, if you have
b = {'x':1,1:(1,2,3),'arthur':'A string',99:{'j':45,'k':111}}
and a looks like this: you produce this:
a = (0,1,'x') [[], (1, 2, 3), 1]
a = (0,2,3,22) [[], [], [], []]
a = ['x','arthur'] [1, 'A string']
... and so on.
--
rzed
--
http://mail.python.org/mailman/listinfo/python-list
Re: is parameter an iterable?
Steven D'Aprano [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: def foo(inputVal): try: for val in inputVal: # do stuff except TypeError, msg: if msg == iteration over non-sequence: # handle non-iterable case else: # some other TypeError is a bug, so re-raise the exception raise Does this in fact work on your system? On mine (2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)]), it doesn't seem to. I tried if msg.find(iteration over non-sequence) = 0: ... but I got a traceback, and AttributeError: TypeError instance has no attribute 'find' ... which leads me to belive that 'msg' is not type(str). It can be coerced (str(msg).find works as expected). But what exactly is msg? It appears to be of type 'instance', and does not test equal to a string. This is not the least surprise to me. -- rzed -- http://mail.python.org/mailman/listinfo/python-list
Re: is parameter an iterable?
Fredrik Lundh [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: Rick Wotnaz wrote. ... which leads me to belive that 'msg' is not type(str). It can be coerced (str(msg).find works as expected). But what exactly is msg? It appears to be of type 'instance', and does not test equal to a string. it's an instance of the exception type, of course. ::: if you do raise SomeError, value Python will actually do raise SomeError(value) (that is, create a SomeError exception and pass the value as its first argument). you can use either form in your code (I prefer the latter myself). ::: as for catching the exceptions, if you do try: ... except SomeError, v: ... Python will treat this as try: ... except: # some exception occurred typ = sys.exc_type exc = sys.exc_value if issubclass(typ, SomeError): v = exc ... else: raise # propagate! (where typ and exc are internal variables) Thank you (and Roy Smith) for helping to clarify this. I see that my mental image of an Exception (which, I admit, was not based on extensive R'ing of TFM) was way off. Judging by Steven D'Aprano's code sample, I'm not the only one who was mistaken about the nature of v in your example. I'd always assumed it was the human- readable string associated with the TypeError. Wrong, I see. -- rzed -- http://mail.python.org/mailman/listinfo/python-list
Re: Python doc problem example: gzip module (reprise)
Gerard Flanagan [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: Xah Lee wrote: Python Doc Problem Example: gzip [...] A quality documentation should be clear, succinct, precise. And, the least it assumes reader's expertise to obtain these qualities, the better it is. Vast majority of programers using this module really just want to compress or decompress a file. They do not need to know any more details about the technicalities of this module nor about the Gzip compression specification. Here's what Python documentation writers should do to improve it: ⢠Rewrite the intro paragraph. Example: âThis module prov ides a simple interface to compress and decompress files using the GNU compression format gzip. For detailed working with gzip format, use the zlib module.â. The âzlib moduleâ phrase should be linked to its documentation. ⢠Near the top of the documentation, add a example of usage. A example is worth a thousand words: # decompressing a file import gzip fileObj = gzip.GzipFile(/Users/joe/war_and_peace.txt.gz, 'rb'); fileContent = fileObj.read() fileObj.close() # compressing a file import gzip fileObj = gzip.GzipFile(/Users/mary/hamlet.txt.gz, 'wb'); fileObj.write(fileContent) fileObj.close() You want to create the world before which you can kneel: this is your ultimate hope and intoxication. Also sprach Zarathustra. I've managed to avoid reading Xah Lee's diatribes for the most part. Since you included the *WHOLE THING* in your post, I had an opportunity to see what he had to say, and for once I agree with some of it. Some of us learn by example; sometimes an example is all we need to use a particular feature (especially one that we don't often have need for). The criticism that the documentation would be improved by adding some model code is valid for *all* documentation, I think, not just Python's. Typically, when someone proposes changes to documentation to an open source project, someone else will come along and remind everyone that it's all volunteer effort, so why shouldn't the one doing the propopsing be the one to make the change? In the case of documentation, that approach would mean that those who have the least idea of how a module works should be the ones to describe it for everyone else, which seems a little backward to me. The examples should come from those who know what they're doing and they should explain what the example is doing -- just the sort of things a casual user wants to learn quickly. Someone is sure to jump in now and point to sample code, which nearly all reasonably major packages include. That's good stuff. With (for example) wxPython, it's the only useful documentation, or rather, it's the only thing that makes the wxWidgets documentation useful. Links to code samples in the documentation would be fine in lieu of snippets of example calls. But there's not enough of either in most documentation. I would love to see examples for essentially every function and method. And not just something that echoes the signature, but some context to show how it might be useful. That would be in the intoxication class of ultimate hopes. In most cases, though, it would be *extremely* helpful for a casual user of that part of the package. -- rzed -- http://mail.python.org/mailman/listinfo/python-list
Re: convert char to byte representation
Scott David Daniels [EMAIL PROTECTED] wrote in
news:[EMAIL PROTECTED]:
Philipp H. Mohr wrote:
I am trying to xor the byte representation of every char in a
string with its predecessor. But I don't know how to convert a
char into its byte representation.
ord('a') == 97; chr(97) == 'a'; ord gives you the value of the
byte.
e.g. everything between $ and * needs to be xor:
$GPGSV,3,1,10,06,79,187,39,30,59,098,40,25,51,287,00,05,25,
103,44*
to get the checksum.
Probably you want a byte-array here, rather than going
char-by-char. Try:
import array
base = ('$GPGSV,3,1,10,06,79,187,39,30,59,098,'
'40,25,51,287,00,05,25,103,44*')
bytes = array.array('b', base[1 : -1])
for i in reversed(range(len(bytes))):
bytes[i] ^= bytes[i-1]
result = bytes.tostring()
--Scott David Daniels
[EMAIL PROTECTED]
What is the byte representation of 287?
--
rzed
--
http://mail.python.org/mailman/listinfo/python-list
Re: When someone from Britain speaks, Americans hear a British accent...
Mike Meyer [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: Grant Edwards [EMAIL PROTECTED] writes: On 2005-10-06, DaveM [EMAIL PROTECTED] wrote: Frankly, I can't watch Shakespeare or movies like the full monty or trainspotting because I can't understand a damn word they say. British talk sounds like gibberish to me for the most part. Not just you. It always amuses me in trips to the US that British voices (outside of the movies) are often subtitled, while first-generation Americans whose English is. um, limited, are not. What?!? I've never seen a British voice (inside or outside of the movies) subtitled -- with the exception of one of a nightclub scenes in one movie (I think it was Trainspotting) where the dialog was inaudible because of the music. Maybe they were dubbed? I know America International dubbed the first version of Mad Max that they imported into the US. Then again, American International is well-know for their quality. A couple of nights ago, I was amused and amazed to see subtitles during NBC news interviews with some good citizens of Louisiana. I don't know what NBC was thinking. I didn't think the accents were especially thick, either. I had no difficulty understanding the spoken words except in one stretch where background noise obscured some bits. I've certainly heard some New Yorkers with harder-to- understand speech, though without subtitles. I suppose I could be fooling myself in thinking I understood them. -- rzed -- http://mail.python.org/mailman/listinfo/python-list
Re: What is self?
Roy Smith [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: Ron Adam [EMAIL PROTECTED] wrote: You can actually call it anything you want but self is sort of a tradition. That's true, but I think needs to be said a bit more emphatically. There's no reason to call it anything other than self and a newcomer to the language would be well advised to not try and be creative here. Using self is virtually universal, and calling it anything else will just lead to confusion by other people who have to read your code. I've long thought that Guido missed an opportunity by not choosing to use 'i' as the instance identifier, and making it a reserved word. For one thing, it would resonate with the personal pronoun 'I', and so carry essentially the same meaning as 'self'. It could also be understood as an initialism for 'instance'. And, because it is shorter, the number of objections to its existence *might* have been smaller than seems to be the case with 'self' as the convention. And as a side benefit, it would make it impossible to use as a loop index a language feature that would be a huge selling point among a lot of experienced programmers. -- rzed -- http://mail.python.org/mailman/listinfo/python-list
Re: What is self?
Terry Hancock [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: On Friday 23 September 2005 07:11 am, Rick Wotnaz wrote: I've long thought that Guido missed an opportunity by not choosing to use 'i' as the instance identifier, and making it a reserved word. For one thing, it would resonate with the personal pronoun 'I', and so carry essentially the same meaning as 'self'. It could also be understood as an initialism for 'instance'. And, because it is shorter, the number of objections to its existence *might* have been smaller than seems to be the case with 'self' as the convention. And as a side benefit, it would make it impossible to use as a loop index a language feature that would be a huge selling point among a lot of experienced programmers. How exactly is that? Anybody who uses i as a variable name for anything other than an innermost loop index is a sick and twisted code sadist. You'd prefer what? count or kount or i_am_an_innermost_loop_index_counter. I mean explicit is better than implicit, right? Maybe Fortran warped my brain, but I just don't see the benefit here. -- Oh, 'ix' would be fine. Single-letter loop counters are also semi- fine if that is in fact their only use. It too-frequently happens that at some point the handy 'i' identifier is used outside the loop (for another placeholder), and its value is tromped by an intervening loop. Not terribly difficult to discover, but then what? When you're maintaining code, even a two-character index is a *lot* easier to find in source code and replace as needed. -- rzed -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: add sys to __builtins__
Michael J. Fromberger [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: In article [EMAIL PROTECTED], Rick Wotnaz [EMAIL PROTECTED] wrote: You're right that there is no necessity for such a change. I was not actually talking about importing *any* module in every case, but rather about importing, say, 'sys' when, for example, sys.argv appeared in the code and no import had been specified. I think I must have missed that post; I will go back and look at it. However, while I'm here, how would your proposal deal with code like this: import foobar # ... some while later ... def f( ... ): ... global foobar, sys sys = foobar ... # ... some while even later ... f( ... ) sys.wallaby(Fear and loathing!) In particular, we have no import of sys, but the name sys is meaningful as a local alias for a different module. I'm not saying you couldn't deal with this, but it rules out some of the more obvious ways of detecting and automatically handling this kind of substitution. Naturally, you might well ask, why would you do such a fool thing? To this I can only respond: Never underestimate the ingenuity of fools. I don't know that this would cause any particular problem with the [not exactly-]proposed method. The automagic lookup would not be triggered until a NameError occurred, which would not happen in this case. As you say, why would anyone -- at least anyone who wanted to rely on sys.xxx being automatically resolved -- do such a thing? Even under the current scheme, occluding 'sys' would prevent correct interpretation of sys.argv. An error is an error in either case. Now, if 'wallaby' is not part of the foobar namespace, the automagic system would kick in an incorrectly import sys, and on retry would still not find 'wallaby' in the namespace. Much merriment would ensue, I'm sure. At that point, I'd want such a system to have a nervous breakdown and allow the debugging to begin. Whether I hand- entered an import statement or not wouldn't change that. -- rzed -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: add sys to __builtins__
Michael J. Fromberger [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: In article [EMAIL PROTECTED], Rick Wotnaz [EMAIL PROTECTED] wrote: Michael Hoffman [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: What would people think about adding sys to __builtins__ so that import sys is no longer necessary? This is something I must add to every script I write that's not a one-liner since they have this idiom at the bottom: if __name__ == __main__: sys.exit(main(sys.argv[1:])) [...] In short, given the wide use of sys, its unambiguous nature, and the fact that it really is built-in already, although not exposed as such, I think we would be better off if sys were always allowed even without an import statement. +1 here. As far as I'm concerned, both os and sys could be special- cased that way. That said, I would guess the likelihood of that happening is 0. While I'm mildly uncomfortable with the precedent that would be set by including the contents of sys as built-ins, I must confess my objections are primarily aesthetic: I don't want to see the built-in namespace any more cluttered than is necessary -- or at least, any more than it already is. But os is another matter -- the os module contains things which might well not be present in an embedded Python environment (e.g., file and directory structure navigation, stat). Do you really want to force everyone to deal with that? Is it so much more work to add import os to those Python programs that require it? Of course, you might counter why should we force everybody else to type `import os' just in case somebody wants to imbed Python? But then, why don't we just include the whole standard library in __builtins__? Or, since that would be too much, maybe we survey the user community and include the top fifteen most included modules! Where do you draw the line? Do you really want to hard-code user opinions into the language? Right now, we have a nice, simple yet effective mechanism for controlling the contents of our namespaces. I don't think this would be a worthwhile change. -1. You're right that there is no necessity for such a change. I was not actually talking about importing *any* module in every case, but rather about importing, say, 'sys' when, for example, sys.argv appeared in the code and no import had been specified. In another post I go into a little more detail about what I meant, but in any case I did not and do not think it's necessary. I have no problem keying in the import statement and the current system works fine. It could be argued that it would be convenient in the case of quick utility code not to have to import well-known modules explicitly, and it could be argued that 'sys' in particular contains much that is so seemingly fundamental that it could be built in. I'd not argue that it should be split out if it were already built in; it seems to be borderline standard as it is. I suppose it's a C mindset talking, there. When I'm cobbling together a QD script, my routine often involves running it once and then going back in and inserting the single import line that I forgot. It's a minor annoyance, because it seems clear to me that the needed information is actually available to Python when it kicks out its NameError. But it *is* minor, and I am not seriously proposing a change to Python in this regard. -- rzed -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: add sys to __builtins__
Terry Reedy [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: Colin J. Williams [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Rick Wotnaz wrote: +1 here. As far as I'm concerned, both os and sys could be special- cased that way. That said, I would guess the likelihood of that happening is 0. +1 for both. Some people might prefer that math be special cased. Or some other module. A neutral criterion is needed. Actually, I don't think it's beyond reason to suggest that any module included with the standard distribution be special-cased in this way. That is, a reference to xxx.func(), without a previous import of xxx *could* be resolvable automatically, at least for those modules that can be found in a standard location. Whether it's a good idea to do so is another question. Offhand, I am not sure why it would be an insanely poor idea. It would mean some funky namespace building and possibly redundant imports, I guess. I'll certainly defer to just about anybody else's opinion as to the difficulty and advisability, but I believe it would be possible to do. Note that I am not saying that a reference to, say, 'argv' should provoke an automatic import. I don't mean that some automatic search for a matching function name should be done through some undefined module chain. I'm talking only about qualified references, like os.path or sys.stderr. As it is, a NameError is generated if the proper import has not been done. At the point of that error, the module name is known. For the programmer to fix the situation, an import statement has to be added to the code and then the code must be rerun. I don't see why it would be impossible to make that happen automatically, provided the module to be imported was recognized (through some undefined magic). I'd think the module would have to be known, because trying to import a nonexistent module -- import ssy, say (in the event of a typo for sys) -- would fail, so there would have to be a way to avoid looping on the ssy.func() line. Is it worth adding that kind of complexity to execution of a Python program? Probably not. Is it even a good idea to try to make it happen automatically? Possibly not. For one thing, it wouldn't always be the right thing to do. A developer would most likely want to set up the imports properly, and to know when they were not correctly set up instead of having Python fix things quietly. There's a reason why Explicit is better than Implicit. But *could* it be done? I'd think so. -- rzed -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: add sys to __builtins__
Michael Hoffman [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: What would people think about adding sys to __builtins__ so that import sys is no longer necessary? This is something I must add to every script I write that's not a one-liner since they have this idiom at the bottom: if __name__ == __main__: sys.exit(main(sys.argv[1:])) Additionally, the necessity of import sys makes some one-liners a little more unwieldy than they should be--it is surely the module I am missing the most in one-liners. For example, with this proposal, this inelegant one-liner: $ python -c import sys; print ''.join(sorted(sys.stdin.readlines())) could be replaced by: $ python -c print ''.join(sorted(sys.stdin.readlines())) Since sys is surely the most commonly used module (it is imported in 108 of 188 Python 2.4 stdlib modules on my system, and certainly more than any other module), I would hope few people would be affected by a namespace collision. Other languages (e.g. C#) always make their system namespace available without needing a special import. In short, given the wide use of sys, its unambiguous nature, and the fact that it really is built-in already, although not exposed as such, I think we would be better off if sys were always allowed even without an import statement. +1 here. As far as I'm concerned, both os and sys could be special- cased that way. That said, I would guess the likelihood of that happening is 0. -- rzed -- http://mail.python.org/mailman/listinfo/python-list
Re: Bug in string.find; was: Re: Proposed PEP: New style indexing, was Re: Bug in slice type
Bryan Olson [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: Steve Holden asked: Do you just go round looking for trouble? In the course of programming, yes, absolutly. As far as position reporting goes, it seems pretty clear that find() will always report positive index values. In a five-character string then -1 and 4 are effectively equivalent. What on earth makes you call this a bug? What you just said, versus what the doc says. And what are you proposing that find() should return if the substring isn't found at all? please don't suggest it should raise an exception, as index() exists to provide that functionality. There are a number of good options. A legal index is not one of them. Practically speaking, what difference would it make? Supposing find returned None for not-found. How would you use it in your code that would make it superior to what happens now? In either case you would have to test for the not-found state before relying on the index returned, wouldn't you? Or do you have a use that would eliminate that step? -- rzed -- http://mail.python.org/mailman/listinfo/python-list
Re: Reg python nature.
praba kar [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: Dear All, I want to know the link between c and python. Some people with C background use Python instead of programming in C.why? I will now reveal the secret that explains why some people who know how to program in C use Python instead: because they want to. The primary Python implementation is written in C, and makes use of C library functions. C applications are also written in C and make use of C library functions. So *there* is a link. Here are some possible reasons for using Python instead of C: * Some C programmers do not enjoy all aspects of C (such as managing dynamic allocation and deallocation of data structures), and prefer the higher-level abstraction of Python for routine tasks. * Sometimes extremely high performance is not an issue (probably most times), so the language choice becomes one of deciding which is more convenient. Generally, that would be Python. * Systems that must last for long periods of time will often require maintenance, and the clarity of Python code makes it easier to maintain than C equivalents in many cases. The actual code size is often smaller, and making changes requires fewer additional lines of code. This all adds up to a substantial maintenance advantage. * Many programmers use more languages than just one. Python is a good general-purpose language that is quite reasonable to choose as an alternative (or addition) to C. For those coming from a C background, learning the basics of Python syntax is quite easy. Those who have habitually used pseudocode to describe their program concepts may find it even easier to pick up Python. I hope at least one of these points addresses your question. I don't know that your subject line, referring to the nature of Python, is actually very close to the question itself, though. Programmers with a background in any other language will need to reach an understanding of Python's true nature before they can use it comfortably. The same is true when learning any other language; the language's true nature reveals itself with enough use. -- rzed -- http://mail.python.org/mailman/listinfo/python-list
Re: loop in python
km [EMAIL PROTECTED] wrote in
news:[EMAIL PROTECTED]:
Hi all,
Why is it that the implementation of empty loop so slow in
python when compared to perl ?
#i did this in python (v 1.5)
for x in xrange(1000):
print x
# this took 0.017 seconds
--
#similar code in perl (v 5.6):
for $x (0..1000)
{
print $x;
}
# this took 0.005 seconds only !!!
Is python runtime slow at all aspects when compared to perl ?
I really wonder what makes python slower than perl ?
Is there any proposal to make python faster in future versions ?
curious to know all these ...
It appears that Python is not optimized for empty loops.
--
rzed
--
http://mail.python.org/mailman/listinfo/python-list
Where are gui-sig archives?
I was trying to view the gui-sig archives, but when I click on the link (from http://www.python.org/sigs/gui-sig/), I get a Not Found error: The requested URL /pipermail/gui-sig/ was not found on this server. Apache/1.3.33 Server at mail.python.org Port 80 Does anyone have an active link to the archives? -- rzed -- http://mail.python.org/mailman/listinfo/python-list
