[Python-Dev] Discussion about how to manage additions/removals to the stdlib

2021-09-16 Thread Brett Cannon
https://discuss.python.org/t/how-do-we-want-to-manage-additions-removals-to-the-stdlib/10681

This comes from my language summit talk on the stdlib to help clarify some
things about how we manage the stdlib from the perspective of
additions/deletions.

FYI I will be *muting this email thread immediately*, so please participate
on discuss.python.org if you have anything to say (I almost didn't post
here, but I figured I would see if there's any chance people will follow
through on discuss.python.org if directed there and told feedback here will
be ignored).
___
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/KB2CLR6Q2NVSPA2WR4KPP2S4ITOMAHMS/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Should the definition of an "(async) iterator" include __iter__?

2021-09-16 Thread Terry Reedy

On 9/16/2021 3:02 AM, Paul Moore wrote:


The debate here is (I think!) whether an *iterator* that is not also
an *iterable* is a valid iterator.


This framing of the question seems biased in that it initially uses 
'iterator' to mean 'object with __next__ but not __iter__' whe the 
propriety of that equating is at least half of the debate.



IMO it is valid (because that's what the definitions say, basically)


The definitions pretty much answer the question above in the negative.

https://www.python.org/dev/peps/pep-0234/
C-API:
 "Iterators ought to implement the tp_iter slot as returning a 
reference to themselves; this is needed to make it possible to use an 
iterator (as opposed to a sequence) in a for loop."

Python-API"
" A class that wants to be an iterator should implement two methods: a 
next() method that behaves as described above, and an __iter__() method 
that returns self." ... "Iterators are currently required to support 
both protocols."


The clear intention is that iterators be usable as iterables.

https://docs.python.org/3/glossary.html
iterator:
" Iterators are required to have an __iter__() method that returns the 
iterator object itself so every iterator is also iterable and may be 
used in most places where other iterables are accepted."



but it may not be *useful* in certain circumstances, and it definitely
may not be *expected* (because nearly all iterators are iterables).
"Broken" is a strong word to use, though, and that might be why the
debate is continuing this long...


I think 'semi-iterator' might be a better term, definitely more neutral, 
for an object that is maybe duck-type usable as an iterator and maybe not.


For Python code, I currently do not see a reason to omit the minimal 
"def __init__(self): return self".  I don't know about C code.



--
Terry Jan Reedy

___
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/XHGL3BWV5UNZYOEPQLVT7H5YRRO3UQBU/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Should the definition of an "(async) iterator" include __iter__?

2021-09-16 Thread Brett Cannon
On Wed, Sep 15, 2021 at 4:06 PM Guido van Rossum  wrote:

> [SNIP]
> Reminder about how for-loops work:
>
> This:
>
> for x in seq:
> 
>
> translates (roughly) to this:
>
> _it = iter(seq)
> while True:
> try:
> x = next(_it)
> except StopIteration:
> break
> 
>

And if anyone wants more details on this, I have a blog post about it at
https://snarky.ca/unravelling-for-statements/ .
___
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/5C7IIVHYX6A25ERQT4RJ3MM6AOXZVBAZ/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: python3.10rc2 compilation on android/termux/clang12.0.1 fails

2021-09-16 Thread Adrian Freund
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: How to decipher Windows errors on builds?

2021-09-16 Thread Victor Stinner
Hi Mark,

https://bugs.python.org/issue45220 now tracks these Windows build errors.

Victor

On Thu, Sep 16, 2021 at 3:25 PM Mark Shannon  wrote:
>
> Hi,
>
> I'm getting build errors on Windows for
> https://github.com/python/cpython/pull/28386
>
> The error message is:
>
> C:\Program Files (x86)\Windows
> Kits\10\Include\10.0.22000.0\um\winnt.h(253): error RC2188:
> D:\a\cpython\cpython\PCbuild\obj\311win32_Release\pythoncore\RCa01688(47)
> : fatal error RC1116: RC terminating after preprocessor errors
> [D:\a\cpython\cpython\PCbuild\pythoncore.vcxproj]
>
> Can anyone translate that into English for me?
>
> It suggests that there are errors in the preprocessor. But how do I tell
> what the error is?
>
> 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/SOCIYBNX5VZYPZFQYKWRCCPPN7TNVUMJ/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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/4ZTTG53Z6GDXBQZSPNYK2BVG7MPX2BGN/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] What's the rule for issuing line tracing numbers when using a tracing function?

2021-09-16 Thread Fabio Zadrozny
Hi all,

I have a weird case where I thought line events would be issued and yet
they aren't even though they're in the instructions in the bytecode (both
in 3.9 and 3.10).

i.e.:

Given the code:

def check_backtrack(x):  # line 1
if not (x == 'a'  # line 2
or x == 'c'):  # line 3
pass  # line 4

it has dis.dis such as:

  2   0 LOAD_FAST0 (x)
  2 LOAD_CONST   1 ('a')
  4 COMPARE_OP   2 (==)
  6 POP_JUMP_IF_TRUE12 (to 24)

  3   8 LOAD_FAST0 (x)
 10 LOAD_CONST   2 ('c')
 12 COMPARE_OP   2 (==)

  2  14 POP_JUMP_IF_TRUE10 (to 20)

  4  16 LOAD_CONST   0 (None)
 18 RETURN_VALUE

  2 >>   20 LOAD_CONST   0 (None)
 22 RETURN_VALUE
>>   24 LOAD_CONST   0 (None)
 26 RETURN_VALUE

So, by just following the instructions/line numbers, I'd say that when the
instruction:

2  14 POP_JUMP_IF_TRUE10 (to 20)

is executed, a line event would take place, yet, this isn't true, but if
that offset is changed to include more instructions then such a line event
is issued.

i.e.: something as:

def tracer(frame, event, arg):
print(frame, event)
return tracer

import sys
sys.settrace(tracer)
check_backtrack('f')

prints:

1 call
2 line
3 line
4 line
4 return

when I expected it to print:

1 call
2 line
3 line
2 line |<-- this is not being issued
4 line
4 return

So, I have some questions related to this:

Does anyone know why this happens?
What's the rule to identify this?
Why is that line number assigned to that instruction (i.e.: it seems a bit
odd that this is set up like that in the first place)?

Thanks,

Fabio

p.s.: I'm asking because in a debugger which changes bytecode I want to
keep the same semantics and it appears that if I add more bytecode at that
instruction offset, those semantics aren't kept (but I don't really know
what are the semantics to keep here since it seems like that instruction
should issue a line event even though it doesn't).
___
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/CP2PTFCMTK57KM3M3DLJNWGO66R5RVPB/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] How to decipher Windows errors on builds?

2021-09-16 Thread Mark Shannon

Hi,

I'm getting build errors on Windows for 
https://github.com/python/cpython/pull/28386


The error message is:

C:\Program Files (x86)\Windows 
Kits\10\Include\10.0.22000.0\um\winnt.h(253): error RC2188: 
D:\a\cpython\cpython\PCbuild\obj\311win32_Release\pythoncore\RCa01688(47) 
: fatal error RC1116: RC terminating after preprocessor errors 
[D:\a\cpython\cpython\PCbuild\pythoncore.vcxproj]


Can anyone translate that into English for me?

It suggests that there are errors in the preprocessor. But how do I tell 
what the error is?


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/SOCIYBNX5VZYPZFQYKWRCCPPN7TNVUMJ/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: python3.10rc2 compilation on android/termux/clang12.0.1 fails

2021-09-16 Thread Victor Stinner
Hi,

On Wed, Sep 15, 2021 at 7:16 PM Sandeep Gupta  wrote:
> 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)) {

This warning is tracked at: https://bugs.python.org/issue39277

I proposed a fix but i'm not sure that it's correct and so I never did
anything with this PR: https://github.com/python/cpython/pull/17933

> 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);

This code path should only be taken if HAVE_GETRANDOM macro is
defined. Is it defined in your pyconfig.h file?

Is the getrandom() function available in your libc?

configure.ac tries to build this code:
---
#include 

int main() {
char buffer[1];
const size_t buflen = sizeof(buffer);
const int flags = 0;
/* ignore the result, Python checks for ENOSYS at runtime */
(void)getrandom(buffer, buflen, flags);
return 0;
}
---

Maybe Android needs a different #include? Or a different test?

> Not sure if this is limitation of the platform or Python codebase needs fixes.

Enhancements are welcomed :-)

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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/H35G7QNDUFNQS6AXMN76K3FRE63BXOXF/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Should the definition of an "(async) iterator" include __iter__?

2021-09-16 Thread Paul Moore
On Thu, 16 Sept 2021 at 01:30, Chris Barker via Python-Dev
 wrote:
> """
>  "[i]terators are required to have an __iter__() method" which neither `for` 
> nor `iter()` actually enforce.
> """
>
> I'm confused -- as far as I can tell `for` does enforce this -- well, it 
> doesn't enforce it, but it does require it, which is the same thing, yes? But 
> does it need to?

for enforces that *iterables* have an __iter__ method, not
*iterators*. (for takes an iterable, not an iterator, and uses
__iter__ to *get* an iterator from it).

The debate here is (I think!) whether an *iterator* that is not also
an *iterable* is a valid iterator.

IMO it is valid (because that's what the definitions say, basically)
but it may not be *useful* in certain circumstances, and it definitely
may not be *expected* (because nearly all iterators are iterables).
"Broken" is a strong word to use, though, and that might be why the
debate is continuing this long...

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/UIKBKWT5G4ME2LVZ3W6RYRK5ESNBEZBQ/
Code of Conduct: http://python.org/psf/codeofconduct/