Re: Cross platform mutex to prevent script running more than instance?

On Tue, Sep 4, 2018 at 5:47 PM, Cameron Simpson wrote: > > The downside with mkdir, and also with pd files really, is that a program or > OS abort can leave them lying around. Being persistent objects, some kind of > cleanup is needed. While the OP needs a cross-platform solution, if it's just Wi

Re: Cross platform mutex to prevent script running more than instance?

On 03Sep2018 07:45, Malcolm Greene wrote: >Use case: Want to prevent 2+ instances of a script from running ... >ideally in a cross platform manner. I've been researching this topic and >am surprised how complicated this capability appears to be and how the >diverse the solution set is. I've seen s

Re: Cross platform mutex to prevent script running more than instance?

On 09/04/2018 05:35 AM, Cameron Simpson wrote: > On 03Sep2018 07:45, Malcolm Greene wrote: >> Use case: Want to prevent 2+ instances of a script from running ... >> ideally in a cross platform manner. I've been researching this topic and >> am surprised how complicated this capability appears to b

Re: Cross platform mutex to prevent script running more than instance?

What about using flock()? I don't know if it works on Windows, but it works really well for Unix/Linux systems. I typically create a log file in a known location using any atomic method that doesn't replace/overwrite a file, and flock() it for the duration of the script. Thanks, Cem Karan On Mon

Re: Cross platform mutex to prevent script running more than instance?

On 09/03/18 09:45, Malcolm Greene wrote: > Use case: Want to prevent 2+ instances of a script from running ... > ideally in a cross platform manner. I've been researching this topic and > am surprised how complicated this capability appears to be and how the > diverse the solution set is. I've seen

Re: Cross platform mutex to prevent script running more than instance?

On 04Sep2018 07:57, CFK wrote: What about using flock()? I don't know if it works on Windows, but it works really well for Unix/Linux systems. I typically create a log file in a known location using any atomic method that doesn't replace/overwrite a file, and flock() it for the duration of the

Re: Cross platform mutex to prevent script running more than instance?

On 09/04/2018 05:35 AM, Cameron Simpson wrote: On 03Sep2018 07:45, Malcolm Greene wrote: Use case: Want to prevent 2+ instances of a script from running ... ideally in a cross platform manner. I've been researching this topic and am surprised how complicated this capability appears to be and ho

Re: Cross platform mutex to prevent script running more than instance?

What about using flock()? I don't know if it works on Windows, but it works really well for Unix/Linux systems. I typically create a log file in a known location using any atomic method that doesn't replace/overwrite a file, and flock() it for the duration of the script. Thanks, Cem Karan On Mon

Re: Cross platform mutex to prevent script running more than instance?

On 03Sep2018 07:45, Malcolm Greene wrote: Use case: Want to prevent 2+ instances of a script from running ... ideally in a cross platform manner. I've been researching this topic and am surprised how complicated this capability appears to be and how the diverse the solution set is. I've seen sol

Re: Cross platform mutex to prevent script running more than instance?

On 09/03/18 09:45, Malcolm Greene wrote: > Use case: Want to prevent 2+ instances of a script from running ... > ideally in a cross platform manner. I've been researching this topic and > am surprised how complicated this capability appears to be and how the > diverse the solution set is. I've seen

Re: cross-platform logging.config: how to set cross platform log (handlers) file location?

Thanks Peter for the insights that args are passed to eval(). Thanks Steven for the suggestion that ´~/' may actually work in windows. Combining both I'm now successfully using the following in my logging.conf configuration file, that works in both *nix and Windows: [handler_file] class=handlers

Re: cross-platform logging.config: how to set cross platform log (handlers) file location?

Thanks Peter for the insights that args are passed to eval(). Thanks Steven for the suggestion that ´~/' may actually work in windows. Combining both I'm now successfully using the following in my logging.conf configuration file, that works in both *nix and Windows: [handler_file] class=handlers

Re: cross-platform logging.config: how to set cross platform log (handlers) file location?

ber...@gmail.com wrote: > Hello. > > My python script should run on Linux, Win and MacOS, but I can't find a > way to have logging.conf configuration that works out of the box accross > all these OSes. > > I don't want my users to have to edit configuration files manually. > > > If I use a "li

Re: cross-platform logging.config: how to set cross platform log (handlers) file location?

On Tue, 9 Aug 2016 08:56 pm, ber...@gmail.com wrote: > Hello. > > My python script should run on Linux, Win and MacOS, but I can't find a > way to have logging.conf configuration that works out of the box accross > all these OSes. > > I don't want my users to have to edit configuration files man

Re: cross-platform logging.config: how to set cross platform log (handlers) file location?

On Tue, 9 Aug 2016 08:56 pm, ber...@gmail.com wrote: > Hello. > > My python script should run on Linux, Win and MacOS, but I can't find a > way to have logging.conf configuration that works out of the box accross > all these OSes. Oh! Wait, I didn't pick up on the logging.conf part! D'oh! > [ha

Re: cross platform alternative for signal.SIGALRM?

On 11/12/2015 6:38 AM, Chris Angelico wrote: On Thu, Nov 12, 2015 at 9:15 PM, Terry Reedy wrote: On 11/12/2015 2:37 AM, Chris Angelico wrote: On Thu, Nov 12, 2015 at 5:43 PM, Christian Gollwitzer wrote: My understanding of async is that it creates an event loop. In which case the loop has

Re: cross platform alternative for signal.SIGALRM?

On Thu, Nov 12, 2015 at 9:15 PM, Terry Reedy wrote: > On 11/12/2015 2:37 AM, Chris Angelico wrote: >> >> On Thu, Nov 12, 2015 at 5:43 PM, Christian Gollwitzer >> wrote: >>> >>> My understanding of async is that it creates an event loop. In which case >>> the loop has no chance to run within a blo

Re: cross platform alternative for signal.SIGALRM?

On 11/12/2015 2:37 AM, Chris Angelico wrote: On Thu, Nov 12, 2015 at 5:43 PM, Christian Gollwitzer wrote: My understanding of async is that it creates an event loop. In which case the loop has no chance to run within a block of code that computes anything, is that correct? This is correct. At

Re: cross platform alternative for signal.SIGALRM?

Ulli Horlacher : > Marko Rauhamaa wrote: > >> I'm thinking the only portable way is to run a watchdog process with >> subprocess or multiprocessing. > > How can a subprocess interrupt a function in another process? > > For example: waiting for user input with a timeout. > > raw_input("Hit ENTER t

Re: cross platform alternative for signal.SIGALRM?

On Thu, Nov 12, 2015 at 5:43 PM, Christian Gollwitzer wrote: > My understanding of async is that it creates an event loop. In which case > the loop has no chance to run within a block of code that computes anything, > is that correct? This is correct. At its simplest, asynchronous code is an abst

Re: cross platform alternative for signal.SIGALRM?

Marko Rauhamaa wrote: > I'm thinking the only portable way is to run a watchdog process with > subprocess or multiprocessing. How can a subprocess interrupt a function in another process? For example: waiting for user input with a timeout. raw_input("Hit ENTER to continue or wait 10 s") --

Re: cross platform alternative for signal.SIGALRM?

Terry Reedy wrote: > On 11/11/2015 11:16 AM, Ulli Horlacher wrote: > > I am rewriting a Perl program into Python (2.7). > > I recommend using 3.4+ if you possibly can. It is not possible. The main target platform offers only python 2.7 -- Ullrich Horlacher Server und Virtualisieru

Re: cross platform alternative for signal.SIGALRM?

Am 12.11.15 um 07:14 schrieb Marko Rauhamaa: Terry Reedy : The cross-platform 3.4 asyncio module has some functions with timeouts. Even that doesn't forcefully interrupt an obnoxious blocking function call like time.sleep(1) A blocking call - granted. But what happens in a blocking

Re: cross platform alternative for signal.SIGALRM?

Terry Reedy : > The cross-platform 3.4 asyncio module has some functions with > timeouts. Even that doesn't forcefully interrupt an obnoxious blocking function call like time.sleep(1) The original question claimed signal.alarm() would do the trick in Linux. However, even that cannot be r

Re: cross platform alternative for signal.SIGALRM?

On 11Nov2015 16:16, Ulli Horlacher wrote: I am rewriting a Perl program into Python (2.7). It must run on Linux and Windows. With Linux I have no problems, but Windows... :-( The current show stopper is signal.SIGALRM which is not available on Windows: File "fexit.py", line 674, in formdata_p

Re: cross platform alternative for signal.SIGALRM?

On 11/11/2015 11:16 AM, Ulli Horlacher wrote: I am rewriting a Perl program into Python (2.7). I recommend using 3.4+ if you possibly can. It must run on Linux and Windows. With Linux I have no problems, but Windows... :-( The current show stopper is signal.SIGALRM which is not available on

Re: cross platform alternative for signal.SIGALRM?

Marko Rauhamaa wrote: > Correct. The timer callback function (hello) would be called in a > separate thread. An exception raised in one thread cannot be caught in > the main thread. In general, there is no way for a thread to interrupt a > sibling thread that is in a blocking function call. Then

Re: cross platform alternative for signal.SIGALRM?

Ulli Horlacher : > Hmmm... not so simple for me. My test code: > > from time import * > import threading > import sys > > def hello(): > raise ValueError("hello!!!") > > t = threading.Timer(3.0,hello) > t.start() > try: > print "start" > sleep(5) > print "end" > except ValueError as e: >

Re: cross platform alternative for signal.SIGALRM?

Marko Rauhamaa wrote: > Ulli Horlacher : > > > What is the best practise for a cross platform timeout handler? > > Here's the simplest answer: > >https://docs.python.org/3/library/threading.html#threading.Timer > > (Also available in Python 2.) Hmmm... not so simple for me. My test code:

Re: cross platform alternative for signal.SIGALRM?

Ulli Horlacher : > What is the best practise for a cross platform timeout handler? Here's the simplest answer: https://docs.python.org/3/library/threading.html#threading.Timer (Also available in Python 2.) Marko -- https://mail.python.org/mailman/listinfo/python-list

Re: Cross-platform way to get default directory for binary files like console scripts?

On Thursday, February 20, 2014 4:34:25 PM UTC+1, Piotr Dobrogost wrote: > > I'm wondering if there's some API to get this info as what you showed is > really roundabout way to achieve the goal... Turns out there is API for this - see thread on distutils-sig mailing list at https://mail.python.o

Re: Cross-platform way to get default directory for binary files like console scripts?

On 2/20/14 10:55 AM, Oscar Benjamin wrote: On 20 February 2014 15:42, Ned Batchelder wrote: As roundabout and advanced as that code is, it doesn't give the right answer for me. It returns None. On my Mac, after activating a virtualenv: Python 2.7.2 (default, Oct 11 2012, 20:14:37)

Re: Cross-platform way to get default directory for binary files like console scripts?

On Thursday, February 20, 2014 4:42:54 PM UTC+1, Ned Batchelder wrote: > > As roundabout and advanced as that code is, it doesn't give the right > answer for me. It returns None. Indeed. I tried on Linux and got None both inside and outside virtualenv :( Regards, Piotr -- https://mail.python.

Re: Cross-platform way to get default directory for binary files like console scripts?

On 20 February 2014 15:42, Ned Batchelder wrote: > > As roundabout and advanced as that code is, it doesn't give the right answer > for me. It returns None. On my Mac, after activating a virtualenv: > > Python 2.7.2 (default, Oct 11 2012, 20:14:37) > [GCC 4.2.1 Compatible Apple Clang 4.0

Re: Cross-platform way to get default directory for binary files like console scripts?

On 20 February 2014 15:34, Piotr Dobrogost wrote: > On Thursday, February 20, 2014 4:22:53 PM UTC+1, Oscar Benjamin wrote: > >> You can find the default location in this roundabout way: > > I'm wondering if there's some API to get this info as what you showed is > really roundabout way to achieve

Re: Cross-platform way to get default directory for binary files like console scripts?

On 2/20/14 10:34 AM, Piotr Dobrogost wrote: On Thursday, February 20, 2014 4:22:53 PM UTC+1, Oscar Benjamin wrote: I'm not sure if I understand the question. Are you trying to find where a script would go if it had been installed as a result of 'python setup.py install' or 'pip install ...'?

Re: Cross-platform way to get default directory for binary files like console scripts?

On Thursday, February 20, 2014 4:22:53 PM UTC+1, Oscar Benjamin wrote: > > I'm not sure if I understand the question. Are you trying to find > where a script would go if it had been installed as a result of > 'python setup.py install' or 'pip install ...'? > Yes. > If so there are > different p

Re: Cross-platform way to get default directory for binary files like console scripts?

On 20 February 2014 14:27, Piotr Dobrogost wrote: > Is there cross-platform way to get default directory for binary files > (console scripts for instance) the same way one can use sys.executable to get > path to the Python's interpreter in cross-platform way? > > Context: > There's Python script

Re: Cross-platform way to get default directory for binary files like console scripts?

On 2/20/14 9:27 AM, Piotr Dobrogost wrote: Hi! Is there cross-platform way to get default directory for binary files (console scripts for instance) the same way one can use sys.executable to get path to the Python's interpreter in cross-platform way? Context: There's Python script which runs

RE: Cross Platform

Thank you William. -Original Message- From: William Ray Wing [mailto:w...@mac.com] Sent: Thursday, September 05, 2013 6:18 PM To: Chandru Rajendran Cc: William Ray Wing; python-list@python.org Subject: Re: Cross Platform On Sep 4, 2013, at 11:47 PM, Chandru Rajendran wrote: > Hi

Re: Cross Platform

On Sep 4, 2013, at 11:47 PM, Chandru Rajendran wrote: > Hi all, > > I have a doubt regarding the python cross platform. I think you mean you have a question... > If we write Class in windows ,whether we can without any modifications in > Linux, if so then how about the GUI programming and Li

Re: Cross-Platform Python3 Equivalent to notify-send

On 7/27/13 6:58 AM, Devyn Collier Johnson wrote: Linux systems with the proper software can use the "notify-send" command. Is there a cross-platform Python3 equivalent? Mahalo, Devyn Collier Johnson devyncjohn...@gmail.com http://pythonhosted.org/gntp/ ? -- Kevin Walzer Code by Kevin/Mobile

Re: Cross-Platform Python3 Equivalent to notify-send

On 07/27/2013 11:59 AM, Steven D'Aprano wrote: On Sat, 27 Jul 2013 08:22:00 -0400, Devyn Collier Johnson wrote: On 07/27/2013 07:30 AM, Chris “Kwpolska” Warrick wrote: On Sat, Jul 27, 2013 at 12:58 PM, Devyn Collier Johnson wrote: Linux systems with the proper software can use the "notify-s

Re: Cross-Platform Python3 Equivalent to notify-send

On 07/27/2013 12:06 PM, Chris Angelico wrote: On Sat, Jul 27, 2013 at 4:59 PM, Steven D'Aprano wrote: On Sat, 27 Jul 2013 08:22:00 -0400, Devyn Collier Johnson wrote: That really sucks. I was hoping Python had some way of doing that. All that it needs to do is display a little box at one of t

Re: Cross-Platform Python3 Equivalent to notify-send

On Sat, Jul 27, 2013 at 4:59 PM, Steven D'Aprano wrote: > On Sat, 27 Jul 2013 08:22:00 -0400, Devyn Collier Johnson wrote: >> That really sucks. I was hoping Python had some way of doing that. All >> that it needs to do is display a little box at one of the corners of the >> screen. I thought some

Re: Cross-Platform Python3 Equivalent to notify-send

On Sat, 27 Jul 2013 08:22:00 -0400, Devyn Collier Johnson wrote: > On 07/27/2013 07:30 AM, Chris “Kwpolska” Warrick wrote: >> On Sat, Jul 27, 2013 at 12:58 PM, Devyn Collier Johnson >> wrote: >>> Linux systems with the proper software can use the "notify-send" >>> command. Is there a cross-platfo

Re: Cross-Platform Python3 Equivalent to notify-send

On Sat, Jul 27, 2013 at 1:22 PM, Devyn Collier Johnson wrote: > That really sucks. I was hoping Python had some way of doing that. All that > it needs to do is display a little box at one of the corners of the screen. > I thought someone would have implemented something by now. Thank you anyway.

Re: Cross-Platform Python3 Equivalent to notify-send

On 07/27/2013 07:30 AM, Chris “Kwpolska” Warrick wrote: On Sat, Jul 27, 2013 at 12:58 PM, Devyn Collier Johnson wrote: Linux systems with the proper software can use the "notify-send" command. Is there a cross-platform Python3 equivalent? Mahalo, Devyn Collier Johnson devyncjohn...@gmail.com

Re: Cross-Platform Python3 Equivalent to notify-send

Whoops! On Sat, Jul 27, 2013 at 1:30 PM, Chris “Kwpolska” Warrick wrote: > You already asked this on Thursday. And the answer is probably “no”. > Creating …a solution for this is not the easiest thing one can do. -- Chris “Kwpolska” Warrick PGP: 5EAAEA16 stop html mail |

Re: Cross-Platform Python3 Equivalent to notify-send

On Sat, Jul 27, 2013 at 12:58 PM, Devyn Collier Johnson wrote: > Linux systems with the proper software can use the "notify-send" command. Is > there a cross-platform Python3 equivalent? > > Mahalo, > > Devyn Collier Johnson > devyncjohn...@gmail.com > -- > http://mail.python.org/mailman/listinfo/

Re: Cross-platform module that creates directory object with all file attributes

Hi Tim, > Can't help you with x-platform; but for Windows I can offer my winsys package. > if f.readonly: >print f.created_at, f I like your logical model - that's exactly what I was looking for. Thank you for sharing your code. Cheers, Malcolm -- http://mail.python.org/mailman/listinfo/

Re: Cross-platform module that creates directory object with all file attributes

On 07/13/2010 10:56 AM, pyt...@bdurham.com wrote: Any recommendations for a cross-platform module that creates a directory object with not only file names, but file attributes as well? Use cases: - Sort files by file size or date last modified - Filter files by read-only status I know I can use

Re: Cross-platform detection of exceptions raised during file access via os, shutil, codecs, etc.

On 06/09/2010 11:56 PM, pyt...@bdurham.com wrote: > I'm looking for some suggestions on how to detect exceptions raised > during common types of file access (os, shutil, codecs, etc.) on a > cross-platform basis. I'm looking for feedback relative to Python 2.6 > and 2.7 but would also appreciate he

Re: Cross-platform file paths

On Sonntag 09 Mai 2010, Tim Roberts wrote: > No. On Linux, you need to mount the share in some empty > directory (using mount or smbmount), then read the files from > that directory. actually the mount directory does not have to be empty - whatever it contains is invisible while someting is mount

Re: Cross-platform file paths

utabintarbo wrote: > >Until now, I have used the UNC under Windows (XP) to allow my program >to access files located on a Samba-equipped *nix box (eg. >os.path.normpath(r"\\serverFQDN\sharename\dir\filename")). When I try >to open this file under Linux (Red Hat 5), I get a file not found >error. >

Re: Cross-platform file paths

Hi TIA, utabintarbo wrote: > Until now, I have used the UNC under Windows (XP) to allow my program > to access files located on a Samba-equipped *nix box (eg. > os.path.normpath(r"\\serverFQDN\sharename\dir\filename")). When I try > to open this file under Linux (Red Hat 5), I get a file not found

Re: Cross-platform file paths

On May 7, 11:23 am, cassiope wrote: > > normpath will convert forward slashes to backslashes on WinXX systems, > but > does not seem to do the reverse on posix systems...so try changing > your > string to use forward slashes.  Also- is the path otherwise the same > on > your Linux system? > > HTH.

Re: Cross-platform file paths

On May 7, 7:32 am, utabintarbo wrote: > Until now, I have used the UNC under Windows (XP) to allow my program > to access files located on a Samba-equipped *nix box (eg. > os.path.normpath(r"\\serverFQDN\sharename\dir\filename")). When I try > to open this file under Linux (Red Hat 5), I get a fil

Re: Cross-platform way to retrieve the current (Operative system) DNS server IP address in python

joamag wrote: It's not my ip address that I want to discover... I want to discover my default dns server ip address. This ip is stored in an operative system basis. Dos anyone know how to get it ? You asked for a cross-platform solution; there probably isn't one. The code below works on Unix

Re: Cross-platform way to retrieve the current (Operative system) DNS server IP address in python

maybe this helps you: http://pypi.python.org/pypi/netifaces/0.3 best regards, Katcipis On Tue, Apr 27, 2010 at 7:49 PM, joamag wrote: > On 24 Abr, 14:50, DarkBlue wrote: > > On Apr 22, 4:55 pm, joamag wrote: > > > > > Does anybody know a cross platform way to retrieve the default DNS > > > s

Re: Cross-platform way to retrieve the current (Operative system) DNS server IP address in python

On 24 Abr, 14:50, DarkBlue wrote: > On Apr 22, 4:55 pm, joamag wrote: > > > Does anybody know a cross platform way to retrieve the default DNS > > server IP address in python ? > > > Thanks ! > > João > > import os,urllib2,re > > def getIpAddr(): >     """ >     Function for parsing external ip a

Re: Cross-platform way to retrieve the current (Operative system) DNS server IP address in python

On Apr 22, 4:55 pm, joamag wrote: > Does anybody know a cross platform way to retrieve the default DNS > server IP address in python ? > > Thanks ! > João import os,urllib2,re def getIpAddr(): """ Function for parsing external ip adress by pinging dyndns.com """ External_IP=url

Re: cross-platform coloured text in terminal

On Apr 17, 11:52 am, Jonathan Hartley wrote: > On Apr 16, 5:59 pm, Lie Ryan wrote: > > > > > On 04/16/10 19:28, Jonathan Hartley wrote: > > > > I'm playing with ideas of what API to expose. My favourite one is to > > > simply embed ANSI codes in the stream to be printed. Then this will > > > work

Re: cross-platform coloured text in terminal

That sounds like a nice idea, try it out and see what you make of it. (It may have been done before but probably not as a standalone module as it doesn't require that much code) On Sat, Apr 17, 2010 at 6:52 AM, Jonathan Hartley wrote: > On Apr 16, 5:59 pm, Lie Ryan wrote: > > On 04/16/10 19:28,

Re: cross-platform coloured text in terminal

On Apr 16, 5:59 pm, Lie Ryan wrote: > On 04/16/10 19:28, Jonathan Hartley wrote: > > > I'm playing with ideas of what API to expose. My favourite one is to > > simply embed ANSI codes in the stream to be printed. Then this will > > work as-is on Mac and *nix. To make it work on Windows, printing c

Re: cross-platform coloured text in terminal

On 04/16/10 19:28, Jonathan Hartley wrote: > I'm playing with ideas of what API to expose. My favourite one is to > simply embed ANSI codes in the stream to be printed. Then this will > work as-is on Mac and *nix. To make it work on Windows, printing could > be done to a file0-like object which wra

Re: cross-platform coloured text in terminal

On Apr 16, 10:28 am, Jonathan Hartley wrote: > Hi, > > It irks me that I know of no simple cross-platform way to print > colored terminal text from Python. > > As I understand it, printing ANSI escape codes (as wrapped nicely by > module termcolor and others) works on Macs and *nix, but only works

Re: Cross platform TTF font render from Python [was: Load TTF from pycairo under Windows]

On Friday 18 September 2009 08:54, Laszlo Nagy wrote: > I need to render antialiased PNG images using TTF font files and UTF-8 > text. It needs to be available at least on Linux and Windows. This is > what I have tried: [...] > #4. pygame - documentation looks great, it is cross platform. But th

Re: Cross platform TTF font render from Python [was: Load TTF from pycairo under Windows]

Laszlo Nagy wrote: ... > looks impossible to use it for creating raster images. Details here: http://osdir.com/ml/python.reportlab.user/2005-06/msg00015.html OK your error occurs because we need to set up the renderPM canvas with an initial font (for compatibility with the PDF canvas

Re: Cross platform TTF font render from Python [was: Load TTF from pycairo under Windows]

... the reportlab graphics renderPM(_renderPM) module does most things with T1 and TTF and works linux/win32. We use freetype2 internally to extract the curves from ttf and then draw them with libart_lgpl which does anti-aliasing. I just tried reportlab and RenderPM. I got the same error

Re: Cross platform TTF font render from Python [was: Load TTF from pycairo under Windows]

Laszlo Nagy wrote: Hi All, I need to render antialiased PNG images using TTF font files and UTF-8 text. It needs to be available at least on Linux and Windows. This is what I have tried: #1. PIL - it has some problems and I cannot use it. Specifically, the ImageFont.getsize() returns bad va

Re: cross platform distribution

These are all good suggestions. I just wanted to add that you can distribute pre-built Linux packages for the most popular distros like one for RHEL/Centos/Fedora as RPM and one for Debian/Ubuntu as DEB. Any C code in them would be compiled. On Sep 4, 9:33 am, Philip Semanchuk wrote: > On Sep 4,

Re: cross platform distribution

On Sep 4, 3:33 pm, Philip Semanchuk wrote: > On Sep 4, 2009, at 9:24 AM, vpr wrote: > > > > > On Sep 4, 3:19 pm, Philip Semanchuk wrote: > >> On Sep 4, 2009, at 4:44 AM, vpr wrote: > > >>> Hi All > > >>> After a couple of experiments, searching around and reading Steve > >>> Holden's lament about

Re: cross platform distribution

On Sep 4, 2009, at 9:24 AM, vpr wrote: On Sep 4, 3:19 pm, Philip Semanchuk wrote: On Sep 4, 2009, at 4:44 AM, vpr wrote: Hi All After a couple of experiments, searching around and reading Steve Holden's lament about bundling and ship python code, I thought I'd direct this to to the gro

Re: cross platform distribution

On Sep 4, 3:19 pm, Philip Semanchuk wrote: > On Sep 4, 2009, at 4:44 AM, vpr wrote: > > > > > Hi All > > > After a couple of experiments, searching around and reading Steve > > Holden's lament about bundling and ship python code, I thought I'd > > direct this to to the group. I'm using Python 2.6

Re: cross platform distribution

On Sep 4, 2009, at 4:44 AM, vpr wrote: Hi All After a couple of experiments, searching around and reading Steve Holden's lament about bundling and ship python code, I thought I'd direct this to to the group. I'm using Python 2.6 btw. I've build a commercial application that I'd like to bundle

Re: cross platform method Re: How to get the total size of a local hard disk?

Tim Harig wrote: > > This is a joke. Do not take it seriously. I do not actually suggest > anybody use this method to measure the size of their drive. I do not take any > responsibility for any damages incurred by using this method. I will laugh > at you if you do. Offer not valid in AK, HI,

Re: Cross platform installer builder for Python? (like IzPack for Java)

Hola Gabriel: On 2009-03-25 19:19, Gabriel Genellina wrote: > To distribute complete applications, py2exe + InnoSetup (Windows). That's the point: IzPack (Java) creates installers, that work at least on Windows and Linux, create menu entries in Windows and Gnome/KDE etc. Only one .jar file to dis

Re: Cross platform installer builder for Python? (like IzPack for Java)

En Wed, 25 Mar 2009 17:28:30 -0300, W. Martin Borgert escribió: I'm looking for an installer builder similar to IzPack (which is based on Java). Isn't there anything like that in the Python world? Extra points, if GTK+ or wxWindows is used... To distribute modules/packages, I use distutils.

Re: cross platform accessing paths (windows, linux ...)

Vlastimil Brom wrote: > 2009/3/13 hendra kusuma : >> you may want to use os.sep to replace manually written "/" "\" ":" for each >> os >> I heard that unix/linux use "/" as directory separator while windows use "\" >> and mac os use ":" >> > Thanks for the notice about the ":" path separator on mac

Re: cross platform accessing paths (windows, linux ...)

2009/3/13 hendra kusuma : > you may want to use os.sep to replace manually written "/" "\" ":" for each > os > I heard that unix/linux use "/" as directory separator while windows use "\" > and mac os use ":" > Thanks for the notice about the ":" path separator on mac; windows uses "\" but normally

Re: cross platform accessing paths (windows, linux ...)

2009/3/12 Christian Heimes : > Vlastimil Brom wrote: >> def path_from_pardir(path): >>     return >> os.path.realpath(os.path.normpath(os.path.join(os.path.dirname(__file__), >> os.pardir, path))) >> #  __file__ is substituted with sys.path[0] if not present >> >> real_path = path_from_pardir("txt

Re: cross platform accessing paths (windows, linux ...)

Vlastimil Brom wrote: > def path_from_pardir(path): > return > os.path.realpath(os.path.normpath(os.path.join(os.path.dirname(__file__), > os.pardir, path))) > # __file__ is substituted with sys.path[0] if not present > > real_path = path_from_pardir("txt/text_1.txt") > > The above seems to

Re: cross platform accessing paths (windows, linux ...)

> On Thu, Mar 12, 2009 at 8:10 AM, Vlastimil Brom > wrote: >> >> Hi all, >> I'd like to ask for some advice on how to acomplish file access in a >> cross platform way. >> ... >> Any hints or comments are much appreciated; thanks in advance! >> >> regards, >>   Vlasta 2009/3/12 Mike Mazurek : > Y

Re: cross platform accessing paths (windows, linux ...)

You might want to look at the path module: http://pypi.python.org/pypi/path.py/2.2 It will probably make your code more readable. On Thu, Mar 12, 2009 at 8:10 AM, Vlastimil Brom wrote: > Hi all, > I'd like to ask for some advice on how to acomplish file access in a > cross platform way. > My ap

Re: Cross platform compilation?

On Tuesday 03 February 2009 03:59, John Harper wrote: > Before I try to reverse engineer completely setup.py, is there > something obvious that needs to be done to get it to use the right tool > chain? I think it's more complicated than that, though in an ideal world it wouldn't have to be that w

Re: Cross platform compilation?

Christian Heimes wrote: > John Harper schrieb: > > I am trying to build Python to use in an embedded system which uses a > > ppc_440 CPU. The only information I've found is something written by > > Klaus Reimer a few years ago, which was based on Python 2.2. So far I > > seem to have successfu

Re: Cross platform compilation?

On Feb 2, 6:59 pm, "John Harper" wrote: > I am trying to build Python to use in an embedded system which uses a > ppc_440 CPU. The only information I've found is something written by > Klaus Reimer a few years ago, which was based on Python 2.2. So far I > seem to have successfully built Python it

Re: Cross platform compilation?

John Harper schrieb: > I am trying to build Python to use in an embedded system which uses a > ppc_440 CPU. The only information I've found is something written by > Klaus Reimer a few years ago, which was based on Python 2.2. So far I > seem to have successfully built Python itself, but buildin

Re: cross-platform c questions

En Wed, 14 Nov 2007 20:49:35 -0300, Martin v. Löwis <[EMAIL PROTECTED]> escribió: >> Is there any rules/criteria to decide when to use Py_ssize_t, int, or >> long? I've seen them somewhat mixed and don't know when exactly to use >> Py_ssize_t. > > You should use Py_ssize_t when you are counting

Re: cross-platform c questions

> Is there any rules/criteria to decide when to use Py_ssize_t, int, or > long? I've seen them somewhat mixed and don't know when exactly to use > Py_ssize_t. You should use Py_ssize_t when you are counting things, and when there is no small limit (e.g. 66536) to the maximum number of things you c

Re: cross-platform c questions

En Wed, 14 Nov 2007 05:36:04 -0300, Martin v. Löwis <[EMAIL PROTECTED]> escribió: >> When writing a python c extension for needs to be compiled for >> Windows, Linux, and the Mac, >> what cross-platform differences need to be accounted for?# > > Not functions, no, but macros and typedefs. For

Re: cross-platform c questions

> When writing a python c extension for needs to be compiled for > Windows, Linux, and the Mac, > what cross-platform differences need to be accounted for?# >From a Python point of view, it's primarily the difference in the size of types. For example, long may vary across platforms, and so chan

Re: Cross-platform GUI development

bramble <[EMAIL PROTECTED]> wrote: > [ GTK is ] free >software, so contributors can try and make the L&F more native if it's >really that big a deal. But the people who care about Windows native L&F are not the people with the resources (time, money, probably experience) to address this issue. An

Re: Cross-platform GUI development

On Oct 25, 6:32 am, "Chris Mellon" <[EMAIL PROTECTED]> wrote: > On 10/24/07, bramble <[EMAIL PROTECTED]> wrote: > > > In the end, GTK+ is themable, and it's a free software project, so if > > the MS Windows port has warts, anyone can come along and polish it up > > for that platform. > > There's be

Re: Cross-platform GUI development

On 10/24/07, bramble <[EMAIL PROTECTED]> wrote: > On Oct 23, 2:59 pm, "Chris Mellon" <[EMAIL PROTECTED]> wrote: > > On 10/23/07, maco <[EMAIL PROTECTED]> wrote: > > > > > > > On Oct 13, 12:34 am, Michael L Torrie <[EMAIL PROTECTED]> wrote: > > > > > > Qt doesn't look very native on my desktop. In

Re: Cross-platform GUI development

On Oct 12, 6:30 am, Nick Craig-Wood <[EMAIL PROTECTED]> wrote: > > I'd recommend wxPython over those becase > > 1) native look and feel on all platforms > 2) doesn't require expensive licensing for non-commercial apps (QT) > 3) Isn't a pain to install on windows (GTK) > > That said, times change an

Re: Cross-platform GUI development

On Oct 23, 2:59 pm, "Chris Mellon" <[EMAIL PROTECTED]> wrote: > On 10/23/07, maco <[EMAIL PROTECTED]> wrote: > > > > On Oct 13, 12:34 am, Michael L Torrie <[EMAIL PROTECTED]> wrote: > > > > Qt doesn't look very native on my desktop. In fact, Qt apps have always > > > looked out of place on a Gnome

Re: Cross-platform GUI development

On 10/23/07, maco <[EMAIL PROTECTED]> wrote: > On Oct 13, 12:34 am, Michael L Torrie <[EMAIL PROTECTED]> wrote: > > Alexandre Badez wrote: > > > Personnaly, I use PyQt simply because I prefere Qt to Gtk, witch is > > > much more integrated with all desktop than Gtk. > > > In fact, your application

Re: Cross-platform GUI development

On Oct 13, 12:34 am, Michael L Torrie <[EMAIL PROTECTED]> wrote: > Alexandre Badez wrote: > > Personnaly, I use PyQt simply because I prefere Qt to Gtk, witch is > > much more integrated with all desktop than Gtk. > > In fact, your application in Qt on Mac, Win or Linux look like a > > native app.

  1   2   >