🌐 Mailman 3 December 2000 - Python-list - python.org

Re: Python vs. PHP (& Java?)
by claird＠starbase.neosoft.com Dec. 31, 2000

Dec. 31, 2000

In article <mailman.978059571.14515.python-list(a)python.org>, Moshe Zadka <moshez(a)zadka.site.co.il> wrote: . . . >> Isn't there an axiom in physics that an experimenter influences the >> outcome of his experiment (physicists, help me out here)? > >Widely overused by laymen. >It says that in *some* experiments, measuring one quantity *has* to >interfere with another quantity some specified amount. . . . It's such a beautiful result as to be worth expression in more suggestive language: cer- tain measurements are in a dual relationship, one manifestation of which is that there is a precise lower bound on the accuracy of their *simultaneous* determination. The analytic form of this leads immediately to the mathematics of, for example, signal com- pression or image enhancement. Metaphoric application to macroscopic phenomena is, as Moshe notes, often overdone. -- Cameron Laird <claird(a)NeoSoft.com> Business: http://www.Phaseit.net Personal: http://starbase.neosoft.com/~claird/home.html

3 2

Re: Python vs PHP (& Java?)
by tim＠degree.ath.cx Dec. 31, 2000

Dec. 31, 2000

Ben Ocean <zope(a)TheWebsons.com> wrote: > I'm an intermediate-level programmer that's new to Python (via Zope) and I > like it a lot. However, it appears to me that, while Python is a good > replacement for Perl, it cannot replace much of the functionality of PHP, > which can be scripted into HTML (whereas Python, it appears, must be > called). Ok, everyone else made very good points, but this little comment slipped out (not that I'm surprised, honestly) =) There is no "replacement for Perl!" And Python would do a poor job trying to be Perl (and vice versa), nor does anyone here seem to _want_ Python to be/replace Perl. Let me paraphrase: Perl is Perl and should remain Perl. Python is Python and should remain Python. Java is long-winded and...um, "pragmatic" and should be given a fair shot. PHP is crap and should be left to those to don't want control over their scripts. (Ok, this last one was significantly biased; did ya notice?) Just my $.02. =) And Ben: don't leave language choices up to others...unless "others" are your boss, of course. Research the languages, not just hearsay. -- -Tim Hammerquist <timmy(a)cpan.org> I am opposed to millionaires, but it would be dangerous to offer me the position. -- Mark Twain

4 4

RE: 2001 Enchancement Wishlist
by Pearu Peterson Dec. 31, 2000

Dec. 31, 2000

On Sun, 31 Dec 2000, Tim Peters wrote: > [Pearu Peterson] > > ... > I bet it can't be handled that way in Python 42.0 either <0.41 wink>: on > the very face of it, the only *sensible* thing for a NonZeroInteger > constructor to do when handed a 0 is to raise ValueError -- else its name > lies about the nature of the thing it's constructing. > > Guido has Pronounced on this in the past: a class constructor creates an > instance of the class, end of story. It's a little bit of semantics people > can and do rely on. For example, you didn't show any other methods of your > NonZeroInteger class, but let's say it had a method xxx. Then any Python > programmer can rely on that > > y = NonZeroInteger(anything_at_all) > y.xxx() > > won't blow up with an AttributeError on "xxx", and without doing dynamic > type checks etc first. Ok, the given NonZeroInteger was a bad example. I was quietly assuming that whatever __init__ returns, has the same attribute set as NonZeroInteger, that is, all these classes are derived from some parent class (as you suggested also below). Anyway, if __init__ returning is 'out', then what about class methods that Gareth McCaughan suggested earlier. How 'out' or 'in' would that solution be? > There's nothing wrong with writing a factory function that can return > objects of different classes. It often makes code using them harder to work > with, though, and precisely because you *don't* know what pops out of them > in the absence of further type checks (however spelled). I am willing to take that risk if it will reduce code considerably. It is just a matter of whether a code developer is able to write consistent code, whatever tricks are used. > > c = Plus(a) -> c = a # c is Symbol instance > > > > ***lots of code*** could be avoided with rich Plus.__init__ that would > > return in this case Symbol instance a. > > Wouldn't your "rich Plus.__init__" contain about as much code as a factory > function would today? Both have to consider all the same cases. A factory > function would get to omit the often-useless "self" argument, though <0.9 > wink>. No. The code would be cleaner in various parts. And it would be also faster. And all that because of there would be no need to bother whether an object is in its minimal representation. Examples of minimal representations: Plus(5) is mpz(5) Plus(a) is a Plus(a,b) is Plus(a,b) etc > I suggest you're off track in your modeling, confounding roles that should > be distinct: that of Plus as a function and Plus as an object (representing > an only partially evaluated sum). In this case I'd probably have a base > class Expression for all kinds of expresssions (incl. atoms like Symbols), > make Plus a function mapping zero or more Expressions (or subclasses) to an > Expression (or subclass), and make Sum a subclass of Expression that > represents a partially evaluated sum. Yep. That's exactly how I have modeled it in PySymbolic (though with a bit different naming convention but at least I am not too much off the track;-). > That's the way I *think* of the > domain, so that's the way I'd want to code it (and, no, I'm not bothered by > having to come up with distinct names for the verb sense (Plus) and the noun > sense (Sum) -- the distinction between nouns and verbs is usually helpful!). Just for information: There is a difference between Plus and Sum: Plus - is a sum of Symbols, where the number of Symbols is *always defined and fixed*. E.g. Plus(a,b,c) is a+b+c Sum - is a sum of Symbols, where the number of Symbols is *not defined*, in general. E.g. Sum(n*n,n=[0,m]), where m is arbitrary integer. And Plus will be used only internally in PySymbolic. Actually it just represents operation symbol `+', not the verb `plus'. > symbolic-math-would-be-useless-if-we-always-wanted-the-verb- > form<wink>-ly y'rs - tim Thanks, Pearu

1 0

os module - reliable?
by curtissol＠my-deja.com Dec. 31, 2000

Dec. 31, 2000

I am writing exercise 1 pg 212 of "Learning Python". It asks for a program that prints out the names of all files in a specific directory and all its subdirectories. The code I have seems relatively straight forward: import os, sys import os, sys def ShowDirContents(dir): contents = os.listdir(dir) for file in contents: if os.path.isdir(file): ShowDirContents(file) else: print file if __name__ == "__main__": ShowDirContents(os.getcwd()+"\Doc") However, the test if os.path.isdir(file): seems to only recognize some of subdirectories of "...Python20\Doc". Those that are recognized it handles just fine. Those it does not recognize, it simply treats as files. Also, as you may know, the "Doc" directory contains a subdirectory called 'doc'. When the code sees this, it goes into an infinite loop only outputing some of files in Doc before it enters 'doc' again. This behavior goes away if I change the name of the subdirectory 'doc'. How reliable are the os and os.path modules? I am running Python 2.0 with NT 4.5 on a PC. Windows NT Explorer shows a number of directories (folders) that the 'if' test shown above misses. Thanks Sent via Deja.com http://www.deja.com/

3 2

Tkinter: title oddity
by Dan Underwood Dec. 31, 2000

Dec. 31, 2000

root.title('my nice title') and root.title(string='my nice title') produce the same result... but someOtherToplevel.title('my nice title') works ok but someOtherToplevel.title(string='my nice title') gets the message: unexpected keyword 'string' Did I do it wrong, or is this a known inconsistency? Thanks. Dan.

2 1

What happened in this class
by Emile van Sebille Dec. 31, 2000

Dec. 31, 2000

I saw Pearu's lazy extension and built and installed it on my linux system(recent cvs). I thought I'd see how it played in a class vs getattr and got this result. Thinking something broke along the way, I then switched over to the win95 system(2.0 #8), and got the same thing. This doesn't happen under 1.52. class test: def __getattr__(self, name): return "egs" t = test() print dir(t)[1:5] ['e', 'g', 'g', 's'] Now I know this is contrived, but I still didn't expect these results. Should I have? -- Emile van Sebille emile(a)fenx.com -------------------

2 1

RE: Python vs. PHP (& Java?)
by rturpin＠my-deja.com Dec. 31, 2000

Dec. 31, 2000

On Thu, 28 Dec 2000, Kemp Randy-W18971 <Randy.L.Kemp(a)motorola.com> wrote: >> Could we argue that an artificial language, such as >> Esperanto, is better to use around the world then a >> natural language, like English? In article <mailman.978059571.14515.python-list(a)python.org>, Moshe Zadka <moshez(a)zadka.site.co.il> wrote: > Yes. I think this would be wonderful, except political > constraints dictate otherwise. The greatest problem is cultural inertia. Knowledge of their primary tongue is most people's major intellectual and social asset. The cost of changing this is high, especially since language is best learned at a young age. Few would acquire as great proficiency in a new tongue, regardless of its technical advantage. Looking at something where the stakes are much less, the benefit for each individual more clear, and the new skill is easily learned, cultural inertia STILL wins out over better notation. No one claims that the QWERTY keyboard is technically superior to the Dvorzak. I suspect, though, that the QWERTY keyboard will remain the major character input device for the next two or three decades. (Before thinking that voice recognition will knock it out soon, see how long your throat lasts speaking ten pages of text. Twice, with edits.) Russell Sent via Deja.com http://www.deja.com/

2 1

Re: HTML Parser
by Fredrik Lundh Dec. 31, 2000

Dec. 31, 2000

HTML ParserDenis Voitenko wrote: > I am trying to write an HTML parser. I am starting off with a simple > one like so: There's already an HTML parser in the standard library. If you want to render HTML (e.g. to plain text), check out the htmllib module. If you want to process HTML (filtering tags, etc), it's usually easier to use the sgmllib module. For examples, search for "sgmllib" and "htmllib" on deja.com (or check my library guide). If you still insist on writing your own, check the "sgmllib.py" sources. It's harder than you think. </F>

1 0

SMB Module
by mballen＠erols.com Dec. 31, 2000

Dec. 31, 2000

I frequent the Samba mailing list. A couple of days ago Richard Sharp put together an smbclient.so library of client functions for SMB. SMB is Microsoft's native file and print sharing protocol. Someone wrote a Perl module using it. I just thought one of you guys might want to do the same for Python. Seems only natrual since there's a nice little library all packaged up with open(), read(), write(), ...etc all setup easy like. Mike -- signature pending

1 0

Solution: Re: Lazy Python usage (hack request) (fwd)
by Pearu Peterson Dec. 30, 2000

Dec. 30, 2000

For some reasons this message did not show up in c.l.p. But here it is. ---------- Forwarded message ---------- Date: Sun, 31 Dec 2000 02:56:00 +0200 From: Pearu Peterson <pearu(a)cens.ioc.ee> Newsgroups: comp.lang.python Subject: Solution: Re: Lazy Python usage (hack request) Hi again, I have implemented a Python C/API module `lazy' that you can use to put a Python dictionary to a "lazy" mode. You can find the lazy module in http://cens.ioc.ee/~pearu/misc/lazy-0.1.tar.gz Here is a Python session showing lazy in action: >>> import lazy >>> d = {'a':4} >>> lazy.set(d,lambda k:3) # set d to lazy mode >>> print d {'_lazy_cb': <function <lambda> at 0x8112e24>, 'a': 4} >>> d['b'] 3 >>> print d {'_lazy_cb': <function <lambda> at 0x8112e24>, 'b': 3, 'a': 4} >>> del d['_lazy_cb'] # disable lazy mode >>> d['c'] Traceback (most recent call last): File "<stdin>", line 1, in ? KeyError: c And another example: >>> import lazy >>> def fun(k): ... print 'Creating variable %s'%(`k`) ... return k ... >>> lazy.set(locals(),fun) >>> print a+b+c Creating variable 'a' Creating variable 'b' Creating variable 'c' abc >>> print lazy.set.__doc__ lazy.set(dict,func) - set dictionary dict to a "lazy" mode with a callback function func. "lazy" mode means that the following statement dict[<name>] = func(<name>) is executed whenever dict has no key <name>. WARNING: if dict is set to "lazy" mode, dict.has_key(<name>) returns always 1 and dict[<name>] is set to func(<name>). To disable the "lazy" mode for dict, do del dict['_lazy_cb'] Be lazy and have fun!-) Pearu

1 0