Re: [Python-Dev] Exposing the Android platform existence to Python modules
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`
> 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 what kivy does when running under Android?
I don't think either do anything.
As the OP said, porting Python to Android is mainly about dealing with a
C stdlib that is limited in places. Therefore there might be the odd
missing function or attribute in the Python stdlib - just the same as
can happen with other platforms.
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.
On the other hand if the programmer should not expect to make such an
assumption, and should instead allow for the absence of certain
functions (but which ones?), then the existing value of 'linux' should
be fine.
Another option I don't think I've seen suggested, given the recommended
way of testing for Linux is to use sys.platform.startswith('linux'), is
to use a value of 'linux-android'.
Phil
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sum(...) limitation
On Fri, Aug 01, 2014 at 10:57:38PM -0700, Allen Li wrote: > On Fri, Aug 01, 2014 at 02:51:54PM -0700, Guido van Rossum wrote: > > No. We just can't put all possible use cases in the docstring. :-) > > > > > > On Fri, Aug 1, 2014 at 2:48 PM, Andrea Griffini wrote: > > > > help(sum) tells clearly that it should be used to sum numbers and not > > strings, and with strings actually fails. > > > > However sum([[1,2,3],[4],[],[5,6]], []) concatenates the lists. > > > > Is this to be considered a bug? > > Can you explain the rationale behind this design decision? It seems > terribly inconsistent. Why are only strings explicitly restricted from > being sum()ed? sum() should either ban everything except numbers or > accept everything that implements addition (duck typing). Repeated list and str concatenation both have quadratic O(N**2) performance, but people frequently build up strings with + and rarely do the same for lists. String concatenation with + is an attractive nuisance for many people, including some who actually know better but nevertheless do it. Also, for reasons I don't understand, many people dislike or cannot remember to use ''.join. Whatever the reason, repeated string concatenation is common whereas repeated list concatenation is much, much rarer (and repeated tuple concatenation even rarer), so sum(strings) is likely to be a land mine buried in your code while sum(lists) is not. Hence the decision that beginners in particular need to be protected from the mistake of using sum(strings) but bothering to check for sum(lists) is a waste of time. Personally, I wish that sum would raise a warning rather than an exception. As for prohibiting anything except numbers with sum(), that in my opinion would be a bad idea. sum(vectors), sum(numeric_arrays), sum(angles) etc. should all be allowed. The general sum() built-in should accept any type that allows + (unless explicitly black-listed), while specialist numeric-only sums could go into modules (like math.fsum). -- Steven ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sum(...) limitation
On 02.08.2014 08:35, Terry Reedy wrote: > On 8/2/2014 1:57 AM, Allen Li wrote: >> On Fri, Aug 01, 2014 at 02:51:54PM -0700, Guido van Rossum wrote: >>> No. We just can't put all possible use cases in the docstring. :-) >>> >>> >>> On Fri, Aug 1, 2014 at 2:48 PM, Andrea Griffini wrote: >>> >>> help(sum) tells clearly that it should be used to sum numbers >>> and not >>> strings, and with strings actually fails. >>> >>> However sum([[1,2,3],[4],[],[5,6]], []) concatenates the lists. >>> >>> Is this to be considered a bug? >> >> Can you explain the rationale behind this design decision? It seems >> terribly inconsistent. Why are only strings explicitly restricted from >> being sum()ed? sum() should either ban everything except numbers or >> accept everything that implements addition (duck typing). > > O(n**2) behavior, ''.join(strings) alternative. > > hm could this be a pure python case that would profit from temporary elision [0]? lists could declare the tp_can_elide slot and call list.extend on the temporary during its tp_add slot instead of creating a new temporary. extend/realloc can avoid the copy if there is free memory available after the block. [0] https://mail.python.org/pipermail/python-dev/2014-June/134826.html ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sum(...) limitation
Julian Taylor schrieb am 02.08.2014 um 12:11: > On 02.08.2014 08:35, Terry Reedy wrote: >> On 8/2/2014 1:57 AM, Allen Li wrote: >>> On Fri, Aug 01, 2014 at 02:51:54PM -0700, Guido van Rossum wrote: No. We just can't put all possible use cases in the docstring. :-) On Fri, Aug 1, 2014 at 2:48 PM, Andrea Griffini wrote: help(sum) tells clearly that it should be used to sum numbers and not strings, and with strings actually fails. However sum([[1,2,3],[4],[],[5,6]], []) concatenates the lists. Is this to be considered a bug? >>> >>> Can you explain the rationale behind this design decision? It seems >>> terribly inconsistent. Why are only strings explicitly restricted from >>> being sum()ed? sum() should either ban everything except numbers or >>> accept everything that implements addition (duck typing). >> >> O(n**2) behavior, ''.join(strings) alternative. > > lists could declare the tp_can_elide slot and call list.extend on the > temporary during its tp_add slot instead of creating a new temporary. > extend/realloc can avoid the copy if there is free memory available > after the block. Yes, i.e. only sometimes. Better not rely on it in your code. Stefan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sum(...) limitation
On Sat, Aug 2, 2014 at 3:39 AM, Steven D'Aprano wrote: > String concatenation with + is an attractive > nuisance for many people, including some who actually know better but > nevertheless do it. Also, for reasons I don't understand, many people > dislike or cannot remember to use ''.join. > Since sum() already treats strings as a special case, why can't it simply call (an equivalent of) ''.join itself instead of telling the user to do it? It does not matter why "many people dislike or cannot remember to use ''.join" - if this is a fact - it should be considered by language implementors. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sum(...) limitation
Alexander Belopolsky schrieb am 02.08.2014 um 16:52: > On Sat, Aug 2, 2014 at 3:39 AM, Steven D'Aprano wrote: > >> String concatenation with + is an attractive >> nuisance for many people, including some who actually know better but >> nevertheless do it. Also, for reasons I don't understand, many people >> dislike or cannot remember to use ''.join. > > Since sum() already treats strings as a special case, why can't it simply > call (an equivalent of) ''.join itself instead of telling the user to do > it? It does not matter why "many people dislike or cannot remember to use > ''.join" - if this is a fact - it should be considered by language > implementors. I don't think sum(strings) is beautiful enough to merit special cased support. Special cased rejection sounds like a much better way to ask people "think again - what's a sum of strings anyway?". Stefan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sum(...) limitation
On Sat, Aug 02, 2014 at 10:52:07AM -0400, Alexander Belopolsky wrote: > On Sat, Aug 2, 2014 at 3:39 AM, Steven D'Aprano wrote: > > > String concatenation with + is an attractive > > nuisance for many people, including some who actually know better but > > nevertheless do it. Also, for reasons I don't understand, many people > > dislike or cannot remember to use ''.join. > > > > Since sum() already treats strings as a special case, why can't it simply > call (an equivalent of) ''.join itself instead of telling the user to do > it? It does not matter why "many people dislike or cannot remember to use > ''.join" - if this is a fact - it should be considered by language > implementors. It could, of course, but there is virtue in keeping sum simple, rather than special-casing who knows how many different types. If sum() tries to handle strings, should it do the same for lists? bytearrays? array.array? tuple? Where do we stop? Ultimately it comes down to personal taste. Some people are going to wish sum() tried harder to do the clever thing with more types, some people are going to wish it was simpler and didn't try to be clever at all. Another argument against excessive cleverness is that it ties sum() to one particular idiom or implementation. Today, the idiomatic and efficient way to concatenate a lot of strings is with ''.join, but tomorrow there might be a new str.concat() method. Who knows? sum() shouldn't have to care about these details, since they are secondary to sum()'s purpose, which is to add numbers. Anything else is a bonus (or perhaps a nuisance). So, I would argue that when faced with something that is not a number, there are two reasonable approaches for sum() to take: - refuse to handle the type at all; or - fall back on simple-minded repeated addition. By the way, I think this whole argument would have been easily side-stepped if + was only used for addition, and & used for concatenation. Then there would be no question about what sum() should do for lists and tuples and strings: raise TypeError. -- Steven ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exposing the Android platform existence to Python modules
-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', 'nt' in particular)
> at import time.
>
> - finer: sys.platform may start with freebsd, linux, win, cygwin,
> darwin (`uname -s`). It is defined at python build time.
>
> - detailed: `platform` module. It provides as much info as possible
> e.g., platform.uname(), platform.platform(). It may use runtime
> commands to get it.
>
> If Android is posixy enough (would `posix` module work on Android?)
> then os.name could be left 'posix'.
>
> You could set sys.platform to 'android' (like sys.platform may be
> 'cygwin' on Windows) if Android is not like *any other* Linux
> distribution (from the point of view of writing a working Python code
> on it) i.e., if Android is further from other Linux distribution
> than freebsd, linux, darwin from each other then it might deserve
> sys.platform slot.
>
> If sys.platform is left 'linux' (like sys.platform is 'darwin' on
> iOS) then platform module could be used to detect Android e.g.,
> platform.linux_distribution() though (it might be removed in Python
> 3.6) it is unpredictable [2] unless you fix it on your python
> distribution, e.g., here's an output on my machine:
>
import platform platform.linux_distribution()
> ('Ubuntu', '14.04', 'trusty')
>
> For example:
>
> is_android = (platform.linux_distribution()[0] == 'Android')
>
> You could also define platform.android_version() that can provide
> Android specific version details as much as you need:
>
> is_android = bool(platform.android_version().release)
>
> You could provide an alias android_ver (like existing java_ver,
> libc_ver, mac_ver, win32_ver).
>
> See also, "When to use os.name, sys.platform, or platform.system?"
> [3]
>
> Unrelated, TIL [4]:
>
> Android is a Linux distribution according to the Linux Foundation
>
> [1] https://docs.python.org/3.4/library/os.html#os.name [2]
> http://bugs.python.org/issue1322 [3]
> http://stackoverflow.com/questions/4553129/when-to-use-os-name-sys-platform-or-platform-system
>
>
[4] http://en.wikipedia.org/wiki/Android_(operating_system)
>
>
> btw, does it help adding os.get_shell_executable() [5] function, to
> avoid hacking subprocess module, so that os.confstr('CS_PATH') or
> os.defpath on Android could be defined to include /system/bin
> instead?
>
> [5] http://bugs.python.org/issue16353
Thanks for the detailed information!
I would consider Android at least POSIX-y enough for os.name to be
considered 'posix'. It doesn't implement a few POSIX-mandated things
like POSIX semaphores, but aside from that I would largely consider it
'compatible enough'.
I guess what is left is deciding whether to add a platform slot for
Android, or to stuff the detection in platform.linux_distribution(). I
feel like it would be a bit hacky for standard modules to rely on a
platform.linux_distribution() return value though, it seems mostly
useful for display purposes.
Phil Thompson's idea of setting sys.platform to 'linux-android' also
occurred to me. Under the premise that we can get users to use
sys.platform.startswith('linux'), this seems like the best solution in
my eyes: it both allows for existing code to continue the assumption
that they are running on a Linux platform, which I believe to be correct
in a lot of places, and Python modules to use a solid value to check if
they need to behave differently when running on Android.
On a sidenote, Kivy and SL4A/Py4A do not address this, no. From what
I've seen from their patches they are mostly there to get Python
compiling and running in the first place, not necessarily about fixing
every compatibility issue. :)
As for the os.get_shell_executable(), that seems like a good solution
for the issue that occurs in the subprocess module indeed. I'd
personally prefer it to manual checking within the module.
Kind regards,
Shiz
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQQcBAEBCgAGBQJT3NLBAAoJEICfd9ZVuxW+SnIf/jZmnxyMTcFE5IyrmOC5v53M
AklKWhVK/XeK5gYAiglV7+JwIpkEHyiiIyik5QKr/ssQ/D6EjZTmb7guxoX9QZml
pWHukSmEpHTJVUDtSQ9OqgRADisZKV/8Yu1pLRIqe5zDcyZLZZg7Fg01rvqpBHvp
qhVzp2jdLCrcdlVZFKk3Hk04DgbJD9SUYg7ITCqj4qr5wwphCwCYfbGGlzeUXXyG
/zMWB6rI86DaOcy+b8DOK4Q6xdScnwIdFaV8A3lVEBi8b8DIl5ffGe8t6WtnUBOE
XGXh2wLZvnqYr31rGc0nRP16osm1usipq6jLQ4rNebzMCW/1JbybYbcOjPcOBSJw
TyAjJw5KOac8hK0hapguqWKSDIYTZqnrYPy7dn8r2oXGtXGR24W/kZdELHlQi2cg
HgfWf7YkA4wuMEjJQOa+ulMj34LhfmYQrj19Gy+5Pp6FA+w3r9fcKrELxXcZGZix
66WReYJOvqx78fWXdBaij7650LdOmQblrDZD4mgxiEhoiD9gDDEOib9CosyANDTf
gjKatd/GOhXpJWETU6o/b1l2Yt/+cQWQbuJsvUd1jOiTn67Sf0w6Og0ZlPyV7Fgb
hLp4vYWQ0rWg/UBV9H0HzPsVJz6o4wCR1+8Jj6hdgp2EFHQ0EFVCESxqiPrsFFHz
CT1Ud+ZVs+2Mt7Q47Hb46RiFmzcNl6U0HZ94OczI/NpSVc/HGeY4EzyEtS
Re: [Python-Dev] sum(...) limitation
On 2014-08-02 16:27, Steven D'Aprano wrote: On Sat, Aug 02, 2014 at 10:52:07AM -0400, Alexander Belopolsky wrote: On Sat, Aug 2, 2014 at 3:39 AM, Steven D'Aprano wrote: > String concatenation with + is an attractive > nuisance for many people, including some who actually know better but > nevertheless do it. Also, for reasons I don't understand, many people > dislike or cannot remember to use ''.join. > Since sum() already treats strings as a special case, why can't it simply call (an equivalent of) ''.join itself instead of telling the user to do it? It does not matter why "many people dislike or cannot remember to use ''.join" - if this is a fact - it should be considered by language implementors. It could, of course, but there is virtue in keeping sum simple, rather than special-casing who knows how many different types. If sum() tries to handle strings, should it do the same for lists? bytearrays? array.array? tuple? Where do we stop? We could leave any special-casing to the classes themselves: def sum(iterable, start=0): sum_func = getattr(type(start), '__sum__') if sum_func is None: result = start for item in iterable: result = result + item else: result = sum_func(start, iterable) return result Ultimately it comes down to personal taste. Some people are going to wish sum() tried harder to do the clever thing with more types, some people are going to wish it was simpler and didn't try to be clever at all. Another argument against excessive cleverness is that it ties sum() to one particular idiom or implementation. Today, the idiomatic and efficient way to concatenate a lot of strings is with ''.join, but tomorrow there might be a new str.concat() method. Who knows? sum() shouldn't have to care about these details, since they are secondary to sum()'s purpose, which is to add numbers. Anything else is a bonus (or perhaps a nuisance). So, I would argue that when faced with something that is not a number, there are two reasonable approaches for sum() to take: - refuse to handle the type at all; or - fall back on simple-minded repeated addition. By the way, I think this whole argument would have been easily side-stepped if + was only used for addition, and & used for concatenation. Then there would be no question about what sum() should do for lists and tuples and strings: raise TypeError. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sum(...) limitation
On Sat, Aug 2, 2014 at 11:06 AM, Stefan Behnel wrote: > I don't think sum(strings) is beautiful enough sum(strings) is more beautiful than ''.join(strings) in my view, but unfortunately it does not work even for lists because the initial value defaults to 0. sum(strings, '') and ''.join(strings) are equally ugly and non-obvious because they require an empty string. Empty containers are an advanced concept and it is unfortunate that a simple job of concatenating a list of (non-empty!) strings exposes the user to it. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exposing the Android platform existence to Python modules
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 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
('linux2'). If you want to know whether a specific syscall is there, check
for the presence of the method in the os module.
The platform module is suitable for additional vendor-specific info about
the platform, and I'd hope that there's something there that indicates
Android. Again, what values does the platform module return on SL4A or
Kivy, which have already ported Python to Android? In particular, I'd
expect platform.linux_distribution() to return a clue that it's Android.
There should also be clues in /etc/lsb-release (assuming Android supports
it :-).
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exposing the Android platform existence to Python modules
-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 ('linux2'). If you want to know whether a specific
> syscall is there, check for the presence of the method in the os
> module.
>
> The platform module is suitable for additional vendor-specific info
> about the platform, and I'd hope that there's something there that
> indicates Android. Again, what values does the platform module return
> on SL4A or Kivy, which have already ported Python to Android? In
> particular, I'd expect platform.linux_distribution() to return a
> clue that it's Android. There should also be clues in
> /etc/lsb-release (assuming Android supports it :-).
>
> -- --Guido van Rossum (python.org/~guido )
To the best of my knowledge, Kivy and Py4A/SL4A don't modify that code
at all, so it just returns 'linux2'. In addition, they don't modify
platform.py either, so platform.linux_distribution() returns empty values.
My patchset[1] currently contains patches that both set sys.platform to
'linux-android' and modifies platform.linux_distribution() to parse and
return a proper value for Android systems:
>>> import sys, platform sys.platform
'linux-android'
>>> platform.linux_distribution()
('Android', '4.4.2', 'Blur_Version.174.44.9.falcon_umts.EURetail.en.EU')
The sys.platform thing was mainly done out of curiosity on its
possibility after Phil bringing it up. My main issue with leaving
Android detection to checking platform.linux_distribution() is that it
feels like a bit of a wonky thing for core Python modules to rely on to
change behaviour where needed on Android (as well as introducing a
dependency cycle between subprocess and platform right now).
I'd also like to note that I wouldn't agree with following too many of
Kivy/Py4A/SL4A's design decisions on this, as they seem mostly absent.
- From what I've read, their patches mostly seem geared towards getting
Python to run on Android, not necessarily integrating it well or fixing
all inconsistencies. This also leads to things like subprocess.Popen()
indeed breaking with shell=True[2].
Kind regards,
Shiz
[1]: https://github.com/rave-engine/python3-android/tree/master/src
[2]:
http://grokbase.com/t/gg/python-for-android/1343rm7q1w/py4a-subprocess-popen-oserror-errno-8-exec-format-error
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQQcBAEBCgAGBQJT3TiVAAoJEICfd9ZVuxW+XvAf+waDYEyURnBa7kSanThoV28b
ilx6g4rMwXBZ+R3t4a0D7Q489uSQ63IJ8KWUI6AOE3v998pUOxg4LNdhBIbnr+WD
bT5WUk/elfhhdEEM7pAVIg/r76lIgysVwW0uibZw9bS32TayUjigtxI9nEWUAH8D
48maBBX9CCy5G0aysx4zLqGr49MeRM7stRuS3yf55RArRdoUUibUyHhA7q7ACWbH
LCiV9oECmgUCvc+uzj1dZSLJR4cYsldV9GUnvgE0mSbUGfp4QlqKa9V9WrziH26e
UQ/G3nM0XmZNbdHlKfwl12x6zLq+TLADyCZV8BZEcHF6+FqmvpNyMf6Hwg3DkojX
a7UmEPcbiHcnH0ncqNB6gVu92O+qMtfaWV0kfHGIwWriNPuGfJWWiwEP/Q4TICGm
Yfo+nJ780opdUobvU9NTUjSlQoUBYlQQmJgCrUsOZTBWxZeIdyn4LpspUM7PyVaY
vXMAq+D9fYyF6LjVSv+IBU9rZnwVIxS7XFnTKt4Q/YL2upM4q9KGe5WZH4EqPjaK
1kLX1QHWlDHkCY8BdjhGHdvQBm1YhpJCRcFJgCIMzWUnWiMl4vhHYF4mp/WseiiX
DHKSiHPNd51yhMXBplksPn9gOYfaHnIKJeBccegRsmKdTfiLiyksmWSeSBuFzb8w
lHCir/u8AuadinYYS5V9bb80T6LyJKVZ74qa7dOi9Y9h1Li7ytRC8ZfkLpqUTwS/
2KOpUxNLRkyLVqCvSaGM72LIvAX7t/H0f4U9rnGRAwYJaoSjfyL6eNK8DOGo+J0a
TmueQBSnrFVI85rvCdQtSiPFAj0/UhSat5XP/3AN0X8lcnxWJFnPkYCbFMhkR3pw
Wuhvjv5Xm0gB95zcjNoKlBoISl9R6ZCLnR6td3NYZGbWxyEK4zdA7X6wGRXDK6ZX
YC5jUm6kG+lJ6WzF9SSRCtJ9IvuhFdUPu+1LuWSBrWhRT5pGJIIYr83hTLb6t6V7
zv+pHMfqYGP3IkoXYsCq+STkKmyD4Jce9uwdzHn8IncMM8KNqpwJeMlC8Wz16EsS
/jFi6wftdpCVjiXDHPGxGyuxDW+bDhLfb4giOc9Gx9Wabi3IqGjqHfDfXC1MQY+K
M9T3izX7Zvbf2g2+oxh9qftX4rGMsNe1uuS9b8Ym8Eupwv4NyHUbZx2e1glHTDJ0
u5Vt/DZqWHZPaoNT100vqfWKXlZC+BeFY+MB0k5ozBlhhdMMkST3ZVw8tve2WJCO
fwb7hbhCJ3X7J9hBzq1giljgPJuWbUadYnVa8RulLDSlXQw/yh/8jkPShTc47row
oZfxalB/0qwC+I8kWxb2Ln5LbAxqNhkahALPLSVQ/Mx/+6/shoVNQJTGc1FXn20=
=nA+h
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sum(...) limitation
On Sat, Aug 02, 2014 at 05:39:12PM +1000, Steven D'Aprano wrote: > Repeated list and str concatenation both have quadratic O(N**2) > performance, but people frequently build up strings with + and rarely > do the same for lists. String concatenation with + is an attractive > nuisance for many people, including some who actually know better but > nevertheless do it. Also, for reasons I don't understand, many people > dislike or cannot remember to use ''.join. join() isn't preferable in cases where it damages readability while simultaneously providing zero or negative performance benefit, such as when concatenating a few short strings, e.g. while adding a prefix to a filename. Although it's true that join() is automatically the safer option, and especially when dealing with user supplied data, the net harm caused by teaching rote and ceremony seems far less desirable compared to fixing a trivial slowdown in a script, if that slowdown ever became apparent. Another (twisted) interpretation is that since the quadratic behaviour is a CPython implementation detail, and there are alternatives where __add__ is constant time, encouraging users to code against implementation details becomes undesirable. In our twisty world, __add__ becomes *preferable* since the resulting programs more closely resemble pseudo-code. $ cat t.py a = 'this ' b = 'is a string' c = 'as we can tell' def x(): return a + b + c def y(): return ''.join([a, b, c]) $ python -m timeit -s 'import t' 't.x()' 100 loops, best of 3: 0.477 usec per loop $ python -m timeit -s 'import t' 't.y()' 100 loops, best of 3: 0.695 usec per loop David ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exposing the Android platform existence to Python modules
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.
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
('linux2'). If you want to know whether a specific syscall is there,
check
for the presence of the method in the os module.
It's not just the os module - other modules contain code that would be
affected, but there are plenty of other parts of the Python stdlib that
aren't implemented on every platform. Using the approach you prefer then
all that's needed is to update the documentation to say that certain
things are not implemented on Android.
Phil
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exposing the Android platform existence to Python modules
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 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 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
>> ('linux2'). If you want to know whether a specific syscall is there, check
>> for the presence of the method in the os module.
>>
>
> It's not just the os module - other modules contain code that would be
> affected, but there are plenty of other parts of the Python stdlib that
> aren't implemented on every platform. Using the approach you prefer then
> all that's needed is to update the documentation to say that certain things
> are not implemented on Android.
>
> Phil
>
--
--Guido van Rossum (on iPad)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exposing the Android platform existence to Python modules
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 systems ('linux2'). If you want to know whether a specific
> > syscall is there, check for the presence of the method in the os
> > module.
> >
> > The platform module is suitable for additional vendor-specific info
> > about the platform, and I'd hope that there's something there that
> > indicates Android. Again, what values does the platform module return
> > on SL4A or Kivy, which have already ported Python to Android? In
> > particular, I'd expect platform.linux_distribution() to return a
> > clue that it's Android. There should also be clues in
> > /etc/lsb-release (assuming Android supports it :-).
> >
> > -- --Guido van Rossum (python.org/~guido )
>
> To the best of my knowledge, Kivy and Py4A/SL4A don't modify that code
> at all, so it just returns 'linux2'. In addition, they don't modify
> platform.py either, so platform.linux_distribution() returns empty values.
>
OK, so personally I'd leave sys.platform but improve on
platform.linux_distribution().
> My patchset[1] currently contains patches that both set sys.platform to
> 'linux-android' and modifies platform.linux_distribution() to parse and
> return a proper value for Android systems:
>
> >>> import sys, platform sys.platform
> 'linux-android'
> >>> platform.linux_distribution()
> ('Android', '4.4.2', 'Blur_Version.174.44.9.falcon_umts.EURetail.en.EU')
>
> The sys.platform thing was mainly done out of curiosity on its
> possibility after Phil bringing it up.
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
call isn't possible? I know I pretty much never test for the difference
between OSX and other UNIX variants (including Linux) -- the only platform
distinction that regularly comes up in my own code is Windows vs. the rest.
And even there, often the right thing to test for is something more
specific like os.sep.
> My main issue with leaving
> Android detection to checking platform.linux_distribution() is that it
> feels like a bit of a wonky thing for core Python modules to rely on to
> change behaviour where needed on Android (as well as introducing a
> dependency cycle between subprocess and platform right now).
>
What's the specific change in stdlib behavior that you're proposing for
Android?
> I'd also like to note that I wouldn't agree with following too many of
> Kivy/Py4A/SL4A's design decisions on this, as they seem mostly absent.
> - From what I've read, their patches mostly seem geared towards getting
> Python to run on Android, not necessarily integrating it well or fixing
> all inconsistencies. This also leads to things like subprocess.Popen()
> indeed breaking with shell=True[2].
>
I'm all for fixing subprocess.Popen(), though I'm not sure what the best
way is to determine this particular choice (why is it in the first place
that /bin/sh doesn't work?). However, since it's a stdlib module you could
easily rely on a private API to detect Android, so this doesn't really
force the sys.platform issue. (Or you could propose a fix that will work
for Kivi and SL4A as well, e.g. checking for some system file that is
documented as unique to Android.)
>
> Kind regards,
> Shiz
>
> [1]: https://github.com/rave-engine/python3-android/tree/master/src
> [2]:
>
> http://grokbase.com/t/gg/python-for-android/1343rm7q1w/py4a-subprocess-popen-oserror-errno-8-exec-format-error
>
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #22003: When initialized from a bytes object, io.BytesIO() now
Thanks for spotting, There is a new patch in http://bugs.python.org/issue22125 to fix the warnings. David ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exposing the Android platform existence to Python modules
-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 call isn't possible? I know I pretty much never > test for the difference between OSX and other UNIX variants > (including Linux) -- the only platform distinction that regularly > comes up in my own code is Windows vs. the rest. And even there, > often the right thing to test for is something more specific like > os.sep. > What's the specific change in stdlib behavior that you're proposing > for Android? 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 at /system/bin/sh. The only directories it provides that are POSIX-standard are /dev and /etc, to my knowledge. You could check to see if /system/bin/sh exists and use that first, but that would break the preferred shell on POSIX systems that happen to have /system for some reason or another. In short: the preferred shell on POSIX systems is /bin/sh, but on Android it's /system/bin/sh. Simple existence checking might break the preferred shell on either. For more specific stdlib examples I'd have to check the test suite again. I can see the point of a sys.platform change not necessarily being needed, but it would nice for user code too to have a sort-of trivial way to figure out if it's running on Android. While core CPython might in general care far less, for user applications it's a bigger deal since they have to draw GUIs and use system services in a way that *is* usually very different on Android. Again, platform.linux_distribution() seems more for display purposes than for applications to check their core logic against. In addition, apparently platform.linux_distribution() is getting deprecated in 3.5 and removed in 3.6[1]. I agree that above issue should in fact be solved by the earlier-linked to os.get_preferred_shell() approach, however. > However, since it's a stdlib module you could easily rely on a > private API to detect Android, so this doesn't really force the > sys.platform issue. (Or you could propose a fix that will work for > Kivi and SL4A as well, e.g. checking for some system file that is > documented as unique to Android.) After checking most of the entire Android file system, I'm not sure if such a file exists. Sure, a lot of the Android file system hierarchy isn't really used anywhere else, but 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. The thing that gets closest (which is the thing my platform.py patch checks for) is several Android-specific environment variables being defined (ANDROID_ROOT, ANDROID_DATA, ANDROID_PROPERTY_WORKSPACE...). Wouldn't it be better to put this in the standard Python library and expose it somehow, though? It *is* fragile code, it seems better if applications could 'just rely' on Python to figure it out, since it's not a trivial check. Kind regards, Shiz [1]: http://bugs.python.org/issue1322#msg207427 -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQQcBAEBCgAGBQJT3WrbAAoJEICfd9ZVuxW+CSEgAMgBE12MW1H+MjScIUI19cFi yCexTCEwu1rApjGYWSUw92Ihr9LnWn4aL7tEBqGXHN5pDctw0/FlGH9d0WhpMz/b DN0w5ukqx2YyY1EDK7hp1//6eU+tXTGQu890CWgboj5OQF8LXFyN6ReG0ynAKFC7 gSyYGunqCIInRdnz9IRXWgQ91F/d1D3hZq9ZNffZzacA+PIA1rPdgziUuLdThl14 P2/o98DzLRa3iTrTeW+x8f7nfbfNFmO8BLJsrce0o50BlD75YsUKVeTlwjU9IuIC gbw5Cxo8cfBN9Eg7iLkMgxkwiEVspuLVcVmoNVL4zsuavj41jlmyZFmPvRMO7OK+ NQMq5vGPub7q4lBtlk7a8gFqDJQad7fcEgsCFTIb0nvckkEi1EeLC9kyzmVEqi3C ngiXGVfjM0qpwLKvY+pr5adsoeJSK3dVzIfEXptsvHvOhav6oxG9nCdbe3uW2ROT hM444FSqngUabceRe395TXu2XhXcpDNcl8Ye1ADfMZdiWFYRp8/xtNVKoWZ7Ge6D Gcx3/QiUtXP7jvykE9GI7QGB6JKCFuBY/RloDS7miteCutl7k0GLcp3+tRmtoypi jL3lcCtUSNOMEX4Y5CqfhMcjEVccWvy98oM4Tz7qMdYv5OwASNDAzjRFh3SbRXI+ WRVqBf5aF13hy37RbkgoweXh1qn2vBO9sUUTJFp5ymlz8WisQFr+KRnt5bcjCKAe ycVThHQaLE/j1JOSgOmbD0Xi4hcvfFvlaNEmXTL1TiWRDC0crhM9fqObHHhWlFHv +b6AO39vVSfz1nTxTIByr6Z3GHlTFaU6iUx9oixHModEg2ej9iXb1Hq8atMHv/Z1 thP/sZ7mRRBhakQPoL9i8+5+AIEiFnw5GnW7w74N/cRalF5SB2RpzDAudv2UHMWQ jPpVrDbDv9BAUeZKF/hl1xCpbI3xR1zhpLP6d7kH7p9fDAcS07W2hYIkX1LCyTvx xn0XHQKEejaAZG1HwYE/0aP1Z39SJhODZx1rFjWtgE3q1akO9hfadpRiRVhozsUT r/cXoJN3sakPbctN7B4wMXtSTrVrwqdfPCuua6mG15uTGVbkPFze/vj4yc0b+sql LFed7BAYV0ZSeIDswrt+JyT+ZFBNZRV8zsPPZM2hNBkEqoMHshlI8QloMRbcqDnT GnrxeiWmJXE/DkpyTbEXUPyCm95ggm+TUfUJ/yb/GhdL1yU9xCjVcxuFmAo5s0WH k4tra8/vU21V8OzxPmK0eGH9Sl4fUg7JsmAC/Igez+utO7lJLXwfPnUSz+Ls30ao Xd28IYMsoQ1LCltmfN/fDl3uWJi2e/kZM9v/KTkj9AncvUsDLIOV80AP+remM9E= =Z0j+ -END PGP SIGNATURE- __
Re: [Python-Dev] Exposing the Android platform existence to Python modules
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-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exposing the Android platform existence to Python modules
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 quite clear about its value on Linux systems). Googling terms like "is Android Linux" suggests that there is considerable controversy about the issue, so I suggest you don't wait. :-) On Sat, Aug 2, 2014 at 3:49 PM, Shiz wrote: > -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 call isn't possible? I know I pretty much never > > test for the difference between OSX and other UNIX variants > > (including Linux) -- the only platform distinction that regularly > > comes up in my own code is Windows vs. the rest. And even there, > > often the right thing to test for is something more specific like > > os.sep. > > > What's the specific change in stdlib behavior that you're proposing > > for Android? > > 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 at > /system/bin/sh. The only directories it provides that are POSIX-standard > are /dev and /etc, to my knowledge. You could check to see if > /system/bin/sh exists and use that first, but that would break the > preferred shell on POSIX systems that happen to have /system for some > reason or another. In short: the preferred shell on POSIX systems is > /bin/sh, but on Android it's /system/bin/sh. Simple existence checking > might break the preferred shell on either. For more specific stdlib > examples I'd have to check the test suite again. > > I can see the point of a sys.platform change not necessarily being > needed, but it would nice for user code too to have a sort-of trivial > way to figure out if it's running on Android. While core CPython might > in general care far less, for user applications it's a bigger deal since > they have to draw GUIs and use system services in a way that *is* > usually very different on Android. Again, platform.linux_distribution() > seems more for display purposes than for applications to check their > core logic against. > In addition, apparently platform.linux_distribution() is getting > deprecated in 3.5 and removed in 3.6[1]. > > I agree that above issue should in fact be solved by the earlier-linked > to os.get_preferred_shell() approach, however. > > > However, since it's a stdlib module you could easily rely on a > > private API to detect Android, so this doesn't really force the > > sys.platform issue. (Or you could propose a fix that will work for > > Kivi and SL4A as well, e.g. checking for some system file that is > > documented as unique to Android.) > > After checking most of the entire Android file system, I'm not sure if > such a file exists. Sure, a lot of the Android file system hierarchy > isn't really used anywhere else, but 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. The thing that gets closest (which is the thing my > platform.py patch checks for) is several Android-specific environment > variables being defined (ANDROID_ROOT, ANDROID_DATA, > ANDROID_PROPERTY_WORKSPACE...). Wouldn't it be better to put this in the > standard Python library and expose it somehow, though? It *is* fragile > code, it seems better if applications could 'just rely' on Python to > figure it out, since it's not a trivial check. > > Kind regards, > Shiz > > [1]: http://bugs.python.org/issue1322#msg207427 > -BEGIN PGP SIGNATURE- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQQcBAEBCgAGBQJT3WrbAAoJEICfd9ZVuxW+CSEgAMgBE12MW1H+MjScIUI19cFi > yCexTCEwu1rApjGYWSUw92Ihr9LnWn4aL7tEBqGXHN5pDctw0/FlGH9d0WhpMz/b > DN0w5ukqx2YyY1EDK7hp1//6eU+tXTGQu890CWgboj5OQF8LXFyN6ReG0ynAKFC7 > gSyYGunqCIInRdnz9IRXWgQ91F/d1D3hZq9ZNffZzacA+PIA1rPdgziUuLdThl14 > P2/o98DzLRa3iTrTeW+x8f7nfbfNFmO8BLJsrce0o50BlD75YsUKVeTlwjU9IuIC > gbw5Cxo8cfBN9Eg7iLkMgxkwiEVspuLVcVmoNVL4zsuavj41jlmyZFmPvRMO7OK+ > NQMq5vGPub7q4lBtlk7a8gFqDJQad7fcEgsCFTIb0nvckkEi1EeLC9kyzmVEqi3C > ngiXGVfjM0qpwLKvY+pr5adsoeJSK3dVzIfEXptsvHvOhav6oxG9nCdbe3uW2ROT > hM444FSqngUabceRe395TXu2XhXcpDNcl8Ye1ADfMZdiWFYRp8/xtNVKoWZ7Ge6D > Gcx3/QiUtXP7jvykE9GI7QGB6JKCFuBY/RloDS7miteCutl7k0GLcp3+tRmtoypi > jL3lcCtUSNOMEX4Y5CqfhMcjEVccWvy98oM4Tz7qMdYv5OwASNDAzjRFh3SbRXI+ > WRVqBf5aF13hy37RbkgoweXh1qn2vBO9sUUTJFp5ymlz8WisQFr+KRnt5bcjCKAe > ycVThHQaLE/j1JOSgOmbD0Xi4hcvfFvlaNEmXTL1Ti
Re: [Python-Dev] Exposing the Android platform existence to Python modules
-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 is Linux or not (which would be necessary because the > docs for sys.platform are quite clear about its value on Linux > systems). Googling terms like "is Android Linux" suggests that there > is considerable controversy about the issue, so I suggest you don't > wait. :-) Right, which brings us back to the original point I was trying to make: any chance we could move logic like that into a sys.getandroidversion() or platform.android_version() so user code (and standard library code alike) doesn't have to perform those relatively nasty checks themselves? It seems like a fair thing to do if CPython would support Android as an official target. Kind regards, Shiz -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQQcBAEBCgAGBQJT3cYHAAoJEICfd9ZVuxW+hSogAKg8FUz/SuH6d0a4QvDctpMO pm58gBqVYvd1y/uIiLpQgpGb1dPrNziV1IYOBJaDcU1i/03JlgGdr3HOq29KvHdQ xgaQQbsyl63Tzhs4oA2iow7eoRO5rkZ338hxpWrUQqRek73AYXJt2r5w9dRklUh/ Z1R+80otVRAj69uJub8yAys08QqljKG80cnfQwUcFJVDWZRmr/z/WRGoC7QkRYVK EfIa7EVlm/3mArmueF6vxgF5qHevXIHvVSf18JJ918gxldKLJ4ht1v8L/4h4QBrC zfNqWyg8lXh6evMMH4lM755rycCTrtyzkoxmocLkUsEHrB65eOWWSBYdQgRMpuOH SZs+9K+P1jPwsJlcHl8j4sXoG6NtL6BBim70nlEnvdWQ6qHMivBNcyA1gEwI7Upn hG4t7AM4c3fdbkOg4V1F7EVrS9QqIxxWFIMAfYUGstZnfbBUDDGKIkE68ZbT+scq RTLbh78WsVA/YB/NLnxKvCTCuJb2uwg7R/VC1bMlsTUqTSfmckHl/XSRrgk+ggve A45sOKyoWzpfZEaAL9/e2TsPul5bRatVFX2JqEuzO42OTNZRr7GRxvRgF4tmnmG2 baSfrEhm3rcIFxT2IqLy+28g7ffGKcbbq7oo7LPvrh+zIupamygCnvMs6aSPE3zi Vi31EiFrZ8pn3YF+yfO7D9hjtqE41IIc86dKPUyKYfG+wO1oPXNwzBEZfoRSoJaY 9EKd1fqOm9iYHHzr+mkEko/bl+SxNFHHJ/y/uEU6ZIhBjbylDJ9AKCAm5q9gotuT 5i3PuyOOrTuYO0ei0su5Ya9UO5vD3+gUNKTHe9IdUL/e+5qYt5tjwtfPC9UTldSy xLv8Ca0uC7mOHLPi8ASghoO2tbjy69TNYmzljqIGUufBOKshFnNWA7DDmQdYrdTN t+EXsUAUmqm1RT29Zhrt1LCsoByyXh5jBapyIleU8TTrmotpX3dlI7rooZSegUiy 8lD05oIjX+JRbfXXsNg384e6Stc6UktrhIK00w3ILVP9IqnqAO+dao/uE+5lLvxU BcL9/PjmTY+1U8ZJCb9uZXNG8jWP2lsQEKaSFURkoUjTzfRpAoa6tVpCZOOvqZC2 F52ZSwmUBtP7vydRJ7BZjOeRxDzMD8qd0ED3fciDRbnVdXHIG+8MFL5MY1CDm9i7 r7bngcsqSUURq/Zj4BYnM8lOX1PXC9+U4gVNEkiwf+9CjfeIyMd4QpuMyXPxeiUa QDU8MX5VdA1oBvJ2nbXV8QwriIfODbyhD/00QhLHw5ifKjxB8ZZdF4jNT+Ay9jnR nEWuIpat3ch2Sg/ECtBvcA8hHYE9TfFZGdrdZVvib7fHsS+AUFXuhjAnkEyOVB4= =m+JD -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
