Re: email module, redirecting to stdout
In article <[EMAIL PROTECTED]>,
Peter Otten <[EMAIL PROTECTED]> wrote:
> Laszlo Zsolt Nagy wrote:
>
> > I have this code:
> >
> > s = smtplib.SMTP()
> > s.set_debuglevel(1)
> > s.connect(host=smtp_host)
> > s.set_debuglevel(0)
> > log("Connected, sending e-mail")
> > sys.stdout.flush()
> > s.sendmail(
> > consts.EMAIL_FROMADDRESS,
> > [to],
> > msg.as_string()
> > )
> > log("E-mail sent OK")
> > s.quit()
> >
> > The problem is that whenever I set the debuglevel to 1, messages will go
> > to stderr. I would like them to go to stdout. Using
> >
> > sys.stderr = sys.stdout
> >
> > has no effect. Redirecting stderr to stdout from the shell is not an
> > option for me, because I need to use stderr for other messages.
>
> smtplib obtains a copy of stderr by
>
> from sys import stderr
>
> Therefore you have to do
>
> smtplib.stderr = sys.stdout
>
> to get the desired effect.
Ouch. I'd consider this a bug. "from sys import stderr" should at least
be considered bad style.
Just
--
http://mail.python.org/mailman/listinfo/python-list
Re: Using printf in a C Extension
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: > I am extending python with C and trying to debug with printf. The code > below succssfully returns the string "hello" when compiled and called, > but the "can print from in here phrase" does not reach python stdout. > Is there something screwy with my environment or is there some trick to > this that I don't know. Any help would be greatly appreciated! Have a look at PySys_WriteStdout(). Just -- http://mail.python.org/mailman/listinfo/python-list
Re: Rebinding stdout (was: Re: Python! Is! Truly! Amazing!)
In article <[EMAIL PROTECTED]>, JanC <[EMAIL PROTECTED]> wrote: > Something like this: > > py> import cStringIO > py> import sys > py> > py> def foo(): > ... print "test" > ... > py> f = cStringIO.StringIO() > py> sys.stdout = f > py> foo() > py> s = f.getvalue() > py> sys.stdout = sys.__stdout__ You should always save stdout instead of using __stdout__. It may not be the same! I don't think anyone should *ever* use __stdout__ except when debugging. See also: http://mail.python.org/pipermail/python-dev/2000-October/010144.html > py> f.close() > py> print s.capitalize() > Test Just -- http://mail.python.org/mailman/listinfo/python-list
Re: Rebinding stdout (was: Re: Python! Is! Truly! Amazing!)
In article <[EMAIL PROTECTED]>, Simo Melenius <[EMAIL PROTECTED]> wrote: > I've sometimes replaced sys.stdout (and/or sys.stderr) to > capture/redirect debugging information in existing code that has > unwisely just "print"ed error and warning messages, instead of using > sys.stderr or error logging modules. > > py> def with_output_to_string (func): > ... try: > ... sys.stdout = StringIO.StringIO () > ... func () > ... return sys.stdout.getvalue () > ... finally: > ... sys.stdout = sys.__stdout__ Aargh, I can't believe how widespread this idiom is :-(. See my other reply in this thread: DON'T use sys.__stdout__. Ever. Just -- http://mail.python.org/mailman/listinfo/python-list
Re: how to stop google from messing Python code
In article <[EMAIL PROTECTED]>, "Xah Lee" <[EMAIL PROTECTED]> wrote: > i'm using groups-beta.google.com to post python code. > > Is there a way to stop google from messing with my format? it seems to > have eaten the spaces in my python code. It does that when you cross-post. Just -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie inheritance question.
In article <[EMAIL PROTECTED]>, Ed Leafe <[EMAIL PROTECTED]> wrote: > On Jan 16, 2005, at 9:08 AM, bwobbones wrote: > > > class two(one): > >def __init__(self): > >print "two" > > You need to specifically call the superclass's __init__ here in order > for it to fire. Just add the line > > super(two, self).__init__() > > as the first line of the subclass's __init__. super() only works for new-style classes, ie. class one needs to derive from object for this to work. Just -- http://mail.python.org/mailman/listinfo/python-list
Re: (objects as) mutable dictionary keys
In article <[EMAIL PROTECTED]>, Peter Maas <[EMAIL PROTECTED]> wrote: > Antoon Pardon schrieb: > > Dictionary lookup with mutable types like lists is a source of > > unpleasant surprises for the programmer and therefore impossible in > > Python. > > > > > > It is not impossible in Python. Is too. > > It may be discouraged but it is not > > impossible since I have already done so. > > Wouldn't this raise a TypeError? Or did you wrap them with an object? He created a list subclass that redefines __hash__, so he cheated :). Just -- http://mail.python.org/mailman/listinfo/python-list
Re: lambda
In article <[EMAIL PROTECTED]>, Antoon Pardon <[EMAIL PROTECTED]> wrote: > Op 2005-01-17, Steve Holden schreef <[EMAIL PROTECTED]>: > > There you go with the minutiae again. How about: > > > > "Don't use mutables as hash keys"? > > That sounds too dogmatic to my ears. I also find it > too selective. The problem with mutables as dictionary > keys is not specific to dictionaries. Everywhere you > have mutables in a container, it is possible that > mutating the object in the container will cause > problem. The main difference is: if you mutate a dict key you *always* have a problem. So don't do that. Mutating (say) a list item *only* is a problem if you (say) need that list to remain sorted. Lists don't magically remain sorted, so people generally sort it before they do some operation that expects a sorted list. > Heck even using mutables as arguments can > cause trouble. Why else the specific advice against > > def foo(p = []) > > type of arguments. So should we adopt the principles: > > Don't use mutables in containers Nonsense. > Don't use mutables as default values for parameters That's good advice in general. > Don't use mutables as arguments. Nonsense. > Don't assign one mutable to an other. Nonsense. Some newbies get surprised by Python's assignment-doesn't-copy semantics, but it's such basic knowledge (as well as a useful feature) that I simply don't understand you saying this. > I don't see a big difference between these principles > and the hash key principle, Than you haven't looked hard enough. > so in the end may be we > should just stick with the more general principle: > > Don't use mutables! > > > and be done with it. Ok, so you're indeed a troll. Just -- http://mail.python.org/mailman/listinfo/python-list
Re: lambda
In article <[EMAIL PROTECTED]>,
Antoon Pardon <[EMAIL PROTECTED]> wrote:
> >> I don't see a big difference between these principles
> >> and the hash key principle,
> >
> > Than you haven't looked hard enough.
>
> All of these can get unexpected behaviour because of the
> assignment-doesn't-copy semantics. The same semantics
> that can cause problems if you work with mutable dictionary
> keys.
Again, the difference is:
1. assigning mutable objects *can* cause unexpected behavior
(however, it's a useful feature, everyone using Python
for longer than a day or two knows this, and then it's
*expected* behavior.
2. mutating dict keys *does* *always* cause problems.
(unless you use an identity hash/cmp)
It's nonsense to forbid 1) since it's a useful feature. It's useful to
forbid ("discourage") 2) since mutating dict keys is seldom useful (and
when it is, Python lets you support it in your own objects).
Just
--
http://mail.python.org/mailman/listinfo/python-list
Re: Dictionary keys (again) (was Re: lambda)
In article <[EMAIL PROTECTED]>,
Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
> > A rule of thumb is context sensitive. If circumstances change,
> > so do the rules of thumb. Principles have a broader field
> > of application.
> >
> > IMO there is nothing principally wrong with using a mutable object
> > as a dictionary key. But avoiding doing so is a good rule of
> > thumb if you have a python-like implementation of a dictionary.
>
> For a 'mutable key' to make sense, the following:
>
> lst = []
> dct = {l: "Hi!"}
> print dct[[]]
> print dct[lst]
> lst.append(1)
> print dct[[1]]
> print dct[lst]
>
> Should print:
> Hi
> Hi
> Hi
> Hi
>
> That's completely impractical though - for any sane implementation, at least
> one
> of the above print statements will throw a KeyError.
>
> Your example of a 'safe_dict' that copies mutable keys means that the final
> print statement is the one that fails.
>
> My suggestion of an "identity_dict" means that both of the same-value based
> lookups would fail.
>
> Notice that both of these approaches take a mutable key and make it immutable
> (either by holding the sole reference to a copy, or retrieving an immutable
> property of the mutable object).
>
> There's also your solution of "I promise not to mutate the key while it is in
> the dictionary". Workable, but opens the door to some entertaining bug hunts
> when the promise is broken.
>
> Which solution is the best default behaviour?
>
> Well, the Zen of Python states "In the face of ambiguity, refuse the
> temptation
> to guess".
>
> So that's the policy the builtin dict follows - it doesn't try to guess when
> to
> make a copy, or whether or not to use identity based semantics in the face of
> mutability. Instead, it raises an exception at key entry time, asking the
> programmer to clarify their intent.
>
> The principle is *certainly* that hash tables should contain immutable keys.
> Your own 'safe_dict' example implicitly concedes this point by making copies
> 'when required'. 'When required' for what? When required to preserve
> immutability, perhaps?
>
> In short, sane hash tables require immutable keys, and how mutable keys
> acquire
> the requisite immutability is going to be application dependent.
>
> Provision of a safe_dict or identity_dict would merely allow a programmer to
> state their intent at the time the container is created, rather than having
> to
> state it whenever keys are generated or referenced.
FWIW, the Cocoa framework on OSX supports mutable objects as keys.
However, it makes an immutable copy. This is cheap for immutable objects
-- Cocoa has both a mutable array as well as an immutable array,
likewise for dicts -- since the "copy" will then simply be the same
object. Thanks to PyObjC we can explore this from Python:
Python 2.3 (#1, Sep 13 2003, 00:49:11)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from Foundation import *
>>> lst = []
>>> dct = NSMutableDictionary.alloc().init()
>>> dct
{}
>>> dct[lst] = "Hi!"
>>> dct
{(1) = "Hi!"; }
(Note that Python lists get wrapped as native Cocoa arrays. '(1)' is
Cocoa's repr for the wrapped array.)
>>> dct[lst]
u'Hi!'
>>> lst.append(1)
>>> dct[lst]
Traceback (most recent call last):
File "", line 1, in ?
File
"build/lib.darwin-7.6.0-Power_Macintosh-2.3/objc/_convenience.py", line
77, in __getitem__objectForKey
KeyError: [1, 1]
>>> dct.keys()
((1))
>>> dct[[1]]
u'Hi!'
>>> k = dct.keys()[0]
>>> k
(1)
>>> k.append(2)
Traceback (most recent call last):
File "", line 1, in ?
File
"build/lib.darwin-7.6.0-Power_Macintosh-2.3/objc/_convenience.py", line
205, in
objc.error: NSInternalInconsistencyException - *** -[NSCFArray
addObject:]: mutating method sent to immutable object
>>>
This is not all that different from Python actually, in that Cocoa tries
very hard to make it impossible to mutate dict keys.
Just
--
http://mail.python.org/mailman/listinfo/python-list
Re: Hey, get this! [was: import from database]
In article <[EMAIL PROTECTED]>, Steve Holden <[EMAIL PROTECTED]> wrote: > Just to make things simpler, and (;-) to appeal to a wider audience, > here is a program that doesn't use database at all (it loads the entire > standard library into a dict) and still shows the error. > > What *I* would like to know is: who is allowing the import of bsddb.os, > thereby somehow causing the code of the os library module to be run a > second time. [ ... ] Maybe this?: > if package: > module.__path__ = sys.path I'm fairly sure this should read module.__path__ = ["*db*"] Just -- http://mail.python.org/mailman/listinfo/python-list
Re: XML with Unicode: what am I doing wrong?
In article <[EMAIL PROTECTED]>,
"Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
> > I started out working in the context of elementtidy, but now I am
> > running into trouble in general Python-XML areas, so I thought I'd toss
> > the question out here. The code below is fairly self-explanatory. I have
> > a small HTML snippet that is UTF-8 encoded and is not 7-bit ASCII
> > compatible. I use Tidy to convert it to XHTML, and this particular setup
> > returns a unicode instance rather than a string.
> >
> > import _elementtidy as et
> > from xml.parsers import expat
> >
> > data = unicode(open("snippetWithUnicode.html").read(), "utf-8")
> > html = et.fixup(data)[0]
> > parser = expat.ParserCreate()
> > parser.Parse(html)
> >
> > UnicodeEncodeError: 'ascii' codec can't encode character '\ub5' in
> > position 542: ordinal not in range(128)
> >
> > If I set my default encoding to utf8 in sitecustomize.py, it works just
> > fine. I'm thinking that I can't be the only one trying to pass unicode
> > to expat... Is there something else I need to do here?
>
> you confuse unicode with utf8. Expat can parse the latter - the former is
> internal to python. And passing it to something that needs a string will
> result in a conversion - which fails because of the ascii encoding.
>
> Do this:
>
> parser.Parse(html.encode('utf-8'))
Possibly preceded by
parser = expat.ParserCreate('utf-8')
..so there's no confusion with the declared encoding, in case that's not
utf-8.
Just
--
http://mail.python.org/mailman/listinfo/python-list
Re: Hash of class from instance
In article <[EMAIL PROTECTED]>, "Joakim Storck" <[EMAIL PROTECTED]> wrote: > So I guess it might be a little bit less unwise to use id() instead > then... Why don't you use the class objects themselves as dict keys? Just -- http://mail.python.org/mailman/listinfo/python-list
Re: Reinstall python 2.3 on OSX 10.3.5?
In article <[EMAIL PROTECTED]>, Robert Kern <[EMAIL PROTECTED]> wrote: > Christian Dieterich wrote: > > On Dé Céadaoin, Feabh 2, 2005, at 17:48 America/Chicago, > > [EMAIL PROTECTED] wrote: > > > >> Hi there > >> > >> I started a very long and roundabout process of attempting to install > >> python 2.3.4 along side my apple-installed 2.3 system. To make a long > >> story short, I have completely confabulated my environment ( i deleted > >> the 2.3 binaries and so forth from the system in an attempt to start > >> things fresh), and now I cannot figure out how to reinstall the base > >> 2.3 Apple python distribution. > >> Can somebody please point me in the right direction? > > > > > > You could use > > fink install python > > which makes you a Python installation under /sw. > > But that doesn't solve his problem, which is to restore the > Apple-supplied Python that he deleted. Also: fink is evil. I wouldn't touch it with a ten-foot pole. Just -- http://mail.python.org/mailman/listinfo/python-list
Re: Easy Q: dealing with object type
In article <[EMAIL PROTECTED]>, Steven Bethard <[EMAIL PROTECTED]> wrote: > Erik Johnson wrote: > > "Erick" <[EMAIL PROTECTED]> wrote in message > > news:[EMAIL PROTECTED] > > > >>Ah, you're running into the "old-style classes vs. new style classes". > >>Try subclassing from "object". > >> > >>For example: > >> > >>>>>class A(object): > > > > That works! :) I guess I am fortunate to be running 2.2 - looks kinda ugly > > prior to that. > > It's not horrible: > > py> class A: > ... pass > ... > py> class B: > ... pass > ... > py> a = A() > py> a.__class__ == A > True > py> a.__class__ == B > False Uh, isinstance(a, A) works for both new-style and old-style classes. Heck, isinstance() even works in Python 1.5.2... > Still, if you can use new-style classes, you should. > > Also, you should probably Google for "duck typing". Generally, in > Python it is frowned upon to check the type of an object. There are > times when it's necessary, but if you're just starting off, my guess is > that you haven't discovered one of these times yet... Just -- http://mail.python.org/mailman/listinfo/python-list
Re: Generating .pyc/.pyo from a make file
In article <[EMAIL PROTECTED]>, vincent wehren <[EMAIL PROTECTED]> wrote: > Tim Daneliuk wrote: > > Steve Holden wrote: > > > >> Roland Heiber wrote: > >> > >>> Tim Daneliuk wrote: > >>> > > Aha! Exactly ... and that makes perfect sense too. D'oh! I guess a > > better > > distribution strategy would be to have the installation program generate > > the pyo > > file at installation time... > > > > Thanks - > > Also, the *.py? files contain the full pathname of the *.py they have > been compiled from. True. > Copying them to other path locations will give you > the wrong __file___ information in tracebacks. This is not 100% accurate: yes, the traceback shows the original source file path, yet module.__file__ does point to the actual .pyc file it was loaded from. Just -- http://mail.python.org/mailman/listinfo/python-list
Re: Hey, get this!
In article <[EMAIL PROTECTED]>, Bernhard Herzog <[EMAIL PROTECTED]> wrote: > Bernhard Herzog <[EMAIL PROTECTED]> writes: > > > Steve Holden <[EMAIL PROTECTED]> writes: > >> if package: > >> module.__path__ = sys.path > > > > You usually should initialize a package's __path__ to an empty list. > > Actually, normally it's a list that contains the name of the package > directory as its only item. I'm not sure what you should do when you do > not import from a file system. If it's a path importer, it could be a cookie, specific to the importer. I think in Steve's case initializing __path__ to ["*db*"] should work. Just -- http://mail.python.org/mailman/listinfo/python-list
Re: Hey, get this!
In article <[EMAIL PROTECTED]>,
Steve Holden <[EMAIL PROTECTED]> wrote:
> > If it's a path importer, it could be a cookie, specific to the importer.
> > I think in Steve's case initializing __path__ to ["*db*"] should work.
> >
> > Just
>
> And that's exactly the conclusion I came to when import of the package's
> submodules didn't work as anticipated.
>
> Coming to the question of writing a customer importer from the
> documentation I discovered there is a huge amount of layered cruft in
> the import scheme going all the way back to the days of the "ni" module.
> It took me two aborted attempts just to realize I should be using PEP
> 302 and not ihooks or some wrapper around __import__().
Yes. PEP 302 came about when I tried to reimplement PEP 273 (zip import)
in a "sane" way ("saner" is probably as far as I got...).
Import is indeed very confusing, especially because of packages. I tried
to convince Guido at some point to simplfy package imports by getting
rid of __path__ altogether (and then simply search for
"packagename/submodule.py" on sys.path) but he disliked the idea of
widening submodule imports that much. On the other hand, __path__ is a
mutable list so people can get the same effect by adding stuff to it.
> While this may be interesting history it's very confusing, and I'm
> encouraging Alex Martelli to describe the current PEP-302-based scheme a
> little more fully in his forthcoming revision to the Nutshell. The PEP
> is just a little terse in places, I feel.
Yeah, it's a PEP, not official documentation, but since there isn't any
official documentation, all you've got is the PEP :(
> I'm also wondering if the inspect module shouldn't have a facility to
> hook into custom importers, since its code is pretty much filestore
> based at present. This should probably be via an *optional* API to avoid
> breakage in existing custom importers.
Probably.
Just
--
http://mail.python.org/mailman/listinfo/python-list
Re: variable declaration
In article <[EMAIL PROTECTED]>, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Antoon Pardon wrote:ons already existing. > > The compilor might generate a RESTORE instruction. > > Whether it is done as a LOAD/STORE or a RESTORE, it has to perform the same > work > - check the name exists in the local namespace, and throw an exception if it > doesn't. If it the name does exist, perform a normal store operation. But the compiler would _know_ in which scope the variable was defined, no? Just -- http://mail.python.org/mailman/listinfo/python-list
Re: Style guide for subclassing built-in types?
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: > Thank you but your advice doesn't fit in my case since I want to keep > the memory usage and the initial time minimum. iterable[::-1] would > build another list and it would take big memory and time during > reversing if iterable were huge. (and the "iterable" wouldn't be > garbage-collected because I want to keep a reference to it) If your list contains numbers (or lists of numbers), consider using NumPy (Numeric) or Numarray, in which seq[::-1] will actually return a "view", and not a copy. Just -- http://mail.python.org/mailman/listinfo/python-list
any Python equivalent of Math::Polynomial::Solve?
While googling for a non-linear equation solver, I found Math::Polynomial::Solve in CPAN. It seems a great little module, except it's not Python... I'm especially looking for its poly_root() functionality (which solves arbitrary polynomials). Does anyone know of a Python module/package that implements that? Just -- http://mail.python.org/mailman/listinfo/python-list
Re: any Python equivalent of Math::Polynomial::Solve?
In article <[EMAIL PROTECTED]>, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Just wrote: > > While googling for a non-linear equation solver, I found > > Math::Polynomial::Solve in CPAN. It seems a great little module, except > > it's not Python... I'm especially looking for its poly_root() > > functionality (which solves arbitrary polynomials). Does anyone know of > > a Python module/package that implements that? > > > > Just > > Does SciPy do what you want? Specifically Scientific.Functions.FindRoot [1] & > Scientific.Functions.Polynomial [2] > > Regards, > Nick. > > [1] > http://starship.python.net/~hinsen/ScientificPython/ScientificPythonManual/Sci > entific_9.html > [2] > http://starship.python.net/~hinsen/ScientificPython/ScientificPythonManual/Sci > entific_13.html (Hm, I had the impression that scipy != Konrad Hinsen's Scientific module.) I had played with [1], but it "only" calculates one root, and I need all roots (specifically, for a quintic equation). [2] doesn't seem to be a solver? Just -- http://mail.python.org/mailman/listinfo/python-list
Re: any Python equivalent of Math::Polynomial::Solve?
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (John M. Gamble) wrote: > In article <[EMAIL PROTECTED]>, > Just <[EMAIL PROTECTED]> wrote: > >While googling for a non-linear equation solver, I found > >Math::Polynomial::Solve in CPAN. It seems a great little module, except > > Thank you. > > >it's not Python... > > Sorry about that. Heh, how big are the odds you find the author of an arbitrary Perl module on c.l.py... > > I'm especially looking for its poly_root() > >functionality (which solves arbitrary polynomials). Does anyone know of > >a Python module/package that implements that? > > Are you looking for that particular algorithm, or for any > source that will find the roots of the polynomial? Any will do. As I wrote in another post, I'm currently only looking for a quintic equation solver, which your module does very nicely. > The > original source for the algorithm used in the module is > from Hiroshi Murakami's Fortran source, and it shouldn't > be too difficult to repeat the translation process to python. Ah ok, I'll try to locate that (following the instruction in Solve.pm didn't work for me :( ). Just -- http://mail.python.org/mailman/listinfo/python-list
Re: any Python equivalent of Math::Polynomial::Solve?
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (John M. Gamble) wrote: > >> The > >> original source for the algorithm used in the module is > >> from Hiroshi Murakami's Fortran source, and it shouldn't > >> be too difficult to repeat the translation process to python. > > > >Ah ok, I'll try to locate that (following the instruction in Solve.pm > >didn't work for me :( ). > > > > Ouch. I just did a quick search and found that that site has undergone > a few changes, and the code that i reference is missing. A few other > links in the docs are stale too. I need to update the documentation. > > Anyway, doing a search for 'hqr' and Eispack got me a lot of sites. > In particular, this one is pretty friendly: > > <http://netlib.enseeiht.fr/eispack/> > > Look at the source for balanc.f (does the prep-work) and hqr.f > (does the solving). Minor annoyance: the real and imaginary > parts of the roots are in separate arrays. I combined them into > complex types in my perl source, in case you want to make a > comparison. Thanks! I'll check that out. > Of course, all this may be moot if the other suggestions > work out. SciPy indeed appear to contain a solver, but I'm currently stuck in trying to _get_ it for my platform (OSX). I'm definitely not going to install a Fortran compiler just to evaluate it (even though my name is not "Ilias" ;-). Also, SciPy is _huge_, so maybe a Python translation of that Fortran code or your Perl code will turn out to be more attractive after all... Just -- http://mail.python.org/mailman/listinfo/python-list
Re: any Python equivalent of Math::Polynomial::Solve?
In article <[EMAIL PROTECTED]>, "Raymond L. Buvel" <[EMAIL PROTECTED]> wrote: > Just wrote: > > > > > SciPy indeed appear to contain a solver, but I'm currently stuck in > > trying to _get_ it for my platform (OSX). I'm definitely not going to > > install a Fortran compiler just to evaluate it (even though my name is > > not "Ilias" ;-). Also, SciPy is _huge_, so maybe a Python translation of > > that Fortran code or your Perl code will turn out to be more attractive > > after all... > > > > Just > > The GNU Scientific Library has a nice root finder for polynomials with > real coefficients. I have wrapped this with Pyrex to work with my > ratfun module see: > > http://calcrpnpy.sourceforge.net/ratfun.html > > If this will suit your needs, I can send you an alpha release of the > package with the root finder. It is not pure Python. I requires Pyrex > and a C compiler to install. My guess is that it will work on OSX as > well as it does on Linux. This functionality will be included in the > next release of the ratfun package but I still have to unit test a > number of components and update the documentation. Consequently, an > official release will not happen soon. Thank you, I'll check this out. I had come across GSL, but not Python bindings. (GPL is probably a problem for my project, but it's very good to know anyway.) On the other hand, I just finished translating the relevant portions of Math::Polynomial::Solve to Python, so I'm probably all set, at least for now. Thanks everyone for the responses, especially to John Gamble! Just -- http://mail.python.org/mailman/listinfo/python-list
Re: any Python equivalent of Math::Polynomial::Solve?
In article <[EMAIL PROTECTED]>, "Carl Banks" <[EMAIL PROTECTED]> wrote: > Just wrote: > > While googling for a non-linear equation solver, I found > > Math::Polynomial::Solve in CPAN. It seems a great little module, > except > > it's not Python... I'm especially looking for its poly_root() > > functionality (which solves arbitrary polynomials). Does anyone know > of > > a Python module/package that implements that? > > If you don't have a great need for speed, you can accomplish this > easily with the linear algebra module of Numeric/numarray. Suppose > your quintic polynomial's in the form > >a + b*x + c*x**2 + d*x**3 + e*x**4 + x**5 > > The roots of it are equal to the eigenvalues of the companion matrix: > > 0 1 0 0 0 > 0 0 1 0 0 > 0 0 0 1 0 > 0 0 0 0 1 > -a -b -c -d -e > > It should be pretty easy to set up a Numeric matrix and call > LinearAlgebra.eigenvalues. For example, here is a simple quintic > solver: > > . from Numeric import * > . from LinearAlgebra import * > . > . def quinticroots(p): > . cm = zeros((5,5),Float32) > . cm[0,1] = cm[1,2] = cm[2,3] = cm[3,4] = 1.0 > . cm[4,0] = -p[0] > . cm[4,1] = -p[1] > . cm[4,2] = -p[2] > . cm[4,3] = -p[3] > . cm[4,4] = -p[4] > . return eigenvalues(cm) > > > now-you-can-find-all-five-Lagrange-points-ly yr's, Wow, THANKS. This was the answer I was secretly hoping for... "Great need for speed", no, not really, but this Numeric-based version is about 9 times faster than what I translated from Perl code yesterday, so from where I'm standing your version is blazingly fast... Thanks again, Just -- http://mail.python.org/mailman/listinfo/python-list
Re: naming convention for scalars, lists, dictionaries ...
In article <[EMAIL PROTECTED]>, Jack Diederich <[EMAIL PROTECTED]> wrote: > On Mon, Feb 28, 2005 at 04:02:37PM -0500, Benji York wrote: > > Jack Diederich wrote: > > >Ditto for me, plural implies list and singular implies instance, > > >for (contact) in contacts: > > > # do something with contact > > > > May I ask why you place the parenthesis in the for statement? > > I like the tuple-ness feel of it and frequently unpack multiple > values in for loops. I also like the visual feel, it makes it > easy to see what is being unpacked and what is the source. > > "for (one, two, three) in somelist:" > versus > "for one, two, three in sometlist:" > > Even with a colorizing editor (emacs) I find the first version > easier to read. YMMV. But you're using it for _single_ values. That's like writing (val) = someFunction(...) Just -- http://mail.python.org/mailman/listinfo/python-list
Re: Initializing subclasses of tuple
In article <[EMAIL PROTECTED]>, Dave Opstad <[EMAIL PROTECTED]> wrote: > I'm hoping someone can point out where I'm going wrong here. Here's a > snippet of a Python interactive session (2.3, if it makes a difference): > > -- > >>> class X(list): > ... def __init__(self, n): > ... v = range(n) > ... list.__init__(self, v) > ... > >>> x = X(10) > >>> x > [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] > >>> class Y(tuple): > ... def __init__(self, n): > ... v = tuple(range(n)) > ... tuple.__init__(self, v) > ... > >>> y = Y(10) > Traceback (most recent call last): > File "", line 1, in ? > TypeError: iteration over non-sequence > -- > > How do I initialize instances of a class derived from tuple, if it's not > in the __init__ method? Hi Dave, You're going to have to override __new__. See eg. http://groups-beta.google.com/group/comp.lang.python/browse_thread/thread /4a53d2c69209ba76/9b21a8326d0ef002 http://mail.python.org/pipermail/tutor/2004-January/027779.html Good luck, Just -- http://mail.python.org/mailman/listinfo/python-list
Re: Gordon McMillan installer and Python 2.4
In article <[EMAIL PROTECTED]>, "Serge Orlov" <[EMAIL PROTECTED]> wrote: > Svein Brekke wrote: > > > Seriously, if you're only interested in Windows, just use py2exe, > > > or if you want Linux+Windows, try cx_Freeze. > > > > According to the command line help for cx_Freeze and py2exe, they > > cannot pack my program with additional installation files into one > > self-extracting .exe file (which is what I want to do). > > > > Am I wrong on this? > > You're right, but that doesn't mean py2exe is not for you. Packing > a program, displaying a license, choosing installation directory > is not Python specific, just use a generic installer. They are better > because they have much more users than Python specific installers. > See for example http://nsis.sourceforge.net/features/featurelist/ > > Use py2exe to bundle python core, extentions and your program into > one directory, then use nsis to create the installator. It's not so much about the installation I suppose. A friend of mine is packaging an app for Windows, and he _really_ likes the installed thing to be a single-file .exe, not a folder with many things. Apparently McMillan Installer does that very nicely. Too bad it doesn't support Python 2.4 (yet). Just -- http://mail.python.org/mailman/listinfo/python-list
Re: python -i (interactive environment)
In article <[EMAIL PROTECTED]>,
Steve Holden <[EMAIL PROTECTED]> wrote:
> Michael Hoffman wrote:
> > Joe wrote:
> >
> >> I want the script to decide whether to fall back to the interactive
> >> prompt. You solution makes it ALWAYS fall back to the interactive prompt.
> >
> >
> > Actually, using sys.exit() means the program can exit even if python -i
> > is used.
> >
> > You can use:
> >
> > import code
> > code.interact()
> >
> > which emulates the interactive prompt.
>
> Unfortunately it does so in an entirely new namespace, thereby losing
> the advantage of -i - namely, that you can investigate the program's
> namespace after it's terminated.
code.interact() has a namespace argument ('local'), so it really easy to
have it use the namespace you want.
Just
--
http://mail.python.org/mailman/listinfo/python-list
Re: zipimport IOError reading Modules.zip in Mac standalone app
In article <[EMAIL PROTECTED]>, "Bob Swerdlow" <[EMAIL PROTECTED]> wrote: > We have some users of our application getting error messages like: > IOError: zipimport: can not open file > /Volumes/MyApp/MyApp.app/Contents/Resources/Modules.zip > This only happens on our Mac version - the Windows version seems fine. > > Our build is still using bundlebuilder, which creates Modules.zip. I want > to upgrade to py2app, but have not yet done so (we are using py2exe for the > Windows version). > > Only a few (7) of our users have had these IOError problems other users are > running fine. The errors they were all either: > in shelve.__init__ > in encodings/__init__.py > or in the import to one of our own modules. > > When I look into the Modules.zip file, I see > shelve.pyo > encodings/__init__.pyo > and our own module's pyo file > > So, I don't understand why we get these zipimport IOErrors. > > The application launches more than one process that uses the embedded python > (we started using the new subprocess module in this release). Could that be > a problem? Could it be that more than one process is trying to read > Modules.zip at the same time? If so, what do we do - I don't want to have > to include a separate version of the code for each subprocess. > > Any other suggestion? I need this fixed ASAP. I've never seen this. You should really upgrade to py2app, and see whether that helps. Just -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 338: Executing modules inside packages with '-m'
In article <[EMAIL PROTECTED]>, "Fredrik Lundh" <[EMAIL PROTECTED]> wrote: > Nick Coghlan wrote: > > >> $ python -c "import foo.bar" arg > > > > This doesn't work. Any code protected by "if __name__ == '__main__':" won't > > run in this context > > (since 'foo.bar' is being imported as a module, not run as a script). > > I appreciate that you're taking the time to teach me about Python, but I can > assure you that it's not really needed. Neither is the sarcasm. > as for the rest of your arguments, I have to assume that you were joking. > (or > that you have no experience whatsoever of distribution of Python programs in > Unix and Windows environments). Whatever. You suggestion does not work in many cases. How about a program that starts threads? Can't do that as a side effect of import. Just -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 338: Executing modules inside packages with '-m'
In article <[EMAIL PROTECTED]>, "Fredrik Lundh" <[EMAIL PROTECTED]> wrote: > Just wrote: > > > >> as for the rest of your arguments, I have to assume that you were joking. > >> (or > >> that you have no experience whatsoever of distribution of Python programs > >> in > >> Unix and Windows environments). > > > > Whatever. You suggestion does not work in many cases. How about a > > program that starts threads? Can't do that as a side effect of import. > > my suggestion was to make sure that the user can type "bar arg" to start a > Python program called "bar" with the argument "arg". that's trivial, on all > major platforms, despite what Nick says -- and yes, you can start threads > from a program named "bar". try it. This subthread was specifically about your python -c "import foo.bar" arg suggestion. Just -- http://mail.python.org/mailman/listinfo/python-list
Re: Unicode entries on sys.path
In article <[EMAIL PROTECTED]>, "Martin v. Lowis" <[EMAIL PROTECTED]> wrote: > > Hm, maybe more a windows question than a python question... > > The real question here is: why does Python not support arbitrary > Unicode strings on sys.path? It could, in principle, atleast on > Windows NT+ (and also on OSX). Patches are welcome. Works for me on OSX 10.3.6, as it should: prior to using the sys.path entry, a unicode string is encoded with Py_FileSystemDefaultEncoding. I'm not sure how well it works together with zipimport, though. Just -- http://mail.python.org/mailman/listinfo/python-list
Re: Unicode entries on sys.path
In article <[EMAIL PROTECTED]>, vincent wehren <[EMAIL PROTECTED]> wrote: > Just wrote: > > In article <[EMAIL PROTECTED]>, > > "Martin v. Lowis" <[EMAIL PROTECTED]> wrote: > > > > > >>>Hm, maybe more a windows question than a python question... > >> > >>The real question here is: why does Python not support arbitrary > >>Unicode strings on sys.path? It could, in principle, atleast on > >>Windows NT+ (and also on OSX). Patches are welcome. > > > > > > Works for me on OSX 10.3.6, as it should: prior to using the sys.path > > entry, a unicode string is encoded with Py_FileSystemDefaultEncoding. > > For this conversion "mbcs" will be used on Windows machines, implying > that such conversions are made using the current system Ansi codepage. > (As a matter of interest: What is this on OSX?). UTF-8. Just -- http://mail.python.org/mailman/listinfo/python-list
Re: Optional Static Typing
In article <[EMAIL PROTECTED]>, moma <[EMAIL PROTECTED]> wrote: > What about this? > u'int() = t, 6, 7, What about this? u'int() = t, 6, 7,' ...which is valid Python today. Just -- http://mail.python.org/mailman/listinfo/python-list
Re: Improving Python (was: Lambda going out of fashion)
In article <[EMAIL PROTECTED]>, "Fredrik Lundh" <[EMAIL PROTECTED]> wrote: > func(*arg) instead of apply() is a step back Strongly disagree. I find func(*args) much more readable than apply(func, args). > -- it hides the fact that functions are objects, What does this have to do with anything? > and it confuses the heck out of both C/C++ programmers and > Python programmers that understand the "def func(*arg)" form, because it > looks like something it isn't (there's a false symmetry between the call-form > and the def-form). What's false about the symmetry? Call: you supply a sequence of args Def: you receive a sequence of args Lovely. > and I still do enough 1.5.2-programming to use "x = x + y"; when I find > myself in a situation where my code would benefit a lot from being able to > write "x += y" instead, I go back and fix the design. > > string methods are nice, but nothing groundbreaking, and their niceness is > almost entirely offset by the horrid "".join(seq) construct that keeps > popping > up when people take the "the string module is deprecated" yada yada too > seriously. and what do the python-devers do? they add a "sum" built-in, > but no "join"? hello? That's what you get for unsubscribing ;-) Just -- http://mail.python.org/mailman/listinfo/python-list
Re: unicode character '\N{ }'
In article <[EMAIL PROTECTED]>,
Daewon YOON <[EMAIL PROTECTED]> wrote:
> I learned from http://www.jorendorff.com/articles/unicode/python.html that
> one can specify a unicode character by u'\N {name of the character}'.
>
> Is there any method that I do the reverse of this process? For example,
> when
> I have a unicode character '£', uc.method() should return the character name
> 'POUND SIGN' in str format.
import unicodedata
name = unicodedata.name(c)
Just
--
http://mail.python.org/mailman/listinfo/python-list
Re: deprecation of has_key?
In article <[EMAIL PROTECTED]>, "Terry Reedy" <[EMAIL PROTECTED]> wrote: > "Steven Bethard" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > Ahh, ok. Now I understand. I think you could probably search the > > python-dev archives and see why the decision was made as it was. For > > pretty much all my purposes, "key in dict" is much more useful than "item > > in dict". Practicality beats Purity and all. ;) > > In '[for] x in mydict:', x could potentially be key, value, or item-pair. > All three were considered and discussed -- I believe on clp-- and key > chosen as the most useful. A specific analogy brought forth was the phone > book, a mapping of names to phone number and maybe address. The decision > was definite closer to a coin-toss to a no-brainer. The main argument was that nothing but "key in d" made sense (for __contains__), and that therefore "for key in d" was the only option, for symmetry with the other "in". Just -- http://mail.python.org/mailman/listinfo/python-list
Re: python coding contest
In article <[EMAIL PROTECTED]>,
Christoph Zwerschke <[EMAIL PROTECTED]> wrote:
> Mark Dickinson wrote:
> > Here's a variant of André's brilliant idea that's
> > 119 characters long, and fully printable:
> >
> > j=''.join;seven_seg=lambda z:j(j(' _ | |_ _|_|'
> > [ord('^r|=Zm.:v\r'[int(a)])%u*2:][:3]for a in z)
> > +"\n"for u in(3,7,8))
>
> You have an escaped CR (\r) as the last character in your string.
Which is perfectly printable.
> Here is a 118 character fully printable variant without the \r:
>
> j=''.join;seven_seg=lambda x:j(j(' _ |_|_ _|
> |'[ord('^rm=3|4:s»'[int(c)])%d*2:][:3]for c in x)+"\n"for d in(3,8,7))
>
> Note that there is only one non-ascii character in the code.
Which isn't. So I'm not sure what the point is you're trying to make.
Just
--
http://mail.python.org/mailman/listinfo/python-list
Re: Memoization and encapsulation
In article <[EMAIL PROTECTED]>,
Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> I was playing around with simple memoization and came up with something
> like this:
>
> _cache = {}
> def func(x):
> global _cache
There's no need to declare _cache as global, since you're not assigning
to it. So this global isn't all that pesky after all...
> if _cache.has_key(x):
> return _cache[x]
> else:
> result = x+1 # or a time consuming calculation...
> _cache[x] = result
> return result
>
> when it hit me if I could somehow bind the cache to the function, I could
> get rid of that pesky global variable.
[ ... ]
> What do folks think? Is there a better way?
I actually prefer such a global variable to the default arg trick. The
idiom I generally use is:
_cache = {}
def func(x):
result = _cache.get(x)
if result is None:
result = x + 1 # or a time consuming calculation...
_cache[x] = result
return result
Just
--
http://mail.python.org/mailman/listinfo/python-list
Re: python coding contest
In article <[EMAIL PROTECTED]>,
Just <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> Christoph Zwerschke <[EMAIL PROTECTED]> wrote:
>
> > Mark Dickinson wrote:
> > > Here's a variant of André's brilliant idea that's
> > > 119 characters long, and fully printable:
> > >
> > > j=''.join;seven_seg=lambda z:j(j(' _ | |_ _|_|'
> > > [ord('^r|=Zm.:v\r'[int(a)])%u*2:][:3]for a in z)
> > > +"\n"for u in(3,7,8))
> >
> > You have an escaped CR (\r) as the last character in your string.
>
> Which is perfectly printable.
>
> > Here is a 118 character fully printable variant without the \r:
> >
> > j=''.join;seven_seg=lambda x:j(j(' _ |_|_ _|
> > |'[ord('^rm=3|4:s»'[int(c)])%d*2:][:3]for c in x)+"\n"for d in(3,8,7))
> >
> > Note that there is only one non-ascii character in the code.
>
> Which isn't. So I'm not sure what the point is you're trying to make.
Duh, sorry, it's early. 118 is better than 119. Printable or not :)
Still, a 119 bytes version that is fully printable is pretty cool.
Just
--
http://mail.python.org/mailman/listinfo/python-list
Re: py-cocoa?
In article <[EMAIL PROTECTED]>, Lin-Chieh Shangkuan <[EMAIL PROTECTED]> wrote: > It's known that combining GTK+ or Qt with Python could enable the > GUI design with pygtk/pyqt. > > In Mac OSX, it's suggested that use Cocoa be the GUI framework. > Is there py-cocoa framework? PyObjC. Just -- http://mail.python.org/mailman/listinfo/python-list
Re: Stack trace in C
In article <[EMAIL PROTECTED]>, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: > On Tue, 25 Jul 2006 14:20:41 +0200, Andre Poenitz <[EMAIL PROTECTED]> wrote: > > > > > >Bear with me - I am new to Python. (And redirect me to a more suitable > >newsgroup in case this one is not appropriate.) > > > >I am trying to embed Python into a C++ application and want to get back > >a backtrace in case of errors in the python code. > > I think you'd have more luck with the traceback module, which has such > methods as format_exception and print_tb. >From C, PyErr_Print() is often handy (if only for debugging). Just -- http://mail.python.org/mailman/listinfo/python-list
Re: Bug in re module?
In article <[EMAIL PROTECTED]>, "Ant" <[EMAIL PROTECTED]> wrote: > Ant wrote: > > Look at the following minimal example: > ... (snip example that shows non-capturing group capturing) > > Note I get the same results from python versions 2.4 and 2.5. > Try ?: instead of :? Just -- http://mail.python.org/mailman/listinfo/python-list
Re: CENSORSHIP - Django Project (Schema Evolution Support)
In article <[EMAIL PROTECTED]>, Erik Max Francis <[EMAIL PROTECTED]> wrote: > Thorsten Kampe wrote: > > > I think I have a deja-vu... Did someone say "Xah"?! > > With a hint of Brandon. And a slice of Timothy Rue. Just -- http://mail.python.org/mailman/listinfo/python-list
Re: The Split String Function - How to preserve whitespace?
In article <[EMAIL PROTECTED]>,
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> I am trying to scan the lines in the string text:
> lines = text.split('\n')
>
> seemed to do the job but has the side effect of stripping the
> whitespace. As I am reading Python source in this text and checking
> identation this is a bit annoying :-)
>
> How can I stop this happening? Doesn't look like an option from the
> documents. Do I have to use a regexp (scary unchartered stuff for
> me...)?
>>> "a\nb\nc\n".splitlines(True)
['a\n', 'b\n', 'c\n']
Just
--
http://mail.python.org/mailman/listinfo/python-list
Re: Doctests for nested functions
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: > Can doctests be added to nested functions too? (This can be useful to > me, I use nested function when I don't have attributes that I have to > remember, but I want to split the logic in some subparts anyway). I think we had that discussion before, but that's not what nested functions are for (in Python). Use modules for that. Also solves your doctest problem nicely. Just -- http://mail.python.org/mailman/listinfo/python-list
Re: Thread Question
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Aahz) wrote: > In article <[EMAIL PROTECTED]>, > Kent Johnson <[EMAIL PROTECTED]> wrote: > >D wrote: > >> > >> My question is, how would I go > >> about creating the thread? I have seen examples that used classes, and > >> other examples that just called one thread start command - when should > >> you use one over another? > > > >For simple use it doesn't matter. Use a class when you want to add more > >state or behaviour - for example you might want a flag that tells the > >thread to stop, or a Queue to communicate with the thread. A class might > >be more convenient in these cases. > > > >IOW if you can write it as a single function it doesn't matter much > >which form you use; for more complex usage you may want a class. > > OTOH, always subclassing requires less thinking. Same for never subclassing :) I always felt that subclassing Thread is very unpythonic. It seems like an unfortunate leftover Javaism (much of threading.py was inspired by Java, but I don't need to tell you that). If I need some state, I create my own class, with a reference to the Thread object if needed. Has-a vs. is-a. Just -- http://mail.python.org/mailman/listinfo/python-list
Re: Cross compile generation of .pyc from .py files...
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: > Terry Reedy wrote: > > ... > > I am under the impression that .pyc files are system independent. > > Have you tried simply copying them over? > > > > tjr > > Hi Terry, > > It appears that python on the target ppc system is expecting to see > ppc-related info in the .pyc files. There is no such thing. > These .pyc were generated at cross > compile time (on i686 system) and packaged, deployed, installed on the > ppc system. The "...has bad magic..." appears to indicate that > ppc-version of python is expecting to see ppc-specific .pyc files, but > is encountering i686-specific .pyc files... For some reason, the > cross-compile step that results in the .pyc files is not generating > them for the proper ppc-target, but is building them for the i686 > system where they were being cross-compiled... .pyc files are only compatible with the same major Python version, so it sounds like you're using different versions on both platforms. Just -- http://mail.python.org/mailman/listinfo/python-list
Re: getting the reference count of an object ...
In article <[EMAIL PROTECTED]>, Wildemar Wildenburger <[EMAIL PROTECTED]> wrote: > ... how? > > I'm writing an app that holds a public data dictionary from which other > objects obtain part of their __dict__ values so they all work on the > same dataset (yes I'm fiendishly clever and a constructor of unreadable > sentences (and code) ;)). > > My problem is that I haven't found an easy way to determine if said > dictionary contents are still in use (so it is ok to delete them from > the dictionary). I've thought about creating a dict subclass that counts > the number of assignments and deletions but that seems cumbersome (an > bug-prone). > > Is there a way to get the reference count of these datadict items? I > imagine that this would be a more stable implementation of such a feature. > > Hope this gets my problem accross; if not just bash me and I'll > reformulate. I'm not the best of explainers. > > Oh, and sorry if the solution to my problem is obvious (such as an > __refcount__ attribute or some stupid oversight like that). Direct answer: sys.getrefcount() Better answer: look at the weakref module, especially at the various Dict helper classes. Just -- http://mail.python.org/mailman/listinfo/python-list
Re: pop3proxy
In article <[EMAIL PROTECTED]>, BrokenClock <[EMAIL PROTECTED]> wrote: > Here is a python newbie! I've choose it to make a pop3 proxy - I want to > filter content between a pop3 client and a pop3 server, and I have no > control on the server... > First, I wanted to do an non-filtering, just logging, mono-thread proxy > to make some test.. Not directly helpong with your problem, but perhaps some example code helps: the spambayes project contains a working pop3 proxy. Just -- http://mail.python.org/mailman/listinfo/python-list
Re: py2exe and library.zip
In article <[EMAIL PROTECTED]>, Peter Hansen <[EMAIL PROTECTED]> wrote: > [ ... ] (Note to self: check if zip files that can > be in sys.path can be compressed, Yes. > and if py2exe compresses them.) Don't know, but I assume yes. Just -- http://mail.python.org/mailman/listinfo/python-list
Re: py2exe + svn - the final drama
In article <[EMAIL PROTECTED]>, David Bolen <[EMAIL PROTECTED]> wrote: > Are you perhaps trying to update the zip file in-place while it is still > being used by the application? I'm not sure that's a safe operation. I'm sure it's not :) [lots of useful help snipped] the zipimport module has an attr called _zip_directory_cache, which is a dict you can .clear(). Still, reloading modules is hairy at best, its probably easiest to relaunch your app when the .zip file has changed. Just -- http://mail.python.org/mailman/listinfo/python-list
Re: py2exe + svn - the final drama
In article <[EMAIL PROTECTED]>, David Bolen <[EMAIL PROTECTED]> wrote: > Just <[EMAIL PROTECTED]> writes: > > > the zipimport module has an attr called _zip_directory_cache, which is a > > dict you can .clear(). Still, reloading modules is hairy at best, its > > probably easiest to relaunch your app when the .zip file has changed. > > Except that he's getting an error during the process exit of the > current execution, which is needed to restart. And if he updates to a > different copy, there's the bootstrap problem of how to get it back > into the standard location for the next restart since his application > will need to have it to restart in the first place. Right. It sounds like a module is imported at exit that wasn't imported before. If that's the case, it may help to make sure all modules needed for exit are imported beforehand. Just -- http://mail.python.org/mailman/listinfo/python-list
Re: namespaces in eval(): spot error in 3 line program
In article <[EMAIL PROTECTED]>,
"pasa" <[EMAIL PROTECTED]> wrote:
> I'm an old time python user, but just got bitten by namespaces in eval.
> If this is an old discussion somewhere, feel free to point me there.
>
> Based on the documentation, I would have expected the following to
> work:
>
> def foo(k): print k; print a
>
> ns = {'a':1, 'foo': foo}
> eval('foo(2)', ns)
>
> But it does not, complete session:
>
> [EMAIL PROTECTED] ~]$ python
> Python 2.4 (#2, Feb 13 2005, 22:08:03)
> [GCC 3.4.3 (Mandrakelinux 10.1 3.4.3-3mdk)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> def foo(k): print k; print a
> ...
> >>> ns = {'a':1, 'foo': foo}
> >>> eval('foo(2)', ns)
> 2
> Traceback (most recent call last):
> File "", line 1, in ?
> File "", line 0, in ?
> File "", line 1, in foo
> NameError: global name 'a' is not defined
> >>>
>
> huh? I'd almost be tempted to call this a bug?
>
> Playing with locals() and globals() I see that this one works,
> which I would not have expected to work:
>
> def foo(k): print k; print ns['a']
>
> ns = {'a':1, 'foo': foo}
> eval('foo(2)', ns)
>
> Prints out
> 2
> 1
>
> Do functions carry their own pointer to global namespace,
> which gets defined at function compile time, or what is
> happening here?
Function definition time. Your code is more or less equivalent to:
# A.py:
def foo(k): print k; print a
# B.py:
from A import foo
a = 1
foo()
That will fail with a NameError just the same.
Just
--
http://mail.python.org/mailman/listinfo/python-list
Re: Creating dict from keys and values
In article <[EMAIL PROTECTED]>,
Dirkjan Ochtman <[EMAIL PROTECTED]> wrote:
> Hi there,
>
> I'm looking for an intuitive way of creating a dict from what the
> dict.keys() and dict.values() will return (two lists).
>
> Currently, I'm using this code:
>
> > d = {}
> > for i in range(len(data)):
> > d[header[i]] = data[i]
>
> But this feels kind of inelegant. So: is there a better way?
d = dict(zip(header, data))
Just
--
http://mail.python.org/mailman/listinfo/python-list
Re: metaclass that inherits a class of that metaclass?
In article <[EMAIL PROTECTED]>, "infidel" <[EMAIL PROTECTED]> wrote: > [ ... ] type is, from my trivial understanding, the > base type and base metaclass for everything else in python. Saying > "type is an object" is only confusing you into thinking it is a > subclass of object, which is not the case. Sure is: >>> type.__bases__ (,) > object is a class, which I > believe has type as it's metaclass (though I could be mistaken - this > gets terribly confusing very quickly). Correct: >>> object.__class__ type also has type as its metaclass: >>> type.__class__ In other words, type is an instance of itself. Just -- http://mail.python.org/mailman/listinfo/python-list
Re: Tuple assignment and generators?
In article <[EMAIL PROTECTED]>, Larry Bates <[EMAIL PROTECTED]> wrote: > While I have never needed anything like this in my 5 years of Python > programming, here is a way: > > a,b,c = 3*[0] > q,r,s,t,u,v = 6*[0] This is (IMO) fairly idiomatic: a = b = c = 0 q = r = s = t = u = v = 0 Just -- http://mail.python.org/mailman/listinfo/python-list
Re: md5 from python different then md5 from command line
In article <[EMAIL PROTECTED]>,
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> I noticed that the md5 computed with md5 module from python is
> different then the md5 sum computed with md5sum utility (on slackware
> and gentoo).
>
> i.e.
> $echo marius|md5sum
> 0f0f60ac801a9eec2163083a22307deb -
>
> >>> test = md5.new("marius")
> >>> print test.hexdigest()
> 242aa1a97769109065e3b4df359bcfc9
>
>
> Any idea why? and how to get the same md5 sum for both calls?
echo adds a newline:
>>> import md5
>>> test = md5.new("marius\n")
>>> print test.hexdigest()
0f0f60ac801a9eec2163083a22307deb
Just
--
http://mail.python.org/mailman/listinfo/python-list
Re: list comprehensions put non-names into namespaces!
In article <[EMAIL PROTECTED]>, "Terry Reedy" <[EMAIL PROTECTED]> wrote: > "Mel Wilson" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > Point of information, would this be the interpreter putting > > the result of its last calculation in _ ? > > Yes, [ ... ] No, actually. It's an implementation detail of list comps. -- http://mail.python.org/mailman/listinfo/python-list
Re: generators shared among threads
In article <[EMAIL PROTECTED]>, Kent Johnson <[EMAIL PROTECTED]> wrote: > Paul Rubin wrote: > > Hmm (untested, like above): > > > > class Synchronized: > >def __init__(self, generator): > > self.gen = generator > > self.lock = threading.Lock() > >def next(self): > > self.lock.acquire() > > try: > > yield self.gen.next() > > finally: > > self.lock.release() > > > > synchronized_counter = Synchronized(itertools.count()) > > > > That isn't a general solution but can be convenient (if I didn't mess > > it up). Maybe there's a more general recipe somewhere. > > This code is not allowed in Python 2.4. From PEP 255: [ snip ] The code also doesn't make sense: .next() should *return* a value, not yield one. Substituting "return" for "yield" might just work for the code above. Just -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Evangelism
In article <[EMAIL PROTECTED]>, Steve Holden <[EMAIL PROTECTED]> wrote: > I've been thinking (and blogging) about python evangelism since PyCon, > as a result of which I created a squidoo lens: > >http://www.squidoo.com/pythonlogy > > Imagine my surprise at discovering that this has gone up in rank (by > number of views) from # 442,000 or so to #153! Clearly there's some > mileage in marketing Python, and I'd like to keep the buzz going if it > means more people will adopt the language. > > Any suggestions for improvement? Yeah, the URL: http://www.squidoo.com/pythonology :) Just -- http://mail.python.org/mailman/listinfo/python-list
Re: First script, please comment and advise
In article <[EMAIL PROTECTED]>,
Pedro Graca <[EMAIL PROTECTED]> wrote:
> I'm sure this isn't very pythonic; comments and advice appreciated
>
>
> def curious(text):
> """ Return the words in input text scrambled except for the first and
> last letter. """
> new_text = ""
> word = ""
> for ch in text:
> if ch in "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ":
> word = word + ch
> else:
> new_text = new_text + scramble(word)
> word = ""
> new_text = new_text + ch
> return new_text
>
> def scramble(word):
> """ scramble word """
> from random import randint
>
> if len(word) < 4:
> return word
> new_word = word[0]
>
> ### transform "curious" into ['u', 'r', 'i', 'o', 'u']
> letters = []
> for ch in word:
> letters.append(ch)
> del letters[0:1]
> del letters[-1]
>
> ### why doesn't range(len(letters) - 1, 0, -1) work?
> for i in range(len(letters) - 1, -1, -1):
> j = randint(0, i)
> new_word = new_word + letters[j]
> del letters[j]
> return new_word + word[-1]
>
> print curious(curious.__doc__)
def curious(text):
""" Return the words in input text scrambled except for the
first and last letter. """
new_text = ""
word = ""
for ch in text:
if ch.isalpha():
word += ch
else:
new_text += scramble(word)
word = ""
new_text += ch
new_text += scramble(word)
return new_text
def scramble(word):
""" scramble word """
from random import shuffle
if len(word) < 4:
return word
letters = list(word[1:-1])
shuffle(letters)
return word[0] + "".join(letters) + word[-1]
Just
--
http://mail.python.org/mailman/listinfo/python-list
Re: First script, please comment and advise
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: > My version is similar to Just one: > > from random import shuffle > > def scramble_text(text): > """Return the words in input text string scrambled > except for the first and last letter.""" > def scramble_word(word): > if len(word) < 4: return word > core = list(word[1:-1]) > shuffle(core) > return word[0] + "".join(core) + word[-1] > > return " ".join(map(scramble_word, text.split())) > > print scramble_text(scramble_text.__doc__) Your text split behaves completely different from the original; I think it was intentional that any puntuation wasn't affected. Btw. I find the use of a nested function here completely bogus: you don't need the surrounding scope. Just -- http://mail.python.org/mailman/listinfo/python-list
Re: First script, please comment and advise
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: > Just: > > > Btw. I find the use of a nested function here completely bogus: you > > don't need the surrounding scope. > > I don't agree, nested functions are useful to better structure your > program: to really nest things that are logically nested, to have just > one thing when you have only one thing to do, and they help you to > avoid polluting the namespace (those were the main purposes of nested > functions in Pascal-like languages). Luckily this is Python, not Pascal :) 1. The fact that one function calls the other doesn't mean they're "logically nested". 2. The helper function is useful on its own, so it is a waste to hide it inside another. 3. The nested function makes the enclosing function harder to read. 4. I don't buy the namespace pollution argument, we have modules after all. 5. Overhead: every time a new function object is created, for no good reason. (But you save a global name lookup, yet that doesn't appear to weigh up against the function def. [*]) To me, nested functions (in Python) are *only* helpful when using closures. If you're not using the enclosing scope, you're just obfuscating things. Just [*] % python2.4 -m timeit -s "def helper(): pass" "def nonnesting():" \ " helper()" "nonnesting()" 100 loops, best of 3: 1.92 usec per loop % python2.4 -m timeit "def nesting():" " def helper(): pass" \ " helper()" "nesting()" 10 loops, best of 3: 2.04 usec per loop -- http://mail.python.org/mailman/listinfo/python-list
Re: First script, please comment and advise
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: > >1. The fact that one function calls the other doesn't mean they're > >"logically nested".< > > In this situation they were logically nested, because the scramble_word > is a function needed by another one only, in Java the scramble_word > becomes a (private) method of a text scrambling class; this means it is > nested and hided inside a class. Pascal languages were pre-OOP and they > used nested function for similar purposes, that it to hide and > structure functions inside other ones, that in OO languages like Java, > ObjectPascal, Python, etc. you usually do with classes. In Python one usually doesn't try to hide things. [ ... ] > >4. I don't buy the namespace pollution argument, we have modules after all. > > I presume Guido agrees that function nesting is another way to avoid > namespace pollution :-) I dare you to find out. I'm fairly sure of the answer. > There are many ways to do the same thing, to > avoid pollution in one module. Nesting functions is not one of them. Factoring a bit of functionality into a helper function, giving that function a name and sticking it into a module can _hardly_ be called "pollution". That's what modules are *for*. [ ... ] > >To me, nested functions (in Python) are *only* helpful when using closures. > >If you're not using the enclosing scope, you're just obfuscating things.< > > Note that until recent time, Python nested scopes were managed quite > differently (in a bad way), Yup. > and yet, they regarded the function nesting > useful enough to be kept anyway. Nested functions are supported because you _need_ them if you want to work with closures. Not because it's a good way to structure code in the *absence* of closures. > I don't agree with you, but every programmer is diffent, because their > story is different. If you have learnt to program with Java/C then you > probably don't like nested functions. If you started with a Pascal-like > language then probably you like that nesting more. If you start with a > Scheme/Lisp background you progrably write Python programs like the > good Norvig: > http://aima.cs.berkeley.edu/python/utils.py That's pretty good code. Well documented, clearly written, uses some functional idioms in a sensible way. And no, it doesn't use gratuitous nested functions. > Maybe other people here can say what they think about this topic, it's > just a relaxed discussion. Sure, it's just that I feel strongly that your advice is not a good one (*especially* for beginners). So I repeat: using nested functions are NOT a good way to factor your code. (I don't need to add "in Python" there, do I?) Just -- http://mail.python.org/mailman/listinfo/python-list
Re: Cheese Shop -> BSOL?
In article <[EMAIL PROTECTED]>, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote: > On Sat, 11 Mar 2006 13:30:43 +1100, Tim Churches > <[EMAIL PROTECTED]> declaimed the following in comp.lang.python: > > > Would it be possible to rename "Cheese Shop" as "Bright Side of Life"? > > > I think I'd prefer "The Larch"... > > Or just "SPAM" ( Python Modules ?) Standard Python Archive (of) Modules? Just -- http://mail.python.org/mailman/listinfo/python-list
Re: Generating exceptions from C
In article <[EMAIL PROTECTED]>, Jacob Kroon <[EMAIL PROTECTED]> wrote: > I'll just reply to myself what I've found out so far: > > > 1. PyErr_NewException() creates the exception _class_, not the > > instance right ? > > > Looks like it does yes. It doesn't even seem right to talk about an > _instance_ of an exception... > > > 2. Is PyErr_SetString() the correct way to raise exceptions ? > > After looking at error.c in the python sources, it looks like that > function sets > the global exception type and value variables to the provided arguments. > > > 3. Besides the error message I pass to PyErr_SetString(), I also want > > to pass additional return > > data together with the exception. But this should be attached to the > > exception _instance_, > > not the class, am I right ? > > > The right way seems to be to create a tuple that consists of the string > message, and any additional data, > and pass the tuple in PyErr_SetObject(). > > > 4. If I am supposed to attach it to the exception instance, how would > > I do that ? I never have a > > pointer to the exception instance, just the class. > > As said previously, there is never an instance of the exception, data is > passed in the "value" argument. > > > Does the comments above make sense? Not quite: when raising an exception, an instance of the exception class _is_ created. Just like this: raise SomeException(msg) With the old (deprecated) spelling the instantiation is done implicitly: raise SomeException, msg Just -- http://mail.python.org/mailman/listinfo/python-list
Re: import random module
In article <[EMAIL PROTECTED]>, "Carl Banks" <[EMAIL PROTECTED]> wrote: > Ben Finney wrote: > > "DataSmash" <[EMAIL PROTECTED]> writes: > > > * random.py: > > > > > > import random > > > > Now that you've tripped over this ambiguity of Python's current > > 'import' behaviour, you may be interested to know that the behaviour > > will change to solve this: > > > > http://www.python.org/dev/peps/pep-0328/> > > I don't believe this change will solve the problem at hand, at least > there's nothing in the PEP that says it will. "import random" is an > absolute import even in random.py is in the current directory, because > current directory is in sys.path. Unless there's a change sys.path > planned, the shadowing should still happen. Correct. See also http://python.org/sf/946373 for more explanations and also more of the same confusion. Just -- http://mail.python.org/mailman/listinfo/python-list
Re: Quickie: converting r"\x2019" to int
In article <[EMAIL PROTECTED]>,
Kent Johnson <[EMAIL PROTECTED]> wrote:
> Robin Haswell wrote:
> > Hey guys. This should just be a quickie: I can't figure out how to convert
> > r"\x2019" to an int - could someone give me a hand please?
>
> Is this what you mean?
> In [9]: int(r'\x2019'[2:], 16)
> Out[9]: 8217
>
> or maybe you meant this:
> In [6]: ord(u'\u2019')
> Out[6]: 8217
Or even:
>>> import struct
>>> struct.unpack("q", "\0\0"+ r'\x2019')[0]
101671307850041L
>>>
Who knows :)
Just
--
http://mail.python.org/mailman/listinfo/python-list
Re: just one more question about the python challenge
In article <[EMAIL PROTECTED]>, John Salerno <[EMAIL PROTECTED]> wrote: > Georg Brandl wrote: > > > Have you found the file? You'll have to distribute that file bytewise > > in 5 "piles". > > No, I haven't figured out anything for this puzzle. It seems I might > have to change the filename of the image to something else, but I don't > know what. But even after I find the image, I won't know what to do from > there. I don't know what it means to distribute a file bytewise, but if > I knew exactly which modules/functions to use, I'd be more than happy > reading up on them myself. I just hate not knowing where to go to begin > with (even though I know I probably won't know enough about images to > use the right module properly either, but I can try). Have a look at the url of the image, then try the next. Just -- http://mail.python.org/mailman/listinfo/python-list
Re: just one more question about the python challenge
In article <[EMAIL PROTECTED]>, John Salerno <[EMAIL PROTECTED]> wrote: > Georg Brandl wrote: > > John Salerno wrote: > >> Georg Brandl wrote: > >> > >>> Have you found the file? You'll have to distribute that file bytewise > >>> in 5 "piles". > >> No, I haven't figured out anything for this puzzle. It seems I might > >> have to change the filename of the image to something else, but I don't > >> know what. But even after I find the image, I won't know what to do from > >> there. I don't know what it means to distribute a file bytewise, but if > >> I knew exactly which modules/functions to use, I'd be more than happy > >> reading up on them myself. I just hate not knowing where to go to begin > >> with (even though I know I probably won't know enough about images to > >> use the right module properly either, but I can try). > > > > If you give me the URL of that level, maybe I'll recall what to do. > > > > Georg > > http://www.pythonchallenge.com/pc// > > If you're prompted, the name and password are '' and ''. Erm, it's not nice to post complete solutions in a public forum. Just -- http://mail.python.org/mailman/listinfo/python-list
Re: how to call python code from C#
Thanks for all your kind information. I haven't used COM objects so far.I think now I have to learn it.Anyway thanks a lot again. paritosh. On Mon, 24 Jan 2005 12:43:50 -0700, Dave Brueck <[EMAIL PROTECTED]> wrote: > Peter Hansen wrote: > > paritosh mahana wrote: > > > >> How can I call python code from my C# code. > [snip] > > You could use ctypes or the pywin32 package to provide your > > Python code with an ActiveX interface. Then you could just > > use it via COM, like any other COM object. Lots of references > > available via Google if you want to learn more about this > > approach... > > Lemme add my two cents and say that this approach works well. > > We have a component that uses ctypes and runs as a COM local server (its own > .exe) and we currently use it both from Internet Explorer and from a C# > application. COM can be hairy initially, but if you have any experience with > COM > then this approach is pretty straightforward. > > -Dave > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
SPAM
-- http://mail.python.org/mailman/listinfo/python-list
Re: SPAM
"John Bean" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On Wed, 14 Nov 2007 11:04:35 -0800, "just bob" > <[EMAIL PROTECTED]> wrote: > >> > > Your SPAM appears to be non-existent. Vapourware. Not real. > > Shame, I fancied a Spam fritter. > The guy gets Google dollars when people view the site or click on links, me thinks. It's spam. -- http://mail.python.org/mailman/listinfo/python-list
Re: SPAM
"Lew" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > just bob wrote: >> "John Bean" <[EMAIL PROTECTED]> wrote in message >> news:[EMAIL PROTECTED] >>> On Wed, 14 Nov 2007 11:04:35 -0800, "just bob" >>> <[EMAIL PROTECTED]> wrote: >>> >>> Your SPAM appears to be non-existent. Vapourware. Not real. >>> >>> Shame, I fancied a Spam fritter. >>> >> >> The guy gets Google dollars when people view the site or click on links, >> me thinks. It's spam. > > Yes, but it's not SPAM. > > SPAM is a registered trademark of Hormel Foods Corporation for a canned > pork product. > > Spam is unwanted messages or email. Or "SPAM" , is me shouting an alert for spam. -- http://mail.python.org/mailman/listinfo/python-list
Should ctypes handle mis-matching structure return ABI between mingw and MSVC?
According the Bug 36834 of gcc, there is a mis-matching between mingw and MSVC when a struct was returned by value from a C function. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36834 Should ctypes handle this situation automatically somehow? A ctypes discussion on 2009: http://thread.gmane.org/gmane.comp.python.ctypes.user/4439 -- http://mail.python.org/mailman/listinfo/python-list
How to load file .py
Hello all My name is agiz.im student from indonesia.im stay in borneo island. Hmm. im instal python version 3 and Im try file schemafuzz.py this file created by darkc0de. And my question.how to load file schemafuzz.py in vista? after try to load file with commanD Python schemafuzz.py but my vista cant run the script but open file schemafuzz with openwith mode. Can u tellme to me for running file.py Best Regards Agiz __ Apakah Anda Yahoo!? Lelah menerima spam? Surat Yahoo! memiliki perlindungan terbaik terhadap spam http://id.mail.yahoo.com -- http://mail.python.org/mailman/listinfo/python-list
Coming from delphi - looking for an IDE - willing to spend money
Hi, Coming away from the luxury of the delphi IDE has been something of a shock. As a consequence I've become aware that maybe I need to spend some money on a python IDE. As a beginner I reckon integrated debugging would be helpful. Does anyone have any advice or suggestions? So far I've glanced at Komodo, but as a beginner I'm not in a positon to evaluate it. thanks for exprienced advice, Greg -- http://mail.python.org/mailman/listinfo/python-list
python debugger tips?
Hi All,
I'm switching to python from perl, and like the language a ton, but I
find pdb and pydb to be vastly inferior debuggers to the perl version.
In particular, I've grown very used to stepping into arbitrary
functions interactively. For instance, in perl you can do this:
casqa1:~> perl -de 42
Loading DB routines from perl5db.pl version 1.28
Editor support available.
Enter h or `h h' for help, or `man perldebug' for more help.
main::(-e:1): 42
DB<1> sub foo {return 42}
DB<2> s foo()
main::((eval 7)[/usr/local/lib/perl5/5.8.6/perl5db.pl:628]:3):
3: foo();
DB<<3>> s
main::foo((eval 6)[/usr/local/lib/perl5/5.8.6/perl5db.pl:628]:2):
2: sub foo {return 42};
DB<<3>>
Which is quite awesome; I don't have to restart the program if I want
to step through a given function call with a different set of values.
Does anyone have advice on any macros or something that i could use to
do this?
Additionally, what do people recommend as good "advanced" python
debugger guides? Explaining breakpoints and all is useful, but I
really want to know how to make sophisticated macros and interact with
the debugger from the interactive prompt.
Thanks!
Y
--
http://mail.python.org/mailman/listinfo/python-list
Looking for a decent HTML parser for Python...
I'm trying to parse HTML in a very generic way. So far, I'm using SGMLParser in the sgmllib module. The problem is that it forces you to parse very specific tags through object methods like start_a(), start_p() and the like, forcing you to know exactly which tags you want to handle. I want to be able to handle the start tags of any and all tags, like how one would do in the Xerces C++ XML parser. In other words, I would like a simple start() method that is called whenever any tag is encountered. How may I do this? Thank you... -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for a decent HTML parser for Python...
"Just Another Victim of the Ambient Morality" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >I'm trying to parse HTML in a very generic way. >So far, I'm using SGMLParser in the sgmllib module. The problem is > that it forces you to parse very specific tags through object methods like > start_a(), start_p() and the like, forcing you to know exactly which tags > you want to handle. I want to be able to handle the start tags of any and > all tags, like how one would do in the Xerces C++ XML parser. In other > words, I would like a simple start() method that is called whenever any > tag is encountered. How may I do this? >Thank you... Okay, I think I found what I'm looking for in HTMLParser in the HTMLParser module. Thanks... -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for a decent HTML parser for Python...
"Just Another Victim of the Ambient Morality" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > >Okay, I think I found what I'm looking for in HTMLParser in the > HTMLParser module. Except it appears to be buggy or, at least, not very robust. There are websites for which it falsely terminates early in the parsing. I have a sneaking feeling the sgml parser will be more robust, if only it had that one feature I am looking for. Can someone help me out here? Thank you... -- http://mail.python.org/mailman/listinfo/python-list
I'm looking for a pythonic red-black tree...
I need a red-black tree in Python and I was wondering if there was one built in or if there's a good implementation out there. Something that, lets face it, does whatever the C++ std::map<> allows you to do... Thank you... -- http://mail.python.org/mailman/listinfo/python-list
Getting VideoCapture to work with Python 2.5
I can't seem to get VideoCapture (http://videocapture.sourceforge.net/) to work with my version of Python (2.5). Why is that? I've followed the instructions which made it look easy but, as it happens all too often, it simply doesn't work. The error I get is that the .py interface file can't find an expected module (using the "import" keyword) but that module exists as a DLL in the correct directory. Why doesn't it recognize it? Has anyone else used this library with Python 2.5 successfully? Any theories as to what might be going wrong? Thank you... -- http://mail.python.org/mailman/listinfo/python-list
Unexpected behaviour with HTMLParser...
HTMLParser is behaving in, what I find to be, strange ways and I would like to better understand what it is doing and why. First, it doesn't appear to translate HTML escape characters. I don't know the actual terminology but things like & don't get translated into & as one would like. Furthermore, not only does HTMLParser not translate it properly, it seems to omit it altogether! This prevents me from even doing the translation myself, so I can't even working around the issue. Why is it doing this? Is there some mode I need to set? Can anyone else duplicate this behaviour? Is it a bug? Secondly, HTMLParser often calls handle_data() consecutively, without any calls to handle_starttag() in between. I did not expect this. In HTML, you either have text or you have tags. Why split up my text into successive handle_data() calls? This makes no sense to me. At the very least, it does this in response to text with & like escape sequences (or whatever they're called), so that it may successively avoid those translations. Again, why is it doing this? Is there some mode I need to set? Can anyone else duplicate this behaviour? Is it a bug? These are serious problems for me and I would greatly appreciate a deeper understanding of these issues. Thank you... -- http://mail.python.org/mailman/listinfo/python-list
Re: Unexpected behaviour with HTMLParser...
"Diez B. Roggisch" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Just Another Victim of the Ambient Morality schrieb: >> HTMLParser is behaving in, what I find to be, strange ways and I >> would like to better understand what it is doing and why. >> >> First, it doesn't appear to translate HTML escape characters. I >> don't know the actual terminology but things like & don't get >> translated into & as one would like. Furthermore, not only does >> HTMLParser not translate it properly, it seems to omit it altogether! >> This prevents me from even doing the translation myself, so I can't even >> working around the issue. >> Why is it doing this? Is there some mode I need to set? Can anyone >> else duplicate this behaviour? Is it a bug? > > Without code, that's hard to determine. But you are aware of e.g. > > handle_entityref(name) > handle_charref(ref) > > ? Actually, I am not aware of these methods but I will certainly look into them! I was hoping that the issue would be known or simple before I commited to posting code, something that is, to my chagrin, not easily done with my news client... >> Secondly, HTMLParser often calls handle_data() consecutively, without >> any calls to handle_starttag() in between. I did not expect this. In >> HTML, you either have text or you have tags. Why split up my text into >> successive handle_data() calls? This makes no sense to me. At the very >> least, it does this in response to text with & like escape sequences >> (or whatever they're called), so that it may successively avoid those >> translations. > > That's the way XML/HTML is defined - there is no guarantee that you get > text as whole. If you must, you can collect the snippets yourself, and on > the next end-tag deliver them as whole. I think there's some miscommunication, here. You can't mean "That's the way XML/HTML is defined" because those format specifications say nothing about how the format must be parsed. As far as I can tell, you either meant to say that that's the way HTMLParser is specified or you're referring to how text in XML/HTML can be broken up by tags, in which case I've already addressed that in my post. I expected to see handle_starttag() calls in between calls to handle_data(). Unless I'm missing something, it simply makes no sense to break up contiguous text into multiple handle_data() calls... >> Again, why is it doing this? Is there some mode I need to set? Can >> anyone else duplicate this behaviour? Is it a bug? > > No. It's the way it is, because it would require buffering with unlimited > capacity to ensure this property. It depends on what you mean by "unlimited capacity." Is it so bad to buffer with as much memory as you have? ...or, at least, have a setting for such operation? Moreover, you know that you'll never have to buffer more than there is HTML, so you hardly need "unlimited capacity..." For instance, I believe Xerces does this translation for you 'cause, really, why wouldn't you want it to? >> These are serious problems for me and I would greatly appreciate a >> deeper understanding of these issues. > > HTH, and read the docs. This does help, thank you. I have obviously read the docs, since I can use HTMLParser enough to find this behaviour. I don't find the docs to be very explanatory (perhaps I'm reading the wrong docs) and I think they assume you already know a lot about HTML and parsing, which may be necessary assumptions but are not necessarily true... -- http://mail.python.org/mailman/listinfo/python-list
Need help parsing with pyparsing...
I'm trying to parse with pyparsing but the grammar I'm using is somewhat unorthodox. I need to be able to parse something like the following: UPPER CASE WORDS And Title Like Words ...into two sentences: UPPER CASE WORDS And Title Like Words I'm finding this surprisingly hard to do. The problem is that pyparsing implicitly assumes whitespace are ignorable characters and is (perhaps necessarily) greedy with its term matching. All attempts to do the described parsing either fails to parse or incorrectly parses so: UPPER CASE WORDS A nd Title Like Words Frankly, I'm stuck. I don't know how to parse this grammar with pyparsing. Does anyone know how to accomplish what I'm trying to do? Thank you... -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help parsing with pyparsing...
"Paul McGuire" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On Oct 22, 4:18 am, "Just Another Victim of the Ambient Morality" > <[EMAIL PROTECTED]> wrote: >> I'm trying to parse with pyparsing but the grammar I'm using is >> somewhat >> unorthodox. I need to be able to parse something like the following: >> >> UPPER CASE WORDS And Title Like Words >> >> ...into two sentences: >> >> UPPER CASE WORDS >> And Title Like Words >> >> I'm finding this surprisingly hard to do. The problem is that >> pyparsing >> implicitly assumes whitespace are ignorable characters and is (perhaps >> necessarily) greedy with its term matching. All attempts to do the >> described parsing either fails to parse or incorrectly parses so: >> >> UPPER CASE WORDS A >> nd Title Like Words >> >> Frankly, I'm stuck. I don't know how to parse this grammar with >> pyparsing. >> Does anyone know how to accomplish what I'm trying to do? >> Thank you... > > By the way, are these possible data lines?: > > A Line With No Upper Case Words > A LINE WITH NO TITLE CASE WORDS > SOME UPPER CASE WORDS A Title That Begins With A One Letter Word Thank you for your kind help! Unfortunately, there are some ambiguities but, hopefully and surely, they'll be very rare. There will always be an uppercase section followed by a non-uppercase section. So, your examples will parse like so: A Line With No Upper Case Words ...the second example will result in a parse error... SOME UPPER CASE WORDS A Title That Begins With A One Letter Word Occasional errors can be tolerated. My problem was that my posted problem happened all the time which, of course, is not tolerable. The ambiguities you bring up, especially the last one, are interesting and I'm not sure how to deal with them without an English grammatical analysis, which is too much, especially if I'm to integrate it with pyparsing. Another problem involves the ambiguity of numbers. Some more examples, if you're interested: FAHRENHEIT 451 2000 Copies Sold 1984 Book Of The Year The last example is actually okay but the first one is honestly ambiguous. Thanks again... -- http://mail.python.org/mailman/listinfo/python-list
Is there a usenet library for Python?
Is there a Python library to communicate with a usenet server? I did a bit of googling and found some sites that suggest that you can roll your own fairly easily but, mostly, I got a lot of false positives with talk of Python libraries on usenet and I am really hoping this work has already done. Thank you... -- http://mail.python.org/mailman/listinfo/python-list
Is pyparsing really a recursive descent parser?
Is pyparsing really a recursive descent parser? I ask this because
there are grammars it can't parse that my recursive descent parser would
parse, should I have written one. For instance:
from pyparsing import *
grammar = OneOrMore(Word(alphas)) + Literal('end')
grammar.parseString('First Second Third end')
Amazingly enough, this will fail to parse!
Now, maybe I have no idea what I'm talking about but shouldn't a
recursive descent parser recursively descend through all possible rule
combinations to discover one that works? Why does pyparsing fail to parse
this? Is there a way to get pyparsing to parse a grammar like this?
Thank you...
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is there a usenet library for Python?
"Grant Edwards" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On 2007-10-30, Just Another Victim of the Ambient Morality > <[EMAIL PROTECTED]> wrote: > >> Is there a Python library to communicate with a usenet server? > > Which protocol are you interested in, NNTP (for reading/posting > from a client) or the other one that hosts use to transfer news > feeds amongst themselves (C-NEWS)? If you google for Python > and the protocl name, I bet you'll find something like this: I'm interested in the former, an NNTP client. Thank you Grant and Jean-Paul (who answered this question in another post). I should have guessed at searching for "NNTP" instead of "usenet..." -- http://mail.python.org/mailman/listinfo/python-list
Re: Is pyparsing really a recursive descent parser?
to say, there will be strings that are grammatically correct for which the
parser will fail to parse. Honestly, what is the point of a recursive
descent parser if it doesn't parse correct string? If you're willing to
have correct strings unparsed, you might as well go for LALR parsing, or
some such...
In my opinion, the rule set I mentioned in my original post:
grammar = OneOrMore(Word(alphas)) + Literal('end')
...should be translated (internally) to something like this:
word = Word(alphas)
grammar = Forward()
grammar << ((word + grammar) | (word + Literal(end)))
This allows a recursive search to find the string correct without any
need for "backtracking," if I understand what you mean by that. Couldn't
pyparsing have done something like this?
> Your example did not include either of the alternation classes,
> MatchFirst or Or. These classes implement a form of backtracking on
> the stack, that if we descend into an expression on the list of
> alternatives, and that expression fails, then MatchFirst or Or will
> back up to the same starting location and try the next alternative.
> (MatchFirst is an "eager" matcher, in that it will pick the first
> matching expression in its list - Or is an "exhaustive" matcher, in
> that it will evaluate all of the alternatives, and select the longest
> match.)
I guess I was hoping that I could simply specify, mathematically, a
grammar and have the software Do The Right Thing(tm)...
> The Wikipedia entry for "Recursive Descent Parser" describes this
> parser model as a "predictive parser", and later goes on to say that
> some (uncited) authors equate "predictive parser" with "recursive
> descent parsers". The article makes a special distinction for a
> "recursive parser with backup", which is what I believe the OP was
> asking for. Yes, pyparsing is definitely *not* a "recursive descent
> parser with backup." The solution, as you correctly posted, is to add
> a negative lookahead. NotAny is also represented using the '~'
> operator.
>
> So I will take my stance with the uncited authors who lump predictive
> parsers in with recursive descent parsers.
Well, the good thing about Wikipedia is that, if you don't like the
definition on the page, you're welcome to change it! Although, I'd
recommend discussing it on the talk page before you do, just to make sure
there isn't a good reason for the page to be as it is...
Thank you...
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is pyparsing really a recursive descent parser?
"Paul McGuire" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On Nov 3, 12:33 am, "Just Another Victim of the Ambient Morality"
> <[EMAIL PROTECTED]> wrote:
>> It has recursion in it but that's not sufficient to call it a
>> recursive
>> descent parser any more than having a recursive implementation of the
>> factorial function. The important part is what it recurses through...
>
>
>
>> In my opinion, the rule set I mentioned in my original post:
>>
>> grammar = OneOrMore(Word(alphas)) + Literal('end')
>>
>> ...should be translated (internally) to something like this:
>>
>> word = Word(alphas)
>> grammar = Forward()
>> grammar << ((word + grammar) | (word + Literal(end)))
>>
>> This allows a recursive search to find the string correct without any
>> need for "backtracking," if I understand what you mean by that. Couldn't
>> pyparsing have done something like this?
>>
>
> Dear JAVotAM -
>
> This was a great post! (Although I'm not sure the comment in the
> first paragraph was entirely fair - I know the difference between
> recursive string parsing and recursive multiplication.)
I often use hyperbole to emphasize a point. I honestly mean no offense.
That comment wasn't even meant to be fair, I was hoping to be provocative...
> You really got me thinking more about how this recursion actually
> behaves, especially with respect to elements such as OneOrMore. Your
> original question is really quite common, and up until now, my stock
> answer has been to use negative lookahead. The expression you posted
> is the first time I've seen this solution, and it *does* work.
I'm glad I got you thinking! I'd hate to be another newbie with another
of a thousand questions answered in the FAQ
Hey, are you the author of pyparsing?
> I was all set to write a cocky response on why your expression
> wouldn't work. I've seen it many times before, where people (usually
> coming from EBNF experience) implement listOfXs = OneOrMore(x) as:
>
> listOfXs = Forward()
> listOfXs << ( x + listOfXs | x )
>
> Actually, what they usually write is:
>
> listOfXs << ( listOfXs + x )
>
> but this sends pyparsing into a recursive tailspin.
>
> So I fired up SciTE and copy/pasted your code into the editor and ran
> it, and it worked just fine - this was a shock! I studied this for a
> few minutes, and then realized what was happening. First of all, I
> misread what you posted. You posted this:
>
> grammar << ((word + grammar) | (word + Literal(end)))
>
> which works. I *thought* you posted this:
>
> grammar << ((word + grammar) | word) + Literal(end)
>
> which doesn't work. In fact this behaves the same as your original
> post, except it iterates over the input string's words recursively,
> vs. repetition ins a for-loop, as is done by OneOrMore.
I'm grateful that you actually tested my code before posting your cocky
response!
> So going back to your working version, I had to see why it works.
> Initially, the first term in the MatchFirst (the '|' operator creates
> MatchFirst instances) is just the same, and by grammar referencing
> itself, it just goes word by word through the input trying to find a
> match. I'll try to visualize the steps:
>
> level"First Second Third end"
> 1 word grammar
> 2 word grammar
> 3 word grammar
> 4word grammar <- fails!
> 4word end <- fails!
> (therefore level 3 grammar fails!)
> 3 word end<-- success!!!
>
> grammar has 2 options: to match a word followed by a grammar, or to
> match a word followed by 'end'. At 4 levels deep into the Forward's
> recursion, the first option fails, because after parsing "end" as the
> initial word, there is no more text to try to match against grammar.
> Level 4's Forward then also tries to match a word followed by 'end',
> but this fails for the same reason. So at this point, the 4th level
> Forward fails to match either of its options, so it throws its
> exception back up to level 3, indicating that the first alternative,
> word followed by grammar, failed. Level 3 then moves on to see if
> word followed by the literal 'end' matches, and it does - success!
This is, literally, what it's doing. I'm not exactly a programming whiz
so I think of it a little more abstractly. In pyparsing's implem
Re: Is pyparsing really a recursive descent parser?
"Neil Cerutti" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On 2007-11-03, Paul McGuire <[EMAIL PROTECTED]> wrote:
>> On Nov 3, 12:33 am, "Just Another Victim of the Ambient Morality"
>><[EMAIL PROTECTED]> wrote:
>>> It has recursion in it but that's not sufficient to call it a
>>> recursive
>>> descent parser any more than having a recursive implementation of the
>>> factorial function. The important part is what it recurses through...
>>
>>
>>
>>> In my opinion, the rule set I mentioned in my original post:
>>>
>>> grammar = OneOrMore(Word(alphas)) + Literal('end')
>>>
>>> ...should be translated (internally) to something like this:
>>>
>>> word = Word(alphas)
>>> grammar = Forward()
>>> grammar << ((word + grammar) | (word + Literal(end)))
>>>
>>> This allows a recursive search to find the string correct without
>>> any
>>> need for "backtracking," if I understand what you mean by that.
>>> Couldn't
>>> pyparsing have done something like this?
>>>
>>
>> Dear JAVotAM -
>>
>> This was a great post! (Although I'm not sure the comment in the
>> first paragraph was entirely fair - I know the difference between
>> recursive string parsing and recursive multiplication.)
>>
>> You really got me thinking more about how this recursion actually
>> behaves, especially with respect to elements such as OneOrMore. Your
>> original question is really quite common, and up until now, my stock
>> answer has been to use negative lookahead. The expression you posted
>> is the first time I've seen this solution, and it *does* work.
>
> Is there not an ambiguity in the grammar?
>
> In EBNF:
>
> goal --> WORD { WORD } END
>
> WORD is '[a-zA-Z]+'
> END is 'end'
>
> I think it is fine that PyParsing can't guess what the composer
> of that grammar meant.
First, I don't know if that constitutes an ambiguity in the grammar.
'end' is a word but it's unambiguous that this grammar must end in a literal
'end'. You could interpret the input as just a sequence of words or you
could interpret it as a sequence of words terminated by the word 'end'. One
interpretation conforms to the grammar while the other doesn't. You would
assume that the interpretation that agrees with the grammar would be the
preferable choice and so should the program...
Secondly, even if it is an ambiguity... so what? pyparsing's current
behaviour is to return a parse error, pretending that the string can't be
parsed. Ideally, perhaps it should alert you to the ambiguity but, surely,
it's better to return _a_ valid parsing than to pretend that the string
can't be parsed at all...
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is pyparsing really a recursive descent parser?
"Neil Cerutti" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On 2007-11-04, Just Another Victim of the Ambient Morality
> <[EMAIL PROTECTED]> wrote:
>>
>> "Neil Cerutti" <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]
>>>
>>> Is there not an ambiguity in the grammar?
>>>
>>> In EBNF:
>>>
>>> goal --> WORD { WORD } END
>>>
>>> WORD is '[a-zA-Z]+'
>>> END is 'end'
>>>
>>> I think it is fine that PyParsing can't guess what the composer
>>> of that grammar meant.
>>
>> One interpretation conforms to the grammar while the other
>> doesn't. You would assume that the interpretation that agrees
>> with the grammar would be the preferable choice and so should
>> the program. Secondly, even if it is an ambiguity... so what?
>> pyparsing's current behaviour is to return a parse error,
>> pretending that the string can't be parsed. Ideally, perhaps
>> it should alert you to the ambiguity but, surely, it's better
>> to return _a_ valid parsing than to pretend that the string
>> can't be parsed at all...
>
> I wouldn't characterize it as pretending. How would you parse:
>
> hello end hello end
>
> "WORD END WORD END" and "WORD WORD WORD END" are both valid
> interpretations, according to the grammar.
...and it would be nice if the parser were to parse one of them since
they are both right. Having more than one right answer is not the same as
having no answer, which is what pyparsing claims...
> As soon as you remove the ambiguity from the grammar, PyParsing
> starts to work correctly.
This is simply not true. Try this:
grammar = OneOrMore(Word(alphas)) + Literal('end') + Literal('.')
grammar.parseString('First Second Third end.')
...again, this will fail to parse. Where's the ambiguity?
Besides, parsing ambiguous grammars is a useful feature. Not all
grammars being parsed are designed by those doing the parsing...
> Consider writing a recursive decent parser by hand to parse the
> language '[ab]+b'.
>
> goal --> ab_list 'b'
> ab_list --> 'a' list_tail
> ab_list --> 'b' list_tail
> list_tail --> 'a' list_tail
> list_tail --> 'b' list_tail
> list_tail --> null
>
>
> The above has the exact same bug (and probably some others--I'm
> sorry unable to test it just now) as the PyParsing solution.
>
> The error is in the grammar. It might be fixed by specifying that
> 'b' must be followed by EOF, and then it could be coded by using
> more than one character of lookahead.
I don't exactly understand the syntax you used to describe the
productions of your recursive descent parser so not only did I not follow it
but I couldn't make out the rest of your post. Could you explain in a
little more detail? The last part that points to 'null' is especially
confusing...
As demonstrated earlier, it's not just the grammar. There are
situations that are unambiguous that pyparsing can't parse simply and
there's no reason for it.
Besides, ambiguous grammars are a fact of life and some of us need to
parse them. It's usually okay, too. Consider a previous example:
grammar = OneOrMore(Word(alphas)) + Literal('end')
While you may consider this inherently ambiguous, it's usually not.
That is to say, as long as it is rare that 'end' is used not at the end of
the string, this will simply parse and, yet, pyparsing will consistently
fail to parse it...
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is pyparsing really a recursive descent parser?
"Neil Cerutti" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On 2007-11-04, Just Another Victim of the Ambient Morality
> <[EMAIL PROTECTED]> wrote:
>>> Consider writing a recursive decent parser by hand to parse
>>> the language '[ab]+b'.
>>>
>>> goal --> ab_list 'b'
>>> ab_list --> 'a' list_tail
>>> ab_list --> 'b' list_tail
>>> list_tail --> 'a' list_tail
>>> list_tail --> 'b' list_tail
>>> list_tail --> null
>>>
>>>
>>> The above has the exact same bug (and probably some others--I'm
>>> sorry unable to test it just now) as the PyParsing solution.
>>>
>>> The error is in the grammar. It might be fixed by specifying that
>>> 'b' must be followed by EOF, and then it could be coded by using
>>> more than one character of lookahead.
>>
>> I don't exactly understand the syntax you used to describe the
>> productions of your recursive descent parser so not only did I not follow
>> it
>> but I couldn't make out the rest of your post. Could you explain in a
>> little more detail? The last part that points to 'null' is especially
>> confusing...
>
> It's the BNF spelling of
>
> goal --> ab_list 'b'
> ab_list --> ab { ab }
> ab --> 'a' | 'b'
>
> The null is to say that list_tail can match nothing, i.e, an
> empty string.
>
> Then, in the Parser class, every method (except for match, which
> is used as a central place to consume characters) corresponds to
> one of the productions in the BNF. Breaking things down into
> BNF-based productions often makes implementation, debugging and
> code generation easier.
>
> PyParsing saves me that stop, since I can often directly
> implement the EBNF using PyParsing.
Okay, I see that now, thank you.
Your statement from the previous post:
>> Consider writing a recursive decent parser by hand to parse
>> the language '[ab]+b'.
>>
>> goal --> ab_list 'b'
>> ab_list --> 'a' list_tail
>> ab_list --> 'b' list_tail
>> list_tail --> 'a' list_tail
>> list_tail --> 'b' list_tail
>> list_tail --> null
>>
>>
>> The above has the exact same bug (and probably some others--I'm
>> sorry unable to test it just now) as the PyParsing solution.
...merely demonstrates that this grammar is similarly ambiguous. There
are many ways to parse this correctly and pyparsing chooses none of these!
Instead, it returns the same error it does when the string has no
solutions...
>> As demonstrated earlier, it's not just the grammar. There are
>> situations that are unambiguous that pyparsing can't parse
>> simply and there's no reason for it.
>
> Yes, many parser generators have many more limitations than just
> the requirement of an unambiguous grammar.
Yes, but a recursive descent parser? I expect such things from LALR and
others, but not only do I expect a recursive descent parser to correctly
parse grammars but I expect it to even parse ambiguous ones, in that it is
the only technique prepared to find more than one solution...
>> Besides, ambiguous grammars are a fact of life and some of us
>> need to parse them. It's usually okay, too. Consider a
>> previous example:
>>
>> grammar = OneOrMore(Word(alphas)) + Literal('end')
>>
>> While you may consider this inherently ambiguous, it's usually
>> not. That is to say, as long as it is rare that 'end' is used
>> not at the end of the string, this will simply parse and, yet,
>> pyparsing will consistently fail to parse it...
>
> I believe there's no cure for the confusion you're having except
> for implementing a parser for your proposed grammar.
> Alternatively, try implementing your grammar in one of your other
> favorite parser generators.
I believe there is a cure and it's called recursive descent parsing.
It's slow, obviously, but it's correct and, sometimes (arguably, often),
that's more important the execution speed.
I spent this morning whipping up a proof of concept parser whose
interface greatly resembles pyparsing but, baring unknown bugs, works and
works as I'd expect a recursive descent parser to work. I don't know Python
very well so the parser is pretty simple. It only lexes single characters
as tokens. It only supports And, Or, Optional, OneOrMore and ZeroOrMore
rules but I already think this is a rich set of rules. I'm sure others can
be added. Finally, I'm not sure it's safely copying all its parameter input
the same way pyparsing does but surely those bugs can be worked out. It's
merely a proof of concept to demonstrate a point.
Everyone, please look it over and tell me what you think.
Unfortunately, my news client is kind of poor, so I can't simply cut and
paste the code into here. All the tabs get turned into single spacing, so I
will post this link, instead:
http://theorem.ca/~dlkong/new_pyparsing.zip
I hope you can all deal with .zip files. Let me know if this is a
problem.
Thank you...
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is pyparsing really a recursive descent parser?
"Neil Cerutti" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On 2007-11-04, Just Another Victim of the Ambient Morality
> <[EMAIL PROTECTED]> wrote:
>> "Neil Cerutti" <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]
>>> I believe there's no cure for the confusion you're having except
>>> for implementing a parser for your proposed grammar.
>>> Alternatively, try implementing your grammar in one of your other
>>> favorite parser generators.
>>
>> I believe there is a cure and it's called recursive descent
>> parsing. It's slow, obviously, but it's correct and, sometimes
>> (arguably, often), that's more important the execution speed.
>>
>> I spent this morning whipping up a proof of concept parser
>> whose interface greatly resembles pyparsing but, baring unknown
>> bugs, works and works as I'd expect a recursive descent parser
>> to work. I don't know Python very well so the parser is pretty
>> simple. It only lexes single characters as tokens. It only
>> supports And, Or, Optional, OneOrMore and ZeroOrMore rules but
>> I already think this is a rich set of rules. I'm sure others
>> can be added. Finally, I'm not sure it's safely copying all
>> its parameter input the same way pyparsing does but surely
>> those bugs can be worked out. It's merely a proof of concept
>> to demonstrate a point.
>> Everyone, please look it over and tell me what you think.
>> Unfortunately, my news client is kind of poor, so I can't
>> simply cut and paste the code into here. All the tabs get
>> turned into single spacing, so I will post this link, instead:
>>
>> http://theorem.ca/~dlkong/new_pyparsing.zip
>
> Your program doesn't necessarily address the ambiguity in the
> grammar in question, since right now it is only a recognizer.
> Will it be hard to get it to return a parse tree?
Hey, it's only a proof of concept. If you can parse the tree, surely
you can record what you parsed, right?
Did you notice that the parse() functions have the rather serious bug of
not returning how much of the string they could parse? It just so happens
that the contstructions that I made only ever had to increment the matches
by one, so they just happen to work. That's an easy bug to fix but a pretty
major one to have overlooked. Hence, my enthusiasm for input...
> The grammar in your implementation is:
>
>>>> goal = OneOrMore(RuleAnd('a') | RuleAnd('b')) + RuleAnd('b')
>>>> goal.parse(0, 'ab')
> True
>>>> goal.parse(0, 'ba')
> False
>>>> goal.parse(0, 'b')
> False
>>>> goal.parse(0, 'aaab')
> True
>>>> goal.parse(0, 'abc')
> True
>
> So far so good. :)
Good! Keep hammering at it!
More importantly, study it to understand the idea I'm trying to convey.
This is what I thought a recursive descent parser would do...
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is pyparsing really a recursive descent parser?
"Kay Schluehr" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On Nov 4, 10:44 pm, "Just Another Victim of the Ambient Morality" > <[EMAIL PROTECTED]> > >> I believe there is a cure and it's called recursive descent parsing. >> It's slow, obviously, but it's correct and, sometimes (arguably, often), >> that's more important the execution speed. > > Recursive decendent parsing is not necessarily slow but from your > remarks above I infer you want a general RD parser with backtracking: > when one rule doesn't match, try another one to derive the current > symbol in the input stream. I think I've just discovered a major hurdle in my understand of the problem. You keep saying "with backtracking." Why? Isn't "backtracking" inherent in recursion? So, why can't these alleged "recursive descent parsers" find valid parsings? How are they not already backtracking? What was the point of being recursive if not to take advantage of the inherent backtracking in it? Obviously, these parsers aren't recursing through what I think they should be recursing. The question is "why not?" Correct me if I'm wrong but I'm beginning to think that pyparsing doesn't typically use recursion, at all. It only employs it if you create one, using the Forward class. Otherwise, it does everything iteratively, hence the lack of "backtracking." > I'm not sure one needs to start again with a naive approach just to > avoid any parser theory. For a user of a parser it is quite important > whether she has to wait 50 seconds for a parse to run or 50 > milliseconds. I don't like to compromise speed for implementation > simplicity here. This attitude is all too prevalent among computer professionals... Of course it's a useful thing to shield users from the intricacies of parser theory! Just as much as it is useful to shield drivers from needing automotive engineering or software users from programing. How many people have come to this newsgroup asking about anomalous pyparsing behaviour, despite their grammars being mathematically correct. Think of it this way. You can force all the clients of pyparsing to duplicate work on figuring out how to massage pyparsing to their grammars, or you can do the work of getting pyparsing to solve people's problems, once. That's what a library is supposed to do... Finally, I can't believe you complain about potential speed problems. First, depending on the size of the string, it's likely to be the difference between 2ms and 200ms. Secondly, if speed were an issue, you wouldn't go with a recursive descent parser. You'd go with LALR or the many other parsing techniques available. Recursive descent parsing is for those situations where you need correctness, regardless of execution time. These situations happen... I've said this before, albeit for a different language, but it applies to Python just as well. I don't use Python to write fast code, I use it to write code fast. If _you_ "don't like to compromise speed for implementation simplicity" then you have a plethora choices available to you. What about the guy who needs to parse correctly and is unconcerned about speed? -- http://mail.python.org/mailman/listinfo/python-list
