re.compile() doesn't work under Windows?

[ddtl]

Hello everybody.

My script uses re.compile() function, and while it rans without errors
under Linux, when I ran that script under Windows I get the following
error:

Traceback (most recent call last):
  File "C:\a\projects\re.py", line 4, in ?
import re
  File "C:\a\projects\re.py", line 95, in ?
main()
  File "C:\a\projects\re.py", line 37, in main
s_exp = re.compile(op['-s'])
AttributeError: 'module' object has no attribute 'compile'

What is the problem here? re module is installed and is on the path - 
for example, the following code works and doesn't cause any errors:

import re
re.compile('a')

What else could cause such an error?


ddtl.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: re.compile() doesn't work under Windows?

[ddtl]

Thanks everybody for pointing out the problem.
And indeed, the script was named differently on Linux.

ddtl.
-- 
http://mail.python.org/mailman/listinfo/python-list

Method resolution for super(Class, obj).

[ddtl]

Hello everybody.

Consider the following code:


class A(object):
def met(self):
print 'A.met'
class B(A):
def met(self):
print 'B.met'
super(B,self).met()
class C(A):
def met(self):
print 'C.met'
super(C,self).met()
class D(B,C):
def met(self):
print 'D.met'
super(D,self).met()
d = D()
d.met()


When executed, it prints:

D.met
B.met
C.met
A.met

The book (Python in a nutshell, 2nd edition) explains:

"The solution is to use built-in type super. super(aclass, obj), 
which returns a special superobject of object obj. When we look 
up an attribute (e.g., a method) in this superobject, the lookup 
begins after class aclass in obj's MRO."

But I don't understand - MRO means that when attribute is found 
somewhere in hierarchy, the search for it stops, that is: when 
d.met() is executed, it is supposed to print 'D met', call 
super(D,self).met() which should resolve met() to be B's attribute, 
and after B's met() is executed, we should be done. Why does the 
lookup proceeds from B to C as though met() wasn't found in B? 
Indeed, lookup order (according to a new-style MRO) is B, then C 
and at last A (because of a diamond inheritance), but only when 
attribute is not found in B it is looked up in C, and only if it 
is not found neither in B nor in C it is looked up in A...

What is different here?

ddtl.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Method resolution for super(Class, obj).

[ddtl]

On 7 Sep 2006 10:42:54 -0700, in comp.lang.python you wrote:

>Let's examine what the mro order is for class D:
>>>> D.mro()
>[, , ,
>n__.A'>, ]
>
>When you call d.met(), the call dispatches to the D.met() method.
>After printing out 'D.met', you use super() to get the next class in
>the mro order, and call that class's met method.
>
>As shown with the mro(), the class after D is B.  So B.met() is called.
> Normally, we would be done.  But take a look at B's method!
>
>> class B(A):
>> def met(self):
>> print 'B.met'
>> super(B,self).met()
>
>B.met calls super, and invokes the next met method!  So, the code does
>exactly what you've asked it to do, and searches for the next class
>after B in the mro list: class C.

But when super(B,self).met() is invoked, isn't it supposed to look
at MRO order of *B*, which is:

(, , )

and B doesn't have any relation with C, that is: A's met() is the to
be called as a result. In effect, what you say impies that a call to
super() is context dependant - if super(B,self).met() is invoked as
a result of a call to D().met(), the effect is different from the effect 
of a call to B().met(). But a documentation of a super() doesn't mention
anything like that (or at least I didn't find it), and it seems a 
significant piece of information. Doesn't it imply that there should 
be another explanation?

ddtl.
-- 
http://mail.python.org/mailman/listinfo/python-list

Interpreting non-ascii characters.

[ddtl]

Hello everybody,

I want to create a script which reads files in a
current directory and renames them according to some
scheme. The file names are in Russian - sometimes 
the names encoded as win-1251, sometimes as koi8-r etc. 
I want to read in file name and convert it to list for 
further processing. The problem is that Python treats 
non-ascii characters as multibyte characters - for 
example, hex code for "Small Character A" in koi8-r is 
0xc1, but Python interprets it as a sequence of 
\xd0, \xb1 bytes.

What can I do so that Python interprets non-ascii 
characters correctly?


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Interpreting non-ascii characters.

[ddtl]

On Wed, 18 Jul 2007 08:29:58 +1000, John Machin <[EMAIL PROTECTED]> wrote:
> ...

I have a bunch of directories and files from different systems 
(each directory contains files from the same system) which are
encoded differently (though all of them are in Russian), so the
following encodings are present: koi8-r, win-1251, utf-8 etc., 
and I want to transliterate them into a regular ASCII so that they 
would be readable regardless of the system. Personally I use both 
Linux and Windows. So what I do, is read file name using os.listdir, 
convert to list ('foo.txt' => ['f', 'o', ... , 't'], except that 
file names are in Russian), transliterate (some letters in Russian 
have to be transliterated into 2 or even 3 Latin letters),
and then rename file.

It seems though that after all I solved the problem - I thought
that my Windows (2000) used win-1251 and Linux used koi8-r and
because of that I couldn't understand what are those strange 
codes I got while experimenting with locally created Cyrillic
file names, but in effect Linux uses utf-8, and Windows uses cp866,
so after getting it and reading the article you suggested I
solved the problem.

Thanks.

-- 
http://mail.python.org/mailman/listinfo/python-list