Re: How to make a cross platform python app with pyinstaller??

Use the Dev version of pyinstaller. pip install https://github.com/pyinstaller/pyinstaller/archive/develop.zip Yours, Abdur-Rahmaan Janhangeer pythonmembers.club | github Mauritius On Wed, Feb 5, 2020 at 7:31 AM Souvik Dutta

Re: How to make a cross platform python app with pyinstaller??

On 04Feb2020 21:27, Michael Torrie wrote: On 2/4/20 8:33 PM, Chris Angelico wrote: On Wed, Feb 5, 2020 at 2:32 PM Souvik Dutta wrote: I made a python gui with pyqt5 and packed it with pyinstaller. It is running well in my computer but when I gave it to a friend who doesn't have any python ver

Re: How to make a cross platform python app with pyinstaller??

On 2/4/20 8:33 PM, Chris Angelico wrote: > On Wed, Feb 5, 2020 at 2:32 PM Souvik Dutta wrote: >> >> Hi, >> I made a python gui with pyqt5 and packed it with pyinstaller. It is >> running well in my computer but when I gave it to a friend who doesn't have >> any python version installed and it didn

Re: How to make a cross platform python app with pyinstaller??

On Wed, Feb 5, 2020 at 2:32 PM Souvik Dutta wrote: > > Hi, > I made a python gui with pyqt5 and packed it with pyinstaller. It is > running well in my computer but when I gave it to a friend who doesn't have > any python version installed and it didn't run. The message was "This app > cannot be ru

How to make a cross platform python app with pyinstaller??

Hi, I made a python gui with pyqt5 and packed it with pyinstaller. It is running well in my computer but when I gave it to a friend who doesn't have any python version installed and it didn't run. The message was "This app cannot be run on your pc.". How can I solve this??? -- https://mail.python.

Recommendation on best cross-platform encryption package

Is the cryptography package still considered the "best" cross-platform package for encrypting sensitive data being stored in files on disk. Use case: JSON data files containing potentially confidential/PII data using something along the lines of AES256 encryption. Goal is to encry

Re: Normalizing path strings and separators in cross-platform unit test scripts

at the os and pathlib libraries without seeing >> anything that describes our need. >> Any downsides to this approach? Use os.path.normpath to compare apples to apples, as was mentioned in another post. > If you are confident you'll never have an actual backslash in a path &

Re: Normalizing path strings and separators in cross-platform unit test scripts

On Tue, Jan 8, 2019 at 5:52 AM Malcolm Greene wrote: > > Any recommendations on normalizing path strings in cross platform > (Windows, Linux, macOS) for unit tests? > Our goal is to normalize path strings to use forward slash separators so > that we can consistently reference path

Normalizing path strings and separators in cross-platform unit test scripts

Any recommendations on normalizing path strings in cross platform (Windows, Linux, macOS) for unit tests? Our goal is to normalize path strings to use forward slash separators so that we can consistently reference path strings in our unit tests in a cross platform way. Example: Under Windows we

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,

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

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

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

Karan On Mon, Sep 3, 2018, 11:39 PM 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 co

Cross platform mutex to prevent script running more than instance?

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 solutions ranging from using director

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 solu

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

ion of the script. Please adopt the inline reply format. Thanks. The good things about flock() and open(O_EXCL) and other variations is that if your program aborts (or its OS aborts) the lock goes away. The downside is that it is less cross platform (including network filesystems). Even ignorin

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?

Karan On Mon, Sep 3, 2018, 11:39 PM 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 co

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&#x

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 solu

Cross platform mutex to prevent script running more than instance?

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 solutions ranging from using director

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?

le] > class=handlers.RotatingFileHandler > args=('D:\scribusGenerator.log','a','maxBytes=1000','backupCount=1') > > > One option would be to set the location dynamically in the system temp > directory (from tempfile.gettempdir())... but I

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

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

backupCount=1') One option would be to set the location dynamically in the system temp directory (from tempfile.gettempdir())... but I can't find a way to change the location of the handler loaded via config module. Any piece of advice on how to achieve cross-platform logging that does not require a modification by the user? Thanks. B. -- https://mail.python.org/mailman/listinfo/python-list

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

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 tha

Re: cross platform alternative for signal.SIGALRM?

of emulation). Ok, I have to redesign this part of my code: def timeout_handler(sig,frame): raise ValueError("timeout!") signal.signal(signal.SIGALRM,timeout_handler) while True: chunk = fileo.read(bs) sock.sendall(chunk) (...) What is the best practise for a cross platform

Re: cross platform alternative for signal.SIGALRM?

eo.read(bs) sock.sendall(chunk) (...) What is the best practise for a cross platform timeout handler? The cross-platform 3.4 asyncio module has some functions with timeouts. (3.5 has new 'async' syntac which supposedly makes it easier to use. I have not looked at this yet.) For

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...

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

cross platform alternative for signal.SIGALRM?

n this part of my code: def timeout_handler(sig,frame): raise ValueError("timeout!") signal.signal(signal.SIGALRM,timeout_handler) while True: chunk = fileo.read(bs) sock.sendall(chunk) (...) What is the best practise for a cross platform timeout handler? -- U

Re: A high-level cross-platform API for terminal/console access

"Chris Angelico" wrote: Ah, that might well be it. Does it work if you run: python -S -m pip install --upgrade win32api Hm. c:\>python2 -S -m pip install --upgrade win32api Collecting win32api Could not find any downloads that satisfy the requirement win32api No distributions at al

Re: A high-level cross-platform API for terminal/console access

On 22 October 2015 at 13:42, Gisle Vanem wrote: > "Chris Angelico" wrote: > >> On Thu, Oct 22, 2015 at 10:22 PM, Gisle Vanem wrote: >>> >>> IOError: [Errno 13] Permission denied: >>> 'g:\\Programfiler\\Python27\\Lib\\site-packages\\win32\\win32api.pyd' >>> >>> - >>> >>> BTW, this is on Pyth

Re: A high-level cross-platform API for terminal/console access

On Thu, Oct 22, 2015 at 11:42 PM, Gisle Vanem wrote: > I think the Errno 13 (=EACCESS) is due to another module (WConio.pyd) that > seems gets loaded via my site-customize.py is using this > win32api.pyd. Hence it's is in use and shutil fails in updating it. Ah, that might well be it. Does it wor

Re: A high-level cross-platform API for terminal/console access

"Chris Angelico" wrote: On Thu, Oct 22, 2015 at 10:22 PM, Gisle Vanem wrote: IOError: [Errno 13] Permission denied: 'g:\\Programfiler\\Python27\\Lib\\site-packages\\win32\\win32api.pyd' - BTW, this is on Python 2.7.9 on Win-XP SP3. Does that file exist? A .pyd file is a DLL, so if it

Re: A high-level cross-platform API for terminal/console access

On Thu, Oct 22, 2015 at 10:22 PM, Gisle Vanem wrote: > IOError: [Errno 13] Permission denied: > 'g:\\Programfiler\\Python27\\Lib\\site-packages\\win32\\win32api.pyd' > > - > > BTW, this is on Python 2.7.9 on Win-XP SP3. Does that file exist? A .pyd file is a DLL, so if it already exists and

Re: A high-level cross-platform API for terminal/console access

On Thursday, October 22, 2015 at 12:25:09 PM UTC+1, Gisle Vanem wrote: > I tried installing your package with "pip.exe -v install asciimatics". > Some problem with pypiwin32 it seems: > > Installing collected packages: pypiwin32, future, Pillow, pyfiglet, > asciimatics > > Cleaning up... > E

Re: A high-level cross-platform API for terminal/console access

"Peter Brittain" wrote: I have recently been working on a terminal/console animation package (https://github.com/peterbrittain/asciimatics). I tried installing your package with "pip.exe -v install asciimatics". Some problem with pypiwin32 it seems: Installing collected packages: pypiwin32,

Re: A high-level cross-platform API for terminal/console access

I couldn't > use it directly due to the pip installation restriction. I've now created a > working Windows implementation, so I don't need another mapping for win32. > > More generally, as these posts begin to show, there was no _simple_ way for > me to get a cros

Re: A high-level cross-platform API for terminal/console access

e now created a working Windows implementation, so I don't need another mapping for win32. More generally, as these posts begin to show, there was no _simple_ way for me to get a cross-platform console API that "just worked" out of the box. I've had to jump through various hoops

Re: A high-level cross-platform API for terminal/console access

r Python. While ncurses does a great job of abstracting away the issues of >terminal inter-operation, the Python curses package is just a thin wrapper of >that C library and, as can be seen above, not truly cross-platform due to the >restrictions of PDcurses. > >Shouldn't we have

Re: A high-level cross-platform API for terminal/console access

that C library and, as can be seen above, not truly cross-platform due to the restrictions of PDcurses. Shouldn't we have a higher level simplification? Something that hides away all the complexity of handling all these different platforms and so exposes a simple API? One that humans ca

Re: A high-level cross-platform API for terminal/console access

On 10/21/15, Peter Brittain wrote: >> >> Did you try https://pypi.python.org/pypi/UniCurses ? >> > > Yes - it failed to install with pip and also looked like a dead project when > I followed the project home page URL. > -- > https://mail.python.org/mailman/listinfo/python-list > Also check out th

Re: A high-level cross-platform API for terminal/console access

> > Did you try https://pypi.python.org/pypi/UniCurses ? > Yes - it failed to install with pip and also looked like a dead project when I followed the project home page URL. -- https://mail.python.org/mailman/listinfo/python-list

Re: A high-level cross-platform API for terminal/console access

In a message of Wed, 21 Oct 2015 11:30:25 -0700, Peter Brittain writes: >I have recently been working on a terminal/console animation package >(https://github.com/peterbrittain/asciimatics). Beyond the high-level >animation methods/objects it provides, it also needed to be cross-pla

A high-level cross-platform API for terminal/console access

I have recently been working on a terminal/console animation package (https://github.com/peterbrittain/asciimatics). Beyond the high-level animation methods/objects it provides, it also needed to be cross-platform and and simple to install with pip (including any dependencies). This cross

Re: Shutting down a cross-platform multithreaded app

On Sat, Sep 19, 2015 at 8:48 PM, James Harris wrote: > "Chris Angelico" wrote in message > news:mailman.13.1442657702.21674.python-l...@python.org... >> >> On Sat, Sep 19, 2015 at 7:49 PM, James Harris >> wrote: >>> >>> "Chris Angelico" wrote in message >>> news:mailman.8.1442612439.21674.pytho

Re: Shutting down a cross-platform multithreaded app

"Chris Angelico" wrote in message news:mailman.13.1442657702.21674.python-l...@python.org... On Sat, Sep 19, 2015 at 7:49 PM, James Harris wrote: "Chris Angelico" wrote in message news:mailman.8.1442612439.21674.python-l...@python.org... ... If you're using select() to monitor the sockets

Re: Shutting down a cross-platform multithreaded app

n a test Windows machine AF_UNIX is not present. The >>> only >>> cross-platform option, therefore, seems to be to use each subthread's >>> select()s to monitor two AF_INET sockets: the one to the client and a >>> control one from the master thread. I would seem

Re: Shutting down a cross-platform multithreaded app

"Laura Creighton" wrote in message news:mailman.5.1442609448.21674.python-l...@python.org... In a message of Fri, 18 Sep 2015 20:09:19 +0100, "James Harris" writes: Set the daemon flag on the worker threads, so when the main thread exits, the workers also exit. Interesting idea, and I did n

Re: Shutting down a cross-platform multithreaded app

"Chris Angelico" wrote in message news:mailman.8.1442612439.21674.python-l...@python.org... On Sat, Sep 19, 2015 at 3:17 AM, James Harris wrote: Needless to say, on a test Windows machine AF_UNIX is not present. The only cross-platform option, therefore, seems to be to use each s

Re: Shutting down a cross-platform multithreaded app

"James Harris" writes: ... > Needless to say, on a test Windows machine AF_UNIX is not present. The > only cross-platform option, therefore, seems to be to use each > subthread's select()s to monitor two AF_INET sockets: the one to the > client and a control one from

Re: Shutting down a cross-platform multithreaded app

On Sat, Sep 19, 2015 at 7:48 AM, Random832 wrote: > On Fri, Sep 18, 2015, at 17:40, Chris Angelico wrote: >> Bear in mind, though, that Windows has no protection against other >> processes shutting you down. > > Neither does Unix. Any process that can send you a signal can send you > SIGKILL. Inc

Re: Shutting down a cross-platform multithreaded app

On Fri, Sep 18, 2015, at 17:40, Chris Angelico wrote: > Bear in mind, though, that Windows has no protection against other > processes shutting you down. Neither does Unix. Any process that can send you a signal can send you SIGKILL. Of course, what Windows lacks is a generalized way for other pr

Re: Shutting down a cross-platform multithreaded app

On Sat, Sep 19, 2015 at 3:17 AM, James Harris wrote: > Needless to say, on a test Windows machine AF_UNIX is not present. The only > cross-platform option, therefore, seems to be to use each subthread's > select()s to monitor two AF_INET sockets: the one to the client and a > con

Re: Shutting down a cross-platform multithreaded app

In a message of Fri, 18 Sep 2015 20:09:19 +0100, "James Harris" writes: >> Set the daemon flag on the worker threads, so when the main thread >> exits, the workers also exit. > >Interesting idea, and I did not know that a *thread* could be a daemon. >Unfortunately, I think what you suggest would k

Re: Shutting down a cross-platform multithreaded app

"James Harris" : > I have a multithreaded app that I want to be able to shut down easily > such as by hitting control-c or sending it a signal. The problem with threads is you cannot cause them to exit from the outside. You can do that to asyncio coroutines, however. Maybe you should consider por

Re: Shutting down a cross-platform multithreaded app

"Paul Rubin" wrote in message news:87zj0jd1ta@jester.gateway.sonic.net... "James Harris" writes: I have a multithreaded app that I want to be able to shut down easily such as by hitting control-c or sending it a signal. Set the daemon flag on the worker threads, so when the main thre

Re: Shutting down a cross-platform multithreaded app

"James Harris" writes: > I have a multithreaded app that I want to be able to shut down easily > such as by hitting control-c or sending it a signal. Set the daemon flag on the worker threads, so when the main thread exits, the workers also exit. -- https://mail.python.org/mailman/listinfo/pyt

Shutting down a cross-platform multithreaded app

ocket the thread is using to communicate with the client. The other would be a control connection from the master thread. Now to make this cross platform According to the opening paragraph in the following link Windows select() won't work on arbitrary file descriptors but on

Re: Easiest Way to Do Cross-Platform DB Access (Oracle)

"Gary Furash" wrote in message news:135759bf-0823-480c-9631-106d6cf1a...@googlegroups.com... I need to be able to access Oracle from both Windows and *nix, however, it seems kind of tortuous getting everything working each time on each server. With Java I can just drop (usually the same) JDBC

Easiest Way to Do Cross-Platform DB Access (Oracle)

I need to be able to access Oracle from both Windows and *nix, however, it seems kind of tortuous getting everything working each time on each server. With Java I can just drop (usually the same) JDBC library files in a location and everything works. I'm sure there's some easier way of doing thi

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? > > Conte

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

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

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 various tools like pip using subp

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

Cross Platform

Hi all, I have a doubt regarding the python cross platform. If we write Class in windows ,whether we can without any modifications in Linux, if so then how about the GUI programming and Libraries. Please provide needful information. Thanks, Chandru CAUTION - Disclaimer

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 Ke

Re: Cross-Platform Python3 Equivalent to notify-send

uot;notify-send" command. Is there a cross-platform Python3 equivalent? [snip answer "no"] 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 implemente

Re: Cross-Platform Python3 Equivalent to notify-send

rly trivial that there's no NEED for a library function! Never hurts to throw the question out there... ChrisA I wanted to make a module (boash) that would be useful, but clearly it is not. Here, is a feature that is useful that no one has. This may be the module I decide to make. So, there is no

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&q

Re: Cross-Platform Python3 Equivalent to notify-send

ou anyway. Despite the best efforts of a pretty talented core dev team, Python is not yet capable of magic :) If you browse the python-dev archives, you'll see how much of a nightmare cross-platform compatibility can be (eg the recent discussion on cloexec and passing file descriptors to subpro

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

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 > -- > ht

Cross-Platform Python3 Equivalent to notify-send

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/python-list

Cross-Platform Python3 Equivalent to notify-send

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/python-list

Re: How do I get the OS System Font Directory(Cross-Platform) in python?

On Fri, 12 Jul 2013 23:38:18 -0700, Metallicow wrote: > On Saturday, July 13, 2013 12:36:45 AM UTC-5, Tim Roberts wrote: >> Really? Because Windows is the ONLY one of the major operating systems >> >> that actually has a dedicated system fonts directory. Linux doesn't >> even >> >> have a dedi

Re: How do I get the OS System Font Directory(Cross-Platform) in python?

On Saturday, July 13, 2013 12:36:45 AM UTC-5, Tim Roberts wrote: > Really? Because Windows is the ONLY one of the major operating systems > > that actually has a dedicated system fonts directory. Linux doesn't even > > have a dedicated windowing system. So... Is it expected to install duplicat

  1   2   3   4   5   >