wxpython using variable with wx.statictext ignores \n
Hi, I have some wxPython code created with wxGlade that I am customizing. I have a label created under the def __init__() section of the Frame Class. It states... self.Question = wx.StaticText(self, -1, "My question...") if I insert a new line character in this string like this then the output is placed on two lines as expected. self.Question = wx.StaticText(self, -1, "My \nquestion...") Output My question I am getting the question as an argument using sys.argv[] and putting it in a variable called "question_text". The code is as follows... question_text = "My \nquestion..." self.Question = wx.StaticText(self, -1, question_text) Output My \nquestion How do I get the line text \n recognized so the break is inserted using the variable technique like what happened when I actually used a string? ...in bash you would do "$question_text". Is there comparable macro substitution in python. -- Cheers Simon Simon Cropper - Open Content Creator / Website Administrator Free and Open Source Software Workflow Guides Introduction http://www.fossworkflowguides.com GIS Packages http://www.fossworkflowguides.com/gis bash / Pythonhttp://www.fossworkflowguides.com/scripting -- http://mail.python.org/mailman/listinfo/python-list
Re: How to suppress exception printing to console?
Am 01.06.2012 05:06, schrieb Qi:
> On 2012-5-31 23:01, Ulrich Eckhardt wrote:
>> I can only guess what you are doing, maybe you should provide a simple
>> piece of code (or, rather, one C++ piece and a Python piece) that
>> demonstrates the issue. What I could imagine is that the Python
>> interpreter shuts down with something it considers an unhandled
>> exception, which it then prints to stdout before exiting. When
>> embedding, that shouldn't happen from just calling a Python function in
>> a loaded script, those should just make the error available to the C++
>> side via PyErr functions etc.
>
>
> PyRun_SimpleString("SomeCppFunc(1, 2)");
>
> SomeCppFunc is C++ function bound to Python, and in SomeCppFunc
> it detects the parameter mismatch (such as it expects the first
> parameter to be a string), it throws an exception.
> Then the C++ binding code catches the exception, and call
> PyErr_SetString to propagate it to Python.
I think this has nothing to do with the called C++ code, I guess the
same happens if you call PyRun_SimpleString("raise Exception()");.
> Then Python will print the error message to console.
> What I want to do is to suppress the error message printing...
Don't use PyRun_SimpleString() or catch the exception there. The point
is that it runs the whole string as a module, like running a script from
the commandline, and a pending exception on exit is then reported to stdout.
What I do here is that I create a module using the C API that I register
with Py_InitModule(). It contains the C++ functions exported to Python.
I then load a script using PyImport_ImportModule() and use
PyObject_GetAttrString(), PyCallable_Check() and PyObject_CallObject()
to run the main function of that script.
> Can I redirect sys.stdout in C++?
Maybe, I haven't tried. Since I require a proper main function in the
Python code anyway, I added a few more requirements, i.e. that it uses
one of the provided C++ functions for output. I think you can simply
assign "sys.stdout.write = log_string", where log_string is the provided
C++ function.
Uli
--
http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter deadlock on graceful exit
On Thu, May 31, 2012 at 3:02 PM, Matteo Landi wrote: > On Thu, May 31, 2012 at 3:42 AM, Terry Reedy wrote: >> On 5/30/2012 6:19 PM, Matteo Landi wrote: >>> >>> On May/28, Matteo Landi wrote: Hi list, recently I started to work on an application [1] which makes use of the Tkinter module to handle interaction with the user. Simply put, the app is a text widget displaying a file filtered by given criteria, with a handy feature that the window is raised each time a new line is added to the widget. The application mainly consists of three threads: the first one, the file processor, reads the file, filters the lines of interest, and pushes them into a shared queue (henceforth `lines_queue`); the second one, the gui_updater, pops elements from `lines_queue`, and schedule GUI updates using the `after_idle` method of the Tkinter module; finally the last one, the worker spawner, receives commands by the gui (by means of a shared queue, `filters_queue`), and drives the application, terminating or spawning new threads. For example, let's see what happens when you start the application, fill the filter entry and press Enter button: 1 the associated even handler is scheduled (we should be inside the Tkinter mainloop thread), and the filter is pushed into `filters_queue`; 2 the worker spawner receives the new filter, terminate a possibly running working thread, and once done, create a new file processor; 3 the file processor actually processes the file and fills the `lines_queue` with the lines matching given filter; 4 the gui updater schedules GUI updates as soon as items are pushed into `lines_queue` 5 Tkinter mainloop thread updates the gui when idle What happens when the main window is closed? Here is how I implemented the graceful shutdown of the app: 1 a quit event is scheduled and a _special_ message is pushed into both `filter_queue` and `lines_queue` 2 the gui updater threads receives the _special_ message, and terminates 3 the worker spawner receives the message, terminates the working thread and interrupts her execution. 4 Tk.quit() is called after the quit event handler, and we finally quit the mainloop Honestly speaking, I see no issues with the algorithm presented above; however, if I close the window in the middle of updates of the text widget, the applications hangs indefinitely. On the other hand, everything works as expected if I close the app when the file processor, for example, is waiting for new content to filter. I put some logging messages to analyze the deadlock (?!), and noticed that both the worker spawner and the file processor are terminated correctly. The only thread still active for some strange reasons, is the gui updater. Do you see anything wrong with the description presented above? Please say so, because I can't figure it out! >> >> >> Since no-one else answered, I will ask some questions based on little >> tkinter experience, no thread experience, and a bit of python-list reading. >> >> 1. Are you only using tkinter in one thread? (It seems like so from the >> above)? > > Yes, provided that `after_idle` queues a job for the gui thread > >> >> 2. Is root.destroy getting called, as in 24.1.2.2. A Simple Hello World >> Program in the most recent docs? (I specify 'most recent' because that >> example has been recently revised because the previous version sometimes >> left tkinter hanging for one of the code paths, perhaps similar to what you >> describe. > > No, I'm not calling the destroy method of the main window but, why > that only happens while doing gui updates? > >> >> 3. Have you tried making the gui thread the master thread? (I somehow expect >> that the gui thread should be the last to shut down.) > > No but, same question as above. > > I'm not home right now, so I will try those solutions as soon as > possible. Thanks. > > > Cheers, > Matteo > >> >> -- >> Terry Jan Reedy >> >> -- >> http://mail.python.org/mailman/listinfo/python-list > > > > -- > http://www.matteolandi.net/ Doing further investigation, I found this post [1] dated 2005, which probably explains why I'm gatting this strange deadlock. Quoting the linked article: All Tkinter access must be from the main thread (or, more precisely, the thread that called mainloop). Violating this is likely to cause nasty and mysterious symptoms such as freezes or core dumps. Yes this makes combining multi-threading and Tkinter very difficult. The only fully safe technique I have found is polling (e.g. use after from the main loop to poll a threading Queue that your thread writes). I have seen it suggested that a thread can safely use event_create to communicate with
get latest from svn
Hi All, Can some one suggest me a module to access SVN repository so that i could download any given branch. Thanks -- http://mail.python.org/mailman/listinfo/python-list
Re: wxpython using variable with wx.statictext ignores \n
On 01/06/2012 07:24, Simon Cropper wrote:
Hi,
I have some wxPython code created with wxGlade that I am customizing.
I have a label created under the def __init__() section of the Frame
Class. It states...
self.Question = wx.StaticText(self, -1, "My question...")
if I insert a new line character in this string like this then the
output is placed on two lines as expected.
self.Question = wx.StaticText(self, -1, "My \nquestion...")
Output My
question
I am getting the question as an argument using sys.argv[] and putting
it in a variable called "question_text". The code is as follows...
question_text = "My \nquestion..."
self.Question = wx.StaticText(self, -1, question_text)
Output My \nquestion
How do I get the line text \n recognized so the break is inserted using
the variable technique like what happened when I actually used a string?
...in bash you would do "$question_text". Is there comparable macro
substitution in python.
In a Python script, a \n within a plain string literal such as "My
\nquestion..." will be treated as a newline character.
If you're getting the string from the command line, a \n will be
treated as backslash '\' followed by letter 'n', so it's equivalent to
the string literal "\\n".
In Python 2, you can unescape a string using its .decode method:
>>> "My \\nquestion..."
'My \\nquestion...'
>>> "My \\nquestion...".decode("string_escape")
'My \nquestion...'
--
http://mail.python.org/mailman/listinfo/python-list
DBF records API
I'm getting towards an actual non-beta release, which means even more tests, polishings, cleaning up of various things, and actual documentation. :) However, I am wondering about my current record API: Currently, one does things like: record.scatter_fields() or record.has_been_deleted or record.record_number The reason those method names are so long is that field names are limited to 10 characters, and long method names means no possibility of name clashes. Unfortunately, Version 7 tables can have much longer field names. So, do I not ever support version 7, do I not worry about it until I get there (which could easily be a long time from now), or do I move all the methods out of the record class and make them module level functions instead? That would like: dbf.scatter_fields(record) dbf.has_been_deleted(record) dbf.record_number(record) although probably with shorter names. Thoughts? ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
understanding operator overloading
Is there a good way to trace what's going on under the hood wrt operator
overloading?
I am trying to understand what is happening in the code and output listed
below.
Why doesn't __getitem__ in mylist return the same result as the builtin
list object?
Does it have something to do with the start and stop arguments to slice?
Is the slice object making the call to __len__?
code___
class mylist():
def __init__(self, data):
self.data = data
def __len__(self):
print('len(self.data) -> self.data = {0}'.format(self.data))
return len(self.data)
def __getitem__(self, index):
print('__getitem__(index) -> index = {0}'.format(index))
return self.data[index]
if __name__ == "__main__":
alist = [1, 2, 4]
blist = mylist(alist)
print('printing alist[-4:]')
print(alist[-4:])
print('printing blist[-4:]')
print(blist[-4:])
print('printing blist[-2]')
print(blist[-2])
output_
printing alist[-4:]
[1, 2, 4]
printing blist[-4:]
len(self.data) -> self.data = [1, 2, 4]
__getitem__(index) -> index = slice(-1, 9223372036854775807, None)
[4]
printing blist[-2]
__getitem__(index) -> index = -2
2
Best,
Josh Benner
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to suppress exception printing to console?
On 2012-6-1 15:46, Ulrich Eckhardt wrote: Don't use PyRun_SimpleString() or catch the exception there. The point is that it runs the whole string as a module, like running a script from the commandline, and a pending exception on exit is then reported to stdout. Good hint, thanks. -- WQ -- http://mail.python.org/mailman/listinfo/python-list
While stack:
Can any one clarify what "while stack:" mean? Regards, David -- http://mail.python.org/mailman/listinfo/python-list
CPython 2.7: Weakset data changing size during internal iteration
I've got a bit of a problem - my project uses weak sets in multiple
areas, the problem case in particular being to indicate what objects
are using a particular texture, if any, so that its priority in OpenGL
can be adjusted to match at the same time as it being (de)referenced
by any explicit calls.
Problem is that for certain high-frequency operations, it seems
there's too much data going in and out for it to handle - the
following traceback is given to me (project path changed to protect
the innocent):
Traceback (most recent call last):
File "C:\foo\bar\game.py", line 279, in update
self.player.update()
File "C:\foo\bar\player.py", line 87, in update
PlayerBullet((self.x + 8, self.y + 9), 0, self.parent)
File "C:\foo\bar\player.py", line 96, in __init__
self.sprite = video.Sprite("testbullet", 0)
File "C:\foo\bar\video.py", line 95, in __init__
self.opengl_id = reference_texture(self, target)
File "C:\foo\bar\video.py", line 310, in reference_texture
if not video_handler.textures[target].references:
File "C:\Python27\lib\_weakrefset.py", line 66, in __len__
return sum(x() is not None for x in self.data)
File "C:\Python27\lib\_weakrefset.py", line 66, in
return sum(x() is not None for x in self.data)
RuntimeError: Set changed size during iteration
I can post the sources relevant to the traceback upon request, but
hopefully a traceback is sufficient as the most immediate problem is
in Python's libraries.
Any suggestions on what to do about this? I can't exactly throw a
.copy() in on top of the data iteration and call it good since it's
part of the standard Python library.
~Temia
--
When on earth, do as the earthlings do.
--
http://mail.python.org/mailman/listinfo/python-list
Use a locally built Tk for Python?
Hi, I have multiple Pythons locally installed so that I can test against different versions. (On a 64-bit Debian stable system.) All of them use the system's Tcl/Tk installation. However, I want to make some of them use a locally build Tcl/Tk that has a small customization. There doesn't seem to be any --with-tk or --with-tcl options for configure that would allow me to say where my local Tcl/Tk is. So I ran ./configure --prefix=/home/mark/opt/py32tkmod And then I tried editing Modules/Setup: I just uncommented and edited the _tkinter line as follows: _tkinter _tkinter.c tkappinit.c -DWITH_APPINIT \ -L/home/mark/opt/tcltk85/lib \ -I/home/mark/opt/tcltk85/include \ -I/usr/X11R6/include \ -ltk8.5 -ltcl8.5 \ -L/usr/X11R6/lib \ -lX11 But when I run ~/opt/py32tkmod/bin/python3 tkinter-test.pyw the system tk is being used not my customized one. Can anyone advise? Thanks! -- http://mail.python.org/mailman/listinfo/python-list
Re: While stack:
On Fri, 1 Jun 2012 18:59:57 +0100 (BST) David Shi wrote: > Can any one clarify what "while stack:" mean? > > Regards, > > David > Formal explanation: http://docs.python.org/reference/compound_stmts.html#while Informal introduction: http://learnpythonthehardway.org/book/ex33.html Simplistic summary: it executes the indented code under the "while" until stack evaluates to non-True. -- Corey Richardson -- http://mail.python.org/mailman/listinfo/python-list
Re: get latest from svn
On Fri, 1 Jun 2012 15:38:58 +0530 prakash jp wrote: > Hi All, > > Can some one suggest me a module to access SVN repository so that i > could download any given branch. > > Thanks Doing some basic googling, I found: http://pysvn.tigris.org/ I imagine you could also shell out. -- Corey Richardson -- http://mail.python.org/mailman/listinfo/python-list
Re: While stack:
On Sat, Jun 2, 2012 at 3:59 AM, David Shi wrote: > Can any one clarify what "while stack:" mean? It iterates as long as 'stack' has something that evaluates as true. My guess is that stack is a list, and the loop is removing elements from that list, so it'll keep going as long as there's anything in it. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: While stack:
On 01/06/2012 18:59, David Shi wrote: Can any one clarify what "while stack:" mean? By convention, an empty container is considered false and a non-empty container true in Boolean tests. Therefore, assuming that "stack" is a container, it means "while the stack isn't empty". -- http://mail.python.org/mailman/listinfo/python-list
Re: DBF records API
On 01/06/2012 18:50, Ethan Furman wrote: I'm getting towards an actual non-beta release, which means even more tests, polishings, cleaning up of various things, and actual documentation. :) However, I am wondering about my current record API: Currently, one does things like: record.scatter_fields() or record.has_been_deleted or record.record_number The reason those method names are so long is that field names are limited to 10 characters, and long method names means no possibility of name clashes. Unfortunately, Version 7 tables can have much longer field names. So, do I not ever support version 7, do I not worry about it until I get there (which could easily be a long time from now), or do I move all the methods out of the record class and make them module level functions instead? That would like: dbf.scatter_fields(record) dbf.has_been_deleted(record) dbf.record_number(record) although probably with shorter names. Thoughts? I'd probably think of a record as being more like a dict (or an OrderedDict) with the fields accessed by key: record["name"] but: record.deleted -- http://mail.python.org/mailman/listinfo/python-list
Re: understanding operator overloading
On Fri, Jun 1, 2012 at 9:39 AM, Josh Benner wrote: > > Is there a good way to trace what's going on under the hood wrt operator > overloading? > > I am trying to understand what is happening in the code and output listed > below. > > Why doesn't __getitem__ in mylist return the same result as the builtin list > object? Because your class is old-style rather than new-style since it doesn't subclass the `object` class. See http://docs.python.org/reference/datamodel.html#newstyle . Thus, you're getting the weird, more complicated, old-style semantics for the operator in question. > code___ > > class mylist(): The fix is jus to subclass `object`: class mylist(object): Or use Python version 3.x, where all classes are new-style, and old-style classes no longer exist. Note that classes need only indirectly subclass `object` to be new-style; so, if you have an actual class hierarchy, only the root of your hierarchy needs to subclass `object` (this is also why subclassing built-in types like `list` or `tuple` also results in new-style classes: the built-in types themselves are `object` subclasses). Also, as a general point of coding style, one normally omits the parentheses after the class name if one isn't subclassing anything. Cheers, Chris -- http://rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: DBF records API
MRAB wrote:
On 01/06/2012 18:50, Ethan Furman wrote:
I'm getting towards an actual non-beta release, which means even more
tests, polishings, cleaning up of various things, and actual
documentation. :)
However, I am wondering about my current record API:
Currently, one does things like:
record.scatter_fields()
or
record.has_been_deleted
or
record.record_number
The reason those method names are so long is that field names are
limited to 10 characters, and long method names means no possibility of
name clashes.
Unfortunately, Version 7 tables can have much longer field names.
So, do I not ever support version 7, do I not worry about it until I get
there (which could easily be a long time from now), or do I move all the
methods out of the record class and make them module level functions
instead? That would like:
dbf.scatter_fields(record)
dbf.has_been_deleted(record)
dbf.record_number(record)
although probably with shorter names.
Thoughts?
I'd probably think of a record as being more like a dict (or an
OrderedDict)
with the fields accessed by key:
record["name"]
but:
record.deleted
Record fields are accessible both by key and by attribute -- by key
primarily for those cases when the field name is in a variable:
for field in ('full_name','nick_name','pet_name'):
print record[field]
and since dbf record names cannot start with _ and are at most 10
characters long I've used longer than that method names... but if I want
to support dbf version 7 that won't work.
I would like to, not sure I will (it's not a need for me at work), but
prudence suggests I make the easy preparations now.
~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list
Re: CPython 2.7: Weakset data changing size during internal iteration
On 6/1/2012 11:23 AM, Temia Eszteri wrote:
I've got a bit of a problem - my project uses weak sets in multiple
areas, the problem case in particular being to indicate what objects
are using a particular texture, if any, so that its priority in OpenGL
can be adjusted to match at the same time as it being (de)referenced
by any explicit calls.
Problem is that for certain high-frequency operations, it seems
there's too much data going in and out for it to handle - the
following traceback is given to me (project path changed to protect
the innocent):
Traceback (most recent call last):
File "C:\foo\bar\game.py", line 279, in update
self.player.update()
File "C:\foo\bar\player.py", line 87, in update
PlayerBullet((self.x + 8, self.y + 9), 0, self.parent)
File "C:\foo\bar\player.py", line 96, in __init__
self.sprite = video.Sprite("testbullet", 0)
File "C:\foo\bar\video.py", line 95, in __init__
self.opengl_id = reference_texture(self, target)
File "C:\foo\bar\video.py", line 310, in reference_texture
if not video_handler.textures[target].references:
I gather that the .references attribute is sometimes/always a weakset.
To determine its boolean value, it computes its length. For regular
sets, this is sensible as .__len__() returns a pre-computed value.
File "C:\Python27\lib\_weakrefset.py", line 66, in __len__
return sum(x() is not None for x in self.data)
Given that len(weakset) is defined (sensibly) as the number of currently
active members, it must count. weakset should really have .__bool__
method that uses any() instead of sum(). That might reduce, but not
necessarily eliminate your problem.
File "C:\Python27\lib\_weakrefset.py", line 66, in
return sum(x() is not None for x in self.data)
RuntimeError: Set changed size during iteration
I can think of two reasons:
1. You are using multiple threads and another thread does something to
change the size of the set during the iteration. Solution? put a lock
around the if-statement so no other thread can change self.data during
the iteration.
2. Weakset members remove themselves from the set before returning None.
(Just a thought, in case you are not using threads).
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
Re: DBF records API
On 06/01/12 15:05, Ethan Furman wrote:
> MRAB wrote:
>> I'd probably think of a record as being more like a dict (or an
>> OrderedDict)
>> with the fields accessed by key:
>>
>> record["name"]
>>
>> but:
>>
>> record.deleted
>
> Record fields are accessible both by key and by attribute -- by key
> primarily for those cases when the field name is in a variable:
>
> for field in ('full_name','nick_name','pet_name'):
> print record[field]
>
> and since dbf record names cannot start with _ and are at most 10
> characters long I've used longer than that method names... but if I want
> to support dbf version 7 that won't work.
It seems to me that, since you provide both the indexing notation
and the dotted notation, just ensure that the methods such as
dbf.scatter_fields
*always* trump and refer to the method. This allows for convenience
of using the .field_name notation for the vast majority of cases,
but ensures that it's still possible for the user (of your API) to
use the indexing method to do things like
value = dbf["scatter_fields"]
if they have a thusly-named field name and want its value.
-tkc
--
http://mail.python.org/mailman/listinfo/python-list
Re: CPython 2.7: Weakset data changing size during internal iteration
On Fri, 01 Jun 2012 18:42:22 -0400, Terry Reedy wrote: >I gather that the .references attribute is sometimes/always a weakset. >To determine its boolean value, it computes its length. For regular >sets, this is sensible as .__len__() returns a pre-computed value. Indeed. Back when I was using 2.6 to develop, it was simply an integer counter, but that led to some difficulties in maintaining it in case some sprite objects hadn't been explicitly killed. >Given that len(weakset) is defined (sensibly) as the number of currently >active members, it must count. weakset should really have .__bool__ >method that uses any() instead of sum(). That might reduce, but not >necessarily eliminate your problem. Think it might be worth looking into submitting a patch for the next minor releases for Python if it turns out to solve the problem? Failing that, I might just have to check the truth value of the data attribute inside the weak set manually... >I can think of two reasons: > >1. You are using multiple threads and another thread does something to >change the size of the set during the iteration. Solution? put a lock >around the if-statement so no other thread can change self.data during >the iteration. > >2. Weakset members remove themselves from the set before returning None. >(Just a thought, in case you are not using threads). It's a multithreaded program to a small extent - I offload I/O operations, music handling, and a basic, optional debugger console (which I really wish I could set up to use the real interactive interpreter instead of the shoddy setup I've got now) to seperate threads, while the main logic operates in one thread due to OpenGL's issues with multiple Python threads. Since the sprite object calls to reference a texture in __init__(), that means no other thread could even safely reference the texture due to the potential of making OpenGL calls without the relevant context kept by the main thread (this has made the loading thread kind of useless, but the texture strings themselves can still be loaded into temporary memory, and other data like music still works). If the weak references removing themselves is the case, it seems like a kind of silly problem - one would imagine they'd wrap the data check in _IterationGuard in the _weakrefset.py file like they do for calls to __iter__(). Very strange. Anyway, I truly appreciate your input and suggestions. I'll see if they have any results, and if so, we can work out submitting a patch. If not, at least reading through this gave me the idea to just call the data set inside it, so I can use it as an imperfect but functional solution within the scope of my project. ~Temia -- When on earth, do as the earthlings do. -- http://mail.python.org/mailman/listinfo/python-list
Re: DBF records API
On 01/06/12 23:13, Tim Chase wrote:
On 06/01/12 15:05, Ethan Furman wrote:
MRAB wrote:
I'd probably think of a record as being more like a dict (or an
OrderedDict)
with the fields accessed by key:
record["name"]
but:
record.deleted
Record fields are accessible both by key and by attribute -- by key
primarily for those cases when the field name is in a variable:
for field in ('full_name','nick_name','pet_name'):
print record[field]
and since dbf record names cannot start with _ and are at most 10
characters long I've used longer than that method names... but if I want
to support dbf version 7 that won't work.
It seems to me that, since you provide both the indexing notation
and the dotted notation, just ensure that the methods such as
dbf.scatter_fields
*always* trump and refer to the method. This allows for convenience
of using the .field_name notation for the vast majority of cases,
but ensures that it's still possible for the user (of your API) to
use the indexing method to do things like
value = dbf["scatter_fields"]
if they have a thusly-named field name and want its value.
-tkc
I did think about *trumping* one way or the other, but both *ugh*.
Ethan:
I think offering both is over-complicating the design for no gain, and
possible complications later. For instance, what if you introduce a
method/property called "last" to get the last row of a table, it'll
cause some head-scratching as someone will suddenly have to make sure
your API changes didn't conflict with their column names (or if they've
used yours as a base and introduce methods, doesn't interfere with their
users of their version of the library...)
To most developers, I think blah["whatever"] is perfectly clear as
looking up a value via key is mostly done that way.
I suppose you could use __getitem__ to grab certain fields in one go (
as per your example - from any iterable that isn't a basestring? - and
users would probably enjoy not keep re-typing "record.xxx" and would
save you having to invent another possibly conflicting name) such as:
print record['full_name', 'nick_name', 'pet_name'] # looks clean to me
In short I totally agree with MRAB here.
Just my 2p,
Jon.
--
http://mail.python.org/mailman/listinfo/python-list
Re: other languages API to python
On Thu, May 24, 2012 at 9:25 AM, Chris Angelico wrote: > On Thu, May 24, 2012 at 9:58 PM, Rita wrote: >> Hello, >> >> A vendor provided a C, C++ and Java API for a application. They dont support >> python so I would like to create a library for it. My question is, how >> hard/easy would it be to create something like this? Is there a simple HOWTO >> or examples I can follow? Can someone shed home light on this? > > The best way would be to write something in C that exposes the API to > Python. Check out the docs on "Extending and Embedding Python": > > For Python 2.x: http://docs.python.org/extending/ > For Python 3.x: http://docs.python.org/py3k/extending/ > > You'll need to learn Python's own API, of course, but if you're a > competent C programmer, you should find it fairly straightforward. > > There's an alternative, too, though I haven't personally used it. The > ctypes module allows you to directly call a variety of C-provided > functions. > > http://docs.python.org/library/ctypes.html > http://docs.python.org/py3k/library/ctypes.html > > The resulting code isn't nearly as Pythonic as it could be if you > write a proper wrapper, but you save the work of writing C code. > > Chris Angelico > -- > http://mail.python.org/mailman/listinfo/python-list There are some wrapping libraries that may help in wrapping C/C++ for Python... Take a look at Boost::Python, Swig, Sip and Cython (personally, I like Boost::Python, but the generated code can be a bit bloated -- but not a problem unless it's a really huge library -- Cython seems nice too, but I've only made few things with it, so, I can't comment much). Cheers, Fabio -- http://mail.python.org/mailman/listinfo/python-list
Re: DBF records API
On 06/01/12 19:05, Jon Clements wrote: > On 01/06/12 23:13, Tim Chase wrote: >>dbf.scatter_fields >> >> *always* trump and refer to the method. > > I did think about *trumping* one way or the other, but both *ugh*. For the record, it sounded like the OP wanted to be able to use the dot-notation for accessing fields by name, and I think it's a pretty non-pythonic way to do it. I'd much rather just stick to purely using __getitem__ for the fields and attributes/methods for non-fields. -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: CPython 2.7: Weakset data changing size during internal iteration
On Fri, 01 Jun 2012 08:23:44 -0700, Temia Eszteri wrote: > I've got a bit of a problem - my project uses weak sets in multiple > areas, the problem case in particular being to indicate what objects are > using a particular texture, if any, so that its priority in OpenGL can > be adjusted to match at the same time as it being (de)referenced by any > explicit calls. > > Problem is that for certain high-frequency operations, it seems there's > too much data going in and out for it to handle I doubt that very much. If you are using threads, it is more likely your code has a race condition where you are modifying a weak set at the same time another thread is trying to iterate over it (in this case, to determine it's length), and because it's a race condition, it only happens when conditions are *just right*. Since race conditions hitting are usually rare, you only notice it when there's a lot of data. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: CPython 2.7: Weakset data changing size during internal iteration
On 02 Jun 2012 03:05:01 GMT, Steven D'Aprano wrote: >I doubt that very much. If you are using threads, it is more likely your >code has a race condition where you are modifying a weak set at the same >time another thread is trying to iterate over it (in this case, to >determine it's length), and because it's a race condition, it only >happens when conditions are *just right*. Since race conditions hitting >are usually rare, you only notice it when there's a lot of data. Except that the few threads I use don't modify that data at all because the functions that even touch the references set rely on OpenGL contexts along with it which are thread-bound, ergo, impossible to call without stopping the code in its tracks to begin with unless the context's explicitly shifted (which it very much isn't). And I've done some looking through the weak set's code in the intervening time; it does easily have the potential to cause this kind of problem because the weak references made are set to a callback to remove them from the data set when garbage is collected. See for yourself.: Lines 81-84, _weakrefset.py: def add(self, item): if self._pending_removals: self._commit_removals() self.data.add(ref(item, self._remove)) <-- Lines 38-44, likewise: (for some reason called in __init__ rather than at the class level, but likely to deal with a memory management issue) def _remove(item, selfref=ref(self)): self = selfref() if self is not None: if self._iterating: <-- self._pending_removals.append(item) else: self.data.discard(item) <-- self._remove = _remove The thing is, as Terry pointed out, its truth value is tested based on __len__(), which as shown does NOT set the _iterating protection: def __len__(self): return sum(x() is not None for x in self.data) Don't be so fast to dismiss things when the situation would not have made a race condition possible to begin with. ~Temia -- When on earth, do as the earthlings do. -- http://mail.python.org/mailman/listinfo/python-list
Re: DBF records API
Tim Chase wrote: On 06/01/12 19:05, Jon Clements wrote: On 01/06/12 23:13, Tim Chase wrote: dbf.scatter_fields *always* trump and refer to the method. I did think about *trumping* one way or the other, but both *ugh*. For the record, it sounded like the OP wanted to be able to use the dot-notation for accessing fields by name, and I think it's a pretty non-pythonic way to do it. I'd much rather just stick to purely using __getitem__ for the fields and attributes/methods for non-fields. It can't be *that* non-Pythonic -- we now have namedtuples which pretty much behave just like my record class (although its indexes are only numbers, not strings as well). ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: CPython 2.7: Weakset data changing size during internal iteration
On 6/1/2012 7:40 PM, Temia Eszteri wrote: Given that len(weakset) is defined (sensibly) as the number of currently active members, it must count. weakset should really have .__bool__ method that uses any() instead of sum(). That might reduce, but not necessarily eliminate your problem. Think it might be worth looking into submitting a patch for the next minor releases for Python if it turns out to solve the problem? I think a patch would be worthwhile even if this is not the source of your problem. If bool is defined as 'if any ...', that should be the code. I can think of two reasons: 1. You are using multiple threads and another thread does something to change the size of the set during the iteration. Solution? put a lock around the if-statement so no other thread can change self.data during the iteration. 2. Weakset members remove themselves from the set before returning None. (Just a thought, in case you are not using threads). In other words, it is possible that weakset.__len__ is buggy. Since you are sure that 1) is not your problem, that seems more likely now. If the weak references removing themselves is the case, it seems like a kind of silly problem - one would imagine they'd wrap the data check in _IterationGuard in the _weakrefset.py file like they do for calls to __iter__(). Very strange. While looking into the weakset code, you might check the tracker for weakset issues. And also check the test code. I have *no* idea how well that class has been exercised and tested. Please do submit a patch if you can if one is needed. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
