Embed vtk window in a QTabWidget
Hi: I know this may not be the right place to post this but I found some other PyQt questions and I am desperate. My app is the Window class object below and I am trying to embed a QVTKRenderWindowInteractor class called ConeWindow in its QTabWidget. First of all running ConeWindow gives out QPainter::begin:, QPainter::save:, QPainter::setClipRegion:, and QPainter::restore: messages. This may be what is crashing the Window class when I embed it. Can somebody help me here? Thanks. --- #!/usr/bin/env python from PyQt4 import QtGui, QtCore import vtk from vtk.qt4.QVTKRenderWindowInteractor import QVTKRenderWindowInteractor import sys class Window(QtGui.QMainWindow): def __init__(self, parent=None): super(Window, self).__init__(parent) self.treeArea = QtGui.QTreeWidget() self.textArea = QtGui.QTextEdit() self.viewArea = QtGui.QTabWidget() self.msgArea = QtGui.QTextBrowser() # Add tabs self.modelTab = ConeWindow(self) #self.modelTab = QtGui.QTextBrowser() self.reportTab = QtGui.QTextBrowser() self.viewArea.addTab(self.modelTab, Model) self.viewArea.addTab(self.reportTab, Report) # Window area splitters self.vSplitter = QtGui.QSplitter(QtCore.Qt.Vertical) self.vSplitter.addWidget(self.viewArea) self.vSplitter.addWidget(self.msgArea) self.hSplitter = QtGui.QSplitter(QtCore.Qt.Horizontal) self.hSplitter.addWidget(self.treeArea) self.hSplitter.addWidget(self.textArea) self.hSplitter.addWidget(self.vSplitter) # Assign mainwindow self.setCentralWidget(self.hSplitter) class ConeWindow(QVTKRenderWindowInteractor): def __init__(self, parent=None): QVTKRenderWindowInteractor.__init__(self, parent) self._parent = parent self.vrenderer = vtk.vtkRenderer() self.renderWindow = self.GetRenderWindow() self.renderWindow.AddRenderer(self.vrenderer) self.iren = self.renderWindow.GetInteractor() # self.cone = vtk.vtkConeSource() self.cone.SetResolution(8) self.coneMapper = vtk.vtkPolyDataMapper() self.coneMapper.SetInput(self.cone.GetOutput()) self.coneActor = vtk.vtkActor() self.coneActor.SetMapper(self.coneMapper) self.vrenderer.AddActor(self.coneActor) self.iren.Initialize() if __name__ == '__main__': app = QtGui.QApplication(sys.argv) widge = Window() widge.show() sys.exit(app.exec_()) -- Kene :: kemen...@gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Running external module and accessing the created objects
Michael Torrie torriem at gmail.com writes: It's not possible to setuid a python script, so I don't see how execfile or exec is any more dangerous than the user creating a shell script that rm -rf * things, and then running it. Bash exec's scripts all the time that users create and provide. How is this different and what issues did you have in mind, exactly? This is close to my reasoning too, although I appreciate Dave's concern. -- http://mail.python.org/mailman/listinfo/python-list
Re: Running external module and accessing the created objects
Dave Angel davea at davea.name writes: The __import__() function is defined http://docs.python.org/2/library/functions.html#__import__ Thanks. The name of the imported file will change with each user and for each project so according to the this reference using this in my situation makes sense. appname = myapp usermodule = __import__(appname, globals(), locals(), [], -1) And now you can use usermodule as though you had imported it in the usual way. Thanks. This worked! I was using __import__ without the other arguments before. I guess did not think it will work :-) As for my other caveat, I've said it before in this thread. Make sure you don't ever load a module by more than one name, or you'll end up with a mess. And that includes the original script, which is loaded by the name '__main__' You also should avoid any circular import, as it can be very tricky to deal with them. The two programs are separate, there is no fear of a circular import. Also, I need only a function to get access to the objects in the other module so the import is inside the function... no fear of ending up in a mess. Thanks. I guess this makes more sense than execfile and it works. -- http://mail.python.org/mailman/listinfo/python-list
Re: Running external module and accessing the created objects
Here's the answer to this question.
The summary of the question: how to run a module (called myapp.py) from
another module (called myappwin.py) and be able to access the namespace of
myapp.py from myappwin.py.
--
# contents of myapp.py
import math
class MyApp(object):
def __init__(self):
super(MyApp, self).__init__()
self.name = MyAppName
def testFunction():
boke = Smilling
print math.sin(1), boke
-
# contents of myappwin
def test():
dic = {}
execfile(myapp.py, dic)
testObj = dic[MyApp]() # access MyApp class
dic[testFunction]()# execute testFunction
print testObj.name # print string
test()
-
# OUTPUT
$ python myappwin.py
0.841470984808 Smilling
MyAppName
--
Kene
::
kemen...@gmail.com
--
http://mail.python.org/mailman/listinfo/python-list
Re: Running external module and accessing the created objects
Dave Angel wrote: On 03/11/2013 07:57 PM, Kene Meniru wrote: I hope you're just kidding. execfile() and exec() are two of the most dangerous mechanisms around. import or __import__() would be much better, as long as your user hasn't already run myapp.py as his script. It does what I want. Security is another issue and I understand but can't help it until I find another solution. import does not do what I want. How does __import__() work and what do you mean as long as your user hasn't already run myapp.py as his script.? -- Kene :: kemen...@gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Running external module and accessing the created objects
Dave Angel wrote: On 03/11/2013 07:57 PM, Kene Meniru wrote: I hope you're just kidding. execfile() and exec() are two of the most dangerous mechanisms around. import or __import__() would be much better, as long as your user hasn't already run myapp.py as his script. Tried __import__ and it seems to execute the myapp.py just like execfile however it only provides access to objects defined in the module myapp.py only. Like I mentioned, my program has multiple packages and the objects myappwin needs access to are stored in an object in another module called doc.py. - myapp.py provides the functions used to describe 3D objects - app.py is imported into myapp.py and is called by the functions after they create the 3D objects. - app.py uses another module called doc.py which app.py imports to save the objects in a class with a dictionary. - myappwin needs to access the dictionary in the class inside the doc module. -- Kene :: kemen...@gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Running external module and accessing the created objects
Steven D'Aprano wrote: What do you mean, objects are saved in another object? doc.py has a dictionary. When the user describes a wall, it is passed to the doc object to be saved in the dictionary. What happens if the user launches appwin with a different argument? If appwin can only take one, compulsory, argument, then it's silly to require it as an argument. Just have appwin automatically import user.py, and do whatever it needs. I guess my description does not come across well. I thought user.py sounded like it is, a user created file. It will be named differently for each user to created different types of 3D objects. It does not make sense to expect every user to name their design file the same. So there will have to be a differently named single argument for buildeswin. This makes no sense to me. Are you saying that appwin opens a text editor that allows the user to edit the user.py source code? No. appwin opens an opengl (pyglet.window.Window()) graphics window as I mentioned. I don't know. How does user.py create the objects? Suppose it users a function called create. Then you would do this in appwin: import user user.create() I have tried importing user.py and/or app.py. However there is no single command to call. My program is designed to assist in the building design process. It is a big program and the creation of building components takes quite a few steps. I do not want to support these steps in a graphics window which is why the user uses any text editor they prefer to create user.py. I want appwin.py (which has a graphics window) to be able to access objects stored in doc.py (which has a dictionary) after a command like python user.py so that the objects saved in doc.py after execution can be retrieved and drawn in appwin.py. What do you mean by view() is encounted? This is a command that the user can enter in user.py. app.py will then encounter this command as python parses the file. How would you access the objects stored in doc.py? Suppose you access them using a list called list_of_objects. Then in appwin.py: import doc for obj in doc.list_of_objects: do_something_with(obj) I have tried this but there are no objects found in the dictionary in doc.py. I am guessing that I have to execute appwin.py so that it shares the same namespace with user.py or maybe a way to access that namespace. This is the reason for my question. where you have to write the function do_something_with, to do whatever it is you want to do. -- Kene :: kemen...@gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Running external module and accessing the created objects
OK. Sorry to have caused all the confusion. Let me try this again. To use my program the user needs a script file I will call user.py. Functions from my program must be imported into this file with something like from myapp import *. myapp.py is a module in my program that has all the functions that the user needs to describe building components. There is also a main controller object that is imported into myapp.py module called app. When python parses user.py module, the functions the user has provided creates building components which are then saved in a dictionary located in an object called doc that is part of my program. The user is free to use the functions in myapp.py to describe building components. When this process is complete or when the user wants to view their work-in-progress, they have to place a function called view() on the last line in user.py. This function currently exports the components into POV-Ray or OpenSCAD format. These are CAD programs that read script files to render or create images of the described artifacts. So this means that to view their work the user needs to run python on user.py to export the building and then run POV-Ray or OpenSCAD on the exported file to see the building. I want to make it possible for the user to preview the building components without having to use the external rendering programs. I can currently have the app object provide this preview but it means that the user will have to process user.py with python then exit the graphic window each time they need to see changes. So the solution I am looking for is to have a graphic window open that watches user.py for changes. If there is a change the graphic window updates the rendition of the created components without further intervention by the user. However this means that the graphic must somehow run python to parse user.py and then be able to access the objects stored in doc so that the coordinates can be used to update the view. This is where I am having difficulty. I hope this is clearer. -- Kene :: kemen...@gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Running external module and accessing the created objects
Dave Angel wrote: On 03/09/2013 10:34 AM, Kene Meniru wrote: To use my program the user needs a script file I will call user.py. Functions from my program must be imported into this file with something like from myapp import *. And does the user run this script by doing python user.py Yes myapp.py is a module in my program that has all the functions that the user needs to describe building components. There is also a main controller object that is imported into myapp.py module called app. When python parses user.py module, You presumably mean, When Python runs the script user.py When the user types and enters at the command line: python user.py the functions the user has provided creates building components which are then saved in a dictionary located in an object called doc that is part of my program. What program is that? Looks to me like you're writing a series of modules, a framework perhaps, that is invoked by the user script. Yes. I am writing many functions and classes in many modules that work together. The user is free to use the functions in myapp.py to describe building components. When this process is complete or when the user wants to view their work-in-progress, they have to place a function called view() on the last line in user.py. Don't you mean the code in user.py has to *call* the function app.view() when they're all done with defining the components? That has nothing to do with being the last line. Well... yes. The function is app.view() but it is not called automatically by the code in user.py. The following is an example of the contents of user.py ### begin user.py # from buildes import * site(Willow_Creek_Ct, 5) Create a site with name and number of boundaries. level(level1, 3000) level(level2, 3000) Create levels with name and height. setLevel(level1) Set the current level to place objects space(Dining, 5) Create a space with 5 sides (walls) linearSide(Dining-S1, 3683, 152, 0) Initialize the first side of space called Dining offset(Dining-S1, (3000, 0, 0)) Install the first side of Dining space called Dining-S1 view(POV) Exports objects to POV-Ray format ### end user.py # This function currently exports You mean writes files into the file system? Yes. the components into POV-Ray or OpenSCAD format. These are CAD programs that read script files to render or create images of the described artifacts. So this means that to view their work the user needs to run python on user.py to export the building and then run POV-Ray or OpenSCAD on the exported file to see the building. At that point, the user.py script has completed, and Python is done, right? Yes I want to make it possible for the user to preview the building components without having to use the external rendering programs. I can currently have the app object provide this preview but it means that the user will have to process user.py with python then exit the graphic window each time they need to see changes. What changes are those? You can't change a script while it's executing. Could you clarify this so I can rethink the following paragraph? Working on the user.py is an iterative process. The user adds new objects or changes the parameters of the objects already there and envokes python user.py each time to see the changes made. Just like using a program like LaTeX. You edit your text file and run LaTeX on the file to see the changes you made. The process continues until you finish the document. So the solution I am looking for is to have a graphic window open that watches user.py for changes. If there is a change the graphic window updates the rendition of the created components without further intervention by the user. However this means that the graphic must somehow run python to parse user.py and then be able to access the objects stored in doc so that the coordinates can be used to update the view. This is where I am having difficulty. -- Kene :: kemen...@gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Running external module and accessing the created objects
Rick Johnson wrote: On Saturday, March 9, 2013 9:34:53 AM UTC-6, Kene Meniru wrote: Interactive Input Create an interactive environment where the user can enter commands directly into the namespace using your API in real time, then when he is ready to see the result of those commands, he can call display command or push a display button and the App will run the appropriate outside programs to show the visualization. Scripts loaded at runtime If you prefer the user to write scripts, and then have your App read these scripts (and create visualizations from the commands within the scripts) then the only difference between step 1 and step 2 is *when* the commands are interpreted. In this case your app will *load* the scripts AFTER they are completely written (this could be done automatically by the app at runtime IF the path to these scripts is known, or could be accomplished by the user picking files in a dialog (Menu-RunScript). Please see my last response to Dave Angel. I think it is possible for a program to watch a file. I am not interested in menus which is why I am going this route. I could easily use PyQt to make this but I am not interested in graphical user interfaces. Are you are familiar with LaTeX? That is the system I very much want to emulate. I think you are trying to create step 1 without the interactive environment. This is your mistake. Having users work with raw files and then *somehow* watching a raw file for certain display commands (in real time) is folly. It is possible to watch files for changes without user intervention. If a change is detected (whether by file size or time) the file can be executed as all python modules can be using python FILENAME.py. How is this folly? Heck, when you edit a file in a text editor you are only seeing a representation of the file from the last time it was saved, and your app could never know when the file data and the file view where synchronized; without an asinine amount of foolish programming of course. If this is not what you want, then i suggest you create a simple representation of your code (or link to the actual code). My code is available at http://sourceforge.net/projects/buildes. The documentation is at http://buildes.sourceforge.net/. -- Kene :: kemen...@gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Running external module and accessing the created objects
Dave Angel wrote: So the solution I am looking for is to have a graphic window open that watches user.py for changes. It would then have to be a separate executable. This is my thinking too. Are you really saying you want this window to keep running after the script ends? And that somehow it notices that the user has rerun the user.py script? Or could it simply be a window created during the user.py run that stays running till it's closed, which ends the script as well? Following the idea that it should be a separate executable, the user does not have to run the script by doing python user.py as they would normally do. The window takes this over. It sits there watching for changes to user.py such as change in file size and/or time or if the user hits the enter key while it has focus. My question really is how can the graphics window have access to the objects saved in the dictionary of the doc object after running python user.py. It need to do this to be able to use their coordinates to redraw the view. If there is a change the graphic window updates the rendition of the created components without further intervention by the user. Is running the script considered intervention? Or do you mean literally that somebody watches the script for changes (eg. by watching the timestamp)? I do not understand. What I mean is that this happens automatically. The user no longer needs to do python user.py the graphics window now should do this for the user when changes are detected in user.py by watching timestamp for example. However this means that the graphic must somehow run python to parse user.py and then be able to access the objects stored in doc so that the coordinates can be used to update the view. This is where I am having difficulty. If you really want two processes, then you should consider having the user run the the graphic app, with a commandline parameter of user.py, and have it create the user.py process. The user.py process runs till it has created all the data, then sends it via some ipc to the graphic app. Once sent, it terminates. The graphic app reads the ipc stuff, updates its graphics, then idles, watching for timestamp changes on the user.py file. This sounds interesting. What is ipc. Can you give me an example? -- Kene :: kemen...@gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Running external module and accessing the created objects
Kene Meniru wrote: Dave Angel wrote: If you really want two processes, then you should consider having the user run the the graphic app, with a commandline parameter of user.py, and have it create the user.py process. The user.py process runs till it has created all the data, then sends it via some ipc to the graphic app. Once sent, it terminates. The graphic app reads the ipc stuff, updates its graphics, then idles, watching for timestamp changes on the user.py file. This sounds interesting. What is ipc. Can you give me an example? Actually there is a possible simple solution consistent with the way my program works already. I can just provide another exporter for OpenGL that pyglet.window.Window() subclass will be able to read. So I will provide another parameter for OGL so the user can use view(OGL). When the user.py script is run, all objects in doc are converted and exported to a file that the graphics window is watching. The contents will then be used to update the view. So this means that the user or the graphics window object can run python user.py it no longer matters how. Thanks for your comments. -- Kene :: kemen...@gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Running external module and accessing the created objects
Program summary: I have a module called user.py that imports another module called app.py. Functions in app.py are used in user.py to describe 3D objects. These objects are saved in another object described in doc.py. app.py contains a function called view(). When called in user.py, it signals the end of object descriptions. Presently all objects contained in doc.py are exported to either POV-Ray or OpenSCAD file format depending on the argument given to view(). My Issues: I have decided I want to provide a preview of the objects using opengl (pyglet). So I am trying to create another module called appwin.py which the user can launch with user.py as an argument. When each object is described in user.py, I want the user to be able to switch to appwin.py, provide a signal that makes appwin.py redraw the screen to show any modifications (perhaps with the enter key). I do not want to invest much time with appwin.py now as I am still coding app.py. Right now, appwin.py just subclasses pyglet.window.Window(). I do not want to merge app.py and appwin.py. I want them to be two separate applications because I want to retain the option of either console or many different window interfaces. The problem then is: How can I run appwin.py which will then execute user.py to create the objects to be saved in doc.py. Then when view() is encountered to be able to access the objects stored in doc.py in appwin.py? Any ideas will help. -- Kene :: kemen...@gmail.com -- http://mail.python.org/mailman/listinfo/python-list
python math problem
I am trying to calculate the coordinates at the end of a line. The length and angle of the line are given and I am using the following formula: x = (math.sin(math.radians(angle)) * length) y = (math.cos(math.radians(angle)) * length) The following are sample answers in the format (x, y) to the given length/angle values of the line: 120/0 = (0.0, 25.0) 120/89 = (24.9961923789, 0.436310160932) 120/90 = (25.0, 1.53075794228e-15) 120/91 = (24.9961923789, -0.436310160932) Why am I getting a string number instead of the expected answer for 120/90 which should be (25.0, 0.0). This happens at all multiples of 90 (i.e. 180 and 270) -- Kene :: kemen...@gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Re: python math problem
Bob Brusa wrote: Kene, are you sure your length is 120? It seems to be 25. I did these calculations with length = 25 and then your numbers make perfect sense. Bob Thanks. You are right I was actually using 25 -- Kene :: kemen...@gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Re: python math problem
Joel Goldstick wrote: This is not a string, it is scientific notion for 1.53... times 10 to the -15th power. Because of rounding errors caused by doing floating point math on in binary, you get a very small number instead of 0. I was just doing some testing and it was not equating to zero. Perhaps if I rounded it up I may be more successful. -- Kene :: kemen...@gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Can't seem to start on this
Mitya Sirenef wrote: So, how many instances do you want to make.. what kind of different functionality / properties they will have? - mitya I am porting a modeling system I created using POV-Ray scene description language available at sourceforge at http://sourceforge.net/projects/kobldes/ The user can create as many marks as possible (limited by memory available). The difference between each mark are the parameters provided i.e. name, length, and position in the scene. If the user wishes to customize part of the program they must update the classes or create new ones before using it in the scene. File A in my previous illustrations can be considered the scene file. -- http://mail.python.org/mailman/listinfo/python-list
Re: Can't seem to start on this
D'Arcy J.M. Cain wrote: OK, global variables is the clue that you need to rethink this. Try to stay away from global variables as much as possible except for maybe some simple setup variables within the same file. Consider something like this instead. The global variable is not part of the LinearMark object. It will be used by ALL objects created. I understand the uneasiness with this so maybe I will make it a function so it will be set with something like: SnapSize(num) In file B: class TopClass(object): def __init__(self, snap_size, var1 = None, var2 = None): self.snap_size = snap_size self.var1 = var1 if var2 is None: self.var2 = 7 self.var3 = GO self.var4 = Static string *add class methods here* In file A: class MyClass(TopClass): def __init__(self, var1): TopClass.__init__(self, 10, var1, 8) self.var3 = STOP x = MyClass(42) x.var4 = Not so static after all As I mentioned, the file A can be considered a scene file. I do not want the user to have to create classes there. I apologize for the lack of code. I will soon have some python code so my future questions will have some examples. Thanks for the comments. -- http://mail.python.org/mailman/listinfo/python-list
Re: Can't seem to start on this
D'Arcy J.M. Cain wrote: As I mentioned, the file A can be considered a scene file. I do not I don't know what a scene file is. A scene file is applicable to programs like POV-Ray at www.povray.org. It is a file that is used to describe 3D objects such as box, sphere, polygon, etc. My program specializes this situation and allows the user to describe building components to be used in constructing houses. But you expect them to write Python code? ... Actually, I specifically do not want this. This is why in another thread (titled Parsing files in python) I was proposing developing a new language with python-PLY. After the comments here and in the PLY group, I decided it would be easier to just port the application I have now before thinking in this direction so that I am clear in my mind what I want to do with python. ... Here is a simpler example that may meet your requirements. File B: class TopClass(object): def __init__(self, snap_size): self.snap_size = snap_size def put(self, ... I understand where you are coming from and this is already being done but in modules C, D, etc, following my previous description. Module B will have the boundary classes which the user uses to interact with these other modules (C, D, etc.). In file A: class MyClass(TopClass): def __init__(self): TopClass.__init__(self, 10) x = MyClass() x.put(... Now you have a new class where every instance uses a snap size of 10. Notice that this class in what you call the user's code is only three lines. That's pretty simple for your user. If you can imagine creating hundreds of building components for each building described in the A, then you will understand that for any user (who just wants to make buildings and not program), it is not desirable to use this method. Think of LaTeX and using simple symbols to tell the computer how to lay out text. I want to do the same for architecture/building engineering. If you think that that is too complicated still then maybe the user shouldn't be writing any Python code and instead look at the various ways of parsing configuration files which they can write. Yes, I guess that is the main thing. I do not want users to have to write python code unless they are interested in customizing how the program behaves or perhaps a building component. In that case any of the other modules can be updated instead of A. Actually A will not be part of the packaged program. -- http://mail.python.org/mailman/listinfo/python-list
Re: Can't seem to start on this
D'Arcy J.M. Cain wrote: That works too. It's just that you had users writing Python code but assumed that a three line subclass was beyond them. Not requiring them to write any Python code is a better option than the first one (global variables) that you proposed. That's all I am trying to say. I understand. program behaves or perhaps a building component. In that case any of the other modules can be updated instead of A. Actually A will not be part of the packaged program. Or A becomes the script that parses the config file and runs the other code. Yes. To be more precise, later I will create A_Interface to provide the user with an interface for creating the contents of A. A_Interface will then parse A, calling B as required to create the artifact. I had wanted to jump into A_Interface using something like urwid or PyQt but it makes sense to work with A directly for now. Thanks for taking the time to understand. -- http://mail.python.org/mailman/listinfo/python-list
Re: Can't seem to start on this
Mitya Sirenef wrote: I'm not familiar with POV-Ray. I want to note that with python standard style, class names look like this: ClassName, instances look like this: instance_name; it sounds like you want LMark to be an instance? Or you want instances in A to use class naming style? Think of A as an extension of the user interface. I want to make the user's life as easy as possible and in this case, part of that is to write as few text as possible. Using the abbreviated LMark is laziness on my part. I wanted to differentiate the boundary class LinearMark, which the user will type in A from the entity class LMark which will have the actual data about a linear mark object. LMark is actually called LinearMarkData. Second, is the LMark instance only used to perform one set of actions? If that's the case, you can have users instantiate it in A and the __init__ method will do the set of actions you need -- this will be just as easy for the user as the alternative. -m So far this is working for me. I am not sure if you mean something different. I have a command in A like: Site(New Site, borderNum) # Creates a building site object in B In B, the Site class (which is a subclass of the main class that coordinates the creation of the entire building) receives this call, processes the parameters with any required calculations and calls another class called SiteData (from module C) which generates the object called New Site with the number of boundaries provided. Site then stores SiteData in a dictionary provided in its super class. The super class coordinates the creation of the entire building so all objects can interact with the properties of the objects in the dictionary (of building components). So in effect no instantiation is performed in A. The user calls classes in B with the appropriate parameters to create the building components which are then created and stored for later access by other components. -- Kene :: kemen...@gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Can't seem to start on this
Mitya Sirenef wrote: Ok but if the user creates two sites, how does he then manipulate them, if you are not binding instances in A? (e.g. you are not doing site1 = Site(New Site)). If the user only ever needs one site, that's fine. -m There can only be one site for each building(s) so the super object that coordinates the creation of the entire building, will check and deal with this situation. This is where the building knowledge kicks in and is part of why I am designing it this way. That is with an overall coordinator that has the knowledge of all objects being created and provides the means for them to communicate with each other. So onces there is a site object in the dictionary, an attempt to add a new one will be caught and an error reported to the user. -- Kene :: kemen...@gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Can't seem to start on this
Mitya Sirenef wrote: Ok but if the user creates two sites, how does he then manipulate them, if you are not binding instances in A? (e.g. you are not doing site1 = Site(New Site)). If the user only ever needs one site, that's fine. -m In case of situations where the user needs to manipulate an existing component like a side (wall) for a Space, this will be done using the name of the component to find it in the dictionary. So for example if user enters: LinearSide.put(Dining, (x,y,z)) # moves 'Dining' to x,y,z location The put function of the LinearSide boundary class finds Dining (which is an entity class called LinearSideData) in the dictionary and then allows this LinearSideData class to calculate its new location using the x,y,z values provided. -- Kene :: kemen...@gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Can't seem to start on this
Mitya Sirenef wrote: That's what I thought, just wanted to confirm. However, if your objective to make it as easy for the user as possible, is it not easier to bind dining to a name and then do this?: dining.move(x, y, z) Absolutely. I just found that out after replying to your comment! It actually decreases typing. Also discovered the module Logging. Interesting using python indeed :-) -- Kene :: kemen...@gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Can't seem to start on this
This sounds so simple but being new to python I am finding it hard to get started. I want to create a module which I will call B. There will be other modules called C, D, etc, which will most likely be imported in B. Then I want the user to import B ONLY into another file I will call A in which commands such as the following will be entered: snap_size = 10 LinearMark(name) LinearMark.put(name, length, rotation, (x,y,z)) The file A allows the user to enter commands that provide global variables as well as to use classes provided in modules C, D, etc, in the manner shown in the sample above. For example snap_size is a global setting. LinearMark(name) creates a linear mark of the provided name. LinearMark.put(...) places the LinearMark object using the provided parameters, etc. How can I make this possible? I am guessing I have to instantiate the classes in file B but typing LinearMark(name) in file A generates an error. Eventually I will provide a gui but I want to separate usage so there is no dependence on the gui to run this application. Please help. -- http://mail.python.org/mailman/listinfo/python-list
Re: Can't seem to start on this
Mitya Sirenef wrote: Where is snap_size from? Where is LinearMark from? You don't need to instantiate LinearMark in B, do it in A. I want to hide as much of the python syntax from the file A so the user just concentrates on using the classes as illustrated. snap_size is a global setting. LinearMark is a class in module C described as LMark but with the interface class as LinearMark in B. What error do you get when you instantiate LinearMark in A? Please paste. I am no longer getting errors. Am able to use the interface class described in B as follows: class Trogg(object): def __init__(self, ogle1, ogle2): self.ogle1 = ogle1 self.ogle2 = ogle2 print ogle1 print ogle2 In A I have the following: from buildes import Trogg Trogg(froken, groky) I now get the proper output from running A which is: froken groky I guess if I save the instantiation of each LinearMark in B using perhaps a dictionary, I will be able to create as many as I want in A this way? If LinearMark is imported in from C, you can do: B.py from C import LinearMark A.py from B import LinearMark lmark = LinearMark(name) lmark.put(...) Or do you want to use class method of LinearMark? Since you don't provide any code, it's really hard to tell what you're doing HTH, -m Sorry, my problem is not so clear. I hope the information I have provided above will help you understand more. Thanks. -- http://mail.python.org/mailman/listinfo/python-list
Re: Parsing files in python
Chris Angelico wrote: I'm hoping you meant for that to be public; if not, my apologies for forwarding a private message. On Mon, Dec 24, 2012 at 8:45 PM, Kene Meniru kene.men...@illom.org wrote: Chris Angelico wrote: from povray_macros import * Am afraid you misunderstood my post. The file format I described is not an attempt to re-create or modify a python environment. I do not wish to be able to import python macros but other text files similar to the one I described. Yep. There are two possibilities: Either you create a program that reads in a file of format you invent, or you make a set of Python functions and classes that mean that the format is actually a Python script. Instead of writing a file parser, you use Python's, and the program you write is actually a module rather than a top-level application. Actually, I think I mean what you are saying. Let me repeat what I understand maybe I am understanding it wrong. You are saying I can create a python module that can parse this file format without using a system like python-ply? I know how to parse strings using python but considering that text files that describe a whole building may be quite large I thought perhaps the re module may not be adequate. Producing output on stdout is one of the easiest and most standard ways to export content. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Parsing files in python
Chris Angelico wrote: On Mon, Dec 24, 2012 at 9:32 PM, Kene Meniru kene.men...@illom.org wrote: You are saying I can create a python module that can parse this file format without using a system like python-ply? I know how to parse strings using python but considering that text files that describe a whole building may be quite large I thought perhaps the re module may not be adequate. Effectively, what you do is leverage the Python parser. Your script would look like this: possible user file content for parsing # Boiler-plate to make this work from pypovray import * # in the following the python interface program reads # the contents of the file other.file as if its content # were located at this point. import other.file #In the following the python interface makes snap_size a # global parameter snap_size = 10 # In the following buildingLevel is a class (or function) that is # called and passed the parameters in parenthesis. buildingLevel(FirstLevel, 3000) # In the following snapOffset is a class that is # called and passed the parameters in parenthesis. snapOffset(Closet-S1_r1, Closet-S2_r3, (0,0,0)) end of user file content Note the extreme similarity to your original example. Everything between the two snip-lines is perfectly legal Python code. (The semantics of a Python import aren't quite the same as a C preprocessor #include, so that might need a little tweaking, depending on what you wanted to achieve there. Possibly from other.file import * would do it.) Instead of writing a file parser, with all the complexities that that entails, all you need to write is a set of functions/classes that can be invoked. The only part that doesn't work cleanly is the vector, since its syntax doesn't work in Python. You'll need to use round brackets instead of angle ones, as in the above example, and on output to Python, translate them. But that's fairly straight-forward, and by this method, you get *everything else* done for you - parsing, nesting of function calls, the entire Python standard library... the works. ChrisA Thanks. This makes sense and it is something I can start right away porting my code. Sincerely glad I voiced my thoughts. The import directive will have to be tackled later but that is not for at least a year or so :-) -- http://mail.python.org/mailman/listinfo/python-list
Parsing files in python
Hello: I am writing a program that is made up of a collection of POV-Ray macros. POV-Ray is available at povray.org. It is a ray-tracing program that reads a scene description language (SDL) to create photo-realistic images. At this time my program (for modeling building information) is so huge that I am finding it difficult managing the macros and I am not even near completion. I am hoping to move this program to python and am wondering the best way to approach this. I would like to model my program after LaTeX. Basically the user writes a text file using certain key words and numbers and my python program reads this file, calls the classes that will then work together to calculate the information that is needed to create an accurate model. The result of this calculation will be an output to another text file in the appropriate format such as POV-Ray SDL, OpenSCAD script, etc. This file output can then be rendered by the corresponding program to produce the actual 3D model. The macros I have now currently does this but like I said it is getting tedious and most importantly the fun factor is losing its strength for me. I have been advised to check out python-ply and I have come across others. I have not really tried any yet and before I dive into any one of them I was wondering what else I should know. The following is a sample of what the text file that will be processed by this proposed system will contain. I appreciate any pointers and suggestions. Thank you very much. possible user file content for parsing // in the following the python interface program reads //+ the contents of the file other.file as if its content //+ were located at this point. include other.file //In the following the python interface makes snap_size a //+ global parameter declare snap_size = 10 // In the following buildingLevel is a class that is //+ called and passed the parameters in parenthesis. buildingLevel(FirstLevel, 3000) // In the following snapOffset is a class that is //+ called and passed the parameters in parenthesis. snapOffset(Closet-S1_r1, Closet-S2_r3, 0,0,0) end of user file content It should also be possible to include comments using double-slashes, etc. Sincerely, Kene (kemen...@gmail.com) -- http://mail.python.org/mailman/listinfo/python-list
