[Python-Dev] Re: PEP 647 (type guards) -- final call for comments
Here's another suggestion: PEP 593 introduced the `Annotated` type annotation. This could be used to annotate a TypeGuard like this: `def is_str_list(val: List[object]) -> Annotated[bool, TypeGuard(List[str])]` Note that I used ( ) instead of [ ] for the TypeGuard, as it is no longer a type. This should fulfill all four requirements, but is a lot more verbose and therefore also longer. It would also be extensible for other annotations. For the most extensible approach both `-> TypeGuard(...)` and `-> Annotated[bool, TypeGuard(...)]` could be allowed, which would open the path for future non-type-annotations, which could be used regardless of whether the code is type-annotated. -- Adrian On February 14, 2021 2:20:14 PM GMT+01:00, Steven D'Aprano wrote: >On Sat, Feb 13, 2021 at 07:48:10PM -, Eric Traut wrote: > >> I think it's a reasonable criticism that it's not obvious that a >> function annotated with a return type of `TypeGuard[x]` should return >> a bool. >[...] >> As Guido said, it's something that a developer can easily >> look up if they are confused about what it means. > >Yes, developers can use Bing and Google :-) > >But it's not the fact that people have to look it up. It's the fact that >they need to know that this return annotation is not what it seems, but >a special magic value that needs to be looked up. > >That's my objection: we're overloading the return annotation to be >something other than the return annotation, but only for this one >special value. (So far.) If you don't already know that it is special, >you won't know that you need to look it up to learn that its special. > > >> I'm open to alternative formulations that meet the following requirements: >> >> 1. It must be possible to express the type guard within the function >> signature. In other words, the implementation should not need to be >> present. This is important for compatibility with type stubs and to >> guarantee consistent behaviors between type checkers. > >When you say "implementation", do you mean the body of the function? > >Why is this a hard requirement? Stub files can contain function >bodies, usually `...` by convention, but alternatives are often useful, >such as docstrings, `raise NotImplementedError()` etc. > >https://mypy.readthedocs.io/en/stable/stubs.html > >I don't think that the need to support stub files implies that the type >guard must be in the function signature. Have I missed something? > > >> 2. It must be possible to annotate the input parameter types _and_ the >> resulting (narrowed) type. It's not sufficient to annotate just one or >> the other. > >Naturally :-) > >That's the whole point of a type guard, I agree that this is a truly >hard requirement. > > >> 3. It must be possible for a type checker to determine when narrowing >> can be applied and when it cannot. This implies the need for a bool >> response. > >Do you mean a bool return type? Sorry Eric, sometimes the terminology >you use is not familiar to me and I have to guess what you mean. > > >> 4. It should not require changes to the grammar because that would >> prevent this from being adopted in most code bases for many years. > >Fair enough. > > >> Mark, none of your suggestions meet these requirements. > >Mark's suggestion to use a variable annotation in the body meets >requirements 2, 3, and 4. As I state above, I don't think that >requirement 1 needs to be a genuinely hard requirement: stub files can >include function bodies. > >To be technically precise, stub functions **must** include function >bodies. It's just that by convention we use typically use `...` as the >body. > > >> Gregory, one of your suggestions meets these requirements: >> >> ```python >> def is_str_list(val: Constrains[List[object]:List[str]) -> bool: >> ... >> ``` > >That still misleadingly tells the reader (or naive code analysis >software) that parameter val is of type > >Contrains[List[object]:List[str]] > >whatever that object is, rather than what it *actually* is, namely >`List[object]`. I dislike code that misleads the reader. > > >> As for choosing the name of the annotation >[...] >> `TypeGuard` is the term that is used in other languages to describe >> this notion, so it seems reasonable to me to adopt this term > >Okay, this reasoning makes sense to me. Whether spelled as a decorator >or an annotation, using TypeGuard is reasonable. > > >> Steven, you said you'd like to explore a decorator-based formulation. >> Let's explore that. Here's what that it look like if we were to meet >> all of the above requirements. >> >> ```python >> @type_guard(List[str]) >> def is_str_list(val: List[object]) -> bool: ... >> ``` > >Okay. > > >I note that this could be easily extended to support narrowing in the >negative case as well: > >@type_guard(List[str], List[float]) >def is_str_list(val: List[Union[str, float]]) -> bool: ... > > >> The problem here, as I mention in the "rejected ideas" secti
[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)
Hi Mark,
I also wanted to give some feedback on this. While most of the
discussion so far has been about the matching of the pattern itself I
think it should also be considered what happens in the block below.
Consider this code:
```
m = ...
match m:
case [a, b, c] as l:
# what can we safely do with l?
```
or in terms of the type system: What is the most specific type that we
can know l to be?
With PEP 634 you can be sure that l is a sequence and that it's length
is 3. With PEP 653 this is currently not explicitly defined. Judging
from the pseudo code we can only assume that l is an iterable (because
we use it in an unpacking assignment) and that it's length is 3, which
greatly reduces the operations that can be safely done on l.
For mapping matches with PEP 634 we can assume that l is a mapping. With
PEP 653 all we can assume is that it has a .get method that takes two
parameters, which is even more restrictive, as we can't even be sure if
we can use len(), .keys, ... or iterate over it.
This also makes it a lot harder for static type checkers to check match
statements, because instead of checking against an existing type they
now have to hard-code all the guarantees made my the match statement or
not narrow the type at all.
Additionally consider this typed example:
```
m: Mapping[str, int] = ...
match m:
case {'version': v}:
pass
```
With PEP 634 we can statically check that v is an int. With PEP 653
there is no such guarantee.
Therefore I would strongly be in favor of having sequence and mapping
patterns only match certain types instead of relying on dunder
attributes. If implementing all of sequence is really to much work just
to be matched by a sequence pattern, as PEP 653 claims, then maybe a
more general type could be chosen instead.
I don't have any objections against the other parts of the PEP.
Adrian Freund
On 3/27/21 2:37 PM, Mark Shannon wrote:
> Hi everyone,
>
> As the 3.10 beta is not so far away, I've cut down PEP 653 down to the
> minimum needed for 3.10. The extensions will have to wait for 3.11.
>
> The essence of the PEP is now that:
>
> 1. The semantics of pattern matching, although basically unchanged,
> are more precisely defined.
>
> 2. The __match_kind__ special attribute will be used to determine
> which patterns to match, rather than relying on the collections.abc
> module.
>
> Everything else has been removed or deferred.
>
> The PEP now has only the slightest changes to semantics, which should be
> undetectable in normal use. For those corner cases where there is a
> difference, it is to make pattern matching more robust.
> E.g. With PEP 653, pattern matching will work in the collections.abc
> module. With PEP 634 it does not.
>
>
> As always, all thoughts and comments are welcome.
>
> Cheers,
> Mark.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/YYIT3QXMLPNLXQAQ5BCXE4LLJ57EE7JV/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/OAVTGQCFXNX47JH52ZMOAHVISDZ2JNMO/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Typing syntax and ecosystem
I see multiple problems with including a type checker as part of the standard library: First of all this would require defining precise type checking semantics and not making breaking changes to them. Currently some parts of type checking are not precisely defined and are done differently by different type checkers. Take this example: if condition: a = 1 else: a = "foo" reveal_type(a) Mypy raises an error at the second assignment and infers a as int. Pyright on the other hand doesn't report errors and infers a as Union[int, str]. Both approaches are equally valid and have their advantages and drawbacks. My second concern would be the development speed. Python type checking is still relatively young and is developing at a vastly different rate from the rest of the language. While cpython currently has a 1 year release cycle mypy had 5 releases (excluding minor releases) in the last year. This development speed difference can also be seen by the use of typing_extensions to back port typing features to older python versions. GitHub search shows 16.500 python results for "from typing_extensions" (excluding forks). Being tied to the cpython release cycle would probably significantly hinder the development of a type checker. I agree that a delay between a python release and mypy (and other type checkers) supporting it isn't optimal, but it can probably be solved much easier: By having more developers put in work to keep it up do date. This work would still need to be done, even for a type checker that's part of the standard library. The only difference would be that changes would then cause tests in cpython to fail instead of just in mypy. In the future, when development on type checkers has slowed, adding a type checker to the standard library might be useful, but in my opinion it would currently do more harm than good. Adrian Freund On April 13, 2021 11:55:05 PM GMT+02:00, Luciano Ramalho wrote: >Hugh was unfortunate in presenting the problem, but I agree that we >should commit all the way to supporting type hints, and that means >bundling a type checker as part of the standard library and >distribution. > >There is always a delay after a Python release before Mypy catches up >to—and that's the type checker hosted in the python organization on >github. > >I believe this is an unfortunate state of affairs for many users. I am >not aware of any other optionally typed language that underwent core >changes to support type annotations and yet does not bundle a type >checker. > >Cheers, > >Luciano > > > >On Mon, Apr 12, 2021 at 7:01 AM Hugh Fisher wrote: >> >> > Message: 1 >> > Date: Sun, 11 Apr 2021 13:31:12 -0700 >> > From: Barry Warsaw >> > Subject: [Python-Dev] Re: PEP 647 Accepted >> >> > >> > This is something the SC has been musing about, but as it’s not a fully >> > formed idea, I’m a little hesitant to bring it up. That said, it’s >> > somewhat relevant: We wonder if it may be time to in a sense separate the >> > typing syntax from Python’s regular syntax. TypeGuards are a case where >> > if typing had more flexibility to adopt syntax that wasn’t strictly legal >> > “normal” Python, maybe something more intuitive could have been proposed. >> > I wonder if the typing-sig has discussed this possibility (in the future, >> > of course)? >> >> [ munch ] >> >> > >> > Agreed. It’s interesting that PEP 593 proposes a different approach to >> > enriching the typing system. Typing itself is becoming a little ecosystem >> > of its own, and given that many Python users are still not fully embracing >> > typing, maybe continuing to tie the typing syntax to Python syntax is >> > starting to strain. >> >> I would really like to see either "Typed Python" become a different >> programming >> language, or progress to building type checking into the CPython >> implementation >> itself. (Python 4 seems to me the obvious release.) The current halfway >> approach >> is confusing and slightly ridiculous. >> >> The first, a separate programming language, would be like RATFOR and CFront >> in the past and TypeScript today. Typed Python can have whatever syntax the >> designers want because it doesn't have to be compatible with Python, just as >> TypeScript is not constrained by JavaScript. A type checker translates >> the original >> Typed Python source into "dynamic" or "classic" Python for execution. (Maybe >> into .pyc instead of .py?) >> >> This would mean no overhead for type checking in CPython itself. No need
[Python-Dev] Re: PEP 563 and 649: The Great Compromise
I think there is a point to be made for requiring a function call to resolve annotations, in regard to the ongoing discussion about relaxing the annotation syntax (https://mail.python.org/archives/list/python-dev@python.org/message/2F5PVC5MOWMGFVOX6FUQOUC7EJEEXFN3/) Type annotation are still a fast moving topic compared to python as a whole. Should the annotation syntax be relaxed and annotations be stored as strings then requiring a function call to resolve annotations would allow third party libraries, be it typing_extensions or something else, to backport new type annotation syntax by offering their own version of "get_annotated_values". Typing features are already regularly backported using typing_extensions and this could not be done for new typing syntax unless annotations are stored as strings and resolved by a function. Note: Obviously new typing syntax couldn't be backported to versions before the typing syntax was relaxed, unless explicitly wrapped in a string, but I would imagine that if we see a relaxed annotation syntax we might see new typing syntax every now and then after that. Adrian Freund On April 18, 2021 6:49:59 PM GMT+02:00, Larry Hastings wrote: >On 4/18/21 9:10 AM, Damian Shaw wrote: >> Hi Larry, all, I was thinking also of a compromise but a slightly >> different approach: >> >> Store annotations as a subclass of string but with the required frames >> attached to evaluate them as though they were in their local context. >> Then have a function "get_annotation_values" that knows how to >> evaluate these string subclasses with the attached frames. >> >> This would allow those who use runtime annotations to access local >> scope like PEP 649, and allow those who use static type checking to >> relax the syntax (as long as they don't try and evaluate the syntax at >> runtime) as per PEP 563. > > >Something akin to this was proposed and discarded during the discussion >of PEP 563, although the idea there was to still use actual Python >bytecode instead of strings: > > > https://www.python.org/dev/peps/pep-0563/#keeping-the-ability-to-use-function-local-state-when-defining-annotations > >It was rejected because it would be too expensive in terms of >resources. PEP 649's approach uses significantly fewer resources, which >is one of the reasons it seems viable. > >Also, I don't see the benefit of requiring a function like >"get_annotation_values" to see the actual values. This would force >library code that examined annotations to change; I think it's better >that we preserve the behavior that "o.__annotations__" are real values. > > >Cheers, > > >//arry/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/N74BWTHGBWWR46EB3TVLZZDJXTMHSIP2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Keeping Python a Duck Typed Language.
According to PEP 484 all missing annotations in checked functions should be handled as Any. Any is compatible with all types. I think from a technical standpoint it should be possible to infer protocols for arguments for most functions, but there are some edge cases where this would not be possible, making it impractical to make this the default behavior. Having an annotation to make a type checker infer a protocol would be interesting though. For example: def f(x: int): ... def g(x: str): ... def main(t): if t[0] == 'version': f(t[1]) elif t[0] == 'name': g(t[1]) You could statically type t as Union[Tuple[Literal['version'], int], Tuple[Literal['name'], str]], but inferring a Protocol for this would be either very hard or even impossible, especially with even more complex conditions. Adrian Freund On April 22, 2021 1:04:11 PM GMT+02:00, Paul Moore wrote: >On Thu, 22 Apr 2021 at 11:21, Paul Moore wrote: >> >> On Thu, 22 Apr 2021 at 11:06, Chris Angelico wrote: >> > >> > Someone will likely correct me if this is inaccurate, but my >> > understanding is that that's exactly what you get if you just don't >> > give a type hint. The point of type hints is to give more information >> > to the type checker when it's unable to simply infer from usage and >> > context. >> >> Hmm, I sort of wondered about that as I wrote it. But in which case, >> what's the problem here? My understanding was that people were >> concerned that static typing was somehow in conflict with duck typing, >> but if the static checkers enforce the inferred duck type on untyped >> arguments, then that doesn't seem to be the case. Having said that, I >> thought that untyped arguments were treated as if they had a type of >> "Any", which means "don't type check". > >Looks like it doesn't: > >> cat .\test.py >def example(f) -> None: >f.close() > >import sys >example(12) >example(sys.stdin) >PS 12:00 00:00.009 C:\Work\Scratch\typing >> mypy .\test.py >Success: no issues found in 1 source file > >What I was after was something that gave an error on the first call, >but not on the second. Compare this: > >> cat .\test.py >from typing import Protocol > >class X(Protocol): >def close(self): ... > >def example(f: X) -> None: >f.close() > >import sys >example(12) >example(sys.stdin) >PS 12:03 00:00.015 C:\Work\Scratch\typing >> mypy .\test.py >test.py:10: error: Argument 1 to "example" has incompatible type >"int"; expected "X" >Found 1 error in 1 file (checked 1 source file) > >Paul >___ >Python-Dev mailing list -- python-dev@python.org >To unsubscribe send an email to python-dev-le...@python.org >https://mail.python.org/mailman3/lists/python-dev.python.org/ >Message archived at >https://mail.python.org/archives/list/python-dev@python.org/message/54C6G2JLYYD6B37J5KVKPCKSQDCGLRKA/ >Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/M4XDZUPWKPGRO3NF5VONG22YHOHAYZCM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Keeping Python a Duck Typed Language.
On April 22, 2021 3:15:27 PM GMT+02:00, Paul Moore wrote: >On Thu, 22 Apr 2021 at 13:23, Adrian Freund wrote: >> >> According to PEP 484 all missing annotations in checked functions should be >> handled as Any. Any is compatible with all types. > >Yep, that's what I understood to be the case. > >> I think from a technical standpoint it should be possible to infer protocols >> for arguments for most functions, but there are some edge cases where this >> would not be possible, making it impractical to make this the default >> behavior. Having an annotation to make a type checker infer a protocol would >> be interesting though. > >Absolutely, I see no problem with "use duck typing for this argument" >being opt-in. > >> For example: >> >> def f(x: int): ... >> def g(x: str): ... >> >> def main(t): >> if t[0] == 'version': >> f(t[1]) >> elif t[0] == 'name': >> g(t[1]) >> >> >> You could statically type t as Union[Tuple[Literal['version'], int], >> Tuple[Literal['name'], str]], but inferring a Protocol for this would be >> either very hard or even impossible, especially with even more complex >> conditions. > >Yes, but that's inferred static typing which is *not* what I was >proposing. I think I understood what you were proposing, but my example might have been less than ideal. Sorry for that. I mixed some static types in there to simplify it. The union wasn't meant at what it should infer but was meant as a comparison to what we would to currently, with static, nominal typing. Let me try again without static types. def file(x): print(x.read()) # x has to have .read(): object def string(x): print(str(x)) # x has to have .__str__(self): object def main(t): if t[0] == 'file': file(t[1]) elif t[0] == 'string': string(t[1]) Here we can infer that t has to have a __getitem__(self, idx: int), but we can't infer it's return type >I was suggesting that the checker could easily infer that t >must have a __getitem__ method, and nothing more. So the protocol to >infer is > >class TypeOfT(Protocol): >def __getitem__(self, idx): ... > >It would be nice to go one step further and infer > >class TypeOfT(Protocol): >def __getitem__(self, idx: int): ... > >but that's *absolutely* as far as I'd want to go. Note in particular >that I don't want to constrain the return value The problem is that this isn't enough to have a type safe program. You need to also constrain the return type to make sure the returned value can be safely passed to other functions. If you don't do this large parts of your codebase will either need explicit annotations or will be unchecked. >- we've no way to know >what type it might have in the general case. IMO, inferring anything >else would over-constrain t - there's nothing in the available >information, for example, that says t must be a tuple, or a list, or >that t[3] should have any particular type, or anything like that. You can infer the return type of a function by looking at all the returns it contains, and inferring the types of the returned expressions. That isn't too hard and pytype for example already does it. You can infer the return type a protocol function should have by looking at all the places it's result are used. If you have inferred return types then constraining return types using inferred protocols would be practical in my opinion. > >My instinct is that working out that t needs to have a __getitem__ >that takes an int is pretty straightforward, as all you have to do is >look at where t is used in the function. Four places, all followed by >[] with a literal integer in the brackets. That's it. I fully >appreciate that writing *code* to do that can be a lot harder than it >looks, but that's an implementation question, not a matter of whether >it's reasonable as a proposal in theory. > >This feels like *precisely* where there seems to be a failure of >communication between the static typing and the duck typing worlds. I >have no idea what I said that would make you think that I wanted >anything like that Union type you quoted above. And yet obviously, you >somehow got that message from what I did say. Like I said above the Union. Was just meant as an example of that we would do with static, nominal typing, not what we want with duck typing. Sorry for the misunderstanding. > >Anyway, as I said this is just an interesting idea as far as I'm >concerned. I've no actual need for it right now, so I'm happy to leave >it to the mypy developers whether they want to do anything with it. > >Paul ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/AG6LWGMUNGP5O3PXJZUVDRRXO5VTJ7FW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Keeping Python a Duck Typed Language.
On 4/22/21 5:00 PM, Paul Moore wrote: > On Thu, 22 Apr 2021 at 15:22, Adrian Freund wrote: >> On April 22, 2021 3:15:27 PM GMT+02:00, Paul Moore >> wrote: >>> but that's *absolutely* as far as I'd want to go. Note in particular >>> that I don't want to constrain the return value >> The problem is that this isn't enough to have a type safe program. You need to also constrain the return type to make sure the returned value can be safely passed to other functions. > But I don't want a type safe program. At least not in an absolute > sense. All I want is for mypy to catch the occasional error I make > where I pass the wrong parameter. For me, that's the "gradual" in > "gradual typing" - it's not a lifestyle, just a convenience. You seem > to be implying that it's "all or nothing". I don't think that inferring the required return type breaks gradual typing, but it is required for people who want type safety. If I understand correctly your concerns with inferring return types for inferred protocols are that it might be to restrictive and prevent gradual typing. Here are some examples to show how gradual typing would still work. If you have any concrete examples where inferring the return type would break gradual typing let me know and I'll have a look at them. def foo(x: DuckType): # x has to have a .bar(self) method. # The return type of which is inferred as Any, as it isn't used x.bar() def bar(x): x.bar() def foo(x: DuckType): # x has to have a .read(self) method. # The return type of which ist inferred as Any, as the parameter to bar isn't typed. bar(x.read()) Contrast that with def bar(x: DuckType): # x has to have a .bar(self) method. # The return type of which is inferred as Any. x.bar() def foo(x: DuckType): # x has to have a .read(self) method that returns something with a .bar(self) method. # If we don't infer the return type our call to bar() might be unsafe despite both foo and bar being typed. bar(x.read()) > I repeat, all I'm proposing is that > > def f(x: int): ... > def g(x: str): ... > > def main(t: DuckTyped) -> None: > if t[0] == 'version': > f(t[1]) > elif t[0] == 'name': > g(t[1]) > > gets interpreted *exactly* the same as if I'd written > > class TType(Protocol): > def __getitem__(self, int): ... > > def f(x: int): ... > def g(x: str): ... > > def main(t: TType) -> None: > if t[0] == 'version': > f(t[1]) > elif t[0] == 'name': > g(t[1]) > > How can you claim that the second example requires that " large parts > of your codebase will either need explicit annotations or will be > unchecked"? And if the second example doesn't require that, nor does > the first because it's equivalent. Both examples don't check the calls to f and g despite f and g both being typed functions and being called from typed functions. In a real codebase this will lead to a lot more instances of this happening. It would happen every time you do anything with something returned from a method on an inferred protocol > > Honestly, this conversation is just reinforcing my suspicion that > people invested in type annotations have a blind spot when it comes to > dealing with people and use cases that don't need to go "all in" with > typing :-( I don't think this is an all in or nothing. You can infer return types of inferred protocols and still use gradual typing. It's just that not inferring return types causes problems for both full and gradual typing. Adrian Freund ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/KVB33BV6T6H7PFXN574CMFZUJOVSVUBV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: python3.10rc2 compilation on android/termux/clang12.0.1 fails
As you are using termux it might be worth checking out the build
arguments and patches termux uses to build their own version of python
(Currently 3.9.7):
https://github.com/termux/termux-packages/tree/master/packages/python
I'm not sure if this will be enough to build python3.10 or if additional
patches and build arguments are needed though.
Adrian
On 9/15/21 19:06, Sandeep Gupta wrote:
I am trying to compile Python3.10rc2 on rather unusual platform
(termux on android). The
gcc version is listed below:
~ $ g++ -v
clang version 12.0.1
Target: aarch64-unknown-linux-android24
Thread model: posix
InstalledDir: /data/data/com.termux/files/usr/bin
I get following warnings and errors:
Python/pytime.c:398:10: warning: implicit conversion from 'long' to
'double' changes value from 9223372036854775807 to 9223372036854775808
[-Wimplicit-const-int-float-conver
sion]
if (!_Py_InIntegralTypeRange(_PyTime_t, d)) {
Python/bootstrap_hash.c:141:17: error: implicit declaration of
function 'getrandom' is invalid in C99
[-Werror,-Wimplicit-function-declaration]
n = getrandom(dest, n, flags);
^
Python/bootstrap_hash.c:145:17: error: implicit declaration of
function 'getrandom' is invalid in C99
[-Werror,-Wimplicit-function-declaration]
n = getrandom(dest, n, flags);
Not sure if this is limitation of the platform or Python codebase
needs fixes.
Thanks
-S
___
Python-Dev mailing list --python-dev@python.org
To unsubscribe send an email topython-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived
athttps://mail.python.org/archives/list/python-dev@python.org/message/KEURSMCLUVI7VPKM6M2VUV4JIW6FP66Z/
Code of Conduct:http://python.org/psf/codeofconduct/___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/WFKYODUXY3UHENII7U47XQPUIZQFJDG4/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: python3.10rc2 compilation on android/termux/clang12.0.1 fails
I looked a bit more into this and managed to run python 3.10.0rc2 on
android in termux. No additional patches were needed, but the build
process isn't straight forward.
Some packages don't build on-device and have to be built on a computer.
Python is one of them
(https://github.com/termux/termux-packages/issues/4157. The issue is
closed because making all packages build on-device is no longer a goal
of termux)
Follow https://github.com/termux/termux-packages/wiki/Build-environment
to set up your termux build environment. You can use Docker, Vagrant,
Ubuntu or Arch Linux. I used docker.
Next build and install python3.10.0rc2 *on the build machine*. You need
python3.10 installed to cross-compile python3.10.
After that go back to the termux packages and change
packages/python/build.sh. All you need to change is version number, url
and hash. Here's a patch anyways:
diff --git a/packages/python/build.sh b/packages/python/build.sh
index c36bff5e5..d9fd86d02 100644
--- a/packages/python/build.sh
+++ b/packages/python/build.sh
@@ -2,10 +2,11 @@ TERMUX_PKG_HOMEPAGE=https://python.org/
TERMUX_PKG_DESCRIPTION="Python 3 programming language intended to
enable clear programs"
TERMUX_PKG_LICENSE="PythonPL"
TERMUX_PKG_MAINTAINER="@termux"
-_MAJOR_VERSION=3.9
-TERMUX_PKG_VERSION=${_MAJOR_VERSION}.7
-TERMUX_PKG_SRCURL=https://www.python.org/ftp/python/${TERMUX_PKG_VERSION}/Python-${TERMUX_PKG_VERSION}.tar.xz
-TERMUX_PKG_SHA256=f8145616e68c00041d1a6399b76387390388f8359581abc24432bb969b5e3c57
+_MAJOR_VERSION=3.10
+_MINOR_VERSION=.0
+TERMUX_PKG_VERSION=${_MAJOR_VERSION}${_MINOR_VERSION}rc2
+TERMUX_PKG_SRCURL=https://www.python.org/ftp/python/${_MAJOR_VERSION}${_MINOR_VERSION}/Python-${TERMUX_PKG_VERSION}.tar.xz
+TERMUX_PKG_SHA256=e75b56088548b7b9ad1f2571e6f5a2315e4808cb6b5fbe8288502afc802b2f24
TERMUX_PKG_DEPENDS="gdbm, libandroid-support, libbz2, libcrypt,
libffi, liblzma, libsqlite, ncurses, ncurses-ui-libs, openssl, readline,
zlib"
TERMUX_PKG_RECOMMENDS="clang, make, pkg-config"
TERMUX_PKG_SUGGESTS="python-tkinter"
Finally just run "./build-package.sh -i -f python" and send
"output/python*.deb" to your phone, where you can install it using dpkg -i.
Adrian
On 9/16/21 14:27, Adrian Freund wrote:
As you are using termux it might be worth checking out the build
arguments and patches termux uses to build their own version of python
(Currently 3.9.7):
https://github.com/termux/termux-packages/tree/master/packages/python
I'm not sure if this will be enough to build python3.10 or if
additional patches and build arguments are needed though.
Adrian
On 9/15/21 19:06, Sandeep Gupta wrote:
I am trying to compile Python3.10rc2 on rather unusual platform
(termux on android). The
gcc version is listed below:
~ $ g++ -v
clang version 12.0.1
Target: aarch64-unknown-linux-android24
Thread model: posix
InstalledDir: /data/data/com.termux/files/usr/bin
I get following warnings and errors:
Python/pytime.c:398:10: warning: implicit conversion from 'long' to
'double' changes value from 9223372036854775807 to
9223372036854775808 [-Wimplicit-const-int-float-conver
sion]
if (!_Py_InIntegralTypeRange(_PyTime_t, d)) {
Python/bootstrap_hash.c:141:17: error: implicit declaration of
function 'getrandom' is invalid in C99
[-Werror,-Wimplicit-function-declaration]
n = getrandom(dest, n, flags);
^
Python/bootstrap_hash.c:145:17: error: implicit declaration of
function 'getrandom' is invalid in C99
[-Werror,-Wimplicit-function-declaration]
n = getrandom(dest, n, flags);
Not sure if this is limitation of the platform or Python codebase
needs fixes.
Thanks
-S
___
Python-Dev mailing list --python-dev@python.org
To unsubscribe send an email topython-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived
athttps://mail.python.org/archives/list/python-dev@python.org/message/KEURSMCLUVI7VPKM6M2VUV4JIW6FP66Z/
Code of Conduct:http://python.org/psf/codeofconduct/
___
Python-Dev mailing list --python-dev@python.org
To unsubscribe send an email topython-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived
athttps://mail.python.org/archives/list/python-dev@python.org/message/WFKYODUXY3UHENII7U47XQPUIZQFJDG4/
Code of Conduct:http://python.org/psf/codeofconduct/___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/2V5AVBB4QDN2NSEUFBQJ4X2M2FC6IMUA/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Python 3.9.11
It looks like the 3.9.11 commit was done 14 hours ago: https://github.com/python/cpython/commit/0f0c55c9f0f4c358d759470702821c471fcd1bc8 It hasn't been tagged and uploaded to the website yet. I'm not involved in the release process, but I'd imagine that it will show up on the website soon. 3.9.10 was released approximately one day after the commit was made. Regards, Adrian Freund On 3/15/22 18:43, Prasad, PCRaghavendra wrote: Hi Team, Can someone please let us know the release date of Python 3.9.11 ( with libexpat 2.4.8 security issues fixed ) In the python.org releases it was mentioned as 14-march-2022, but still, I couldn’t see the bin/source code. Can someone help with this Thanks, Raghavendra Internal Use - Confidential ___ Python-Dev mailing list --python-dev@python.org To unsubscribe send an email topython-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived athttps://mail.python.org/archives/list/python-dev@python.org/message/5LWAYP7A4BBGPXXBAUWTSL6YQWHDX25N/ Code of Conduct:http://python.org/psf/codeofconduct/___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/JTOX2B4GDW2W2C4JJGQ7VI57NE4EUPXJ/ Code of Conduct: http://python.org/psf/codeofconduct/
