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
28 matches
Mail list logo