[Python-ideas] Re: A “big picture” question.
I would note that the accepted [PEP 626](https://peps.python.org/pep-0626/) explicitly constrains line-tracing behavior: """Python should guarantee that when tracing is turned on, “line” tracing events are generated for all lines of code executed and only for lines of code that are executed.""" So even peephole optimizations should now theoretically follow PEP 626 and produce the expected line-tracing events. For example, the line "try:" typically emits a "NOP" instruction that is kept around just for the sake of tracing. If I recall correctly, there might not be 100% compliance with PEP 626 so far, but in general, things have recently gotten more well-specified and predictable in this regard, not less. The interpreter is still allowed to go wild by, e.g., executing type-specialized versions of different opcodes (PEP 659), but just not in such a way as to change language semantics, including the semantics of tracing when tracing is enabled. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/EK2HDVLAVC7B3EY7RDZTMXIGL5RYQI6J/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: A “big picture” question.
On Fri, Jun 10, 2022 at 09:59:36PM -0500, James Johnson wrote: > I guess I was jumping to conclusions. Thank you for taking the time to look > at my email. > > I apologize if I wasted your time. No stress -- opening issues up for discussion is not a waste of time. This would be a good time to mention that there have been previous requests to have more control of what optimizations the Python byte-code compiler performs, mostly for the benefit of profiling applications. While the compiler doesn't do many, or any, large complex optimizations like a C compiler may do, it does do some keyhole optimizations. Sometimes those keyhole optimizations interfere with the ability of programs to analyse Python code and report on code coverage. While the keyhole optimization doesn't change the semantics of the code, it does change the structure of it, and makes it harder to analyse whether or not each clause in a statement is covered by tests. So other people have also requested the ability to tell the compiler to turn off all optimizations. Another factor is that as we speak, Mark Shannon is doing a lot of work on optimization for the CPython byte-code compiler, including adding JIT compilation techniques. (PyPy has had this ability for many years.) So it is possible that future compiler optimizations may start to move into the same areas that C/C++ compiler optimizations take, possibly even changing the meaning of code. It would be good to plan ahead, and start considering more fine grained optimization control, rather than the underpowered -O and -OO flags we have now. -- Steve ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/T3YBQRFVSQUJ2O6R6ON5ZTN77A6XGSZK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: A “big picture” question.
On Wed, Jun 08, 2022 at 06:51:54AM -0500, James Johnson wrote: > When an amateur develops code incorrectly, s/he sometimes ends up with a > code object that doesn’t run because of intermediate compiler optimizations. If that happens, that's a bug in the compiler. Optimizations should never change the meaning of code. If you have an example of this, where the compiler optimization changes the meaning of Python code beyond what is documented, please raise a bug report for it. But I doubt you will find any, because Python performs very, very few optimizations of the sort you are referring to. -- Steve ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/RRLF5OJFKYIO6WFCZS3RFMZDNIBPBI3P/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: disallow assignment to unknown ssl.SSLContext attributes
No because existence of this attribute is dynamic On Fri, Jun 25, 2021, 3:44 PM Guido van Rossum wrote: > Would a static type checker have found this? > > On Fri, Jun 25, 2021 at 02:07 Thomas Grainger wrote: > >> I was debugging some code that was using TLSv1.2 when I expected it to >> only support TLSv1.3, I tracked it down to a call to: >> >> context.miunimum_version = ssl.TLSVersion.TLSv1_3 >> >> it should have been: >> >> context.minimum_version = ssl.TLSVersion.TLSv1_3 >> >> I'd like invalid attribute assignment to be prevented at runtime >> ___ >> Python-ideas mailing list -- python-ideas@python.org >> To unsubscribe send an email to python-ideas-le...@python.org >> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-ideas@python.org/message/RPD5OICSY3KLVXKIYWFTABNIA7F7YWG3/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > -- > --Guido (mobile) > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/GPCJXBGQYBIT5QYRWUSI3YKU265W4XJY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: disallow assignment to unknown ssl.SSLContext attributes
urllib3 was also burned by this problem https://github.com/urllib3/urllib3/issues/2636 On Fri, Jul 9, 2021, 5:39 PM Thomas Grainger wrote: > > if we find time to implement it for 3.11. > > https://www.python.org/dev/peps/pep-0543/#configuration > was Withdrawn > > would this need a new PEP? > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/VV7ZQVXICCUXOTBZ4LMWA7TAJSGEEF2V/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/MRYEHDRVAUQUTMSJUUNENO7RQ3IGN2L5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: A “big picture” question.
On Fri, 10 Jun 2022 at 21:20, James Johnson wrote: > > The unasked question never gets answered. I don’t know if you can practically > use the following suggestion, but it may be clarifying anyway. > > When an amateur develops code incorrectly, s/he sometimes ends up with a code > object that doesn’t run because of intermediate compiler optimizations. > Got any examples of that happening in Python? ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/V36OLCG6WLCSYP5LNVWELCI75UBTH5PO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] A “big picture” question.
The unasked question never gets answered. I don’t know if you can practically use the following suggestion, but it may be clarifying anyway. When an amateur develops code incorrectly, s/he sometimes ends up with a code object that doesn’t run because of intermediate compiler optimizations. As an example, you could ask a high school class to individually build a 26x26 grid, with the first line having abcdef…xyz; the second line having zabcd…wxy, and so on. This often results in code that has been corrected, but will not run correctly because of pre-mature compiler optimizations. Another task that might illustrate this artifact of program development might be to have amateurs write a function that raises a^b mod x. When programming in a C++ environment, this is monitored by keeping track of “commit charges.” I’m imagining the following solution. Instead of implementing compiler optimizations at every execution, have python run completely interpretive like old Basic. Then introduce a command line switch, that tells python you are ready to employ compiler optimizations. There exists a -O switch; there is also a “compileall,” command, both of which introduce optimizations. It isn’t clear what each does that is different, or how to turn all optimizations off for purposes of testing (usually bad) logic. Would python benefit as a language by introducing a clearer deliberation as to when the “commit charge,” occurs? I ask this only to suggest clarity of thought… it might be impractical to disambiguate them all, after “killing yourselves,” making the language run like a bat out of hell already. Thanks for all you do, James Johnson ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/5IBZCY5Q54BXK7YHB4EY5FY22ZDKOZX4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Null wildcard in de-structuring to ignore remainder and stop iterating
On 09/06/2022 10:28, Paul Moore wrote:
On 09/06/2022 09:50, Paul Moore wrote:
On Thu, 9 Jun 2022 at 01:12, Steve Jorgensen wrote:
My current thinking in response to that is that using islice is a decent
solution except that it's not obvious. You have to jump outside of the thinking
about the destructuring capability and consider what else could be used to
help. Probably, first thing that _would_ come to mind from outside would be
slicing with square brackets, but that would restrict the solution to only
work with sequences and not other iterables and iterators as islice does.
That brings up a tangential idea. Why not allow square-bracket indexing of
generators instead of having to import and utilize islice for that?
Because generators don't have a common (sub-)type, so there's no class
to put the relevant __getitem__ method on.
How so?
>>> def mygen(): yield 42
...
>>> type(mygen())
Sorry, I was assuming the request was for slicing to work for
iterables, not generators. But do we really want to make slicing work
for generators, but still fail for other iterators? That seems like
it'll just cause confusion. Take the OP's original example:
with open("some.file") as f:
for line in f[:10]:
# This fails because f isn't a generator
with open("some.file") as f:
for line in (l for l in f)[:10]:
# This does work because we're slicing a generator
You're bound to get someone (possibly even the OP!!!) asking for the
first version to "just work"...
Also, "obvious" cases like
# How we would do this currently
def get_first_3_current(i):
return list(itertools.islice(i, 3))
# How someone might assume we could do this with the new indexing
def get_first_3(i):
return list(i[:3])
get_first_3(range(10))
get_first_3({1,2,3,4})
get_first_3({"a": "one", "b": "two", "c": "three"})
won't work, and no amount of adding iter() will make them work.
Paul
Well, you can write
for line in f.readlines()[:10]:
But taking the general point:
Yes, it would no doubt cause confusion if some iterators supported
slicing and other's didn't. But it would be a useful feature.
Slicing could be added piecemeal to iterators such as open() according
to demand.
Of course, for non-reusable iterators it would be forbidden to go
backwards (or even remain in the same place):
agen[42]
agen[41]
ValueError: Generator has been used up past the slice point. (Better
wordings are doubtless available.)
I realise this is asking for a lot of work do be done.🙁
Rob Cliffe
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/U2BXTPTME5WBQPPIHEJH5HE5XNGVRSDP/
Code of Conduct: http://python.org/psf/codeofconduct/
