Re: Problems of Symbol Congestion in Computer Languages
On Sat, 2011-02-19 at 06:29 +, Steven D'Aprano wrote: > On Fri, 18 Feb 2011 18:14:32 -0800, Westley Martínez wrote: > > >> Besides, Windows and MacOS users will be scratching their head asking > >> "xorg? Why should I care about xorg?" > > Why should I care if my programs run on Windows and Mac? Because I'm a > > nice guy I guess > > Python is a programming language that is operating system independent, > and not just a Linux tool. So you might not care about your Python > programs running on Windows, but believe me, the Python core developers > care about Python running on Windows and Mac OS. (Even if sometimes their > lack of resources make Windows and Mac somewhat second-class citizens.) You didn't seem to get my humor. It's ok; most people don't. > >> That's a limitation of the Linux virtual terminal. In 1984 I used to > >> use a Macintosh which was perfectly capable of displaying and inputting > >> non- ASCII characters with a couple of key presses. Now that we're > >> nearly a quarter of the way into 2011, I'm using a Linux PC that makes > >> entering a degree sign or a pound sign a major undertaking, if it's > >> even possible at all. It's well past time for Linux to catch up with > >> the 1980s. > > > > I feel it's unnecessary for Linux to "catch up" simply because we have > > no need for these special characters! > > Given that your name is Westley Martínez, that's an astonishing claim! > How do you even write your name in your own source code??? > > Besides, speak for yourself, not for "we". I have need for them. The í is easy to input. (Vim has a diacritic feature) It's the funky mathematical symbols that are difficult. > > When I read Python code, I only > > see text from Latin-1, which is easy to input > > Hmmm. I wish I knew an easy way to input it. All the solutions I've come > across are rubbish. How do you enter (say) í at the command line of a > xterm? I use this in my xorg.conf: Section "InputDevice" Identifier "Keyboard0" Driver "kbd" Option "XkbLayout" "us" Option "XkbVariant""dvorak-alt-intl" EndSection Simply remove 'dvorak-' to get qwerty. It allows you to use the right Alt key as AltGr. For example: AltGr+' i = í AltGr+c = ç AltGr+s = ß I don't work on Windows or Mac enough to have figured out how to do on those platforms, but I'm sure there's a simple way. Again, it's the funky symbols that would be difficult to input. > But in any case, ASCII != Latin-1, so you're already using more than > ASCII characters. > > > > Languages that > > accept non-ASCII input have always been somewhat esoteric. > > Then I guess Python is esoteric, because with source code encodings it > supports non-ASCII literals and even variables: > > [steve@sylar ~]$ cat encoded.py > # -*- coding: utf-8 -*- > résumé = "Some text here..." > print(résumé) > > [steve@sylar ~]$ python3.1 encoded.py > Some text here... I should reword that to "Languages that require non-ASCII input have always been somewhat esoteric" i.e. APL. > [...] > > A byte saved is a byte earned. What about embedded systems trying to > > conserve as much resources as possible? > > Then they don't have to use multi-byte characters, just like they can > leave out comments, and .pyo files, and use `ed` for their standard text > editor instead of something bloated like vi or emacs. Hey, I've heard of jobs where all you do is remove comments from source code, believe it or not! > [...] > > I believe dealing with ASCII is simpler than dealing with Unicode, for > > reasons on both the developer's and user's side. > > Really? Well, I suppose if you want to define "you can't do this AT ALL" > as "simpler", then, yes, ASCII is simpler. > > Using pure-ASCII means I am forced to write extra code because there > aren't enough operators to be useful, e.g. element-wise addition versus > concatenation. It means I'm forced to spell out symbols in full, like > "British pound" instead of £, and use legally dubious work-arounds like > "(c)" instead of ©, and mispell words (including people's names) because > I can't use the correct characters, and am forced to use unnecessarily > long and clumsy English longhand for standard mathematical notation. > > If by simple you mean "I can't do what I want to do", then I agree > completely that ASCII is simple. I guess it's a matter of taste. I don't mind seeing my name as westley_martinez and am so use to seeing **, sqrt(), and / that seeing the original symbols is a bit foreign! > >> And as for one obvious way, there's nothing obvious about using a | b > >> for set union. Why not a + b? The mathematician in me wants to spell > >> set union and intersection as a ⋃ b ⋂ c, which is the obvious way to me > >> (even if my lousy editor makes it a PITA to *enter* the symbols). > > > > Not all programmers are mathematicians (in fact I'd say most aren't). I > > know what those symbols mean, but some people might think "a
Re: Python Path registry Key
Hi, Thanks for replying. Yes sys.prefix works in the python shell window. But I have to find out python's path from another application running on windows. How can I access sys.prefix from that application. Thanks, Sathish On Sat, Feb 19, 2011 at 12:50 AM, Westley Martínez wrote: > On Fri, 2011-02-18 at 11:56 +0530, Sathish S wrote: > > Hi Ppl, > > > > > > I'm trying to launch IDLE from another application. For this I need > > the python directory path. I have been trying to get the Active Python > > versions path from the Windows registry. However, these registry > > entries seem not be consistent across various stations, that i > > checked. I'm reading the following resitry key to get the active > > versions path: Software\\Microsoft\\Windows\\CurrentVersion\\App Paths > > \\Python.exe. There are two entries in this key. Some stations have > > only one entry. Some do not have both. Probably they were removed > > while python was uninstall ed and was not added again when it was > > installed again. > > > > > > So what will be a good solution to get the Python path ? > > > > > > > > Thanks, > > Sathish > > > Try sys.prefix > > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: file/folder naming
On Feb 19, 1:38 am, Steven D'Aprano wrote: > On Fri, 18 Feb 2011 22:13:42 -0800, ecu_jon wrote: > > ok changed the try/except to just a file copy and got this: > > sourcepath is : > > [u'I:\\college\\spring11\\capstone-project\\facbac-009.py'] > > Note that it's a list. > > > shutil.copy2(sourcepath, > > os.path.join(destpath,os.path.basename(files))) > > Note that you are calling copy2 with the first argument as a list. > > > TypeError: coercing to Unicode: need string or buffer, list found > > Note that the error tells you exactly what is wrong. > > > yes i see the list. > > but shouldnt this "for files in sourcepath:" parse thru the list ... ? > > Yes it does. So what? You don't use files, you use sourcepath each time. > > >>> source = ['a', 'bb', 'ccc'] > >>> for x in source: > > ... print(len(source)) > ... > 3 > 3 > 3 > > -- > Steven so i changed it to shutil.copy2(files, os.path.join(destpath,os.path.basename(files))) seems to be working. in the mornig when im not bleary eyed. ill check again but this look like the fix. thanks. -- http://mail.python.org/mailman/listinfo/python-list
Re: file/folder naming
On Fri, 18 Feb 2011 22:13:42 -0800, ecu_jon wrote: > ok changed the try/except to just a file copy and got this: > sourcepath is : > [u'I:\\college\\spring11\\capstone-project\\facbac-009.py'] Note that it's a list. > shutil.copy2(sourcepath, > os.path.join(destpath,os.path.basename(files))) Note that you are calling copy2 with the first argument as a list. > TypeError: coercing to Unicode: need string or buffer, list found Note that the error tells you exactly what is wrong. > yes i see the list. > but shouldnt this "for files in sourcepath:" parse thru the list ... ? Yes it does. So what? You don't use files, you use sourcepath each time. >>> source = ['a', 'bb', 'ccc'] >>> for x in source: ... print(len(source)) ... 3 3 3 -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: file/folder naming
On Fri, Feb 18, 2011 at 10:13 PM, ecu_jon wrote: > ok changed the try/except to just a file copy and got this: > sourcepath is : [u'I:\\college\\spring11\\capstone-project\ > \facbac-009.py'] > destpath is : V:\week3 > destpath is : V:\week3\facbac-009.py > Traceback (most recent call last): > File "I:\college\spring11\capstone-project\folder.py", line 53, in > button1Click > backupfiles() > File "I:\college\spring11\capstone-project\folder.py", line 19, in > backupfiles > shutil.copy2(sourcepath, > os.path.join(destpath,os.path.basename(files))) > File "C:\Python27\lib\shutil.py", line 127, in copy2 > copyfile(src, dst) > File "C:\Python27\lib\shutil.py", line 67, in copyfile > if _samefile(src, dst): > File "C:\Python27\lib\shutil.py", line 62, in _samefile > return (os.path.normcase(os.path.abspath(src)) == > File "C:\Python27\lib\ntpath.py", line 471, in abspath > path = _getfullpathname(path) > TypeError: coercing to Unicode: need string or buffer, list found > > yes i see the list. > but shouldnt this "for files in sourcepath:" parse thru the list ... ? That doesn't matter when your actual copy2() call still refers to `sourcepath` (the list): shutil.copy2(sourcepath, os.path.join(destpath,os.path.basename(files))) ^^ I presume you want `files` here rather than `sourcepath`. Incidentally, I think `sourcepath` is poorly named given that it's a list of paths, and `files` is also poorly named given that it's a single filepath. Cheers, Chris -- "There are only two hard problems in Computer Science: cache invalidation and naming things." – Phil Karlton http://blog.rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Problems of Symbol Congestion in Computer Languages
On Fri, 18 Feb 2011 18:14:32 -0800, Westley Martínez wrote:
>> Besides, Windows and MacOS users will be scratching their head asking
>> "xorg? Why should I care about xorg?"
> Why should I care if my programs run on Windows and Mac? Because I'm a
> nice guy I guess
Python is a programming language that is operating system independent,
and not just a Linux tool. So you might not care about your Python
programs running on Windows, but believe me, the Python core developers
care about Python running on Windows and Mac OS. (Even if sometimes their
lack of resources make Windows and Mac somewhat second-class citizens.)
>> That's a limitation of the Linux virtual terminal. In 1984 I used to
>> use a Macintosh which was perfectly capable of displaying and inputting
>> non- ASCII characters with a couple of key presses. Now that we're
>> nearly a quarter of the way into 2011, I'm using a Linux PC that makes
>> entering a degree sign or a pound sign a major undertaking, if it's
>> even possible at all. It's well past time for Linux to catch up with
>> the 1980s.
>
> I feel it's unnecessary for Linux to "catch up" simply because we have
> no need for these special characters!
Given that your name is Westley Martínez, that's an astonishing claim!
How do you even write your name in your own source code???
Besides, speak for yourself, not for "we". I have need for them.
> When I read Python code, I only
> see text from Latin-1, which is easy to input
Hmmm. I wish I knew an easy way to input it. All the solutions I've come
across are rubbish. How do you enter (say) í at the command line of a
xterm?
But in any case, ASCII != Latin-1, so you're already using more than
ASCII characters.
> Languages that
> accept non-ASCII input have always been somewhat esoteric.
Then I guess Python is esoteric, because with source code encodings it
supports non-ASCII literals and even variables:
[steve@sylar ~]$ cat encoded.py
# -*- coding: utf-8 -*-
résumé = "Some text here..."
print(résumé)
[steve@sylar ~]$ python3.1 encoded.py
Some text here...
[...]
> A byte saved is a byte earned. What about embedded systems trying to
> conserve as much resources as possible?
Then they don't have to use multi-byte characters, just like they can
leave out comments, and .pyo files, and use `ed` for their standard text
editor instead of something bloated like vi or emacs.
[...]
> I believe dealing with ASCII is simpler than dealing with Unicode, for
> reasons on both the developer's and user's side.
Really? Well, I suppose if you want to define "you can't do this AT ALL"
as "simpler", then, yes, ASCII is simpler.
Using pure-ASCII means I am forced to write extra code because there
aren't enough operators to be useful, e.g. element-wise addition versus
concatenation. It means I'm forced to spell out symbols in full, like
"British pound" instead of £, and use legally dubious work-arounds like
"(c)" instead of ©, and mispell words (including people's names) because
I can't use the correct characters, and am forced to use unnecessarily
long and clumsy English longhand for standard mathematical notation.
If by simple you mean "I can't do what I want to do", then I agree
completely that ASCII is simple.
>> And as for one obvious way, there's nothing obvious about using a | b
>> for set union. Why not a + b? The mathematician in me wants to spell
>> set union and intersection as a ⋃ b ⋂ c, which is the obvious way to me
>> (even if my lousy editor makes it a PITA to *enter* the symbols).
>
> Not all programmers are mathematicians (in fact I'd say most aren't). I
> know what those symbols mean, but some people might think "a u b n c ...
> what?" | actually makes sense because it relates to bitwise OR in which
> bits are turned on.
Not all programmers are C programmers who have learned that | represents
bitwise OR. Some will say "a | b ... what?". I know I did, when I was
first learning Python, and I *still* need to look them up to be sure I
get them right.
In other languages, | might be spelled as any of
bitor() OR .OR. || ∧
[...]
> Being a person who has
> had to deal with the í in my last name and Japanese text on a variety of
> platforms, I've found the current methods of non-ascii input to be
> largely platform-dependent and---for lack of a better word---crappy,
Agreed one hundred percent! Until there are better input methods for non-
ASCII characters, without the need for huge keyboards, Unicode is hard
and ASCII easy, and Python can't *rely* on Unicode tokens.
That doesn't mean that languages like Python can't support Unicode
tokens, only that they shouldn't be the only way to do things. For a long
time Pascal include (* *) as a synonym for { } because not all keyboards
included the { } characters, and C has support for trigraphs:
http://publications.gbdirect.co.uk/c_book/chapter2/alphabet_of_c.html
Eventually, perhaps in another 20 years, digraphs like != and <= will go
the same way as t
Re: Unit testing multiprocessing code on Windows
Il Thu, 17 Feb 2011 18:31:59 -0500, Matt Chaput ha scritto: > > The problem is that with both "python setup.py tests" and "nosetests", > Maybe multiprocessing is starting new Windows processes by copying the > command line of the current process? But if the command line is > "nosetests", it's a one way ticket to an infinite explosion of processes. You can adapt this code to inhibit test execution if another process is testing yet. http://code.activestate.com/recipes/474070-creating-a-single-instance-application/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python subprocesses experience mysterious delay in receiving stdin EOF
After way too much time, I figured it out, after a quote from [this
post](http://fixunix.com/questions/379652-sending-eof-named-pipe.html)
jumped out at me:
> See the "I/O on Pipes and FIFOs" section of pipe(7) ("man 7 pipe")
>
> "If all file descriptors referring to the write end of a pipe have
> been closed, then an attempt to read(2) from the pipe will see
> end-of-file (read(2) will return 0)."
I should've known this, but it never occurred to me - had nothing to
do with Python in particular. What was happening was: the subprocesses
were getting forked with open (writer) file descriptors to each
others' pipes. As long as there are open writer file descriptors to a
pipe, readers won't see EOF.
E.g.:
p1=Popen(..., stdin=PIPE, ...) # creates a pipe the parent process
can write to
p2=Popen(...) # inherits the writer FD - as long as p2 exists, p1
won't see EOF
Turns out there's a `close_fds` parameter to `Popen`, so the solution
is to pass `close_fds=True`. All simple and obvious in hindsight, but
still managed to cost at least a couple eyeballs good chunks of time.
On Sun, Feb 13, 2011 at 11:52 PM, Yang Zhang wrote:
> Anybody else see this issue?
>
> On Thu, Feb 10, 2011 at 10:37 AM, Yang Zhang wrote:
>> On Thu, Feb 10, 2011 at 12:28 AM, Jean-Michel Pichavant
>> wrote:
>>> Yang Zhang wrote:
On Wed, Feb 9, 2011 at 11:01 AM, MRAB wrote:
>
> On 09/02/2011 01:59, Yang Zhang wrote:
>
>>
>> I reduced a problem I was seeing in my application down into the
>> following test case. In this code, a parent process concurrently
>> spawns 2 (you can spawn more) subprocesses that read a big message
>> from the parent over stdin, sleep for 5 seconds, and write something
>> back. However, there's unexpected waiting happening somewhere, causing
>> the code to complete in 10 seconds instead of the expected 5.
>>
>> If you set `verbose=True`, you can see that the straggling subprocess
>> is receiving most of the messages, then waiting for the last chunk of
>> 3 chars---it's not detecting that the pipe has been closed.
>> Furthermore, if I simply don't do anything with the second process
>> (`doreturn=True`), the first process will *never* see the EOF.
>>
>> Any ideas what's happening? Further down is some example output.
>> Thanks in advance.
>>
>> from subprocess import *
>> from threading import *
>> from time import *
>> from traceback import *
>> import sys
>> verbose = False
>> doreturn = False
>> msg = (20*4096+3)*'a'
>> def elapsed(): return '%7.3f' % (time() - start)
>> if sys.argv[1:]:
>> start = float(sys.argv[2])
>> if verbose:
>> for chunk in iter(lambda: sys.stdin.read(4096), ''):
>> print>> sys.stderr, '..', time(), sys.argv[1], 'read',
>> len(chunk)
>> else:
>> sys.stdin.read()
>> print>> sys.stderr, elapsed(), '..', sys.argv[1], 'done reading'
>> sleep(5)
>> print msg
>> else:
>> start = time()
>> def go(i):
>> print elapsed(), i, 'starting'
>> p = Popen(['python','stuckproc.py',str(i), str(start)],
>> stdin=PIPE, stdout=PIPE)
>> if doreturn and i == 1: return
>> print elapsed(), i, 'writing'
>> p.stdin.write(msg)
>> print elapsed(), i, 'closing'
>> p.stdin.close()
>> print elapsed(), i, 'reading'
>> p.stdout.read()
>> print elapsed(), i, 'done'
>> ts = [Thread(target=go, args=(i,)) for i in xrange(2)]
>> for t in ts: t.start()
>> for t in ts: t.join()
>>
>> Example output:
>>
>> 0.001 0 starting
>> 0.003 1 starting
>> 0.005 0 writing
>> 0.016 1 writing
>> 0.093 0 closing
>> 0.093 0 reading
>> 0.094 1 closing
>> 0.094 1 reading
>> 0.098 .. 1 done reading
>> 5.103 1 done
>> 5.108 .. 0 done reading
>> 10.113 0 done
>>
>>
>
> I changed 'python' to the path of python.exe and 'stuckproc.py' to its
> full path and tried it with Python 2.7 on Windows XP Pro. It worked as
> expected.
>
Good point - I didn't specify that I'm seeing this on Linux (Ubuntu
10.04's Python 2.6).
>>>
>>> python test.py 0.000 0 starting
>>> 0.026 0 writing
>>> 0.026 0 closing
>>> 0.026 0 reading
>>> 0.029 .. 0 done reading
>>> 0.030 1 starting
>>> 0.038 1 writing
>>> 0.058 1 closing
>>> 0.058 1 reading
>>> 0.061 .. 1 done reading
>>> 5.026 0 done
>>> 5.061 1 done
>>>
>>> on debian lenny (Python 2.5)
>>>
>>> JM
>>>
>>
>> FWIW, this is consistently reproduce-able across all the Ubuntu 10.04s
>> I've tried. You may need to increase the message size so that it's
>> large enough for your system.
>>
>> --
>> Yang Zhang
>> http://yz.
Re: file/folder naming
ok changed the try/except to just a file copy and got this: sourcepath is : [u'I:\\college\\spring11\\capstone-project\ \facbac-009.py'] destpath is : V:\week3 destpath is : V:\week3\facbac-009.py Traceback (most recent call last): File "I:\college\spring11\capstone-project\folder.py", line 53, in button1Click backupfiles() File "I:\college\spring11\capstone-project\folder.py", line 19, in backupfiles shutil.copy2(sourcepath, os.path.join(destpath,os.path.basename(files))) File "C:\Python27\lib\shutil.py", line 127, in copy2 copyfile(src, dst) File "C:\Python27\lib\shutil.py", line 67, in copyfile if _samefile(src, dst): File "C:\Python27\lib\shutil.py", line 62, in _samefile return (os.path.normcase(os.path.abspath(src)) == File "C:\Python27\lib\ntpath.py", line 471, in abspath path = _getfullpathname(path) TypeError: coercing to Unicode: need string or buffer, list found yes i see the list. but shouldnt this "for files in sourcepath:" parse thru the list ... ? -- http://mail.python.org/mailman/listinfo/python-list
Re: file/folder naming
On Feb 18, 11:59 pm, Chris Rebert wrote: > On Fri, Feb 18, 2011 at 8:29 PM, ecu_jon wrote: > > im trying to use wxpython to get a source file/files, then a > > destination folder to write them to. the file and folder picker works. > > the problem is, actually copying (actually shutil.copy2() ). i get an > > except error > > Please include the exact text of the error message and accompanying > Traceback. And always do so in the future. > > Cheers, > Chris as i was using tr/except, there is no traceback, or i would have done so. the except error comes back and says it cant copy to the folder. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python leaks in cyclic garbage collection
On Fri, 18 Feb 2011 20:49:09 -0800, Chris Rebert wrote: > And following the pointer to gc.garbage's docs: > http://docs.python.org/library/gc.html#gc.garbage : "Objects that have > __del__() methods and are part of a reference cycle ***cause the entire > reference cycle to be uncollectable*** [...] Python doesn’t collect such > cycles automatically because, in general, it isn’t possible for Python > to guess a safe order in which to run the __del__() methods. [...] It’s > generally better to avoid the issue by not creating cycles containing > objects with __del__() methods" Another solution is to manually break the cycle, perhaps by providing a "close" method, and requiring the caller to use it. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: file/folder naming
On Fri, 18 Feb 2011 20:29:13 -0800, ecu_jon wrote: > im trying to use wxpython to get a source file/files, then a destination > folder to write them to. the file and folder picker works. the problem > is, actually copying (actually shutil.copy2() ). i get an except error, > as if the destination file name is not correct. looking at the print > lines the destination looks right. i used os.path.join to join the > folder path and the filebasename. i can hear it now, that this belongs > on the wxpython page, and i will be posting there as well. but, im > fairly certain its something in this "for files in sourcepath:" > try: > shutil.copy2(sourcepath, > os.path.join(destpath,os.path.basename(files))) > except: > print "error file" There's your problem there: by hiding the *actual* error message Python provides, and substituting a rubbish, useless, generic "error file" message, you make it impossible to see what causes the error. Don't do that. Until you fix that, you can't diagnose errors, because the information needed to diagnose them is tossed away. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: email library, get_payload() bug?
On 18 fév, 14:41, peterob wrote: > Helllo, > > I want to get the raw format of email body. the code Im using is > > for part in email.walk(): > if part.get_content_maintype() == 'multipart': > continue > if part.get_content_type() == 'text/plain': > # print part.get_content_type() > print part.get_payload(None,True) > > The problem is, that code adds one more '\n' at the and of the output > printed by get_payload(). Is that bug? > > Thanks. > > Best, > Peter No sure to undeerstand, but print add one '\n' by itself maybe using print part.get_payload(None,True), with a "," at the end to tell print not to add a "\n" hope this help -- http://mail.python.org/mailman/listinfo/python-list
Re: file/folder naming
On Fri, Feb 18, 2011 at 8:29 PM, ecu_jon wrote: > im trying to use wxpython to get a source file/files, then a > destination folder to write them to. the file and folder picker works. > the problem is, actually copying (actually shutil.copy2() ). i get an > except error Please include the exact text of the error message and accompanying Traceback. And always do so in the future. Cheers, Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: Python leaks in cyclic garbage collection
On Fri, Feb 18, 2011 at 8:10 PM, moerchendiser2k3 wrote: > Hi, I have some problems with Python and the garbage collection. In > the following piece of code I create a simple gargabe collection but I > am still wondering why the finalizers are never called - at least on > exit of Py they should be called somehow. What do I miss here? Read The Fine Manual (all emphases added): http://docs.python.org/reference/datamodel.html#object.__del__ : "***It is not guaranteed that __del__() methods are called for objects that still exist when the interpreter exits.***" "Note: [...] x.__del__() — [...] is only called when x‘s reference count reaches zero. Some common situations that may prevent the reference count of an object from going to zero include: circular references between objects [...] Circular references which are garbage are detected when the option cycle detector is enabled (it’s on by default), ***but can only be cleaned up if there are no Python-level __del__() methods involved***. Refer to the documentation for the `gc` module for more information about how __del__() methods are handled by the cycle detector, particularly the description of the `garbage` value." And following the pointer to gc.garbage's docs: http://docs.python.org/library/gc.html#gc.garbage : "Objects that have __del__() methods and are part of a reference cycle ***cause the entire reference cycle to be uncollectable*** [...] Python doesn’t collect such cycles automatically because, in general, it isn’t possible for Python to guess a safe order in which to run the __del__() methods. [...] It’s generally better to avoid the issue by not creating cycles containing objects with __del__() methods" Cheers, Chris -- http://blog.rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Making Line Graphs
Standard answer in such a case is matplotlib http://matplotlib.sourceforge.net/ -- http://mail.python.org/mailman/listinfo/python-list
file/folder naming
im trying to use wxpython to get a source file/files, then a
destination folder to write them to. the file and folder picker works.
the problem is, actually copying (actually shutil.copy2() ). i get an
except error, as if the destination file name is not correct. looking
at the print lines the destination looks right. i used os.path.join to
join the folder path and the filebasename. i can hear it now, that
this belongs on the wxpython page, and i will be posting there as
well. but, im fairly certain its something in this "for files in
sourcepath:"
import wx,os,string,shutil,getpass
from datetime import *
def backupfiles():
dialog = wx.FileDialog(None, "Choose a source file :", style=1 |
wx.MULTIPLE )
if dialog.ShowModal() == wx.ID_OK:
sourcepath = dialog.GetPaths()
else:
dialog.Destroy()
dialog = wx.DirDialog(None, "Choose a destination directory :",
style=1 )
if dialog.ShowModal() == wx.ID_OK:
destpath = dialog.GetPath()
else:
dialog.Destroy()
print "sourcepath is :",sourcepath
print "destpath is :",destpath
for files in sourcepath:
print "destpath
is :",os.path.join(destpath,os.path.basename(files))
try:
shutil.copy2(sourcepath,
os.path.join(destpath,os.path.basename(files)))
except:
print "error file"
class MyForm(wx.Frame):
"""make a frame, inherits wx.Frame"""
def __init__(self):
# create a frame, no parent, default to wxID_ANY
wx.Frame.__init__(self, None, wx.ID_ANY, title="FacBac",
pos=(300, 150), size=(500, 200))
self.SetBackgroundColour("purple")
panel = wx.Panel(self, wx.ID_ANY)
self.title1 = wx.StaticText(panel, wx.ID_ANY, "Backup")
self.title2 = wx.StaticText(panel, wx.ID_ANY, "Restore")
self.button1 = wx.Button(panel, id=-1, label='Backup ALL')
self.button1.Bind(wx.EVT_BUTTON, self.button1Click)
self.button1.SetToolTip(wx.ToolTip("this will backup your
whole folder"))
gridSizer = wx.GridSizer(rows=4, cols=2, hgap=5, vgap=5)
gridSizer.Add(self.title1, 0, wx.ALL|wx.ALIGN_CENTER, 5)
gridSizer.Add(self.title2, 0, wx.ALL|wx.ALIGN_CENTER, 5)
gridSizer.Add(self.button1, 0, wx.ALL|wx.EXPAND, 5)
topSizer = wx.BoxSizer(wx.VERTICAL)
topSizer.Add(gridSizer, 0, wx.ALL|wx.EXPAND, 5)
self.SetSizeHints(500,200,500,200)
panel.SetSizer(topSizer)
topSizer.Fit(self)
def button1Click(self, event):
self.button1.SetLabel("Doing Backup")
backupfiles()
self.button1.SetLabel("Backup All")
if __name__ == "__main__":
app = wx.PySimpleApp()
frame = MyForm().Show()
#import wx.lib.inspection
#wx.lib.inspection.InspectionTool().Show()
app.MainLoop()
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python leaks in cyclic garbage collection
Thanks a lot for any help!!! Bye, moerchendiser2k3 -- http://mail.python.org/mailman/listinfo/python-list
Python leaks in cyclic garbage collection
Hi, I have some problems with Python and the garbage collection. In the following piece of code I create a simple gargabe collection but I am still wondering why the finalizers are never called - at least on exit of Py they should be called somehow. What do I miss here? I know, there is no deterministic way how to resolve this though. class Foo(): def __init__(self): self.b=Bar(self) def __del__(self): print "Free Foo" class Bar(): def __init__(self, f): self.f=f def __del__(self): print "Free Bar" f=Foo() print f -- http://mail.python.org/mailman/listinfo/python-list
Re: How to use Python well?
Roy Smith writes: > Whether it's a wiki or the generated output of sphinx/doxygen/etc, HTML > provides for a much richer presentation. Which is more convenient: > having the signal(3) man page reference "sigaction(2)" textually, or > having it be a clickable link that can take me right there? My man page browser does exactly that: the reference to another man page is clickable, bringing me directly to the approrpiate page. If yours doesn't, perhaps that's what needs to be addressed? > HTML also gives you much greater formatting flexibility than what's > still basically 35-year old nroff. Full agreement there. > If, for whatever reason, you're still wed to plain text, even info > gives you much better capabilities than man. Yet the manual system is reliably installed on any Unix system I'm likely to encounter. The ‘info’ system is not. Which is my point: there's one place the documentation is expected to be. > I'm not saying that help text is the be-all and end-all for > documentation. Nor am I making any similar claim for the Unix manual system. But it is the common baseline which can be relied upon – unless vendors fail to provide it. Hence the appeal not to do that. -- \ “Every man would like to be God, if it were possible; some few | `\ find it difficult to admit the impossibility.” —Bertrand | _o__)Russell, _Power: A New Social Analysis_, 1938 | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: How to use Python well?
In article <878vxcbudn@benfinney.id.au>, Ben Finney wrote: > This collection of a great deal of documentation for the operating > system into a single âmanualâ is one reason why users like man pages so > much: we want to find anything installed on the system documented in > that one place. What made man pages such a great technology back in the 70's was exactly what Ben is saying. Everything was on-line and instantly available for quick reference. Not to mention that you could use man as just another cog in the unix toolset and do things like grep all of /usr/man for a term (or an error message which appeared and you didn't know what had produced it). These were astonishing advances in usability vs. having printed manuals (which may or may not have been available to you). But, today we have such better tools available. HTML, for example. Whether it's a wiki or the generated output of sphinx/doxygen/etc, HTML provides for a much richer presentation. Which is more convenient: having the signal(3) man page reference "sigaction(2)" textually, or having it be a clickable link that can take me right there? HTML also gives you much greater formatting flexibility than what's still basically 35-year old nroff. If, for whatever reason, you're still wed to plain text, even info gives you much better capabilities than man. At least you get basic stuff like menus, document hierarchy, cross-linking, and browsing history. I'm not saying that help text is the be-all and end-all for documentation. I'm just saying that if you're going to do more than help text, it's hard to imagine putting any effort into producing man pages. Except possibly as the automated output of some multi-target documentation system which produces them as a by-product of producing other, richer, formats. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to use Python well?
Westley Martínez writes: > From what I've seen, the man pages are supposed to be in depth > information that covers every nook and cranny of every option Those are man pages the document commands. There are many more man pages on a typical Unix-like system, which do not document commands. This collection of a great deal of documentation for the operating system into a single “manual” is one reason why users like man pages so much: we want to find anything installed on the system documented in that one place. -- \ “The trouble with eating Italian food is that five or six days | `\later you're hungry again.” —George Miller | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Problems of Symbol Congestion in Computer Languages
Westley Martínez writes: > When I read Python code, I only > see text from Latin-1, which is easy to input and every *decent* font > supports it. When I read C code, I only see text from Latin-1. When I > read code from just about everything else that's plain text, I only see > text from Latin-1. Even Latex, which is designed for typesetting > mathematical formulas, only allows ASCII in its input. Languages that > accept non-ASCII input have always been somewhat esoteric. Maybe we'll see more of them as time goes by. C, Python, and Latex all predate Unicode by a number of years. If Latex were written today it would probably accept Unicode for math symbols, accented and non-Latin characters, etc. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to use Python well?
On Sat, 2011-02-19 at 11:39 +1100, Ben Finney wrote: > Roy Smith writes: > > > In article , > > Jorgen Grahn wrote: > > > > > On Thu, 2011-02-17, Roy Smith wrote: > > > > These days, user documentation for me means good help text for > > > > argparse to use. > > > > > > Perhaps I'm old-fashioned, but all other software I use (on Unix) > > > has man pages. I /expect/ there to be one. (It's not hard to write a > > > man page either, if you have a decent one as a template.) > > > > The nice thing about help text is that it keeps the documentation and > > the code in one place, which makes it a little more likely people will > > actually update the docs as they update the code. > > Yes, that's nice for the programmer. But isn't the point of the man page > to be nice for the users? The man pages document many more things than > help text output from the program. > > -- > \ “Very few things happen at the right time, and the rest do not | > `\ happen at all. The conscientious historian will correct these | > _o__) defects.” —Mark Twain, _A Horse's Tale_ | > Ben Finney From what I've seen, the man pages are supposed to be in depth information that covers every nook and cranny of every option while the --help option is supposed to simply print a summary in case one forgets the syntax, but nowadays they've kind of been blended together. -- http://mail.python.org/mailman/listinfo/python-list
Re: Problems of Symbol Congestion in Computer Languages
On Sat, 2011-02-19 at 01:01 +, Steven D'Aprano wrote:
> On Fri, 18 Feb 2011 11:16:30 -0800, Westley Martínez wrote:
>
> > Allowing non-ascii characters as operators is a silly idea simply
> > because if xorg breaks, which it's very likely to do with the current
> > video drivers, I'm screwed.
>
> And if your hard drive crashes, you're screwed too. Why stop at "xorg
> breaks"?
Because I can still edit text files in the terminal.
I guess you could manually control the magnet in the hard-drive if it
failed but that'd be horrifically tedious.
> Besides, Windows and MacOS users will be scratching their head asking
> "xorg? Why should I care about xorg?"
Why should I care if my programs run on Windows and Mac? Because I'm a
nice guy I guess
> Programming languages are perfectly allowed to rely on the presence of a
> working environment. I don't think general purpose programming languages
> should be designed with reliability in the presence of a broken
> environment in mind.
>
> Given the use-cases people put Python to, it is important for the
> language to *run* without a GUI environment. It's also important (but
> less so) to allow people to read and/or write source code without a GUI,
> which means continuing to support the pure-ASCII syntax that Python
> already supports. But Python already supports non-ASCII source files,
> with an optional encoding line in the first two lines of the file, so it
> is already possible to write Python code that runs without X but can't be
> easily edited without a modern, Unicode-aware editor.
>
> > Not only does the Linux virtual terminal not
> > support displaying these special characters, but there's also no way of
> > inputting them.
>
> That's a limitation of the Linux virtual terminal. In 1984 I used to use
> a Macintosh which was perfectly capable of displaying and inputting non-
> ASCII characters with a couple of key presses. Now that we're nearly a
> quarter of the way into 2011, I'm using a Linux PC that makes entering a
> degree sign or a pound sign a major undertaking, if it's even possible at
> all. It's well past time for Linux to catch up with the 1980s.
I feel it's unnecessary for Linux to "catch up" simply because we have
no need for these special characters! When I read Python code, I only
see text from Latin-1, which is easy to input and every *decent* font
supports it. When I read C code, I only see text from Latin-1. When I
read code from just about everything else that's plain text, I only see
text from Latin-1. Even Latex, which is designed for typesetting
mathematical formulas, only allows ASCII in its input. Languages that
accept non-ASCII input have always been somewhat esoteric. There's
nothing wrong with being different, but there is something wrong in
being so different that your causing problems or at least speed bumps
for particular users.
> > On top of that, these special characters require more
> > bytes to display than ascii text, which would bloat source files
> > unnecessarily.
>
> Oh come on now, now you're just being silly. "Bloat source files"? From a
> handful of double-byte characters? Cry me a river!
>
> This is truly a trivial worry:
>
> >>> s = "if x >= y:\n"
> >>> u = u"if x ≥ y:\n"
> >>> len(s)
> 11
> >>> len(u.encode('utf-8'))
> 12
>
>
> The source code to the decimal module in Python 3.1 is 205470 bytes in
> size. It contains 63 instances of ">=" and 62 of "<=". Let's suppose
> every one of those were changed to ≥ or ≤ characters. This would "bloat"
> the file by 0.06%.
>
> Oh the humanity!!! How will my 2TB hard drive cope?!?!
A byte saved is a byte earned. What about embedded systems trying to
conserve as much resources as possible?
> > You say we have symbol congestion, but in reality we have our own symbol
> > bloat. Japanese has more or less than three punctuation marks, while
> > English has perhaps more than the alphabet! The fundamental point here
> > is using non-ascii operators violates the Zen of Python. It violates
> > "Simple is better than complex," as well as "There should be one-- and
> > preferably only one --obvious way to do it."
>
> Define "simple" and "complex" in this context.
>
> It seems to me that single character symbols such as ≥ are simpler than
> digraphs such as >=, simply because the parser knows what the symbol is
> after reading a single character. It doesn't have to read on to tell
> whether you meant > or >=.
>
> You can add complexity to one part of the language (hash tables are more
> complex than arrays) in order to simplify another part (dict lookup is
> simpler and faster than managing your own data structure in a list).
I believe dealing with ASCII is simpler than dealing with Unicode, for
reasons on both the developer's and user's side.
> And as for one obvious way, there's nothing obvious about using a | b for
> set union. Why not a + b? The mathematician in me wants to spell set
> union and intersection as a ⋃ b ⋂ c, whic
Re: Making Line Graphs
spam head writes: > I'm looking for an easy way to display simple line graphs generated by > a python program in Windows. It could be done from within the > program, or I could write the information out to a file and call an > external program. Either is fine. I've used gnuplot and rrdtool for this in recent projects. Rrdtool is for ongoing time series and gnuplot is for more general graphing. I looked at Timeplot too, which looks really neat, but I didn't try to use it. -- http://mail.python.org/mailman/listinfo/python-list
Making Line Graphs
I'm looking for an easy way to display simple line graphs generated by a python program in Windows. It could be done from within the program, or I could write the information out to a file and call an external program. Either is fine. Does anybody have any recommendations for a good program from generating these simple graphs? -- http://mail.python.org/mailman/listinfo/python-list
Re: Problems of Symbol Congestion in Computer Languages
On Fri, 18 Feb 2011 11:16:30 -0800, Westley Martínez wrote:
> Allowing non-ascii characters as operators is a silly idea simply
> because if xorg breaks, which it's very likely to do with the current
> video drivers, I'm screwed.
And if your hard drive crashes, you're screwed too. Why stop at "xorg
breaks"?
Besides, Windows and MacOS users will be scratching their head asking
"xorg? Why should I care about xorg?"
Programming languages are perfectly allowed to rely on the presence of a
working environment. I don't think general purpose programming languages
should be designed with reliability in the presence of a broken
environment in mind.
Given the use-cases people put Python to, it is important for the
language to *run* without a GUI environment. It's also important (but
less so) to allow people to read and/or write source code without a GUI,
which means continuing to support the pure-ASCII syntax that Python
already supports. But Python already supports non-ASCII source files,
with an optional encoding line in the first two lines of the file, so it
is already possible to write Python code that runs without X but can't be
easily edited without a modern, Unicode-aware editor.
> Not only does the Linux virtual terminal not
> support displaying these special characters, but there's also no way of
> inputting them.
That's a limitation of the Linux virtual terminal. In 1984 I used to use
a Macintosh which was perfectly capable of displaying and inputting non-
ASCII characters with a couple of key presses. Now that we're nearly a
quarter of the way into 2011, I'm using a Linux PC that makes entering a
degree sign or a pound sign a major undertaking, if it's even possible at
all. It's well past time for Linux to catch up with the 1980s.
> On top of that, these special characters require more
> bytes to display than ascii text, which would bloat source files
> unnecessarily.
Oh come on now, now you're just being silly. "Bloat source files"? From a
handful of double-byte characters? Cry me a river!
This is truly a trivial worry:
>>> s = "if x >= y:\n"
>>> u = u"if x ≥ y:\n"
>>> len(s)
11
>>> len(u.encode('utf-8'))
12
The source code to the decimal module in Python 3.1 is 205470 bytes in
size. It contains 63 instances of ">=" and 62 of "<=". Let's suppose
every one of those were changed to ≥ or ≤ characters. This would "bloat"
the file by 0.06%.
Oh the humanity!!! How will my 2TB hard drive cope?!?!
> You say we have symbol congestion, but in reality we have our own symbol
> bloat. Japanese has more or less than three punctuation marks, while
> English has perhaps more than the alphabet! The fundamental point here
> is using non-ascii operators violates the Zen of Python. It violates
> "Simple is better than complex," as well as "There should be one-- and
> preferably only one --obvious way to do it."
Define "simple" and "complex" in this context.
It seems to me that single character symbols such as ≥ are simpler than
digraphs such as >=, simply because the parser knows what the symbol is
after reading a single character. It doesn't have to read on to tell
whether you meant > or >=.
You can add complexity to one part of the language (hash tables are more
complex than arrays) in order to simplify another part (dict lookup is
simpler and faster than managing your own data structure in a list).
And as for one obvious way, there's nothing obvious about using a | b for
set union. Why not a + b? The mathematician in me wants to spell set
union and intersection as a ⋃ b ⋂ c, which is the obvious way to me (even
if my lousy editor makes it a PITA to *enter* the symbols).
The lack of good symbols for operators in ASCII is a real problem. Other
languages have solved it in various ways, sometimes by using digraphs (or
higher-order symbols), and sometimes by using Unicode (or some platform/
language specific equivalent). I think that given the poor support for
Unicode in the general tools we use, the use of non-ASCII symbols will
have to wait until Python4. Hopefully by 2020 input methods will have
improved, and maybe even xorg be replaced by something less sucky.
I think that the push for better and more operators will have to come
from the Numpy community. Further reading:
http://mail.python.org/pipermail/python-dev/2008-November/083493.html
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to use Python well?
Roy Smith writes: > In article , > Jorgen Grahn wrote: > > > On Thu, 2011-02-17, Roy Smith wrote: > > > These days, user documentation for me means good help text for > > > argparse to use. > > > > Perhaps I'm old-fashioned, but all other software I use (on Unix) > > has man pages. I /expect/ there to be one. (It's not hard to write a > > man page either, if you have a decent one as a template.) > > The nice thing about help text is that it keeps the documentation and > the code in one place, which makes it a little more likely people will > actually update the docs as they update the code. Yes, that's nice for the programmer. But isn't the point of the man page to be nice for the users? The man pages document many more things than help text output from the program. -- \ “Very few things happen at the right time, and the rest do not | `\ happen at all. The conscientious historian will correct these | _o__) defects.” —Mark Twain, _A Horse's Tale_ | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: How to use Python well?
In article , Jorgen Grahn wrote: > On Thu, 2011-02-17, Roy Smith wrote: > > In article , > > Jorgen Grahn wrote: > > > >> - Write user documentation and build/installation scripts. Since I'm > >> on Unix, that means man pages and a Makefile. > > > > Wow, I haven't built a man page in eons. These days, user documentation > > for me means good help text for argparse to use. > > Perhaps I'm old-fashioned, but all other software I use (on Unix) has > man pages. I /expect/ there to be one. (It's not hard to write a man > page either, if you have a decent one as a template.) The nice thing about help text is that it keeps the documentation and the code in one place, which makes it a little more likely people will actually update the docs as they update the code. > I guess you're working within an organization? FSVO "organization", but yes. > Local rules override personal preferences -- if everyone else is > using the wiki, I guess you must do too. I've become very enamored of wikis because of the lost activation energy barrier and instant feedback. To update a man page (info node, etc), you need to find the source document, perhaps check it out, edit it, submit it back to version control, install the new version in /usr/man, and so on. People tend not to bother. Wikis are so much more lightweight, they're that much more likely to get kept current. > I have to say though that *not* handling the documentation together > with the source code is harmful. If source code and documentation > aren't in version control together, they *will* go out of sync. That is a valid argument against wikis. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to use Python well?
On Thu, 2011-02-17, Roy Smith wrote: > In article , > Jorgen Grahn wrote: > >> - Write user documentation and build/installation scripts. Since I'm >> on Unix, that means man pages and a Makefile. > > Wow, I haven't built a man page in eons. These days, user documentation > for me means good help text for argparse to use. Perhaps I'm old-fashioned, but all other software I use (on Unix) has man pages. I /expect/ there to be one. (It's not hard to write a man page either, if you have a decent one as a template.) Help texts are better than nothing though (and unlike man pages they work on Windows too). > If I need something > more than that, I'll write it up in our wiki. I guess you're working within an organization? Local rules override personal preferences -- if everyone else is using the wiki, I guess you must do too. I have to say though that *not* handling the documentation together with the source code is harmful. If source code and documentation aren't in version control together, they *will* go out of sync. >> Anyway, I don't feel bad if I don't find any classes at first. > > Same here. I don't usually find a reason to refactor things into > classes until I've written the second or third line of code :-) > > Somewhat more seriously, the big clue for me that I've got a class > hiding in there is when I start having all sorts of globals. That's > usually a sign you've done something wrong. Or a whole bunch of related arguments to a function, and/or the same arguments being passed to many functions. /Jorgen -- // Jorgen GrahnO o . -- http://mail.python.org/mailman/listinfo/python-list
Re: Problems of Symbol Congestion in Computer Languages
On Fri, 18 Feb 2011 04:43:13 -0800, Xah Lee wrote: > for example, when you type >= in python, the text editor can > automatically change it to ≥ (when it detects that it's appropriate, > e.g. there's a “if” nearby) You can't rely on the presence of an `if`. flag = x >= y value = lookup[x >= y] filter(lambda x, y: x >= y, sequence) Not that you need to. There are no circumstances in Python where the meaning of >= is changed by an `if` statement. Followups set to comp.lang.python. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Archiving Modules
On Fri, 2011-02-18, Alexander Kapps wrote:
> On 18.02.2011 19:51, Westley Martínez wrote:
>> On Fri, 2011-02-18 at 04:55 -0800, peter wrote:
>>> On Feb 17, 9:55 pm, Jorgen Grahn wrote:
>>>
>>>
RAR is a proprietary format, which complicates things. For example,
Linux distributions like Debian cannot distribute software which
handles it. If Python included such a module, they'd be forced to
remove it from their version.
>>>
>>> Good point, and one that I did not appreciate. But there are freeware
>>> applications such as jzip (http://www.jzip.com) which can handle .rar
>>> files, so there must be a way round it.
>>>
I wouldn't encourage its use by writing /more/ software which handles
it. IMHO, archives should be widely readable forever, and to be that
they need to be in a widely used, open format.
>>>
>>> I agree, but if a file is only available as a rar archive I would like
>>> to be able to extract it without using another 3rd party application.
>>>
>>> peter
>> Freeware is still proprietary software.
It can be ("freeware" is a vague term). As I understand they situation
here, such software is either in a gray area legally, or the author
has made some kind of special agreement with the RAR people.
> While I agree with the general refusal of .rar or other non-free
> archive formats, a useful archiving tool should still be able to
> extract them. Creating them is an other issue.
>
> There is a free (open source) un-rar for Linux which AFAIK can at
> least handle .rar archives below v3.
That's part of my point -- unrar-free is the only decoder free enough
to be distributed by Debian, and yes, it's limited to decoding old
versions or the rar file format. Wikipedia seems to say it was based
on RAR as it looked before some license terms change.
/Jorgen
--
// Jorgen GrahnO o .
--
http://mail.python.org/mailman/listinfo/python-list
Re: Connecting to remote Oracle db via Python
Hello, On Thu, Feb 17, 2011 at 02:40:22AM -0800, pstatham wrote: > I've installed the cx_Oracle module for Python > and I'm trying to connect to my remote Oracle > db. Can you tnsping your remote Oracle DB successfully? > >>> uid = "scott" > >>> pwd = "tiger" > >>> service = "10.5.1.12:1521:PR10" > >>> db = cx_Oracle.connect(uid + "/" + pwd + "@" + service) Try 'tnsping service' or 'sqlplus uid/pwd@service' in your Korn/Bourne/whoever shell 1st. If this works, then cx_Oracle will work too. 'service' must be specified in system TNSNAMES file or in your ~/.tnsnames.ora -- With best regards, xrgtn -- http://mail.python.org/mailman/listinfo/python-list
Re: client server socket interaction (inetd)
On Fri, 18 Feb 2011 07:23:35 -0800, Tim wrote: > When LaTeX encounters a problem it stops processing, asks the user > what to do (like abort/retry, kind-of), and does whatever the user > says. The daemon.py script handles that okay from the command line, > but if I'm understanding you this will be much harder if not > impossible to accomplish from a client communicating over a socket. The difficulty of achieving this is unrelated to the use of a socket. It's an issue of whether you have a user available to respond to any prompts, or whether the client has to be able to do this itself. If you want to "script" an interactive program, you need to be able to recognise prompts and respond appropriately. If the program was designed to interact with a human, this can be far from straightforward. But the method of communication (pipes versus sockets) isn't relevant. -- http://mail.python.org/mailman/listinfo/python-list
Re: Best way to gain root privileges
On 18 February 2011 20:23, Alexander Kapps wrote: ... > Don't know if this helps you, but at least for CentOS 5.4, gksudo is > available in the gksu package from rpmforge. It looks as though policykit includes similar functionality, namely the command pkexec replaces gksudo: http://hal.freedesktop.org/docs/polkit/pkexec.1.html http://hal.freedesktop.org/docs/polkit/polkit.8.html http://www.freedesktop.org/wiki/Software/PolicyKit A python package: http://pypi.python.org/pypi?:action=search&term=polkit&submit=search But there is example python code here: http://hal.freedesktop.org/docs/polkit/polkit-apps.html I'm still not clear exactly how this works but will post some code once I figure it out. -- http://mail.python.org/mailman/listinfo/python-list
Re: IMAP4_SSL, libgmail, GMail and corporate firewall/proxy
Hello, On Fri, Feb 18, 2011 at 09:40:19AM +0500, Andrea Gavana wrote: > Fails with a variety of errors depending on which port I use: > > - Port 80: urllib2.HTTPError: HTTP Error 407: Proxy Authentication > Required ( The ISA Server requires authorization to fulfill the > request. Access to the Web Proxy filter is denied. ) Wow, that's much better! So your python proxy is working but just doesn't know how to authenticate. Unfortunately I don't remember how to specify proxy auth in python, but this is definitely achievable. Please 1st make ports 80 and 443 working, then you can try IMAP and other ports. In general, you're out of luck if your corporate proxy only supports connecting to ports 80 and 443 in outside world. But if you own a box in the wild, you can setup ssh/openvpn/socks server/whatever on port 443 on that box and use it as a kind of access broker to the rest of ports in the world. -- With best regards, xrgtn -- http://mail.python.org/mailman/listinfo/python-list
Re: Best way to gain root privileges
On 18 February 2011 20:21, Alexander Kapps wrote: ... > IIUC, than SELinux can also help, since it allows program-specific > permissions. But I could easily be wrong here since I have yet to really > learn SElinux. Who has, LOL! If you could post a (very very) quick 'I don't have a PhD in computer security' guide I'm sure we'd all be very grateful :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Best way to gain root privileges
On 18.02.2011 15:42, GSO wrote: I note that policykit was created by redhat, and that RHEL6 does not include gksudo in with its gnome for some odd reason. Don't know if this helps you, but at least for CentOS 5.4, gksudo is available in the gksu package from rpmforge. -- http://mail.python.org/mailman/listinfo/python-list
Re: Best way to gain root privileges
On 18.02.2011 15:22, Adam Skutt wrote: On Feb 18, 9:04 am, Ricardo Aráoz wrote: Many a time I have wanted to allow access to certain privileges to a user but *only* through a program. As far as security is concerned it would be enough that only root has permission to give the said program running privileges (privileges different from those of the user that is actually running it), that only allowed users may modify the program, and that *other* users may only run it. This would address the issue of someone modifying the program to gain access to it's privileges. Now, if someone is able to gain illegal privileges to modify the program, then there *is* a security hole and the program is not really the problem. sudo already does this to a limited degree. If you want more granularity than sudo, you're looking at mandatory access controls. Adam IIUC, than SELinux can also help, since it allows program-specific permissions. But I could easily be wrong here since I have yet to really learn SElinux. -- http://mail.python.org/mailman/listinfo/python-list
Re: Archiving Modules
On 18.02.2011 19:51, Westley Martínez wrote: On Fri, 2011-02-18 at 04:55 -0800, peter wrote: On Feb 17, 9:55 pm, Jorgen Grahn wrote: RAR is a proprietary format, which complicates things. For example, Linux distributions like Debian cannot distribute software which handles it. If Python included such a module, they'd be forced to remove it from their version. Good point, and one that I did not appreciate. But there are freeware applications such as jzip (http://www.jzip.com) which can handle .rar files, so there must be a way round it. I wouldn't encourage its use by writing /more/ software which handles it. IMHO, archives should be widely readable forever, and to be that they need to be in a widely used, open format. I agree, but if a file is only available as a rar archive I would like to be able to extract it without using another 3rd party application. peter Freeware is still proprietary software. While I agree with the general refusal of .rar or other non-free archive formats, a useful archiving tool should still be able to extract them. Creating them is an other issue. There is a free (open source) un-rar for Linux which AFAIK can at least handle .rar archives below v3. HTH -- http://mail.python.org/mailman/listinfo/python-list
Open InvitationTo Join Fun Python based Project
Sorry, for the double post, was not intended. Because of wrong subject name ! Hi there, We are currently looking for someone who has ideally several years coding experience, and who is familar with Network coding and the Python language. The project revolves around emulation and a chat based system, altough the vast majority of the project is focused on the chat based system itself. This should prove to be a very fun and rewarding project, and anyone thats able to spare their time to assist, would be greatly appreciated indeed. If you are interested, please contact Jason "Digital Ghost" via his blog http://10ghost.blogspot.com/ On behalf of the Team, Thankyou Zambr123 (Project Software Tester and GUI Designer) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Path registry Key
On Fri, 2011-02-18 at 11:56 +0530, Sathish S wrote: > Hi Ppl, > > > I'm trying to launch IDLE from another application. For this I need > the python directory path. I have been trying to get the Active Python > versions path from the Windows registry. However, these registry > entries seem not be consistent across various stations, that i > checked. I'm reading the following resitry key to get the active > versions path: Software\\Microsoft\\Windows\\CurrentVersion\\App Paths > \\Python.exe. There are two entries in this key. Some stations have > only one entry. Some do not have both. Probably they were removed > while python was uninstall ed and was not added again when it was > installed again. > > > So what will be a good solution to get the Python path ? > > > > Thanks, > Sathish > Try sys.prefix -- http://mail.python.org/mailman/listinfo/python-list
Re: Closures in metaclasses
Hi there, We are currently looking for someone who has ideally several years coding experience, and who is familar with Network coding and the Python language. The project revolves around emulation and a chat based system, altough the vast majority of the project is focused on the chat based system itself. This should prove to be a very fun and rewarding project, and anyone thats able to spare their time to assist, would be greatly appreciated indeed. If you are interested, please contact Jason "Digital Ghost" via his blog http://10ghost.blogspot.com/ On behalf of the Team, Thankyou Zambr123 (Project Software Tester and GUI Designer) -- http://mail.python.org/mailman/listinfo/python-list
Re: Problems of Symbol Congestion in Computer Languages
On Fri, 2011-02-18 at 04:43 -0800, Xah Lee wrote: > On 2011-02-16, Xah Lee wrote: > │ Vast majority of computer languages use ASCII as its character set. > │ This means, it jams multitude of operators into about 20 symbols. > │ Often, a symbol has multiple meanings depending on contex. > > On 2011-02-17, rantingrick wrote: > … > > On 2011-02-17, Cthun wrote: > │ And you omitted the #1 most serious objection to Xah's proposal, > │ rantingrick, which is that to implement it would require unrealistic > │ things such as replacing every 101-key keyboard with 10001-key > keyboards > │ and training everyone to use them. Xah would have us all replace our > │ workstations with machines that resemble pipe organs, rantingrick, > or > │ perhaps the cockpits of the three surviving Space Shuttles. No doubt > │ they'd be enormously expensive, as well as much more difficult to > learn > │ to use, rantingrick. > > keyboard shouldn't be a problem. > > Look at APL users. > http://en.wikipedia.org/wiki/APL_(programming_language) > they are happy campers. > > Look at Mathematica, which support a lot math symbols since v3 (~1997) > before unicode became popular. > see: > 〈How Mathematica does Unicode?〉 > http://xahlee.org/math/mathematica_unicode.html > > word processors, also automatically do symbols such as “curly quotes”, > trade mark sign ™, copyright sing ©, arrow →, bullet •, ellipsis … > etc, and the number of people who produce document with these chars > are probably more than the number of programers. > > in emacs, i recently also wrote a mode that lets you easily input few > hundred unicode chars. > 〈Emacs Math Symbols Input Mode (xmsi-mode)〉 > http://xahlee.org/emacs/xmsi-math-symbols-input.html > > the essence is that you just need a input system. > > look at Chinese, Japanese, Korean, or Islamic. They happily type > without requiring that every symbol they use must have a corresponding > key on keyboard. Some lang, such as Chinese, that's impossible or > impractical. > > when a input system is well designd, it could be actually more > efficient than > keyboard combinations to typo special symbols (such as in Mac OS X's > opt key, or > Windows's AltGraph). Because a input system can be context based, that > it looks > at adjacent text to guess what you want. > > for example, when you type >= in python, the text editor can > automatically change it to ≥ (when it detects that it's appropriate, > e.g. there's a “if” nearby) > > Chinese phonetic input system use this > extensively. Abbrev system in word processors and emacs is also a form > of > this. I wrote some thought about this here: > > 〈Designing a Math Symbols Input System〉 > http://xahlee.org/comp/design_math_symbol_input.html > > Xah Lee More people despise APL than like it. Allowing non-ascii characters as operators is a silly idea simply because if xorg breaks, which it's very likely to do with the current video drivers, I'm screwed. Not only does the Linux virtual terminal not support displaying these special characters, but there's also no way of inputting them. On top of that, these special characters require more bytes to display than ascii text, which would bloat source files unnecessarily. You say we have symbol congestion, but in reality we have our own symbol bloat. Japanese has more or less than three punctuation marks, while English has perhaps more than the alphabet! The fundamental point here is using non-ascii operators violates the Zen of Python. It violates "Simple is better than complex," as well as "There should be one-- and preferably only one --obvious way to do it." -- http://mail.python.org/mailman/listinfo/python-list
Re: Archiving Modules
On Fri, 2011-02-18 at 04:55 -0800, peter wrote: > On Feb 17, 9:55 pm, Jorgen Grahn wrote: > > > > RAR is a proprietary format, which complicates things. For example, > > Linux distributions like Debian cannot distribute software which > > handles it. If Python included such a module, they'd be forced to > > remove it from their version. > > Good point, and one that I did not appreciate. But there are freeware > applications such as jzip (http://www.jzip.com) which can handle .rar > files, so there must be a way round it. > > > I wouldn't encourage its use by writing /more/ software which handles > > it. IMHO, archives should be widely readable forever, and to be that > > they need to be in a widely used, open format. > > I agree, but if a file is only available as a rar archive I would like > to be able to extract it without using another 3rd party application. > > peter Freeware is still proprietary software. -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie getting desperate with for
On 18/02/11 07:29, Cameron Simpson wrote: > On 18Feb2011 08:40, I wrote: > | On 17Feb2011 18:40, Alister Ware wrote: > | | On Thu, 17 Feb 2011 16:42:05 +0800, Werner wrote: > | | > On 17/02/11 16:39, Chris Rebert wrote: > | | >> On Thu, Feb 17, 2011 at 12:27 AM, Werner wrote: > | | >>> I have a trivially simple piece of code called timewaster.py: > | | >>> > | | >>> while True: > | [...] > | | may I ask what is the purpose of this code segment, it does not look like > | | it would achieve much? > [... long shebang description...] > > Hmm, looks like maybe you meant the original python snippet. > If so, my apologies for the long misanswer. It was't a misanswer, you were laying a finger on the wound and explained how things are. I am very grateful for that. This is my first contact with this newsgroup and I thank you all for being patient and understanding with a newbie. Best Regards Werner Dahn -- http://mail.python.org/mailman/listinfo/python-list
Re: Unit testing multiprocessing code on Windows
On 17/02/2011 8:22 PM, phi...@semanchuk.com wrote: Hi Matt, I assume you're aware of this documentation, especially the item entitled "Safe importing of main module"? http://docs.python.org/release/2.6.6/library/multiprocessing.html#windows Yes, but the thing is my code isn't __main__, my unittest classes are being loaded by setup.py test or nosetests. And while I'm assured multiprocessing doesn't duplicate the original command line, what I get sure looks like it, because if I use "python setup.py test" that command seems to be re-run for every Process that starts, but if I use "nosetests" then *that* seems to be re-run for every Process. Matt -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie getting desperate with for
On Fri, Feb 18, 2011 at 4:54 PM, Michael Torrie wrote: > On 02/17/2011 04:10 PM, Werner wrote: > Just for your information, your code is the equivalent of: > > while True: > temp = range(2000) > > The for loop does absolutely nothing in your case. After the range is > computed, the for loop exits on the first iteration. Ah, but the for loop is there for a reason, I imagine. It'd certainly be slower per while loop. -- http://mail.python.org/mailman/listinfo/python-list
Re: Unit testing multiprocessing code on Windows
On 18/02/2011 2:54 AM, Terry Reedy wrote: On 2/17/2011 6:31 PM, Matt Chaput wrote: Does anyone know the "right" way to write a unit test for code that uses multiprocessing on Windows? I would start with Lib/test/test_multiprocessing. Good idea, but on the one hand it doesn't seem to be doing anything special, and on the other hand it seems to do it's own things like not having its test cases inherit from unittest.TestCase. I also don't know if the Python devs start it with distutils or nosetests, which are the ones I'm having a problem with. For example, starting my test suite inside PyDev doesn't show the bug. My test code isn't doing anything unusual... this is pretty much all I do to trigger the bug. (None of the imported code has anything to do with processes.) from __future__ import with_statement import unittest import random from whoosh import fields, query from whoosh.support.testing import TempIndex try: import multiprocessing except ImportError: multiprocessing = None if multiprocessing: class MPFCTask(multiprocessing.Process): def __init__(self, storage, indexname): multiprocessing.Process.__init__(self) self.storage = storage self.indexname = indexname def run(self): ix = self.storage.open_index(self.indexname) with ix.searcher() as s: r = s.search(query.Every(), sortedby="key", limit=None) result = "".join([h["key"] for h in r]) assert result == "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz", result class TestSorting(unittest.TestCase): def test_mp_fieldcache(self): if not multiprocessing: return schema = fields.Schema(key=fields.KEYWORD(stored=True)) with TempIndex(schema, "mpfieldcache") as ix: domain = list(u"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ") random.shuffle(domain) w = ix.writer() for char in domain: w.add_document(key=char) w.commit() tasks = [MPFCTask(ix.storage, ix.indexname) for _ in xrange(4)] for task in tasks: task.start() for task in tasks: task.join() if __name__ == '__main__': unittest.main() -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie getting desperate with for
On 02/17/2011 09:15 PM, Larry Hudson wrote: > A true time waster indeed -- it's an infinite loop that will _never_ end. > > Others have already about the need of the shebang line to run as a python > script, but I'm > surprised no one mentioned how truly useless this code is. > > The i = 0 line is totally unnecessary. The variable i is created and set to > zero by the first > iteration of the for loop. The break will abort the for loop (NOT the while > loop) in the first > iteration, and the 2nd through the 10th iterations will be skipped altogether. To be fair the range() call will be fairly time and memory-consuming on python 2, since it returns a list. > > This effectively leaves your code as: > > while True: > pass # Do nothing, forever > > An empty loop as a time delay can occasionally be useful, but as a practical > matter, a for loop > with only 10 (empty/pass) iterations is probably too short for anything > useful. Instead of > being empty, do some more complex (but ignored) operation -- say math.sqrt() > or math.sin() for > example -- and a much larger repetition count. But it's likely that does use > up processor > cycles unnecessarily, although it can give you delays of fractions of > seconds. If you want > delays greater than a second, check out the time.sleep() function. > > -=- Larry -=- -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie getting desperate with for
On 02/17/2011 04:10 PM, Werner wrote: > It is meant to put load on a CPU, RAM and disk (swap). The code now > looks like this: > #!/usr/bin/python > while True: > i = 0 > for i in range(2000): > break Just for your information, your code is the equivalent of: while True: temp = range(2000) The for loop does absolutely nothing in your case. After the range is computed, the for loop exits on the first iteration. On python 3.0 range() is a generator so your code essentially distills down to this if you ran it on python 3: while True: pass -- http://mail.python.org/mailman/listinfo/python-list
Re: client server socket interaction (inetd)
On Fri, 18 Feb 2011 07:23:35 -0800, Tim wrote: > Thanks for helping me to understand. I don't know if you're familiar > with LaTeX, but that's part of what daemon.py calls via subprocess, and > that is the underlying process I wanted the user to be able to interact > with. > I've used nroff but never LaTeX - however, my understanding is that its essentially a batch process. > When LaTeX encounters a problem it stops processing, asks the user what > to do (like abort/retry, kind-of), and does whatever the user says. The > daemon.py script handles that okay from the command line, but if I'm > understanding you this will be much harder if not impossible to > accomplish from a client communicating over a socket. > Are you sure it wouldn't be better to end the run, returning suitable error messages to the user, who would correct the input file(s) and rerun LaTex? > I thought that maybe I needed to fork the socket (somehow) so it could > listen after the message is sent, but it looks like it will be more > complex. > The easier way my be to give the user a login to a captive shell that's restricted to running LateX, an editor and little else apart from a results viewer. Bash and most decent editors can be restricted so the user can't start a second, less restricted shell, and the range of programs it can execute can be restricted by adjusting with $PATH. You may also be able to find a menu program that can impose many of those restrictions by replacing the login's shell by the menu program. I do this as a matter of course: my menu program may get released one of these days but it's not currently on a fit state to publish. If you want to continue down the server path you should investigate popen. It is part of the os module. You could design the server so a suitable request runs LaTeX via popen, captures the stdout and stderr output, if any, and returns that and the LaTeX termination status code to the client as a response message. -- martin@ | Martin Gregorie gregorie. | Essex, UK org | -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem with giant font sizes in tkinter
On Fri, Feb 11, 2011 at 09:35:56PM EST, Steven D'Aprano wrote: > On Fri, 11 Feb 2011 01:29:02 -0500, Chris Jones wrote: > > >> >> labelfont = '-Adobe-Helvetica-Bold-R-Normal-*-140-*' > > [...] > > First of all, you need to know precisely what the above font name coding > > means. > [...] > > http://www.archive.org/details/xwindowsytemosf03querarch > > Thanks for the link, that's incredibly useful (although the PDF > doesn't render correctly in any of the five different PDF viewers > I tried, but I was able to read it). The O'Reilly X admin guide is also available at the same address and has a few more pieces of the puzzle. Should've mentioned that you should download the (much smaller) *.djvu files rather than the pdf's. Much smaller files, and render considerably faster. The ‘evince’ viewer on GNU/Linux appears to understand the djvu format. cj -- http://mail.python.org/mailman/listinfo/python-list
Re: Problems of Symbol Congestion in Computer Languages
On Fri, Feb 18, 2011 at 06:40:17AM EST, Steven D'Aprano wrote: > On Fri, 18 Feb 2011 02:50:11 -0500, Chris Jones wrote: > > Always struck me as odd that a country like Japan for instance, with > > all its achievements in the industrial realm, never came up with one > > single major piece of software. > I think you are badly misinformed. > > The most widespread operating system in the world is not Windows. It's > something you've probably never heard of, from Japan, called TRON. > > http://www.linuxinsider.com/story/31855.html > http://web-japan.org/trends/science/sci030522.html > > Japan had an ambitious, but sadly failed, "Fifth Generation Computing" > project: > > http://en.wikipedia.org/wiki/Fifth_generation_computer > http://vanemden.wordpress.com/2010/08/21/who-killed-prolog/ > > They did good work, but unfortunately were ahead of their time and the > project ended in failure. > > Japan virtually *owns* the video game market. Yes, yes, Americans publish > a few high-profile first-person shooters. For every one of them, there's > about a thousand Japanese games that never leave the country. > > There's no shortages of programming languages which have come out of > Japan: > > http://hopl.murdoch.edu.au/findlanguages.prx?id=jp&which=ByCountry > http://no-sword.jp/blog/2006/12/programming-without-ascii.html > > The one you're most likely to have used or at least know of is Ruby. Food for thought.. Thanks much for the links..! cj -- http://mail.python.org/mailman/listinfo/python-list
Re: client server socket interaction (inetd)
On Feb 17, 6:09 pm, Martin Gregorie wrote: > On Thu, 17 Feb 2011 13:02:08 -0800, Tim wrote: > > But. The server may encounter a problem > > during the process and ask the user for more information like > > 'abort/retry' or something like that. > > Servers never ask the client for information: they are strictly request/ > response handlers. To do what you're asking about, you'll need to change > both the client and server: > > - the client must analyse every response and, if necessary, ask for > more input from the user. IMO it would be best to design it so it > can accept several commands, with 'quit' being one of them. Either > that or all request/response pairs must be designed so that the client > can always send a single request, output the result and exit no matter > what the server returns. > > - the server must always return a response to every possible request > or log a failure reason, preferably to the system log which is > /var/log/messages in Linux, and die. The server must thoroughly > validate requests and return an adequate error message if errors were > found. I'd strongly suggest that every request generates a single > (newline terminated?) response message because that makes error > detection much easier. If the response is multi-line, send it as a > single line, possibly as a comma-separated list, and let the client > format it for display > > I tend to precede every request and response message with a fixed length > byte count: this way the recipient process always knows how many bytes to > read and can report errors if the received length is wrong. Using an 'end > of message marker' (NEWLINE unless a message can legally contain internal > newlines) can also be useful. I tend to put an error flag in the response > message because this simplifies the client. I also design all messages to > be plain ASCII because this makes debugging a lot easier. If things > really turn to worms you can use wireshark to watch the traffic and read > it straight off the screen without needing to decode binary values, etc. > So, an invalid request and response might look like this: > > Request: "0013,WHOIS,elvis\n" > Response: "0030,ERROR,Unknown request: WHOIS\n" > > > The inetd configuration is: > > myservice stream tcp nowait root /local/daemon.py daemon.py > > From what I recall about inetd that should be OK - I guess it must be > since you can get one request through, and I assume (you didn't say) that > a second request is also accepted without restarting the server. > > -- > martin@ | Martin Gregorie > gregorie. | Essex, UK > org | Thanks for helping me to understand. I don't know if you're familiar with LaTeX, but that's part of what daemon.py calls via subprocess, and that is the underlying process I wanted the user to be able to interact with. When LaTeX encounters a problem it stops processing, asks the user what to do (like abort/retry, kind-of), and does whatever the user says. The daemon.py script handles that okay from the command line, but if I'm understanding you this will be much harder if not impossible to accomplish from a client communicating over a socket. I thought that maybe I needed to fork the socket (somehow) so it could listen after the message is sent, but it looks like it will be more complex. thanks, I'm going to back to reading more on socket programming. --Tim -- http://mail.python.org/mailman/listinfo/python-list
Re: Problems of Symbol Congestion in Computer Languages
On 18/02/2011 7:43 AM, Xah Lee wrote: On 2011-02-17, Cthun wrote: │ And you omitted the #1 most serious objection to Xah's proposal, │ rantingrick, which is that to implement it would require unrealistic │ things such as replacing every 101-key keyboard with 10001-key keyboards What does your classic unsubstantiated and erroneous claim have to do with Lisp, Lee? -- http://mail.python.org/mailman/listinfo/python-list
Re: Problems of Symbol Congestion in Computer Languages
On 2/17/11 7:42 PM, Littlefield, Tyler wrote: >>My intention was to educate him on the pitfalls of multiplicity. > O. that's what you call that long-winded nonsense? Education? You must > live in America. Can I hazard a guess that your universal language might > be english? Has it not ever occured to you that people take pride in > their language? It is part of their culture. And yet you rant on about > selfishness? This is an old-rant, there's nothing new to it. Rick's racist and imperialistic anti-Unicode rants have all been fully hashed out months if not years ago, Tyler. There's really nothing more to say about it. He doesn't get it. -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Problems of Symbol Congestion in Computer Languages
On Fri, 18 Feb 2011 06:22:32 -0800 (PST), rantingrick wrote: >Evolution is about one cog gaining an edge over another, yes. However >the system itself moves toward perfection at the expense of any and >all cogs. Um, do you actually know anything about (biological) evolution? There is no evidence of an overall "goal" of any kind, perfect or not. * There are many examples of evolutionary "arms races" in nature; e.g., the cheetah and the gazelle, each gaining incrementally on the other, and a thousand generations later, each in essentially the same place relative to the other that they started from, only with longer legs or a more supple spine. * There are many adaptations that confer a serious DISadvantage in one aspect of survivability, that survive because they confer an advantage in another (sickle-cell disease in humans, a peacock's tail, etc.). >If perfection is evil then what is the pursuit of perfection: AKA: >gaining an edge? 1) I never said that perfection is evil; those are entirely your words. 2) If you don't already see the obvious difference between "pursuit of perfection" and "gaining an edge," then I'm afraid there's nothing I can do or say to help you. -Steve Schafer -- http://mail.python.org/mailman/listinfo/python-list
Re: Problems of Symbol Congestion in Computer Languages
On Feb 18, 8:22 am, rantingrick wrote: > > Perfect is the enemy of good. Do you think that just because something has a negative impact towards you (or your existence) that the *something* is then evil? Take a animal for instance: We kill animals for sustenance. The act of killing the animal is negative from the viewpoint of the animal however it does not make the killing evil. Of course if the animal could speak i am sure it will tell you that you are evil for ending its life. However the animal would be speaking from a selfish viewpoint. The animal fails to see that the human is more important than itself in the evolutionary chain. And by consuming the flesh of the animal the human can continue to evolve more knowledge. However the animal's life was not in vain for it's flesh contributed to the life of an intelligent agent who then was able to further the knowledge base of evolution far beyond what the animal could have ever achieved! Likewise *we* as intelligent agents are the tools of an intelligent evolution. When the human becomes insufficient (from the rise of AI) then the human will become the consumable. You are like the animal, not understanding your place in the universe. You fail to see the Universe from OUTSIDE your *own* selfish interpretation. You cannot wield the meanings of good and evil from a selfish and naive interpretation of the Universe. You must look much deeper. "You are not *something* unless you first realize you are *nothing*." -- http://mail.python.org/mailman/listinfo/python-list
Re: Best way to gain root privileges
On Feb 17, 3:32 pm, GSO wrote: > > I'm having a awfully hard time figuring out why a home CCTV > > application might need privilege at all. Are you sure you really need > > privilege? It sounds to me like there may be some larger design > > issues mandating the need for privilege when it's not really > > necessary. > > A user login should only able to view the footage. It's important > that a user login cannot delete any images/video. This much can be > done with ACL - but having said that a user login would still be able > to copy the images/video, so ACL would work but is not ideal - I could > prevent copying with raised privileges. If I were to allow a user to > archive footage without using an admin login then that would require > ACL with write access, which is out of the question. Uour origianl questions was: I'm sure this question is as old as time, but what is the best way to gain root privileges? (Am using Python 2.6.5, pygtk2 v2.16, Gtk v2.18.9, on RHEL6.) To which I would say, redesign the app so that you do not need root privileges. There has been plentiful advice in this thread already, but I would add: Now that you've said what the requirement is, why don't you work with the OS instead of against it? Linux and, to a lesser extent, Unix have the ability to set 'setuid', 'setgid' and 'sticky' bits on a directory's permissions, so if, for example the setgid bit is set, then all files created in that directory will belong to the group owning the directory. The sticky bit ensures that only the super user or the file owner may delete a file in the directory. See the chmod manual entry - man chmod - for details. You would need to be root to set this up initially. I think that using this mechanism, together with an appropriate umask or mode setting, should satisfy your requirements, without potential security breakages. Best wishes, John -- -- http://mail.python.org/mailman/listinfo/python-list
Re: Best way to gain root privileges
On 17 February 2011 18:39, Adam Skutt wrote: ... > As Terry suggests (and I fully concur), all of these issues are best > solved by having a privileged daemon (though it may not need to be > root or entirely root). > I think this could be done more or less with the multiprocessing module: http://docs.python.org/library/multiprocessing.html#module-multiprocessing However I would like to have a look at policykit first, it could be a more elegant solution: http://pypi.python.org/pypi?:action=search&term=polkit&submit=search http://en.wikipedia.org/wiki/PolicyKit http://www.freedesktop.org/wiki/Software/PolicyKit http://ubuntuforums.org/showthread.php?t=1359397 http://live.gnome.org/PolicyKit I note that policykit was created by redhat, and that RHEL6 does not include gksudo in with its gnome for some odd reason. -- http://mail.python.org/mailman/listinfo/python-list
Re: interrupted system call w/ Queue.get
On Feb 17, 8:46 pm, Philip Winston wrote: > We have a multiprocess Python program that uses Queue to communicate > between processes. Recently we've seen some errors while blocked > waiting on Queue.get: > > IOError: [Errno 4] Interrupted system call > > What causes the exception? Is it necessary to catch this exception > and manually retry the Queue operation? Thanks. > The exception is caused by a syscall returning EINTR. A syscall will return EINTR when a signal arrives and interrupts whatever that syscall was trying to do. Typically a signal won't interrupt the syscall unless you've installed a signal handler for that signal. However, you can avoid the interruption by using `signal.siginterrupt` to disable interruption on that signal after you've installed the handler. As for the other questions - I don't know, it depends how and why it happens, and whether it prevents your application from working properly. Jean-Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Best way to gain root privileges
On Feb 18, 9:04 am, Ricardo Aráoz wrote: > I've always asked myself why can't a program be used by users of a > certain group but run with the privileges of some other user, not > necessarily the one that uses it, but one created specifically for the > tasks the program is responsible for. > > AFAIK in Linux a program will only run with the privileges of the user > who runs it. This is precisely what the setuid /setgid bits do: force the program to run as the user and group that owns the program, instead of the user / group of the caller. It is forbidden for scripts due to lots of historical problems and inherent difficultly in writing (shell) scripts that can be elevated securely. That being said, it's typically a terrible, horrible idea. The effort involved in ensuring the program cannot be exploited rarely outweighs the gains involved from switching privileges. > Many a time I have wanted to allow access to certain privileges to a user but > *only* > through a program. As far as security is concerned it would be enough > that only root has permission to give the said program running > privileges (privileges different from those of the user that is actually > running it), that only allowed users may modify the program, and that > *other* users may only run it. This would address the issue of someone > modifying the program to gain access to it's privileges. Now, if someone > is able to gain illegal privileges to modify the program, then there > *is* a security hole and the program is not really the problem. sudo already does this to a limited degree. If you want more granularity than sudo, you're looking at mandatory access controls. Adam -- http://mail.python.org/mailman/listinfo/python-list
Re: Problems of Symbol Congestion in Computer Languages
On Feb 18, 7:55 am, Steve Schafer wrote: > On Thu, 17 Feb 2011 20:47:57 -0800 (PST), rantingrick > > wrote: > >What is evolution? > > >Evolution is the pursuit of perfection at the expense of anything and > >everything! > > No, evolution is the pursuit of something just barely better than what > the other guy has. You fail to see from a larger perspective. You still see through the eyes of part and not a whole. Each cog that is part of a machine is just a means to an end. You are attempting to elevate one cog above all other cogs, heck, you want to elevate one cog above the machine. You are nothing, and until you accept your nothingness, only then will you understand your place in the greater game. > Evolution is about gaining an edge, not gaining > perfection. Evolution is about one cog gaining an edge over another, yes. However the system itself moves toward perfection at the expense of any and all cogs. > Perfect is the enemy of good. No. Perfect is the enemy of YOU. You are not able to be perfect therefor you claim that perfection is evil to justify your meaningless existence. And who are YOU to weigh good an evil? What do YOU know about the Universe that gives you these powers of judgment? Do you think with your measly 60-100 years of lifetime you can contemplate the meaning of good and evil in a Universe that has existed for eons? Get REAL! We only see and know a small fraction of what the Universe really is. A huge portion of the Universe cannot even be accounted for. And you parade around like some all-knowing being with all the answers and full of selfishness and vanity. Ha! If perfection is evil then what is the pursuit of perfection: AKA: gaining an edge? -- http://mail.python.org/mailman/listinfo/python-list
Re: interrupted system call w/ Queue.get
In article
,
Philip Winston wrote:
> We have a multiprocess Python program that uses Queue to communicate
> between processes. Recently we've seen some errors while blocked
> waiting on Queue.get:
>
> IOError: [Errno 4] Interrupted system call
>
> What causes the exception?
Unix divides system calls up into "slow" and "fast". The difference is
how the react to signals.
Fast calls are things which are expected to return quickly. A canonical
example would get getuid(), which just returns a number it looks up in a
kernel data structure. Fast syscalls cannot be interrupted by signals.
If a signal arrives while a fast syscall is running, delivery of the
signal is delayed until after the call returns.
Slow calls are things which may take an indeterminate amount of time to
return. An example would be a read on a network socket; it will block
until a message arrives, which may be forever. Slow syscalls get
interrupted by signals. If a signal arrives while a slow syscall is
blocking, the call returns EINTR. This lets your code have a chance to
do whatever is appropriate, which might be clean up in preparation for
process shutdown, or maybe just ignore the interrupt and re-issue the
system call.
Here's a short python program which shows how this works (tested on
MacOS-10.6, but should be portable to just about any posix box):
-
#!/usr/bin/env python
import socket
import signal
import os
def handler(sig_num, stack_frame):
return
print "my pid is", os.getpid()
signal.signal(signal.SIGUSR1, handler)
s = socket.socket(type=socket.SOCK_DGRAM)
s.bind(("127.0.0.1", 0))
s.recv(1024)
-
Run this in one window. It should print out its process number, then
block on the recv() call. In another window, send it a SIGUSR1. You
should get something like:
play$ ./intr.py
my pid is 6969
Traceback (most recent call last):
File "./intr.py", line 14, in
s.recv(1024)
socket.error: [Errno 4] Interrupted system call
> Is it necessary to catch this exception
> and manually retry the Queue operation? Thanks.
That's a deeper question which I can't answer. My guess is the
interrupted system call is the Queue trying to acquire a lock, but
there's no predicting what the signal is. I'm tempted to say that it's
a bug in Queue that it doesn't catch this exception internally, but
people who know more about the Queue implementation than I do should
chime in.
> We have some Python 2.5 and 2.6 machines that have run this program
> for many 1,000 hours with no errors. But we have one 2.5 machine and
> one 2.7 machine that seem to get the error very often.
Yup, that's the nature of signal delivery race conditions in
multithreaded programs. Every machine will behave a little bit
differently, with no rhyme or reason. Google "undefined behavior" for
more details :-) The whole posix signal delivery mechanism dates back
to the earliest Unix implementations, long before there were threads or
networks. At this point, it's got many layers of duct tape.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Best way to gain root privileges
On 17/02/2011 06:46 p.m., Steven D'Aprano wrote: On Thu, 17 Feb 2011 19:44:20 +, Katie T wrote: Running any kind of script sudo'd is a bad idea, it's very very hard (in many cases impossible) to do securely. Root permissions in general should only be used for what they're needed for and nothing else (that means getting the permission, doing the stuff that needs to be done as root, and then returning back to normal privs), anything else is just asking for trouble. I agree with your general point, but the specific point to avoid running scripts with sudo? Are you sure you're not conflating sudo with setuid? By my reading, sudo is far preferred over running scripts setuid root. Linux, for example, simply will not run scripts setuid root because of the security risk, while running things using sudo is considered best practice, and much preferred over logging in as root. The idea of sudo is to do exactly what you say: doing the stuff needed as root with elevated permission, then returning to normal. Maybe this is a bit OT, as it involves the OS and security system, but considering the general knowledge assembled in this list and that it is related to the thread... I've always asked myself why can't a program be used by users of a certain group but run with the privileges of some other user, not necessarily the one that uses it, but one created specifically for the tasks the program is responsible for. AFAIK in Linux a program will only run with the privileges of the user who runs it. But I can see no reason (other than it is not actually permitted by the OS) that a program can't run with it's *own* privileges. Many a time I have wanted to allow access to certain privileges to a user but *only* through a program. As far as security is concerned it would be enough that only root has permission to give the said program running privileges (privileges different from those of the user that is actually running it), that only allowed users may modify the program, and that *other* users may only run it. This would address the issue of someone modifying the program to gain access to it's privileges. Now, if someone is able to gain illegal privileges to modify the program, then there *is* a security hole and the program is not really the problem. Am I misinformed and you can actually do this in Linux? Am I being naive security wise? -- http://mail.python.org/mailman/listinfo/python-list
Re: Problems of Symbol Congestion in Computer Languages
On Thu, 17 Feb 2011 20:47:57 -0800 (PST), rantingrick wrote: >What is evolution? > >Evolution is the pursuit of perfection at the expense of anything and >everything! No, evolution is the pursuit of something just barely better than what the other guy has. Evolution is about gaining an edge, not gaining perfection. Perfect is the enemy of good. -Steve Schafer -- http://mail.python.org/mailman/listinfo/python-list
email library, get_payload() bug?
Helllo, I want to get the raw format of email body. the code Im using is for part in email.walk(): if part.get_content_maintype() == 'multipart': continue if part.get_content_type() == 'text/plain': # print part.get_content_type() print part.get_payload(None,True) The problem is, that code adds one more '\n' at the and of the output printed by get_payload(). Is that bug? Thanks. Best, Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Problems of Symbol Congestion in Computer Languages
Chris Jones wrote: «.. from a quite different perspective it may be worth noting that practically all programming languages (not to mention the attached documentation) are based on the English language. And interestingly enough, most any software of note appears to have come out of cultures where English is either the native language, or where the native language is either relatively close to English.. Northern Europe mostly.. and not to some small extent, countries where English is well- established as a universal second language, such as India. Always struck me as odd that a country like Japan for instance, with all its achievements in the industrial realm, never came up with one single major piece of software.» btw, english is one of the two of India's official lang. It's used between Indians, and i think it's rare or non-existent for a college in india that uses local dialect. (this is second hand knowledeg. I learned this in Wikipedia and experience with indian co-workers) i also wondered about why japan doesn't seems to have created major software or OS. Though, Ruby is invented in Japan. I do think they have some OSes just not that popular... i think for special purposes OSes, they have quite a lot ... from Mitsubishi, NEC, etc... in their huge robotics industry among others. (again, this is all second hand knowledge) ... i recall having read non-english comp lang that appeared recently... Xah Lee -- http://mail.python.org/mailman/listinfo/python-list
Re: Archiving Modules
On Feb 17, 9:55 pm, Jorgen Grahn wrote: > RAR is a proprietary format, which complicates things. For example, > Linux distributions like Debian cannot distribute software which > handles it. If Python included such a module, they'd be forced to > remove it from their version. Good point, and one that I did not appreciate. But there are freeware applications such as jzip (http://www.jzip.com) which can handle .rar files, so there must be a way round it. > I wouldn't encourage its use by writing /more/ software which handles > it. IMHO, archives should be widely readable forever, and to be that > they need to be in a widely used, open format. I agree, but if a file is only available as a rar archive I would like to be able to extract it without using another 3rd party application. peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Problems of Symbol Congestion in Computer Languages
On 2011-02-16, Xah Lee wrote: │ Vast majority of computer languages use ASCII as its character set. │ This means, it jams multitude of operators into about 20 symbols. │ Often, a symbol has multiple meanings depending on contex. On 2011-02-17, rantingrick wrote: … On 2011-02-17, Cthun wrote: │ And you omitted the #1 most serious objection to Xah's proposal, │ rantingrick, which is that to implement it would require unrealistic │ things such as replacing every 101-key keyboard with 10001-key keyboards │ and training everyone to use them. Xah would have us all replace our │ workstations with machines that resemble pipe organs, rantingrick, or │ perhaps the cockpits of the three surviving Space Shuttles. No doubt │ they'd be enormously expensive, as well as much more difficult to learn │ to use, rantingrick. keyboard shouldn't be a problem. Look at APL users. http://en.wikipedia.org/wiki/APL_(programming_language) they are happy campers. Look at Mathematica, which support a lot math symbols since v3 (~1997) before unicode became popular. see: 〈How Mathematica does Unicode?〉 http://xahlee.org/math/mathematica_unicode.html word processors, also automatically do symbols such as “curly quotes”, trade mark sign ™, copyright sing ©, arrow →, bullet •, ellipsis … etc, and the number of people who produce document with these chars are probably more than the number of programers. in emacs, i recently also wrote a mode that lets you easily input few hundred unicode chars. 〈Emacs Math Symbols Input Mode (xmsi-mode)〉 http://xahlee.org/emacs/xmsi-math-symbols-input.html the essence is that you just need a input system. look at Chinese, Japanese, Korean, or Islamic. They happily type without requiring that every symbol they use must have a corresponding key on keyboard. Some lang, such as Chinese, that's impossible or impractical. when a input system is well designd, it could be actually more efficient than keyboard combinations to typo special symbols (such as in Mac OS X's opt key, or Windows's AltGraph). Because a input system can be context based, that it looks at adjacent text to guess what you want. for example, when you type >= in python, the text editor can automatically change it to ≥ (when it detects that it's appropriate, e.g. there's a “if” nearby) Chinese phonetic input system use this extensively. Abbrev system in word processors and emacs is also a form of this. I wrote some thought about this here: 〈Designing a Math Symbols Input System〉 http://xahlee.org/comp/design_math_symbol_input.html Xah Lee -- http://mail.python.org/mailman/listinfo/python-list
Re: Problems of Symbol Congestion in Computer Languages
Steven D'Aprano writes: >> A dedicated concatenation operator would have avoided that mess. > > I don't quite agree that the mess is as large as you make out, but yes, > more operators would be useful. am i wrong, or "|" is still available? -- l'amore e' un sentimento a senso unico. a volte una via comincia dove finisce un'altra e viceversa -- Caldana, in IFQ -- http://mail.python.org/mailman/listinfo/python-list
Re: Problems of Symbol Congestion in Computer Languages
Chris Jones writes: > [...] most any software of note appears to have come out of cultures > where English is either the native language, or where the native > language is either relatively close to English... i do acknowledge your "most", but how do you spell "Moon" in Portuguese? -- http://mail.python.org/mailman/listinfo/python-list
mortar_rdb 1.0.0 released!
Hi All, I'm very pleased to finally announce the release of mortar_rdb 1.0.0. This package ties together SQLAlchemy, sqlalchemy-migrate and the component architecture to make it easy to develop projects using SQLAlchemy through their complete lifecycle. While I'll be using it with Pyramid, the idea is that it should seamlessly slot into any framework, web or otherwise. I'll be actively helping anyone who runs into problems with their framework of choice. If you'd like to see what mortar_rdb can do for you, please have a read of the narrative usage docs, which give a quick run through of the lifespan of a project developers using mortar_rdb: http://packages.python.org/mortar_rdb/use.html Full package details including mailing list, irc and bug tracker details can be found here: http://www.simplistix.co.uk/software/python/mortar_rdb cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk -- http://mail.python.org/mailman/listinfo/python-list
Re: Problems of Symbol Congestion in Computer Languages
On Fri, 18 Feb 2011 02:50:11 -0500, Chris Jones wrote: > Always > struck me as odd that a country like Japan for instance, with all its > achievements in the industrial realm, never came up with one single > major piece of software. I think you are badly misinformed. The most widespread operating system in the world is not Windows. It's something you've probably never heard of, from Japan, called TRON. http://www.linuxinsider.com/story/31855.html http://web-japan.org/trends/science/sci030522.html Japan had an ambitious, but sadly failed, "Fifth Generation Computing" project: http://en.wikipedia.org/wiki/Fifth_generation_computer http://vanemden.wordpress.com/2010/08/21/who-killed-prolog/ They did good work, but unfortunately were ahead of their time and the project ended in failure. Japan virtually *owns* the video game market. Yes, yes, Americans publish a few high-profile first-person shooters. For every one of them, there's about a thousand Japanese games that never leave the country. There's no shortages of programming languages which have come out of Japan: http://hopl.murdoch.edu.au/findlanguages.prx?id=jp&which=ByCountry http://no-sword.jp/blog/2006/12/programming-without-ascii.html The one you're most likely to have used or at least know of is Ruby. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Problems of Symbol Congestion in Computer Languages
On Thu, 17 Feb 2011 21:43:37 -0800, John Nagle wrote:
> I've used both the "MIT Space Cadet" keyboard on a Symbolics LISP
> machine, and the Stanford SAIL keyboard. There's something to be said
> for having more mathematical symbols.
Agreed. I'd like Python to support proper mathematical symbols like ∞ for
float('inf'), ≠ for not-equal, ≤ for greater-than-or-equal, and ≥ for
less-than-or-equal.
They would have to be optional, because most editors still make it
difficult to enter such characters, and many fonts are lacking in glyphs,
but still, now that Python supports non-ASCII encodings in source files,
it could be done.
> Some programs use a bigger character set. MathCAD,
> for example, has a broader range of mathematical symbols on the input
> side than ASCII offers. They're not decorative; MathCAD has different
> "=" symbols for assignment, algebraic equivalence, identity, and
> comparison.
>
> I've previously mentioned that Python suffers in a few places
> from unwanted overloading. Using "+" for concatenation of strings, then
> extending that to vectors, resulted in undesirable semantics. "+" on
> arrays from "numpy", and on built-in vectors behave quite differently.
> A dedicated concatenation operator would have avoided that mess.
I don't quite agree that the mess is as large as you make out, but yes,
more operators would be useful.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: ctypes from_param() truncating 64 bit pointers to 32 bit
On 18 Feb, 10:55, Stefan Krah wrote: > Joakim Hove wrote: > > > and I actually don't know how this specific case works. > > > However, you are not providing a function signature for the "print_addr" C > > > function in the BugTest case, so my guess is that it assumes the standard > > > signature for C functions, which is "int func(int)". That would explain > > > the > > > 32bit truncation. > > > Well; I think you are wrong. First of all because what I showed in the > > Stackoverflow post was just a contrived example - the real code where > > the problem initially arose does indeed have the proper function > > signature. > > I suggest that you reconsider, since this appears to work: > > def from_param(self): > return ctypes.c_void_p(self.c_ptr) > > Stefan Krah That works - thank you very much! Joakim -- http://mail.python.org/mailman/listinfo/python-list
Re: ctypes from_param() truncating 64 bit pointers to 32 bit
> Ok, then take care to post proper code next time. Details can be important, > especially when asking about non-obvious problems. Point taken - however the original context where the problem arose consists of several massive libraries, which would be quite impractical to post on a forum. The code I did post was proper in the sense that it compiles and demonstrates the problem. > Hmm, so you think that to call a C function, ctypes doesn't need to know > what the exact signature is? That sounds a bit naive to me. I fully agree that ctypes needs to know the type signature of the C functions it wishes to call, my point is that this particular information is not present in the shared library, and for that reason we must set the input / return attributes of the ctypes functions manually. In the Python code I do this like: class BugTest: def from_param(self): return self.c_ptr def __init__(self) self.c_ptr = lib_handle = ctypes.CDLL( "lib.so" ) ... func = getattr( lib_handle , "print_addr") # Set the return type: func.restype = None # Set the types of the arguments: func.argtypes = [ BugTest ] Now - the point is that if I omit the ctypes method from_param() and instead set the argtype as: func.argtypes = [ ctypes.c_void_p ] And manually passing the internalized C - pointer to C things work as I expect; I believe that the problem is somewhere along the from_param() function path. I did not make it really clear that if the original C allocation points to memory in "32 bit region" everything works fine (as I expected). Thank you for your time. Joakim -- http://mail.python.org/mailman/listinfo/python-list
Re: ctypes from_param() truncating 64 bit pointers to 32 bit
Joakim Hove wrote: > > and I actually don't know how this specific case works. > > However, you are not providing a function signature for the "print_addr" C > > function in the BugTest case, so my guess is that it assumes the standard > > signature for C functions, which is "int func(int)". That would explain the > > 32bit truncation. > > Well; I think you are wrong. First of all because what I showed in the > Stackoverflow post was just a contrived example - the real code where > the problem initially arose does indeed have the proper function > signature. I suggest that you reconsider, since this appears to work: def from_param(self): return ctypes.c_void_p(self.c_ptr) Stefan Krah -- http://mail.python.org/mailman/listinfo/python-list
Re: ctypes from_param() truncating 64 bit pointers to 32 bit
Joakim Hove, 18.02.2011 09:46: Thanks for answering; I rarely use ctypes You should :-) Apart from my current struggle I think ctypes is really good. I'm well aware that it's a very good solution for the cases where you can trade performance for minimizing your external dependencies. But being a Cython developer, those use cases are truly rare for me. and I actually don't know how this specific case works. However, you are not providing a function signature for the "print_addr" C function in the BugTest case, so my guess is that it assumes the standard signature for C functions, which is "int func(int)". That would explain the 32bit truncation. Well; I think you are wrong. Nicely put. First of all because what I showed in the Stackoverflow post was just a contrived example - the real code where the problem initially arose does indeed have the proper function signature. Ok, then take care to post proper code next time. Details can be important, especially when asking about non-obvious problems. Secondly:The use function signatures will be relevant for C-C linkage, but ctypes library only relates to the fully linked shared librarry lib.so where these signatures have been long lost anyway; that is why we have to specify the argtypes and restype attributes of the ctypes function objects?. Hmm, so you think that to call a C function, ctypes doesn't need to know what the exact signature is? That sounds a bit naive to me. It's correct that all compile time information about function signatures is gone in the library. So you must provide ctypes with the exact signature to allow it to convert your input and output data correctly, and to put the values on the call stack in the correct calling layout. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: ctypes from_param() truncating 64 bit pointers to 32 bit
Thanks for answering; > I rarely use ctypes You should :-) Apart from my current struggle I think ctypes is really good. > and I actually don't know how this specific case works. > However, you are not providing a function signature for the "print_addr" C > function in the BugTest case, so my guess is that it assumes the standard > signature for C functions, which is "int func(int)". That would explain the > 32bit truncation. Well; I think you are wrong. First of all because what I showed in the Stackoverflow post was just a contrived example - the real code where the problem initially arose does indeed have the proper function signature. Secondly: The use function signatures will be relevant for C-C linkage, but ctypes library only relates to the fully linked shared librarry lib.so where these signatures have been long lost anyway; that is why we have to specify the argtypes and restype attributes of the ctypes function objects?. Joakim -- http://mail.python.org/mailman/listinfo/python-list
Re: reimport module every n seconds
> > Don't do that. ;-) I suggest using exec instead. However, I would be > > surprised if import worked faster than, say, JSON (more precisely, I > > doubt that it's enough faster to warrnat this kludge). > > I'm with Aahz. Don't do that. > > I don't know what you're doing, but I suspect an even better solution > would be to have your program run a "reconfigure" thread which listens > on a UDP socket and reads a JSON object from it. Or, at the very least, > which listens for a signal which kicks it to re-read some JSON from a > disk file. This will be more responsive when the data changes quickly > and more efficient when it changes slowly. As opposed to just polling > for changes every 10 seconds. Somehow I guessed that I would be told not to do it. But it's my fault. I should have been more explicit. The data is not just data. It is a large set of Django objects I call "ContentClassifiers" that have each certain methods that calculate from user input very large regular expressions. They they have a method "classify" that is applied to messages and uses the very large regular expressions. To classify a message I simply apply the classify method of all ContentClassifiers. There are very many Contentclassifiers. I compile the ContentClassifiers, which are Django objects, to pure Python objects in order to not have to fetch them from the database each time I need them and in order to be able to compile the large regular expressions offline. In Django, I generated and compiled each regular expressions of each ContentClassifier each time I needed it to classify a message. I didn't find a good way to calculate and compile the regular expressions once and store them. I already tested the automatically generated module: Before, classifying a message took about 10 seconds, now it takes miliseconds. My only problem is reloading the module: At the time being, I simply restart the web server manually from time to time in order to load the freshly compiled module. -- http://mail.python.org/mailman/listinfo/python-list
Re: ctypes from_param() truncating 64 bit pointers to 32 bit
Joakim Hove, 18.02.2011 09:29: I wonder if I am encountering a bug in ctypes; or if I am doing things wrong? I have written a small Python class wrapping a C library, the Python class has a from_param() method which passes a "raw pointer value" from Python to C. When reaching C the pointer has been truncated to 32 bits. I have written a quite extensive post about this on Stackoverflow: http://www.stackoverflow.com/q/5029341/421889/ - so far without response. Would have been very glad if anyone could indicate if this was a bug on my part, or if it is a ctypes bug. I rarely use ctypes and I actually don't know how this specific case works. However, you are not providing a function signature for the "print_addr" C function in the BugTest case, so my guess is that it assumes the standard signature for C functions, which is "int func(int)". That would explain the 32bit truncation. Stefan -- http://mail.python.org/mailman/listinfo/python-list
ctypes from_param() truncating 64 bit pointers to 32 bit
Hello, I wonder if I am encountering a bug in ctypes; or if I am doing things wrong? I have written a small Python class wrapping a C library, the Python class has a from_param() method which passes a "raw pointer value" from Python to C. When reaching C the pointer has been truncated to 32 bits. I have written a quite extensive post about this on Stackoverflow: http://www.stackoverflow.com/q/5029341/421889/ - so far without response. Would have been very glad if anyone could indicate if this was a bug on my part, or if it is a ctypes bug. I have tried with Python version 2.4 and 2.6 with identical results. Regards Joakim -- http://mail.python.org/mailman/listinfo/python-list
