Re: Why it doesn't work?
Lad wrote:
I have a list
L={}
This IS a dictionary, not a list.
Now I can assign the value
L['a']=1
and I have
L={'a': 1}
but I would like to have a dictionary like this
L={'a': {'b':2}}
You need to initialise L['a'] first, before referencing L['a']['b']
So, you need to call first:
L['a'] = {}
Then you can write:
L['a']['b'] = 2
Tomasz Lisowski
--
http://mail.python.org/mailman/listinfo/python-list
Re: py vs pyc
Sakcee wrote: Hi I want to know that is .pyc files execute faster than .py files,? since both are interpreted by python , is there any speedup in using one or other.? e.g. what is the difference between runing from cmd python test.py and python test.pyc thanks When running python test.py the interpreter will first precompile the test.py source file, and then execute it. When running python test.pyc, the interpreter will go straight to the execution of the script. Tomasz -- http://mail.python.org/mailman/listinfo/python-list
Re: A simple list question.
KraftDiner wrote: I am trying to implement a two dimensional array. mylist = [[a,b,c],[d,e,f,c],[g,h,i]] So the array is of length 3 here... So how do I initialize this array and then set each object? At some point in my code I know there will be 3 lists in the list. So how do I initialize this list such that I can access them as elements... like mylist[1] = [c,f,g] in random order... Why not just say: mylist = [[], [], []] since you know, that this array will have a length of 3. Then you can safely use append. I am not quite sure, though, what you mean by accessing the elements in random order. What's the idea behind having mylist[1] = [c,f,g], when the elements c, f, and g are apread across all three internal lists, and at various position within these lists (not necessarily 1, as the mylist index suggests). Tomasz Lisowski -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: concatenate literals (using jython)
Fredrik Lundh wrote: [EMAIL PROTECTED] wrote: I'm using Jython (actually WebLogic WLST), and trying to do something really simple. I want to create a string from two function calls and a literal, like: serverport = server.getListenAddress() + ':' + server.getListenPort() This complains: TypeError: __add__ nor __radd__ defined for these operands I've looked at various references, and this seems like the way I'm supposed to do this, but I'm obviously missing something. Note that getListenPort() returns an int. Is that a problem? yes. python's string concatenation operator doesn't convert things nilly- willy (should 1+1 be 2 or 11 ?). to convert an object to a string, use str(obj). see this tutorial section for more info: http://docs.python.org/tut/node9.html#SECTION00910 /F You are right, Fredrik, but David is using Jython, so perhaps he tried to mimic the Java language behaviour, where adding ints and strings is perfectly valid :) I admit, though, that I do not know much about Jython apart from the fact, that it is somehow related to Java ... Best regards, Tomasz Lisowski -- http://mail.python.org/mailman/listinfo/python-list
Re: problem adding list values
Dave Hansen wrote: I think what you want is for cr in credlist: credits += cr Which could also be implemented as credits = reduce(lambda x,y: x+y, credlist) or even: credits = sum(credlist) Tomasz Lisowski -- http://mail.python.org/mailman/listinfo/python-list
Re: non descriptive error
Timothy Smith wrote: i try to run my app and i get this %python DutyShift.py error thats it. thats the error. mya pp was previously working, and i did make some fairly large changes to it, but i'd expect a more descriptive message then just error. anyidea where i need to start looking? It seems to me, like a result of a print statement, exexcuted somewhere (maybe in the except: clause). You may look for lines similar to: print error Tomasz Lisowski -- http://mail.python.org/mailman/listinfo/python-list
Re: bug or feature?
beza1e1 wrote: Coming back from a bug hunt, i am not sure what to think of this python behaviour. Here is a demo program: class A: def __init__(self, lst=[]): self.lst = lst a = A() b = A() b.lst.append(hallo) print a.lst # output: [hallo] The point seems to be, that lst=[] creates a class attribute (correct name?), which is shared by all instances of A. So a.lst ist the same object as b.lst, despite the fact, that object a is different to object b. It is an *instance attribute* by nature, since it does not reside in the class object, but only in its instances. The truth is, that a.lst and b.lst point to the same memory object, so it seems to behave much like the class attribute :) It is no more different from the simple fact, that two variables (attributes) may point to the same memory object, like you see below: a = b = [] a.append(hallo) print b #output: [hallo] In fact, it is usually a bad practice to assign instance attributes a reference to the compound variable, existing in an external scope. Example: aList = [] class A: def __init__(self, lst): #no default attribute! self.lst = lst a = A(aList) aList.append(hallo) print a.lst #output: [hallo] and your default value (, lst=[]) IS such an variable! The bad thing is, that the value of the instance attribute 'lst' (example above) depends on the external variable, which may be independently modified, thus modifying unexpectedly the instance attribute. The safer approach, of course is to write: class A: def __init__(self, lst): #no default attribute! self.lst = lst[:] #take a copy Summing up, is it an error, or a feature? I would say - a feature. Everyone should be aware, that the argument default values are evaluated once, and the same value (memory object) is reused at each instance creation. Best regards, Tomasz Lisowski -- http://mail.python.org/mailman/listinfo/python-list
Re: Help w/ easy python problem
[EMAIL PROTECTED] napisał(a): Actually, it is not a sin curve i need to plot, it is dots running down the page in the shape of a sin curve like this . . . etc... Seems, like a homework to me :-) Anyway, use the following hints: math.sin() is your sine function, ranging, from -1.0 to 1.0 inclusively set up a for loop printing the strings containing spaces, and one dot at the appropriate location with: - the appropriate argument increase step between the lines (print statements) - the appropriate scaling of the -1.0, 1.0 range into e.g. 0, 71, representing the 72 characters wide lines being printed. Tomasz Lisowski -- http://mail.python.org/mailman/listinfo/python-list
Re: catching all exceptions
Hello, I'd like to catch all exeptions and be able to inspect them. The simple case: I know which exceptions I'll get: # standard textbook example: try: something() except ThisException, e: print some error occurred: , str(e) The not-so-simple case: Handling all other exceptions: # nice-to-have: try: something() except *, e: print some error occurred: , type(e), str(e) Well, actually the second statement doesn't even compile... any ideas why I shouldn't be able to catch anonymous exceptions like this, or whether and how I can (and only overlooked it)? TIA! Kind Regards, Toni Try this: import sys try: something() except: info = sys.exc_info() ... and you can inspect the tuple info, which contains the exception type, value, and traceback. Best regards, Tom -- http://mail.python.org/mailman/listinfo/python-list
Re: Where is Word?
Unfortunately, I need to open/edit a (temporary) text file with Word, and those are opened by default with UltraEdit (or Notepad or..). Thanks for the tip, though. Anything else? Do I need to read the registry? g You may try to launch Word as a COM object and control it directly from Python using the COM object methods. This does not require you to know the application's path, only the COM object identifier. TLis -- http://mail.python.org/mailman/listinfo/python-list
Re: Where is Word?
Thanks, but could you pretty please post some code that does this? I'm new to Python, let alone COM.. TIA, g import win32com.client wordCOMID = Word.Application word = win32com.client.Dispatch(wordCOMID) Then you can use the methods of the word object, provided by the COM object definition. Unfortunately I don't know them - you may do a research by making a reference to the Microsoft Word type library in Visual Basic, declaring the variable of type Word.Application, and then watching the code assistant showing the available methods and properties. You may also use the object browser. Tomasz Lisowski Tomasz Lisowski [EMAIL PROTECTED] schreef in bericht news:[EMAIL PROTECTED] You may try to launch Word as a COM object and control it directly from Python using the COM object methods. This does not require you to know the application's path, only the COM object identifier. TLis -- http://mail.python.org/mailman/listinfo/python-list
Re: Strange behaviour of floating point constants in imported modules
There is no guarantee at all that a .pyc file is good for any purpose
outside the machine that produced it. In practice, however, you
*should* be able to rely on no surprises if you have the same platform
and the same version of Python; do you?
Python 2.3.5 and 2.3.3 on the test machine - it is the same major and
minor version of the interpreter. I think it should be fine. The
platform - Windows XP on both machines - difference is in the language
version of Windows, and in the locale setting of the decimal point ('.'
and ',')
How did you transfer the .pyc files from one box to the other? A
Windows installer? A ZIP file? FTP using text mode? Plain-text
attachments to an e-mail message?
E-mailed in a ZIP file
but recently we
have discovered an annoying problem. In a module, there is the following
code fragment:
Deg2Rad = math.pi/180.0
angleEPS = 0.5
angle0B = angleEPS*Deg2Rad
which calculates 'angle0B' as the angle of a half of a degree, converted
to radians. The module has been compiled on an English Windows XP
machine, and then tested on a Polish Windows XP workstation.
What was our astonishment, when various exceptions started to be raised
on a test machine (no problem on the original English-version Windows
XP). We have traced them to the fact, that both angleEPS and angle0B
were found to be ZERO (!!!), whereas in reality, angle0B is about 0.008.
What evidence do you have? Have you disassembled the .pyc file on both
boxes and diff'ed the results? Have you computed checksums on both
boxes?
I have prepared a 'debug' version of the module, printing out some
variables. The printouts on a test machine showed ZERO values, where
there should be non-zero ones (0.008). The original machine, where the
modules were compiled, showed the correct values.
And this all happened silently, without any error during the import of
the module!
What's the reason of this error? I start thinking, that it may be
related to the fact, that the decimal point on the Enlish Windows XP is
the '.' character, and on the Polish one - ','.
This is *extremely* unlikely. Firstly, you are (I understand) talking
about a .pyc file, that was produced on an English Windows box. Even
though the 180.0 and the 0.5 are visible as character strings in
the .pyc file, Python sure doesn't use the locale when it loads a .pyc
file.
If I modify the decimal point setting in the Regional Settings in the
Control Panel to the dot character '.' - everything seems to work fine.
Whenever it is set to the comma ',' - floating point constants, like 0.5
are considered ZERO by the import statement.
Secondly, even if you are talking about a .py file, Python takes
absolutely no notice of the locale when it compiles the .py file.
Polish programmers write 0.5, not 0,5. Read the language reference
manual, section 2.4.5 -- it uses ., not whatever the decimal point
character might be in your locale. If it did depend on locale, you
would need a locale declaration at the top of the file, if one wanted
.py files to be portable internationally; ever seen or heard of such a
declaration?
Right! The language syntax requires to use the dot regardless of the
locale, BUT the constants are written to the .pyc file in a string form,
probably using repr(), WHICH APPARENTLY DEPENDS ON THE LOCALE (!), when
the documentation states, that the built-in float(), str() functions are
locale-unaware (the locale module provides appropriate functions
supporting the locale).
Thirdly, if the dot was interpreted as something other than a decimal
point, then what? Perhaps assign a tuple (0, 5), or perhaps a syntax
error; zero is achieved under what conditions?
No, it is not a problem with possibly using the comma instead of a dot
in the SOURCE - there only a dot can be used. That's clear.
It's more likely that the .pyc file has been damaged somehow. AFAIK
they don't have checksums.
Very unlikely. I have made these test also directly, sharing the folder
with the .pyc files on the LAN, and running the program from the test
machine. Then, the .pyc files were not manipulated at all.
Is there a good method to avoid this kind of problems? How to make such
distributed modules really portable?
Distribute source.
Yes, that's an option, but not in this case :)
Tomasz Lisowski
--
http://mail.python.org/mailman/listinfo/python-list
Re: Strange behaviour of floating point constants in imported modules
This may be relevant to the problems you're seeing: https://sourceforge.net/tracker/?func=detailatid=305470aid=774665group_id=5470 The short story, as the tracker item paints it, is that setting LC_NUMERIC to anything other than 'C' can give results like the ones you describe---Python itself should never do this, but third parties code may. A web search for python LC_NUMERIC should turn up more about this topic, probably even some past threads on this mailing list/newsgroup. You've got the point. My code uses wxLocale class from wxPython, and sets the wxLANGUAGE_POLISH locale. After setting this locale, I have added the statement: locale.setlocale(locale.LC_NUMERIC, C) and everything seems to be normal now. I agree with the comments in the tracker item, that the float, str(), repr() functions should be locale-independent. We have the functions in the locale module, if someone needs the locale-dependent string-float conversions. -- Tomasz Lisowski -- http://mail.python.org/mailman/listinfo/python-list
Strange behaviour of floating point constants in imported modules
Hi, We are distributing our Python application as the short main script (.py file) and a set of modules compiled to the .pyc files. So far, we have always treated .pyc files as portable between platforms, but recently we have discovered an annoying problem. In a module, there is the following code fragment: Deg2Rad = math.pi/180.0 angleEPS = 0.5 angle0B = angleEPS*Deg2Rad which calculates 'angle0B' as the angle of a half of a degree, converted to radians. The module has been compiled on an English Windows XP machine, and then tested on a Polish Windows XP workstation. What was our astonishment, when various exceptions started to be raised on a test machine (no problem on the original English-version Windows XP). We have traced them to the fact, that both angleEPS and angle0B were found to be ZERO (!!!), whereas in reality, angle0B is about 0.008. And this all happened silently, without any error during the import of the module! What's the reason of this error? I start thinking, that it may be related to the fact, that the decimal point on the Enlish Windows XP is the '.' character, and on the Polish one - ','. Is there a good method to avoid this kind of problems? How to make such distributed modules really portable? Thanks in advance -- Tomasz Lisowski -- http://mail.python.org/mailman/listinfo/python-list
