On 4 Aug 2014 03:18, "Phil Thompson" wrote:
>
> On 03/08/2014 4:58 pm, Guido van Rossum wrote:
>>
>> But *are* we going to support Android officially? What's the point? Do
you
>> have a plan for getting Python apps to first-class status in the App
Store
>> (um, Google Play)?
>
>
> I do...
>
> http
On Sun, Aug 3, 2014 at 10:16 AM, Phil Thompson
wrote:
> On 03/08/2014 4:58 pm, Guido van Rossum wrote:
>
>> But *are* we going to support Android officially? What's the point? Do you
>> have a plan for getting Python apps to first-class status in the App Store
>> (um, Google Play)?
>>
>
> I do...
On 03/08/2014 4:58 pm, Guido van Rossum wrote:
But *are* we going to support Android officially? What's the point? Do
you
have a plan for getting Python apps to first-class status in the App
Store
(um, Google Play)?
I do...
http://pyqt.sourceforge.net/Docs/pyqtdeploy/introduction.html
Phil
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Guido van Rossum wrote:
> But *are* we going to support Android officially? What's the point?
> Do you have a plan for getting Python apps to first-class status in
> the App Store (um, Google Play)?
>
> Regardless, I recommend that you add a new met
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Akira Li wrote:
> FYI, /bin/sh is not POSIX, see
> http://bugs.python.org/issue16353#msg224514
Ah right, my apologies. Android doesn't seem to have getconf(1) either,
but sh /is/ on $PATH. Anyway, even if it weren't, os.defpath could be
tweaked on
But *are* we going to support Android officially? What's the point? Do you
have a plan for getting Python apps to first-class status in the App Store
(um, Google Play)?
Regardless, I recommend that you add a new method to the platform module
(careful people can test for the presence of the new met
Shiz writes:
> The most obvious change would be to subprocess.Popen(). The reason a
> generic approach there won't work is also the reason I expect more
> changes might be needed: the Android file system doesn't abide by any
> POSIX file system standards. Its shell isn't located at /bin/sh, but a
Guido van Rossum writes:
> Well, it really does look like checking for the presence of those ANDROID_*
> environment variables it the best way to recognize the Android platform.
> Anyone can do that without waiting for a ruling on whether Android is Linux
> or not (which would be necessary becaus
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Guido van Rossum wrote:
> Well, it really does look like checking for the presence of those
> ANDROID_* environment variables it the best way to recognize the
> Android platform. Anyone can do that without waiting for a ruling on
> whether Android i
Well, it really does look like checking for the presence of those ANDROID_*
environment variables it the best way to recognize the Android platform.
Anyone can do that without waiting for a ruling on whether Android is Linux
or not (which would be necessary because the docs for sys.platform are
qui
Shiz wrote:
I'm not sure a check to see if e.g.
/system exists is really enough to conclude Python is running on Android
on its own.
Since MacOSX has /System and typically a case-insensitive
file system, it certainly wouldn't. :-)
--
Greg
___
Python-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Guido van Rossum wrote:
> Can you give a few examples of where you'd need to differentiate
> Android from other Linux platforms in otherwise portable code, and
> where testing for the presence or absence of the specific function
> that you'd like to
On Sat, Aug 2, 2014 at 12:14 PM, Shiz wrote:
> Guido van Rossum wrote:
> > sys.platform is for a broad indication of the OS kernel. It can be
> > used to distinguish Windows, Mac and Linux (and BSD, Solaris etc.).
> > Since Android is Linux it should have the same sys.platform as other
> > Linux
Right.
On Saturday, August 2, 2014, Phil Thompson
wrote:
> On 02/08/2014 7:36 pm, Guido van Rossum wrote:
>
>> On Sat, Aug 2, 2014 at 12:53 AM, Phil Thompson <
>> p...@riverbankcomputing.com>
>> wrote:
>>
>> To me the issue is whether, for a particular value of sys.platform, the
>>> programmer
On 02/08/2014 7:36 pm, Guido van Rossum wrote:
On Sat, Aug 2, 2014 at 12:53 AM, Phil Thompson
wrote:
To me the issue is whether, for a particular value of sys.platform,
the
programmer can expect a particular Python stdlib API. If so then
Android
needs a different value for sys.platform.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Guido van Rossum wrote:
> sys.platform is for a broad indication of the OS kernel. It can be
> used to distinguish Windows, Mac and Linux (and BSD, Solaris etc.).
> Since Android is Linux it should have the same sys.platform as other
> Linux systems
On Sat, Aug 2, 2014 at 12:53 AM, Phil Thompson
wrote:
> To me the issue is whether, for a particular value of sys.platform, the
> programmer can expect a particular Python stdlib API. If so then Android
> needs a different value for sys.platform.
>
sys.platform is for a broad indication of the O
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Akira Li wrote:
> Python uses os.name, sys.platform, and various functions from
> `platform` module to provide version info:
>
> - coarse: os.name is 'posix', 'nt', 'ce', 'java' [1]. It is defined
> by availability of some builtin modules ('posix',
On 02/08/2014 4:34 am, Guido van Rossum wrote:
Or SL4A? (https://github.com/damonkohler/sl4a)
On Fri, Aug 1, 2014 at 8:06 PM, Steven D'Aprano
wrote:
On Sat, Aug 02, 2014 at 05:53:45AM +0400, Akira Li wrote:
> Python uses os.name, sys.platform, and various functions from `platform`
> modul
Or SL4A? (https://github.com/damonkohler/sl4a)
On Fri, Aug 1, 2014 at 8:06 PM, Steven D'Aprano wrote:
> On Sat, Aug 02, 2014 at 05:53:45AM +0400, Akira Li wrote:
>
> > Python uses os.name, sys.platform, and various functions from `platform`
> > module to provide version info:
> [...]
> > If And
On Sat, Aug 02, 2014 at 05:53:45AM +0400, Akira Li wrote:
> Python uses os.name, sys.platform, and various functions from `platform`
> module to provide version info:
[...]
> If Android is posixy enough (would `posix` module work on Android?)
> then os.name could be left 'posix'.
Does anyone know
Shiz writes:
> Hi folks,
>
> I’m working on porting CPython to the Android platform, and while
> making decent progress, I’m currently stuck at a higher-level issue
> than adding #ifdefs for __ANDROID__ to C extension modules.
>
> The idea is, not only CPython extension modules have some assumpti
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Charles-François Natali wrote:
> Well, Android is so popular that supporting it would definitely be
> interesting. There are a couple questions however (I'm not familiar
> at all with Android, I don't have a smartphone ;-): - Do you have an
> idea of
2014-08-01 13:23 GMT+01:00 Shiz :
>
>> Is your P.S. suggestive that you would not be willing to support your port
>> for use by others? Of course, until it is somewhat complete, it is hard to
>> know how complete and compatible it can be.
>
> Oh, no, nothing like that. It's just that I'm not sur
On 01 Aug 2014, at 03:54, Glenn Linderman wrote:
> I've no idea what you mean by "userland" in your suggestions above or below,
> but doesn't the Android environment qualify as a (multi-versioned) platform
> independently of its host OS? Seems I've read about an Android
> reimplementation for
> On 1 August 2014 02:54, Glenn Linderman wrote:
>
> Alternatively, if having sys.platform be "linux" makes portability
> easier because code that does a platform check generally gets the
> right answer if Android reports as "linux", then why not make
> sys.linux_distribution report "android"?
>
On 1 August 2014 02:54, Glenn Linderman wrote:
> I've no idea what you mean by "userland" in your suggestions above or below,
> but doesn't the Android environment qualify as a (multi-versioned) platform
> independently of its host OS? Seems I've read about an Android
> reimplementation for Window
On 7/31/2014 5:59 PM, Shiz wrote:
Hi folks,
I’m working on porting CPython to the Android platform, and while making decent
progress, I’m currently stuck at a higher-level issue than adding #ifdefs for
__ANDROID__ to C extension modules.
The idea is, not only CPython extension modules have so
Hi folks,
I’m working on porting CPython to the Android platform, and while making decent
progress, I’m currently stuck at a higher-level issue than adding #ifdefs for
__ANDROID__ to C extension modules.
The idea is, not only CPython extension modules have some assumptions that
don’t seem to f
29 matches
Mail list logo
