Re: Python vs. Lisp -- please explain
Alexander Schmolck wrote: > I wanted to point > out that one could with just as much justification claim CL to be more dynamic > than python (it is in some regards, but not in others -- how to weight them to > achieve some overall "score" is not obvious. I think it's worth pointing out that not all dynamicism is equal, when it comes to difficulty in compiling to machine code. > For example in CL you could just write > > def foo(x, l=[], N=len(l)): [...] Although computing default arguments at call-time vs. define-time is arguably more dynamic, it really doesn't (appreciably) increase the difficulty in creating machine code. I think (see Caveat) that the one major difference between Lisp and Python that has a major bearing on compilability is mutability. Lisp, like the good functional language that it is, has (primarily) immutable values, and minimal side effects. That is, you can make a function that takes in one value, and outputs a different value, but once you have a handle on a value, that value doesn't ever change. That makes it comparatively easy to track value paths, and assign proper machine code to each operation. Python, on the other hand, is mutable to an absurd degree, with reassignments and side effects galore. Even a relatively simple function like: def f(): act(module.value) random_function() act(module.value) can't be (automatically) replaced with the "obvious" equivalent: def f(): mv = module.value act(mv) random_function() act(mv) because of the off chance that random_function() will reassign module.value. Even if you look at random_function(), and rule out a change to module.value, there is always a chance that a some other thread will alter module.value in the mean time. Trivial example, true, but when you figure that you can do the same to any operation or builtin function, the compiler is never quite sure what a particular function will do, what side effects it may have, or what type it will return. In order to be ready for any contingency, a compiled Python program will effectively have to incorporate the entire interpreter. C/C++ gets around the mutability issue by straight-jacketing types & functions. A variable will only contain a particular type (or a subclass), and a function always has a particular signature. Granted, there are ways of doing heavy duty code analysis, and pinning down functions, types, and side effects in Python, and Psyco/PyPy/ShedSkin are making good strides in that regards. But due to the heavy dependency on mutable objects and side effects in Python, such analysis will never be as easy as with Lisp, and considering Python has had less time, and less investment in those areas, it's no wonder that it's only just now seeing progress on the compiler front. * Caveat: I've never seriously programmed in Lisp, and the last time I looked at it was some time ago, with not-up-to-date reference materials. I might be mistaken about the extent of mutability in current versions of Lisp. Hopefully others with more knowledge can give more accurate details of mutability/side effects in Lisp vis-a-vis ease of compilation. -- http://mail.python.org/mailman/listinfo/python-list
Re: can't use NetcdfFile
[EMAIL PROTECTED] wrote: > Hi, > I'm trying to open a Netcdf file using NetcdfFile but I always get an > import error DLL failed > even though I've tried using all these: > > import Numeric > from Scientific.IO.NetCDF import NetCDFFile > from Scientific.IO import NetCDF > from Scientific import * > from Scientific.IO.NetCDF import * Copy & Pasting the exact error message helps tremendously. > > I've got Scientific,Numeric and numpy installed Are you sure you have them installed successfully? How did you install them? (Precompiled or from source, and if so, with which compiler?) IIRC, Scientific doesn't come with the NetCDF, you have to install the NetCDF library separately. (See http://www.unidata.ucar.edu/software/netcdf/ for download.) After installing the NetCDF library, you might need to reinstall Scientific to get it to recognize the NetCDF install. You might also want to check out http://dirac.cnrs-orleans.fr/mmtk_wiki/WindowsInstallation - strictly speaking, it's installation instructions for MMTK, but you can ignore the final steps of installing MMTK, if you want. If you need further help, you can always try a more specific resource, like the MMTK mailing list - http://starship.python.net/mailman/listinfo/mmtk (MMTK is written by the same person (Konrad Hinsen) as Scientific, and depends on Scientific.) -- http://mail.python.org/mailman/listinfo/python-list
Re: That's really high-level: bits of beautiful python
Max wrote:
> But today we were discussing the problem of running externally-provided
> code (e.g. add-on modules). Neither of us knew how to do it in C, though
> I suggested using DLLs. However, I quickly installed python on his
> laptop and coded this:
>
> exec "import %s as ext_mod" % raw_input("Module: ")
> ext_mod.do()
Be careful with this - its fine for developer only use, but I'd avoid it
in production code. You leave the possibility for hackers to try to
import the module named 'os; os.system('rm -rf /'); import', or other
such deviousness.
Probably a better version:
ext_mod_name = raw_input("Module: ")
ext_mod = __import__(ext_mod_name, globals(), locals(), ['__dict__'])
ext_mod.do()
But granted, it's less cool than the original.
P.S. The ", globals(), locals(), ['__dict__']" is there so that the
proper thing is done when you provide the code with a dotted module name.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Mutable numbers
Steve Holden wrote: > fraca7 wrote: > >> The memory allocation for integers is optimized. 'Small' integers >> (between -5 and 100 IIRC) are allocated once and reused. The memory >> for larger integers is allocated once and reused whenever possible, so >> the malloc() overhead is negligible. > > > The first bit's right, the second bit isn't: > > >>> id(12100) > 4604168 > >>> id(121*100) > 4604204 > >>> > FWIW, I read "whenever possible" not as "whenever theoretically possible" but as "whenever the (comparatively simple) interpreter recognizes that reuse is possible". >>> a = 12100 >>> b = 12100 >>> a is b False >>> def f(): a = 12100 b = 12100 c = 121*100 print a is b print a is c >>> f() True False >>> The interpreter, when compiling the function, can recognize that the two constants are identical, and makes them the same object. On the interactive interpreter, or after a computation, the interpreter doesn't bother to check to see if it already has the same value integer object. (It could, but the overhead would likely swamp any savings.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3000 deat !? Is true division ever coming ?
Steven D'Aprano wrote: > Anybody using Python *should* be aware of the division issue. As soon as > they see a division, it is their responsibility to *find out what it > means*. That doesn't require much work: they can scroll up to the > beginning of the module and look at the first few lines. That's not hard. And anyone wanting strict integer division semantics,(and not needing pre-2.2 compatability) should be using the '//' floor division operator anyway. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3000 deat !? Is true division ever coming ?
Gregory Piñero wrote: > On 14 Feb 2006 06:44:02 -0800, [EMAIL PROTECTED] > > >>5./2.=2.5 is floating point math, with all the round off errors that >>incorporates. > > Thanks Curtis, I never knew that trick. I guess for variables do have > true division you have to make them floats? e.g. > float(var1)/float(var2)? Or do you know a less typing approach for > that? Google "python true division" -> I'm feeling lucky: http://www.python.org/doc/2.2.3/whatsnew/node7.html From the web page: """ * By including a from __future__ import division in a module(*), the / operator will be changed to return the result of true division, so 1/2 is 0.5. Without the __future__ statement, / still means classic division. The default meaning of / will not change until Python 3.0. """ *As the first non-docstring/non-comment line. Note that that's for a module -- the interactive interpreter won't respond the same way to the "from __future__ import" statement. -- http://mail.python.org/mailman/listinfo/python-list
Re: how do you pronounce 'tuple'?
Erik Max Francis wrote: > If a 4-tuple is a quadruple, a 3-tuple is a triple, a > 2-tuple is an pair, then I guess a 1-tuple would be a single. Granted > that's not nearly as gruesome enough a name to go with the special > lopsided Pythonic creature mentioned above. I suggest we name it a > hurgledink. +1 QOTW -- http://mail.python.org/mailman/listinfo/python-list
Re: Compiling
Simon Faulkner wrote: > Pardon me if this has been done to death but I can't find a simple > explanation. > > I love Python for it's ease and speed of development especially for the > "Programming Challenged" like me but why hasn't someone written a > compiler for Python? > > I guess it's not that simple eh? The "simple" explanation for the lack of a Python compiler is the massive dynamisism (sp) in Python - since you can change practically everything at any time, in order to compile a generic python program, you have to effectively include the entire interpreter. It's been done before (Python2C was the name, I think), but there wasn't much of a speed-up vs. CPython, and it hasn't been updated to work with recent versions of Python. Recently there has been work on JIT type dynamic compilation techniques, and static compilation of a reduced Python subset. If you want to know more, look up the PyPy project. http://www.codespeak.net/pypy -- http://mail.python.org/mailman/listinfo/python-list
Re: locals() and dictionaries
JerryB wrote:
> Hi,
> I have a dictionary, a string, and I'm creating another string, like
> this:
>
> dict = {}
> dict[beatles] = "need"
> str = "love"
>
> mystr = """All you %(dict[beatles])s is %(str)s""" % locals()
>
> Why do I get
> keyerror: 'dict[one]'?
>
> Is there a way to reference the elements in a dictionary with locals()
> or do I need to create a temp variable, like
>
> need = dict[one]
> mystr = """All you %(need)s is %(str)s"""
1) Avoid variable names like 'dict' and 'str'- they cover up the builtin
names.
2) When showing error, don't retype - cut and paste:
>>> dict[beatles] = "need"
Traceback (most recent call last):
File "", line 1, in -toplevel-
dict[beatles] = "need"
NameError: name 'beatles' is not defined
>>> dict['beatles'] = "need"
>>>
3) In string formating, the item in parenthesis, used as a string, is
the key for the dictionary. That is:
"""All you %(dict[beatles])s is %(str)s""" % ld
is the same as
"""All you %s is %s""" % (ld['dict[beatles]'],ld['str'])
4) Your best bet is not to use locals(), but to create a new dictionary
with the appropriate keys. E.g.:
>>> d = {}
>>> d['beatles'] = "need"
>>> s = "love"
>>> d2 = d.copy()
>>> d2['str'] = s
>>> d['str']
Traceback (most recent call last):
File "", line 1, in -toplevel-
d['str']
KeyError: 'str'
>>> d2['str']
'love'
>>> mystr = """All you %(beatles)s is %(str)s""" % d2
>>> print mystr
All you need is love
--
http://mail.python.org/mailman/listinfo/python-list
Re: Using non-ascii symbols
Ivan Voras wrote: > It's not a far-out idea. I stumbled about a year ago on a programming > language that INSISTED on unicode characters like ≤ as well as the rest > of mathematical/logical symbols; I don't remember its name but the > source code with characters like that looked absolutely beautiful. Could it be APL? http://en.wikipedia.org/wiki/APL_programming_language Although saying it used "Unicode characters" is a bit of a stretch - APL predated Unicode by some 30+ years. -- http://mail.python.org/mailman/listinfo/python-list
Re: beta.python.org content
Paul Boddie wrote: > With the nice font they've used, I don't understand why they didn't > turn the "p" into a snake itself. I'm sure I've seen that done > somewhere before. You're probably thinking of PyPy: http://codespeak.net/pypy/dist/pypy/doc/news.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about isinstance()
Mr.Rech wrote: > All in all it seems that the implementation that uses isinstance() is > better in this case... Well what's "better" depends on what you want to happen when you compare an unrelated class that also defines 'an_attribute'. Unlike in statically typed languages, certain things are made easier when you don't check for strict inheritance (like mock and proxy objects). Google "Duck Typing" for more info. -- http://mail.python.org/mailman/listinfo/python-list
Re: beta.python.org content
Peter Maas wrote: > - The logo does indeed resemble a cross. How about rotating it at 45 deg > to make it look like an x? Or give it a circular shape? Please note > that there are no religious motives in this remark :) It looks like a plus sign to me. Do you also advocate renaming "C++" to "Cxx" or "C (circular shape) (circular shape)"? Also note that if you made it more of a circular shape, it might resemble a Ying-Yang symbol, and we would offend the anti-Daoist programmers. ;-) (Not that I like the logo, mind you. I just think that "looking like a cross" is a poor reason to bash it.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about isinstance()
Dave Benjamin wrote: > On Thu, 26 Jan 2006, Mr.Rech wrote: > >> Suppose I'm writing a base class with an __eq__ special methods, using >> isinstance() I would have wrote: >> >> class foo(object): >>... >>def __eq__(self, other): >> return isinstance(other, type(self)) and self.an_attribute == >> other.an__attribute >> Now, avoiding isinstace() I've written the following code: >> >> class foo(object): >> ... >> def __eq__(self, other): >> try: >> return self.an_attribute == other.an_attribute >> except AttributeError: >> return False > > > You were better off with what you had before. Equality in this case is > left completely open-ended, and as a result, there is no way that you > can guarantee that "a == b" is the same as "b == a" if "a" is a "foo" > and "b" is of unknown type. This can lead to bizarre and unpredictable > behavior. Mind explaining that better? b == a *always* calls b.__eq__(a), if it exists. What a.__eq__(b) is doesn't matter at that point. So you have the same problems either way. The only difference between the two is in the case where b is of an unrelated class and b.an_attribute exists (1). In this case, the first always returns False, and the second returns (a.an_attribute == b.an_attribute). Which you prefer depends on how strictly you adhere to duck typing. (1) To be honest, they also vary when a.an_attribute is undefined. The second always returns False, and the first raises an AttributeError. -- http://mail.python.org/mailman/listinfo/python-list
Re: Using non-ascii symbols
Terry Hancock wrote: > One thing that I also think would be good is to open up the > operator set for Python. Right now you can overload the > existing operators, but you can't easily define new ones. > And even if you do, you are very limited in what you can > use, and understandability suffers. One of the issues that would need to be dealt with in allowing new operators to be defined is how to work out precedence rules for the new operators. Right now you can redefine the meaning of addition and multiplication, but you can't change the order of operations. (Witness %, and that it must have the same precedence in both multiplication and string replacement.) If you allow (semi)arbitrary characters to be used as operators, some scheme must be chosen for assigning a place in the precedence hierarchy. -- http://mail.python.org/mailman/listinfo/python-list
Re: Using non-ascii symbols
Robert Kern wrote: > Rocco Moretti wrote: > > [James Stroud wrote:] > >>>>>I can't find "?, ?, or ?" on my keyboard. >> >>Posting code to newsgroups might get harder too. :-) > > > His post made it through fine. Your newsreader messed it up. I'm not exactally sure what happened - I can see the three charachters just fine in your (Robert's) and the original (Christoph's) post. In Giovanni's post, they're rendered as question marks. My point still stands: _somewere_ along the way the rendering got messed up for _some_ people - something that wouldn't have happened with the <=, >= and != digraphs. (FWIW, my newsreader is Thunderbird 1.0.6.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Using non-ascii symbols
Giovanni Bajo wrote: > Robert Kern wrote: > > >>>I can't find "?, ?, or ?" on my keyboard. Posting code to newsgroups might get harder too. :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: list(...) and list comprehensions (WAS: Arithmetic sequences in Python)
Antoon Pardon wrote:
> Well we could have list(a) return [a], and have a list_from_iterable.
> Although I would prefer a different name.
Or reverse it - list() always takes a single iterable, and
list_from_scalars() is defined something like follows:
>>> def list_from_scalars(*args):
return list(args)
>>> print list_from_scalars(1,2,3)
[1, 2, 3]
>>> print list_from_scalars('a')
['a']
>>>
--
http://mail.python.org/mailman/listinfo/python-list
Re: OT: excellent book on information theory
Alex Martelli wrote: > Terry Hancock <[EMAIL PROTECTED]> wrote: >... > >>due to the Evil Conspiracy of region-coding, I couldn't >>watch the British DVD even if I were to import it (Well, >>yeah I could, but it would be painful, and probably illegal, > > > I have a region-free DVD player here in CA -- N.B.: CA, in addition to being the postal abbreviation for the US state of California, is also the the two-letter country code for Canada. In an international forum such as this, confusion may result, especially as "Legal in California" and "Legal in Canada" are slightly different. -- http://mail.python.org/mailman/listinfo/python-list
Re: making objects unassignable "read-only" (especially when extending)
Johannes Zellner wrote: > Hi, > > can I make an object read-only, so that > > x = new_value > > fails (and x keeps it's orginal value)? Simon gave you a way of doing it when x is an attribute access (e.g. p.x). I am unaware of a way of doing it when x is a straight global or local. Unlike other languages like C, the object pointed to by a variable is in no way involved in the assignment process. Variables are just labels (sticky notes) attached to objects. Assignment is moving of the label - this only involves the interpreter, and the object currently labeled by the variable is not consulted. If you haven't seen it before, http://starship.python.net/crew/mwh/hacks/objectthink.html is a good read. Note that Simon's trick works not because it changes the object pointed to by the variable, but because it changes the properties of the namespace where that variable lives (the p in the p.x). To do so for a local or a global variable would require changing the local & global namespaces - i.e. rewriting the interpreter. -- http://mail.python.org/mailman/listinfo/python-list
Re: Decimal ROUND_HALF_EVEN Default
LordLaraby wrote: > If 'bankers rounding' is HALF_ROUND_EVEN, what is HALF_ROUND_UP? I > confess to never having heard the terms. There was a Slashdot article on rounding a short while back: http://developers.slashdot.org/article.pl?sid=06/01/05/1838214 -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python.org website ?
Roy Smith wrote: > Steve Holden <[EMAIL PROTECTED]> wrote: > >>http://beta.python.org > > All I can say is, "Wow!". If nothing else, it will forever eliminate the > idea that the web site doesn't look professional. It's almost *too* slick. I agree with the "too slick" impression. The "learn why" pictures particularly unnerve me. It looks like a marketing team with a focus group got ahold of the website. Great for reaching the PHB crowd. I'm not sure what J. Random Hacker will think though. -- http://mail.python.org/mailman/listinfo/python-list
Re: Converting milliseconds to human amount of time
Max wrote: > Harlin Seritt wrote: > >> How can I take a time given in milliseconds (I am doing this for an >> uptime script) and convert it to human-friendly time i.e. "4 days, 2 >> hours, 25 minutes, 10 seonds."? Is there a function from the time >> module that can do this? >> >> Thanks, >> >> Harlin Seritt >> > > seconds = millis / 1000 # obviously > > minutes = seconds / 60 > seconds %= 60 > > hours = minutes / 60 > minutes %= 60 > > days = hours / 24 > hours %= 24 > > All this using integer division, of course. This is probably much more > verbose than the tersest soln, but it works (or should do - I haven't > tested it). It's not strictly accurate (from a scientific/UTC > perspective, as some minutes have 59 or 61 seconds rather than 60, but > it's probably the best you need. You'd probably be helped by divmod: >>> help(divmod) Help on built-in function divmod in module __builtin__: divmod(...) divmod(x, y) -> (div, mod) Return the tuple ((x-x%y)/y, x%y). Invariant: div*y + mod == x. >>> def humanize(milli): sec, milli = divmod(milli, 1000) min, sec = divmod(sec, 60) hour, min = divmod(min, 60) day, hour = divmod(hour, 24) week, day = divmod(day, 7) print week, "weeks,", day, "days,", hour, "hours,", \ min, "minutes,", sec, "seconds, and", \ milli, "milliseconds" return (week, day, hour, min, sec, milli) >>> humanize(1234567890) 2 weeks, 0 days, 6 hours, 56 minutes, 7 seconds, and 890 milliseconds (2, 0, 6, 56, 7, 890) >>> humanize(694861001.1) #Also works with floats! 1.0 weeks, 1.0 days, 1.0 hours, 1.0 minutes, 1.0 seconds, and 1.1002384 milliseconds (1.0, 1.0, 1.0, 1.0, 1.0, 1.100238418579) -- http://mail.python.org/mailman/listinfo/python-list
Re: inline function call
Riko Wichmann wrote: > hi everyone, > > I'm googeling since some time, but can't find an answer - maybe because > the answer is 'No!'. > > Can I call a function in python inline, so that the python byte compiler > does actually call the function, but sort of inserts it where the inline > call is made? Therefore avoiding the function all overhead. The cannonical answer is "you probably don't need to do that." If you're still set on inlining functions, take a look at bytecodehacks: http://bytecodehacks.sourceforge.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: One-step multiples list generation?
Damien Wyart wrote: > * Efrat Regev <[EMAIL PROTECTED]> in comp.lang.python: > >>Suppose I have some non-numerical Foo and would like to create a list >>of 20 Foo-s. Is there a one-step method (not a loop) of doing so? > > > Maybe : > > [ Foo ] * 20 > > or, more verbose, > > [ Foo for _ in range(20) ] > If Foo is mutable, keep this in mind: >>> a = [ [] ]*20 # A list of 20 empty lists >>> print id(a[0]) == id(a[1]) True >>> a[0].append(1) >>> print a [[1], [1], [1], [1], [1], [1], [1], [1], [1], [1], [1], [1], [1], [1], [1], [1], [1], [1], [1], [1]] >>> >>> b = [ [] for _ in range(20) ] # A list of 20 empty lists >>> print id(b[0]) == id(b[1]) False >>> b[0].append(1) >>> print b [[1], [], [], [], [], [], [], [], [], [], [], [], [], [], [], [], [], [], [], []] -- http://mail.python.org/mailman/listinfo/python-list
Re: One-step multiples list generation?
Rocco Moretti wrote: > Damien Wyart wrote: > >> * Efrat Regev <[EMAIL PROTECTED]> in comp.lang.python: >> >>> Suppose I have some non-numerical Foo and would like to create a list >>> of 20 Foo-s. Is there a one-step method (not a loop) of doing so? >> >> >> >> Maybe : >> >> [ Foo ] * 20 >> >> or, more verbose, >> >> [ Foo for _ in range(20) ] >> > > If Foo is mutable, keep this in mind: > > >>> a = [ [] ]*20 # A list of 20 empty lists > >>> print id(a[0]) == id(a[1]) > True > >>> a[0].append(1) > >>> print a > [[1], [1], [1], [1], [1], [1], [1], [1], [1], [1], [1], [1], [1], [1], > [1], [1], [1], [1], [1], [1]] > >>> > >>> b = [ [] for _ in range(20) ] # A list of 20 empty lists > >>> print id(b[0]) == id(b[1]) > False > >>> b[0].append(1) > >>> print b > [[1], [], [], [], [], [], [], [], [], [], [], [], [], [], [], [], [], > [], [], []] > Oh, but also: >>> Foo = [] >>> c = [ Foo for _ in range(20) ] # A list of 20 empty lists >>> print id(c[0]) == id(c[1]) True >>> c[0].append(1) >>> print c [[1], [1], [1], [1], [1], [1], [1], [1], [1], [1], [1], [1], [1], [1], [1], [1], [1], [1], [1], [1]] (The difference with the 'b' case is that a new list is created each "time around", in the other cases, the same list is reused. -- http://mail.python.org/mailman/listinfo/python-list
Re: deal or no deal
rbt wrote: > The TV show on NBC in the USA running this week during primetime (Deal > or No Deal). I figure there are roughly 10, maybe 15 contestants. They > pick a briefcase that has between 1 penny and 1 million bucks and then > play this silly game where NBC tries to buy the briefcase from them > while amounts of money are taken away from the list of possibilities. > The contestant's hope is that they've picked a briefcase with a lot of > money and that when an amount is removed from the list that it is small > amount of money not a large amount (I categorize a large amount to be > more than 100,000) Well, if the contestants' choices are truly random, and they stick with their first choice all the way to the end, each contestant wins, on average, $131 477.54 (sum(amounts)/len(amounts)). Assuming that the buyout offer is always less than (or equal to) the average of the still-available amounts, NBC will (on average) never have to pay out more than ~$132k per contestant. Likely they'll pay out less, because most people will get nervous before the very end, and will take the low ball offer NBC is fronting. What I would really like to know, is how they calculate the offer. Obviously, they set the upper limit at the average of the still standing offers, but I wonder if and how they take subsequent rounds into consideration. Is there a "Monty Hall" (http://en.wikipedia.org/wiki/Monty_Hall_problem) type consideration that needs to be taken into effect as cases are eliminated? -- http://mail.python.org/mailman/listinfo/python-list
Re: Guido at Google
Jack Diederich wrote: > On Wed, Dec 21, 2005 at 01:36:42PM -0500, rbt wrote: > >>Alex Martelli wrote: >> >>>I don't think there was any official announcement, but it's true -- he >>>sits about 15 meters away from me;-). >> >>For Americans: 15 meters is roughly 50 feet. > > > Right, so that is about three and a half stone? Stone is a measure of weight, not distance. (14 pounds, ~6.35 kg) 15 meters (150 decimeter, 1500 cm, etc ...) 590 inches 49 feet 16 yards 0.0093 miles 0.008 nautical miles 3 rods 0.075 furlongs 1800 barleycorns 147.63 hands 66 spans 33 cubits 13 ells 8.2 fathoms 75 links 0.75 chains 0.0027 leauges 0.03 li 0.081 stadia 4.8e-16 parsecs 1e-10 astronomical units 5e-8 lightseconds 2.8e11 Bohr radiuses 9.2e35 Plank lenghts and probably most appropriately (being dutch): 1.5 roede In other words "a stone's throw away". -- http://mail.python.org/mailman/listinfo/python-list
Re: Why and how "there is only one way to do something"?
[EMAIL PROTECTED] wrote: > Chris Mellon wrote: > >>Any time you want to write something in any way other than the obvious >>way, ask yourself why? Is it more obvious *to you*, which is a good >>reason as long as you're only writing code for yourself? Or is it just >>to be different, or because you think it'll be faster, or just because >>the slickness of it appeals to you? >> > > The point is again, "obvious" is not so obvious sometimes. You seem to > be assuming that anyone that use style different from you is > intentionally doing it and that your style would first come to their > mind but they don't use it, for the sake of proving that they are > smart. My take on it is that "obvious" is intended to be prescriptive, not descriptive. (Note that in the Zen it is phrased "There *should* be ...".) It describes what Python aspires to, not what it is. If the currently preferred method is not "the one obvious way", steps should be taken to make the preferred way "the obvious way" (i.e. the way that you reach for first, when you want to "do it"). Keep in mind that the Zen was written at a time when there was a certain amount of "Perl vs. Python deathmatch" feeling in the air. That line in the Zen was a reaction to Perl's "There's more than one way to do it (TMTOWTDI)." Perl took the view that flexibility was a virtue to be praised above all others, and allows and encourages (or at least used to) different ways of doing things. I don't think a syntactic construct was excluded from Perl for the sole reason "well, we already can do that with this construct ..." Python, in part due to a backlash to the Perl philosophy, emphasized clarity and readability. There are *many* constructs which have been excluded from Python just because they weren't any clearer than what is already in the language. (Once a language is "Turing complete", anything you can program a computer to do, you can use that language to do. There is no guarantee that it's short or pretty, though.) That's what the "one obvious way" refers to - the clearest, most readable way of expressing what you want to accomplish. In this "obviousness", there is (often) little consideration for what other languages you previously might have used, or might be trying to drag idioms from. As an absurd analogy, if you were born and grew up in a country with a crazed totalitarian leader who, under penalty of death, made you turn around three times while hopping and whistling the national anthem before you sat down for dinner, it might be "obvious" to you that one must turn around three times, hopping and whistling before sitting down for dinner. However, if you move out of that country to, say, the Netherlands, for instance, you no longer need to hop-whistle-turn, and your new countrymen will look at you strangely if you do. That's not to say you can't hop-whistle-turn if the fancy strikes you, but in any practical setting, people will expect you do the simple, "obvious" thing -- just sit. BTW. People who are quick to bring up the Zen (and I'm as guilty as others at times) should also keep in mind that the Zen is found under the *humor* section of the Python website. It's not an actual design document, it's just a surprisingly intuitive description of Python's nature. -- 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: 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: 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: 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: 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: 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: 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: 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: 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: [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: 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: 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: 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: 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
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: 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: [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: 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: 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: 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
[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:
> 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: 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: 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: 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: 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: 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: [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: 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: 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: 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?
[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: 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: 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: 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: 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: 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: '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: '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: 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: 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: 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: 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: 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
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: 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
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)
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)
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: 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: 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: 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...
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: 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: 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: 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: 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
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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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?
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
