[Python-ideas] Re: Possibility to decorate single code line or code block?
Hi Paul I get a syntax error. The code won't even compile. I don't see how your code can avoid it. Are you sure your example works? $ python3.8 Python 3.8.0 (default, Oct 28 2019, 16:14:01) [GCC 8.3.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> @TimeIt ... time.sleep(1) File "", line 2 time.sleep(1) ^ SyntaxError: invalid syntax By the way, I noticed that python 3.9 implements pep 614, but I don't see how that could allow your example to work. If I've made a stupid mistake, please be kind to me. -- Jonathan -- Jonathan ___ 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/KFO2HBFZPYEQOSJLDJF2OMIBB6TLOTCW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Possibility to decorate single code line or code block?
Hi Christopher I did notice the unusual command line, but didn't think any more of it. I thought everything I needed to look at was already in the message. A reference to https://pypi.org/project/importhook/ would have helped me. I don't see importhook providing a practical implementation of the original poster's request. Going back to that, I don't see why something like a = Timer(time_consuming_function)() shouldn't actually provide the semantics wanted for @Timer a = time_consuming_function() My preference is for code that's easier to read rather than quicker to type. It's said that easy reading is hard writing. https://quoteinvestigator.com/2014/11/05/hard-writing/ I'm also reminded of Einstein's (or is it?) Everything Should Be Made as Simple as Possible, But Not Simpler. https://quoteinvestigator.com/2011/05/13/einstein-simple/ -- Jonathan ___ 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/G7ZG5V3DX62XECP5G7IEVITVPNQCNUO2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: A PEP to encourage people to mind docstrings in stub files
Hi Alexey You wrote that docstring-related software generally fails to handle docstrings properly in stub files. I don't have experience of this, probably because I don't use such software. Please would you provide some examples. Ideal would be issued that have been raised (by you if need be) for such docstring-related software. This would help the people on this list get a better sense of the size and importance of this problem. best regards Jonathan ___ 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/WFVBPUWSR7E2F6C2QK6WK6RUM76KTSA4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Standard tool for iterating over recursive data structures?
Hi I'd say the problem isn't recursion. Here I'm using the definitions given in: https://en.wikipedia.org/wiki/Recursion https://www.cs.utah.edu/~germain/PPS/Topics/recursion.html Rather, it's that the data has a loop (or cycle) in it. A simple example of this is >>> x = [] >>> x.append(x) >>> x [[...]] >>> x[0] is x True So far as I know, it's not possible to create such using only immutable objects. And anything created using only immutable objects will have a hash. A beginner can easily by mistake create an object such as x above, and without the short-circuit provided by >>> x [[...]] the result is an unprintable object, that further raises an exception (or worse). That's really bad for the poor beginner. As a first approximation, my opinion is that data having such a loop / cycle in it is at least a code smell, and perhaps worse. However, there may be examples that I've not considered that would make me change my mind. By the way, in the mathematics of the symmetric group (permutations) the two tuples >>> (0, 1, 2, 3) >>> (1, 2, 3, 0) are different representations of the same cycle (where here the word cycle has a different meaning). Also by the way, determining if two vertex-edge graphs are isomorphic is a hard problem. I've been told that the best tool for this is https://www3.cs.stonybrook.edu/~algorith/implement/nauty/implement.shtml To summarise, it's loops / cycles in the representation of the data that's the problem. Without a use case to the contrary, I'd say don't do this. That's my opinion. Yours may be different. Final idea. Perhaps a tool to detect cycles in data might be a good idea. Finally, Happy New Year. -- Jonathan ___ 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/LPWI7X7RJBWOSMXFQ3VURMADKDSLA5VR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Standard tool for iterating over recursive data structures?
Hi Richard
You suggested
A very simple and in my mind reasonable use for this is to build a
> representation of a graph, where each node is represented by a list (or
> some other collection), and the connections are denoted by adding to
> that collection the nodes that are adjacent (or maybe a tuple of the
> node and the distance). This naturally creates a recursive structure
> unless connections are unidirectional and the graph is acyclical (i.e. a
> tree).
>
> For example, a 3 node fully connected graph might be:
>
> a = []
> b = []
> c = []
>
> a.append(b)
> a.append(c)
> b.append(a)
> b.append(c)
> c.append(a)
> c.append(b)
>
According to https://en.wikipedia.org/wiki/Graph_theory#Graph, a graph is
an ordered pair
>>> G = (V, E)
where V is a set of vertices, and E is a set of edges, where an edge is an
unordered pair of vertices.
You've given the complete graph on 3 vertices (although without explicitly
stating the vertex set V).
https://en.wikipedia.org/wiki/Complete_graph
If we use the wikipedia definition (with vertices 'a', 'b' and 'c') we have
>>> V = {'a', 'b', 'c'}
>>> E = {{'a', 'b'}, {'a', 'c'}, {'b', 'c'}}
I've shown how to represent graphs, by directly translating the
mathematical definition into Python (without introducing any additional
classes). You've produced a different way to represent graphs.
Mathematically, your representation is this. There is a set V of vertices.
Further, for each v in V there is associated a subset V_v of V. Further, if
w in V_v then v in V_w.
I wouldn't call what you've written down the Python representation of this
mathematical definition. To explain this, I'll write down what I think it
should be.
Suppose G is a graph with vertices {'a', 'b', 'c', 'd'}. Using a dict to
represent the map that v goes to V_v, we can write G as
{
'a': {...},
'b': {...},
# etc
'e': {...},
}
My initial post suggests that, purely on the basis of the loop in the data
structure, there's a code smell in the representation you provided. I'd say
that not agreeing with its own mathematical definition is a code smell (or
worse).
I'll put it another way. Suppose our vertices are called (or represent)
Alice, Bob, Carol, Dave and Eve. Now let G be the graph whose edges
represent the existence of cryptographically secure communication between X
and Y. I claim that your code isn't able to represent such a graph.
Thank you Richard for forcing me to think things through and find what I
consider to be a flaw in the code you supplied.
--
Jonathan
___
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/BULYB6UCIDT7IO6PNCEJZOTGVRKP7TWK/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Standard tool for iterating over recursive data structures?
Hi Jeff You wrote: Detecting cycles will involve a lot of bikeshedding. (Sorry, couldn't > resist.) > Indeed. That really brought a smile to my face. Thank you. As I recall, bikeshedding is endless discussion (cycles again) of the COLOUR to paint the bikeshed. And in mathematics there's the topic of https://en.wikipedia.org/wiki/Graph_coloring. By the way, according to wikipedia, the convention of using colors originates from the coloring of the countries of a map, as in the famous https://en.wikipedia.org/wiki/Four_color_theorem. Once again, thank you for your careful attention and sense of humour. -- Jonathan ___ 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/TP6ZIBZCPJL45BEDRTCPASI4MINLSG5M/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Standard tool for iterating over recursive data structures?
Hi Jeff > But you're right, that's a better word for discussing the problem. > Steven's problem data structures are cyclic graphs. I don't agree that such > structures are a sign one is doing something wrong (outside the naive > approach to printing them out). > Thank you for agreeing with me, and nicely disagreeing with me. However, the problem of 'walking a graph' to find a spanning tree is first of all a matter of choosing an algorithm. The algorithm to be used and the representation of the graph are two different matters. Suppose the vertices are well ordered, for example (0, 1, 2, 3, .., n). Write each edge as an ORDERED pair, with the first vertex being less than the second vertex. Now list the edges in lexicographic order. That solves the problem, and gives a unique representation, provided we are given a well ordering of the vertices. Under certain circumstances, we can use the Python id to provide the well ordering of vertices. However, that doesn't always work. Two strings (or large ints, or tuples) can be equal even though they have different ids. However, I think it reasonable to assume that we have a sensible equality relation on the vertices. Now things get interesting. For a very large graph, it would be very helpful if every vertex has a hash. This would make determining equality easier. But if the data structure representing the graph has Python cycles in it (as in Steven's use case) then there won't be a hash available. Do you agree with me, Jeff, that the problem of printing out a vertices-and-edges graph is much easier (or at least quicker) if each vertex has a hash. More exactly, we want a quick and easy way to determine if two vertices are equal. It would be nice to have some further input from Steven, whose original post stated the problem he wished to solve. -- Jonathan ___ 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/3AHIT7CQ6PW4SRIXNFP3UWPFKYO3KDGN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Standard tool for iterating over recursive data structures?
Hi Richard You wrote I believe that one solution to detecting the cycles is to create a set > of the object IDs you have visited and started to print. If you come > across an ID you have already seen, this point is in a cycle. Sets are > fairly compact and intentionally fast to search for an item. > Indeed. But I see a flaw. The problem is that we want to know about EQUALITY of nodes, not equality of the ID (memory address in disguise) at which the node is stored. In other words, as stated earlier, things are easier and quicker if the nodes are hashable. Only hashable objects can be stored in a set, and equality of NODE doesn't imply equality of ID. (The converse is trivially true.) Here's an example >>> def f(): return 10**1000 >>> list(map(id, (f(), f( [139927013695536, 139927013696008] By the way, this surprised me. Would anyone like to explain this? >>> id(f()), id(f()) (139927013695536, 139927013695536) -- Jonathan ___ 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/LTHN7GZYSEXDEMQLXL7UZNHY6Y7XDY5K/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: (Off-topic) Different object, same id
Bravo, Jeff. I couldn't have chosen a better example. However, I'd expect large ints to be stored in two parts. A (class, pointer) pair which has fixed size. And memory referenced by the pointer, large enough to store the value of the large int. However, that's part of the language implementation, and not part of the language definition. -- Jonathan ___ 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/QUWKTXL6B4DJ27ILOPUHT3XB4RG6LK2K/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Off-topic: Happy Birthday, Don Knuth (and Python coroutines)
Hi Don Knuth, author of The Art Of Computer Programming and creator of the TeX typesetting system is 83 today. Happy Birthday Don. Thank you for TeX and everything else. You're warmly invited to join me online to celebrate Don's life and work. The virtual party is on Thursday 14 January, 6:30 to 7:30pm UK time. You'll find the zoom details at (and a goto tribute) at: https://jfine2358.github.io/post/2021/01/10/happy-birthday-don-knuth/ This link also contains a discussion of how merging two binary trees provides a good example of how coroutines can be useful, as in Python's async and wait. with best wishes Jonathan ___ 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/4LEOWCSDSGAOQD2QDUTTDOAVELNWQT4X/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Off-topic: What costs NaN pounds for a null amount?
Hi There's interest here in arithmetic operations on NaN . I've just seen a product listed as costing NaN pounds to buy a null amount. That was written as £NaN/null. The bargain item is Glade Shake & Vacuum Citrus, and you can see it at https://www.tesco.com/groceries/en-GB/products/253732570 Searching on this site for 'NaN' brings up many entries for https://en.wikipedia.org/wiki/Naan bread. with best regards Jonathan ___ 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/FIP7EUZ3E3KNCCK7XVWAS3GJY6KMX6C2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Itertools generator injection
Hi I see two issues. The first is present behaviour. The second is alternative ways of ordering the elements of a Cartesian product. Here's an example of the present behaviour. >>> iter_range = iter(range(100)) >>> prod = itertools.product(iter_range, "abcdef") >>> next(iter_range) Traceback (most recent call last): File "", line 1, in StopIteration It's not what I expected before I read this thread, and it is what I expected after I read this thread. I regard it as a bug. I expect iterators to be lazy rather than greedy when consuming input. This helps make for efficient and non-blocking pipelines. I see no reason for the product to consume any items until it has been asked to yield a member of the product. The second issue is that there are at least three sensible ways to iterate a Cartesian product. The itertools.product function is, as said in the docs, equivalent to nested for loops. On ordered input it's equivalent to lexicographic ordering. The squares on a chessboard are labelled a1, a2, a3, b1, b2, b3, ... , g7, g8 (using lexicographic order. There are as many fractions as there are counting numbers. The usual way to prove this is to order unsimplified fractions p/q via the TRIPLE (p + q, p, q). This gives a diagonal ordering. The third order is via subsquares. In other words order via the TRIPLE (max(p,q), p, q). I suggest on the basis of batteries included that all three methods be included in itertools, perhaps with names lexicproduct, diagproduct and maxproduct. Finally, product is a synonym for lexicproduct. This allows the programmer to say without writing a comment that they've considered the alternatives and chosen the function also known as product. with best regards Jonathan ___ 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/SF3X2LJE7BWVECW5NQRVQI3XZU7PRBLN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding syntax for the empty set
In August 2020, in the context of PEP 472 I suggested
>>> {-}
for the empty set literal. At present the closest we can do for an empty
set literal is
>>> {0} - {0}
set()
The context for this is whether PEP 472 should make
>>> something[]
a syntax error. If we do then, what about the workarounds
>>> something[*argv]
>>> something[**kwargs]
which so to speak convert the syntax error to a run-time error.
Because
>>> something[]
was ugly and easily misunderstood I suggested
>>> something[-]
and hence
>>> {-}
as new syntax.
The thread from August 2020 can be found (with >>> prompts as quotes) at
https://mail.python.org/archives/list/python-ideas@python.org/thread/2QANGFBMGUSCYOLU3GJ6AOGV6Q2ATC72/#QOBONXUPUMC3ULCGJU6FVHOCIZQDT45W
--
Jonathan
___
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/TEZUX6EMOLZBMN6GYJC5J5J5KR2QGTOT/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: String comprehension
Hi David
I see where you are coming from. I find it helps to think of sep.join as a
special case. Here's a more general join, with sep.join equivalent to
genjoin(sep, '', '').
def genjoin(sep, left, right):
def fn(items):
return left + sep.join(items) + right
return fn
Here's how it works
genjoin('', '', '')('0123') == '0123'
genjoin(',', '', '')('0123') == '0,1,2,3'
genjoin(',', '[', ']')('0123') == '[0,1,2,3]'
All of these examples of genjoin can be thought of as string
comprehensions. But they don't fit into your pattern for a string
comprehension literal.
By the way, one might want something even more general. Sometimes one wants
a fn such that
fn('') == '[]'
fn('0') == '[0,]'
fn('01') == '[0,1,]'
which is again a string comprehension.
I hope this helps.
--
Jonathan
___
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/PFWPDN2XA4VK3K6TALKU4TWRXSML65P5/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: String comprehension
On Fri, Apr 30, 2021 at 6:00 PM Chris Angelico wrote:
For those cases where you're merging literal parts and generated
> parts, it may be of value to use an f-string:
>
> >>> f"[{','.join('0123')}]"
> '[0,1,2,3]'
>
> The part in the braces is evaluated as Python code, and the rest is
> simple literals.
>
For readability, reuse and testing I think it often helps to have a
function (whose name is meaningful). We can get this via
as_list_int_literal = gensep(',', '[', ']')
It would also be nice to allow as_list_int_literal to have a docstring
(which could also be used for testing).
I accept that in some cases Chris's ingenious construction has benefits.
--
Jonathan
___
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/UVTLPOK4S663GIMSTUWBDMFSFHUEYHGJ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: String comprehension
Summary: The argument in list(arg) must be iterable. The argument in str(arg) can be anything. Further, in [ a, b, c, d ] the content of the literal must be read by the Python parser as a Python expression. But in "this and that" the content need not be a Python expression. Hi David I find your suggestion a good one, in that to respond to it properly requires a good understanding of Python. This deepens our understanding of the language. I'm going to follow on from a contribution from Brendan Barnwell. Please consider the following examples Similarity. >>> list( x*x for x in range(5) ) [0, 1, 4, 9, 16] >>> [ x*x for x in range(5) ] [0, 1, 4, 9, 16] Difference. >>> tmp = (x*x for x in range(5)) ; list(tmp) [0, 1, 4, 9, 16] >>> tmp = (x*x for x in range(5)) ; [ tmp ] [ at 0x7fec02319678>] Difference. >>> list( (x*x for x in range(5)) ) [0, 1, 4, 9, 16] >>> [ (x*x for x in range(5)) ] [ at 0x7fec02319620>] Now consider , >>> str( x * 2 for x in 'abc' ) ' at 0x7fec02319728>' This last one genuinely surprised me. I was expecting 'aabbcc'. To understand this, first note the quote marks in the response. Next recall that str returns the string representation of the argument, via type(obj).__str__(obj). My understanding of the situation is that the list comprehension [ x*x for x in range(5) ] is a shorthand for list( x*x for x in range(5) ). It works because list takes an iterable as its argument (if it has one argument). But str with one argument gives the string representation of an arbitrary object. Here's an example. >>> list(None) TypeError: 'NoneType' object is not iterable >>> str(None) 'None' Here's what Brendan wrote: The difference between your proposal and existing comprehensions is that strings are very different from lists, dicts, sets, and generators (which are the things we currently have comprehensions for). The syntax for those objects is Python syntax, which is strict and can include expressions that have meaning that is interpreted by Python. But strings can contain *anything*, and in general (apart from f-strings) their content is not parsed by Python. In a nutshell: The argument in list(arg) must be iterable. The argument in str(arg) can be anything. Further, in [ a, b, c, d ] the content of the literal must be a Python expression, whereas in "this and that" the content need not be a Python expression. I hope this helps. Jonathan ___ 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/HEORJVBWNK4TFRMFXPTLEHGWG6FDVPSM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] OT: Accessibility: Jana Schroeder's Holman Prize Application
Perhaps Off Topic, but for a good cause. This year I met Jana Scroeder, a blind person forced to change jobs as part of the social cost of Covid. Her outsider experience of computer coding training became a wish to make things better. She has applied for a Holman Prize ($25,000 over a year) to fund this. She's also set up a survey to reach and know better those with similar wishes. One simple way to help open to many is to volunteer to be a sighted helper for a code and math variant of BeMyEyes.org. I encourage you to listen to Jana's pitch for a Holman prize, and if you want to help complete the survey (whether you're blind or sighted, code or math, young or old). I've learnt a lot about accessibility from Jana. *Jana Schroeder's Holman pitch* (90 seconds): https://www.youtube.com/watch?v=3ywl5d162vU *Jana Schroeder's survey* (15 minutes): https://tinyurl.com/blindcodersurvey Finally, *The Holman Prize*: https://holman.lighthouse-sf.org/ best regards Jonathan ___ 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/J67MRND6SQMPXTRNSJMSD2ZKGNEELKVJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: division of integers should result in fractions not floats
Martin wrote: when dividing two integers, the result is a float, which means we > immediately lose precision. This is not good if you want to use code which > supports higher precision. I am of course in favour of keeping precision, if there is no cost. But here there is a cost. Arbitrary precision arithmetic (and roots) uses more memory and takes longer. Therefore, the system must allow the programmer to choice what's wanted (either explicitly or implicitly). Python has been set up to make 1/3 evaluate to a float (an implicit choice), and have Fraction(1, 3) be a fraction (an explicit choice). I don't think it fair to say that this decision is "not good". Rather, it's good for some use cases and not so good for others. On balance, I'm happy with that decision. That said, as a pure mathematician who does integer calculations, I'd like numpy to have better capabilities for integer linear algebra. I hope Martin that you agree with me, that this change would not be an improvement for everyone. -- Jonathan ___ 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/HJXX2MYDP32PYJGJMTCPYLHL47ZF35BV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: division of integers should result in fractions not floats
Hi Martin I think it important to realise there are at least two issues. The first is whether sometimes fraction is better than float, and vice versa. The second is whether the default behaviour for int / int should be changed. A third issue is whether some of the benefits you are seeking can be achieved in some other way. Finally, well done for changing the Python source to implement your idea. That's something I wouldn't have the courage to do. -- Jonathan ___ 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/EBWTTLAPUBUDFGYYVCQZOBSMOS7SXJMD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: division of integers should result in fractions not floats
Martin wrote So, if you show them (the following is fake) > > >>> 1/2 + 1/3 > 5/6 > 1 / 2 + 1 / 3 > 0.83 > > They will immediately spot what's going on. > I'm sighted. I can see the difference. I suspect a blind person using a screen reader would struggle a lot to spot the difference. (I don't know enough about screen readers to be sure.) -- Jonathan ___ 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/XYI6GUEN3IQUGG24ABO4Q4R677SGM3SL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: division of integers should result in fractions not floats
Martin wrote: In general, doing symbolic math in Python is not very beautiful. I think this is a problem worth investigating. (Disclaimer: I do research in pure mathematics.) > The number of hoops you have to jump through is large, mostly because > syntax is abused for things it was not actually meant for. > I don't completely agree with this diagnosis. I think there are more serious difficulties. I'd be interested in a discussion on symbolic math in Python sometime, but perhaps not on this list. I'd like the people who use and develop https://www.sagemath.org/ to be involved. -- Jonathan ___ 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/SVTZM6OISSEJ7737WER5I6K4UNGMYYVR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: symbolic math in Python
Martin wrote: as you might have noticed, I am trying to improve the syntax and semantics > for symbolic math in Python. Until now, I have to say, my ideas were not > that well received, but I learned from the discussion and maybe this time I > come up with something people like. > For about 10 years I've used PARI/gp for computer algebra, mainly for integer linear algebra and polynomials. One day I might use its number theory features. http://pari.math.u-bordeaux.fr/ Lately it's acquired good Python bindings, and most likely for my next project I'll start using them. https://pari.math.u-bordeaux.fr/Events/PARI2019/talks/jeroen.html https://pypi.org/project/cypari2/ https://cypari2.readthedocs.io/en/latest/ Regarding semantics, I'm very happy to go along with PARI/gp. This is in part because of its deep roots in computational number theory and the community it has around it. See also: Integer Factorization Software: PARI/GP, Mathematica, and SymPy https://dzone.com/articles/integer-factorization-software-parigp-mathematica Regarding syntax, I'd be pleased to see a paritools package that makes it easier to use the cypari2 bindings for common purposes. This perhaps could become part of sympy. It's also worth looking at sage. https://doc.sagemath.org/html/en/reference/libs/sage/libs/pari.html This is what I would like. Other people will most likely have different wishes for improving symbolic math in Python. -- Jonathan ___ 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/EOOMLHOIY66OM453SAKQKAPFVXYE5MLY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] SEMANTICS for 'variables' produced by a decorator
There's been a discussion in this list on extending Python to provide
SYNTAX such as
@decorator
name = EXPRESSION
and also suitable semantics. (Here 'name' is an identifier, in the
discussion called a 'variable'.)
This post is about providing SEMANTICS for such decorator syntax. We can do
this within the existing Python syntax for decorators.
Recall that
@decorator
def fn():
# body
is usually equivalent to
def fn():
# body
fn = decorator(fn)
and that decorator is just a callable that returns something. It need not
return another function. It could return a 'variable', such as the result
of calling fn.
Here's a proof of concept. Consider the following
BEGIN
$ cat work.py
from collections import namedtuple
Locn = namedtuple('Locn', 'doc module name')
def locn_from_fn(fn):
name = fn.__name__
module = fn.__module__
doc = fn.__doc__
return Locn(name=name, module=module, doc=doc)
def decovar(fn):
locn = locn_from_fn(fn)
return fn(locn)
@decovar
def variable(locn):
return ('value', locn)
def deconamedtuple(fn):
locn = locn_from_fn(fn)
nt = namedtuple(locn.name, fn())
nt.__doc__ = locn.doc
nt.__module__ = locn.module
nt.__name__ = locn.name
return nt
@deconamedtuple
def Point():
'''Return a point (x, y) in the plane.'''
return 'x y'
print(variable)
print(Point)
print(Point.__doc__)
END
Here's what we get when we run the script.
BEGIN
$ python3 work.py
('value', Locn(doc=None, module='__main__', name='variable'))
Return a point (x, y) in the plane.
END
It should now be clear that this approach allows us to pass much useful
information to the decorator.
I claim that this approach gives most or all of the semantic benefits of
'decorators on variables', and within the current Python syntax. If so, and
the semantic benefits are strong, then here's part of a good case for
extending the syntax in a future version of Python.
--
Jonathan
___
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/QJACDY45QEAIY5XTXGBQBGXGOLWRJK3U/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: dict.sort()?
On Sat, May 29, 2021 at 6:01 PM Chris Angelico > But if you're okay with constructing a new dict, you can do this: > > d = dict(sorted(d.items(), key=lambda kv: ...)) > Or to keep the same dict (not tested) tmp = list(sorted(d.items())) d.clear() d.update(tmp) -- Jonathan ___ 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/SN75Q4U5PPSMAKTMHBTPRXL4K24NHUN6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: The name Ellipsis should be a constant
We have the following. >>> 12 = True SyntaxError: can't assign to literal >>> True = False SyntaxError: can't assign to keyword >>> ... = False SyntaxError: can't assign to Ellipsis We also have (works better in monospaced font) >>> d[] = True d[] = True ^ SyntaxError: invalid syntax Beginners might appreciate having instead as error messages: SyntaxError: can't assign to literal: 12 SyntaxError: can't assign to keyword: True SyntaxError: can't assign to literal: ... -- Jonathan ___ 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/4SHBUENP7TAMXZVN6VK26I6MXWXFBKJM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Off topic: Rational discursive thought and helping others
Off-topic Someone on this list wrote: Mu. > > https://en.wikipedia.org/wiki/Mu_(negative)#%22Unasking%22_the_question This is a koan, a device in Zen Buddhism used by a teacher to help the student liberate themselves from being imprisoned by rational discursive thought. Here is another koan. A Zen student told Ummon: "Brilliancy of Buddha illuminates the whole universe." Before he finished the phrase Ummon asked: "You are reciting another's poem, are you not?" "Yes," answered the student. "You are sidetracked," said Ummon. Here's my commentary. The teacher neither agrees or disagrees with the student's statement. This is "Mu" if you wish. Instead the teacher directly observes the student's mental processes, confirms the observation, and provides helpful advice. The teacher is not trapped by rational discursive thought. Here the teacher uses only 12 words. Sometimes a teacher uses a single word, or no words at all. You'll find this koan and further commentary at https://www.sacred-texts.com/bud/glg/glg39.htm. -- Jonathan ___ 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/4BB6H5IDADCFOBWQTPDG7442P2DXWYRI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: disallow assignment to unknown ssl.SSLContext attributes
Thank you Thomas for concisely and fairly reporting your experience, and based on that suggesting a way to improve Python. Thank you for taking the time to do this. Here's a typo that caused a bug (which inconvenienced the original poster): context.miunimum_version = ssl.TLSVersion.TLSv1_3 > context.minimum_version = ssl.TLSVersion.TLSv1_3 > Here's the fix the original poster suggested: I'd like invalid attribute assignment to be prevented at runtime > This can already be done, if type(context) is defined using __slots__. However, a search in the docs for slots is not so helpful. https://docs.python.org/3/search.html?q=slots Some of the better search results (for the question asked) seem to be: https://docs.python.org/3/reference/datamodel.html?highlight=slots#object.__slots__ https://docs.python.org/3/reference/datamodel.html?highlight=slots https://docs.python.org/3/howto/descriptor.html?highlight=slots I see two ideas here. One idea is to improve the documentation for __slots__, and perhaps provide tools that make it easier to create a class that uses slots. Here's a challenge. Find a page in docs.python.org that describes clearly, with helpful examples, when and how to use __slots__. The second idea, which the OP asks for, is a change to type(context) in the standard library ssl module. Here note: https://docs.python.org/3/library/ssl.html Warning Don’t use this module without reading the Security considerations. Doing so may lead to a false sense of security, as the default settings of the ssl module are not necessarily appropriate for your application. Given that context is important for security, perhaps it's worthwhile closing the door to spelling errors creating security holes. -- Jonathan ___ 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/4GJKWUMWJNEW2CEWUXCTXCQM7VDTK3YW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: disallow assignment to unknown ssl.SSLContext attributes
It may help to think separately about existing code using ssl, and about new code. However, I'm not a user of ssl, so please doubt my opinions below. EXISTING CODE Those maintaining existing code might welcome an easy way of checking that the code doesn't have a misleading assignment. They might also appreciate a quick fix, such as using a subclass of type(context) that does have __slots__. (Such devices might not work well with all existing code.) NEW CODE Those creating new code might appreciate a new API that has been redesigned to simplify the interface and better support security audits. For example: >>> context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER) >>> context Perhaps better is that type(context).__repr__ show the attributes of the context object (and anything inherited from the parent class). BITWISE OPERATIONS Also, the sample code (in docs ssl.html) ctx = ssl.create_default_context(Purpose.CLIENT_AUTH) ctx.options &= ~ssl.OP_NO_SSLv3 contains bitwise operations whose meaning requires some thought. -- Jonathan ___ 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/E5JEVSXRNDZF3AUH7XZZ5XXXJE4JNIDU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: disallow assignment to unknown ssl.SSLContext attributes
Thomas Grainger wrote: It looks like there's a consensus being reached, should I create a bpo? > Perhaps first state what seems to be the consensus and invite further comments before going to bpo. Disclaimer: I'd like to see both: 1. Something on PyPi to help persons who are using ssl on current Python. 2. Something in a future version of Python, that constrains attribute access. We can do (1) first, and it will help inform (2). -- Jonathan ___ 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/UYKZW3RPS6NUKJYMXSJ3ZCONDR5QW3AO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: CACHEDIR.TAG for __pycache__ on Linux
Hi Leon (and Bryan) Here's some comments on your interesting suggestion. Bryan Ford's CACHEDIR.TAG proposal is supported by gnu tar. See: https://www.gnu.org/software/tar/manual/html_node/exclude.html By the way, I've copied Bryan. There's a cachedir_tag module on PyPi, by Alex Willmer: https://pypi.org/project/cachedir-tag/ This search shows some other systems use or think of using CACHEDIR.TAG. https://www.google.com/search?q=CACHEDIR.TAG Other than tar, I don't see any Linux / GNU tools that use CACHEDIR.TAG. Further, in 2004 Bryan Ford opened a Mozilla request to use CACHEDIR.TAG. This was closed in 2014 as WONTFIX. This discussion is useful. https://bugzilla.mozilla.org/show_bug.cgi?id=252179 The change requested is small. However, it implies an endorsement of Bryan Ford's elegant and well presented idea, which is a much larger matter. Rather than saying NO, perhaps a discussion of ALL the problems involved in __pycache__ might be better. Here's one that interests me. How do we efficiently and elegantly support __pycache__ on read-only file systems? A leading example is Ubuntu's: https://en.wikipedia.org/wiki/Snap_(package_manager) For example, on my Ubuntu PC there's a read-only folder that contains __pycache__ folders. /snap/core/11187/usr/lib/python3/dist-packages/ Suppose we want to use the version 11187 dist_packages with multiple versions of Python? We're stymied, unless we know the Python versions prior to creating (or mounting) the read-only file system. By the way, on my Ubuntu PC all the /snap folders are in fact mounted SquashFS images. These images are stored in: /var/lib/snapd/snaps/ Thus, there's little reason to archive / backup the /snap folder. It's /var/lib/snapd/snaps that needs backing up. Finally, Bryan Ford has a focus on systems security. The architecture of Ubuntu's snap architecture seems to reduce the attack surface, although there's more work to be done: https://snapcraft.io/blog/where-eagles-snap-snap-security-overview https://en.wikipedia.org/wiki/Snap_(package_manager)#Configurable_sandbox I hope this helps. -- Jonathan ___ 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/CLF5VFPKSZAYJO7D27DUEHHBE64VZHKE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: writelines2?
The interactive help message for writelines gives no help. I've made an
enhancement request to b.p.o.
help(open('/dev/zero').writelines) gives no help
https://bugs.python.org/issue44623
Please take a look.
--
Jonathan
___
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/6K7TGQHWO6SE3TWRAZ7AK5H6O372W77T/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: writelines2?
Thank you Paul. I used my default Python, which is Python 3.6. However, with 3.7 and 3.8 I get the same as you. I've promoted you 'works for me' on b.p.o to 'not a bug'. Thank you again. -- Jonathan ___ 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/JHKRK324CEKH5DPMLU5QCNAW7TFBIXS4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: New 'How to Write a Good Bug Report' Article for Docs
Jonathan Goble wrote: > Is there a reason why we can't just link to the Wayback Machine copy like > you did here? > I agree with that as immediate first aid. It seems that wikipedia practice now is to link to both the original article and to a copy on the wayback machine. I've found some perhaps useful pages by searching for "Bug report writing guidelines" (with quotes). http://www.jieranqiche.com/developer/docs/mozilla/qa/bug_writing_guidelines/ https://github-wiki-see.page/m/deegree/deegree3/wiki/Bug-Report-writing-Guidelines https://github.com/deegree/deegree3/wiki/Bug-Report-writing-Guidelines It might be helpful to provide links to some well-written bug reports, and perhaps some that could do better. with best regards Jonathan ___ 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/LUIKU4OAQ4UMPKVLYHQ6GO3WLEDKO2RY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Addition of a "plus-minus" binary numeric operator
Hi Yahbai
You might wish to reconsider your proposal in light of existing behaviour
>>> 1+-1
0
Consider also your proposed
>>> a, b = 2 +- 1
We know that {a, b} = {1, 3}. But which is which?
In your use case you might be better off introducing a custom type
>>> lims = pm(2, 1)
>>> lims.lo, lims.hi
(1, 3)
I hope this helps you with your code.
best wishes
Jonathan
___
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/OVQIDTIY6BCSGPYCWEEZEROZKFOUXJSK/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: def variable = value
>From my phone. An important thing about def x and class A is that the strings x and A are made available to the constructor for x and A respectively. The same is not true for x=val. Jonathan ___ 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/GMUQMIGOHZGXF5VA6DG5SBM7WQRQBF7O/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: def variable = value
Hi Serhiy Thank you for so clearly explaining how names get passed to function and class constructors. You also wrote: > We do not have generalized way to call arbitrary constructor with > automatically passing __name__, __qualname__ and __module__. And it would > be convenient. > > create namedtuple Point(x, y, z=0) > [further examples snipped] We can already do something similar by writing (not tested) class Point(Hack): namedtuple = lambda x, y, z=0: None provided Hack has a suitable value. I don't see a way to do much better than this, without introducing a new language keyword. For example allow signature(x, y, z=0) to be an EXPRESSION that returns a function signature. By the way, class Point(Hack): def namedtuple(x, y, z=0): pass gives a syntax error at 'def'. -- Jonathan ___ 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/CRSD2XZXJTRD4VNPRAUAFPKBELMA2FG3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults
Hi Please forgive me if it's not already been considered. Is the following valid syntax, and if so what's the semantics? Here it is: def puzzle(*, a=>b+1, b=>a+1): return a, b Aside: In a functional programming language a = b + 1 b = a + 1 would be a syntax (or at least compile time) error. -- Jonathan ___ 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/3WHUCMGLKATS3NF7F2LAXIWQUUZ732CK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults
Hi Chris You wrote: In fact, on subsequent consideration, I'm inclining more strongly > towards SyntaxError, due to the difficulty of explaining the actual > semantics. Changing the PEP accordingly. Your PEP, so your choice. I now think that if implemented, your PEP adds to the Python compiler (and also runtime?) tools for detecting and well-ordering Directed Acyclic Graphs (DAG). Here's another problem. Suppose def puzzle (*, a=>..., z>=...) gives rise to a directed acyclic graph, and all the initialisation functions consume and use a value from a counter. The semantics of puzzle will now depend on the linearization you choose for the DAG. (This consumption and use of the value from a counter could be internal to the initialisation function.) -- Jonathan ___ 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/JTEA6K6LSDABWKPMGNZSADDENI33VZQC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] PEP 671 proof-of-concept: A less invasive implementation
Hi
One of the motives for PEP 671 is that the signature of a function fn, and
hence the associated help(fn) is sometimes opaque regarding default values.
I won't repeat the excellent examples already given.
In the current implementation default values are handled outside the
compiled code of the function, which is available at fn.__code__. Instead
they are stored in 'metadata' associated with the function.
Here's one way to see this.
from inspect import signature as sig
def fn(a, b=1, c=2): return a, b, c
sig(fn) # Gives
fn.__defaults__ = ('hi', 'there')
sig(fn) # Gives
We can also change the __code__ object, but care is needed here.
def gn(): return (1, 2, 3)
fn.__code__ = gn.__code__
fn() # Gives (1, 2, 3).
sig(fn) # Gives
fn.__defaults__ # Gives ('hi', 'there')
The signature of fn, together with the arguments actually supplied, is used
to initialise the code frame which is put on the top of the stack, and in
which fn.__code__ executes.
I suggest that an implementation which provides additional flexibility in
the manner in which the code frame is initialised would be less invasive.
Necessarily, PEP 671 allows programmer supplied code to be used in the
'initialisation phase'. The previous attempts place that code in
fn.__code__.
I suggest that the implementation adds a new attribute fn.__wibble__ to fn,
which can either be None or a code object. And if fn.__wibble__ is not
None, then it is used to initialise the code frame in which fn.__code__
executes. It would as before take as input the arguments actually supplied
by the user.
I stop here, saying nothing for now about two important questions. First,
what is the programmer syntax for creating such a 'two-part' function fn.
Second, what does the user see as a result of help(fn). Or in other words,
how to extend the semantics of inspect.signature.
with kind regards
Jonathan
___
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/H6NXL3WWHNMD3I32YPYZC32IHXEQWHTT/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 proof-of-concept: A less invasive implementation
Hi Chris I like your questions. You ask: How would fn.__wibble__ be different from checks at the top of fn.__code__? They'd be in two different code blocks. I see a function call going as follows. 1. Process the supplied arguments in the usual way. 2. Create a new frame object and place it on the stack. 3. In that new frame execute fn.__wibble. 4. When fn.__wibble__ is done, execute fn.__code__ IN THE SAME FRAME. I think step 4 is a tail call, as in https://en.wikipedia.org/wiki/Tail_call, which includes the concept of tail recursion. Your other question is: And, seeing something in help(fn) largely necessitates that the source code be retained. Yes, this is true whatever syntax is used. In help(fn) inspect.signature repr() is used to produce help text. There's no extra storage overhead for that. Both your implementation and mine will require source text to be stored (unless the module is compiled as optimised). Oh, but I've made a mistake. If the module is compiled non-optimised then the compile code contains points to the source file. These are used in traceback when an exception occurs. I'm not to say at this point which approach is best for the person who reads help(fn), except the lawyer's answer "it just depends". At this point my focus is on designing a less invasive implementation. Your good questions have led me to rethink. The tail call in my proposed implementation can be removed and then fn.__wibble__ would not be needed. It would be the same as checks at the top of fn.__code__. But instead of fn.__wibble__ we have a pointer (as in fn.__code__) to some location in the body of fn. (Or as fn.__code__ is already well equipped with pointers, we equip fn with a pointer to one of these pointers.) So all that's required now is 1. A syntax in source files that allows the author of fn to specify the end of the 'preamble extra help' in the body of fn. 2. An addition to help(fn) that provides the 'preamble' of fn as an extra help message. with kind regards Jonathan ___ 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/TKV7LIEXBICK3SHMLENYY5YX3IAMVODG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 proof-of-concept: A less invasive implementation
Hi I've just had a brainwave that may give an even less invasive implementation of PEP 671. It relies on every function having a dict, as provided by https://www.python.org/dev/peps/pep-0232/. Consider: def fn(a, b, c): pass fn.__wibble__ = 123 fn.__wibble__ # Give 123, of course. Now consider: @wibble def fn(a, b, c=None): '''Usual docstring goes here.''' if c is None: c = [] '#wibble' return c.extend([a, b]) The @wibble decorator sets fn.__wibble__ to point to the end of the line just before '#wibble'. We can now define Help(fn) to produce something like: fn(a, b, c=None) Usual docstring goes here. -- if c is None: c = [] There we go. The functionality asked for, in a way that works with existing Python. If nothing else, we can use this for experiments to explore the idea. Often in Python there are functions whose source is self-explanatory. Example: @wibble def fahr_to_cent(fahr): return (fahr - 32) * 5 /9 '#wibble' And now for Help(fahr_to_cent) we get: fahr_to_cent(fahr) -- return (fahr - 32) * 5 /9 Final word. Does anyone use PEP 232, function attributes? If not, perhaps remove it as a waste of space. with kind regards Jonathan ___ 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/JHZVHUXV4EU57HHPBVU2EL2U33BIZ2DG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 proof-of-concept: A less invasive implementation
Hi Chris Again you ask good questions. Q: How to find the bare string '#wibble'? It's optimised out during compilation. A: Very good. I didn't know that. For current Python we'll have to use a different marker. For future Python we could change the compiler so that it directly sets fn.__wibble__ without needing the @wibble decorator. Q: You have at least added some source code to help(fn), if it's available. But what if the function came from a .pyc file? A: It will work the same as tracebacks work, and in exactly the same circumstances. I think that's exactly what we want. Any other solution would increase the size of .pyo files, which is to be avoided. Thank you for your interest. I hope this helps. -- Jonathan ___ 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/YDAKBG553PE4RIVZ3NRFQ46OU3LMEKLC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Compiler from python to WebAssembly
Hi Ricard Python to web assembly is a good idea that is already being developed. The first result from this search https://www.google.com/search?q=python+webassembly is the project https://github.com/pyodide/pyodide. Also relevant is https://www.theregister.com/2021/11/30/python_web_wasm/ You loved running JavaScript in your web browser. Now, get ready for Python scripting with kind regards Jonathan ___ 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/QVZKTTPXSOBAFYHONS5YLJXHWMMQ5WG3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Revisiting a frozenset display literal
Summary: Further information is provided, which suggests that it may be
best to amend Python so that "frozenset({1, 2, 3})" is the literal for
eval("frozenset({1, 2, 3})").
Steve D'Aprano correctly notes that the bytecode generated by the expression
x in {1, 2 ,3}
is apparently not optimal. He then argues that introducing a frozenset
literal would allow
x in f{1, 2, 3} # New syntax, giving a frozenset literal
would allow better bytecode to be generated.
However, the following has the same semantics as "x in {1, 2, 3}" and
perhaps gives optimal bytecode.
>>> import dis
>>> dis.dis("x in (1, 2, 3)")
1 0 LOAD_NAME0 (x)
2 LOAD_CONST 3 ((1, 2, 3))
4 COMPARE_OP 6 (in)
6 RETURN_VALUE
For comparison, here's the bytecode Steve correctly notes is apparently not
optimal.
>>> dis.dis("x in {1, 2, 3}")
1 0 LOAD_NAME0 (x)
2 LOAD_CONST 3 (frozenset({1, 2, 3}))
4 COMPARE_OP 6 (in)
6 RETURN_VALUE
Steve states that "x in {1, 2, 3}" when executed calls "frozenset({1, 2,
3})", and in particular looks up "frozenset" in builtins and literals.
I can see why he says that, but I've done an experiment that suggests
otherwise.
>>> bc = compile("x in {1, 2, 3}", "filename", "eval")
>>> eval(bc, dict(x=1))
True
>>> eval(bc, dict(x=1, frozenset="dne"))
True
I suspect that if you look up in the C-source for Python, you'll find that
dis.dis ends up using
frozenset({1, 2, 3})
as the literal for representing the result of evaluating frozenset({1, 2,
3}).
The following is evidence for this hypothesis:
>>> frozenset({1, 2, 3})
frozenset({1, 2, 3})
>>> set({1, 2, 3})
{1, 2, 3}
>>> set([1, 2, 3])
{1, 2, 3}
>>> set([])
set()
To conclude, I find it plausible that:
1. The bytecode generated by "x in {1, 2, 3}" is already optimal.
2. Python already uses "frozenset({1, 2, 3})" as the literal representation
of a frozenset.
Steve in his original post mentioned the issue
https://bugs.python.org/issue46393, authored by Terry Reedy. Steve rightly
comments on that issue that "may have been shadowed, or builtins
monkey-patched, so we cannot know what frozenset({1, 2, 3}) will return
until runtime."
Steve's quite right about this shadowing problem. In light of my plausible
conclusions I suggest his goal of a frozenset literal might be better
achieved by making 'frozenset' a keyword, much as None and True and False
are already keywords.
>>> True = False
File "", line 1
SyntaxError: can't assign to keyword
Once this is done we can then use
frozenset({1, 2, 3})
as the literal for a frozenset, not only in dis.dis and repr and elsewhere,
but also in source code.
As a rough suggestion, something like
from __future__ import literal_constructors_as_keywords
would prevent monkey-patching of set, frozenset, int and so forth (just as
True cannot be monkeypatched).
I thank Steve for bringing this interesting question to our attention, for
his earlier work on the issue, and for sharing his current thoughts on this
matter. It's also worth looking at the message for Gregory Smith that Steve
referenced in his original post.
https://mail.python.org/pipermail/python-ideas/2018-July/051902.html
Gregory wrote: frozenset is not the only base type that lacks a literals
leading to loading values into these types involving creation of an
intermediate throwaway object: bytearray. bytearray(b'short lived bytes
object')
I hope this helps.
--
Jonathan
___
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/KKUZCKB4L5AZJWFLEYZ44IHBXQBRUHJC/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Revisiting a frozenset display literal
The compiler can figure out that the value of
{1, 2, 3}
is a set containing the elements 1, 2 and 3.
The problem with the value of
frozenset({1, 2, 3})
is that the value of frozenset depends on the context. This is because
frozenset = print
is allowed.
According to help(repr):
repr(obj, /)
Return the canonical string representation of the object.
For many object types, including most builtins, eval(repr(obj)) ==
obj.
Consistency suggests that if
x = f{1, 2, 3}
gives always gives frozenset as the value of x then
repr(x)
should be the string 'f{1, 2, 3}'. At present, I think, repr(x) always
returns a literal if it can.
However, changing the repr of frozenset introduces problems of backwards
compatibility, particularly in doctests and documentation.
Another way to achieve consistency is to make frozenset a keyword, in the
same way that None, True and False are identifiers that are also language
keywords.
Both proposals as stated have negative side-effects. I suggest we explore
ways of reducing the above and any other side effects.
--
Jonathan
___
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/L3TVX5Z52DGOPV4LUUB2GNIW7IVLK3IG/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Revisiting a frozenset display literal
Earlier today in https://bugs.python.org/issue46393, Serhiy Storchaka wrote:
As Steven have noted the compiler-time optimization is not applicable here
because name frozenset is resolved at run-time.
In these cases where a set of constants can be replaced with a frozenset of
constants (in "x in {1,2,3}" and in "for x in {1,2,3}") the compiler does
it.
And I don't think there is an issue which is worth changing the language.
Creating a frozenset of constants is pretty rare, and it is even more rare
in tight loops. The most common cases (which are pretty rare anyway) are
already covered.
--
Jonathan
___
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/7WVR2TY6PQQ6H4EG2JCAJGWPS42D57BF/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Revisiting a frozenset display literal
Joao's
{1, 2, 3}.frozen()
shows real originality, arising from deep creative thought about the roots
of the problem. I was both surprised and delighted when I saw it, and I
think some others were too. (I agree with others that here 'freeze' is
better than 'frozen'.)
Obviously, each of the two proposals
f{1, 2, 3}
{1, 2, 3}.freeze()
has advantages and disadvantages when compared to the other.
Both deserve full and fair consideration.
--
Jonathan
___
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/THJCZLVTTQHHTHOGEHADEUYHKBGZK3IX/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Revisiting a frozenset display literal
Hi
Steve D'Aprano started this thread on 16 Jan, referencing
https://bugs.python.org/issue46393.
In the 95th message in this thread, on 27 Jan, Stephen J. Turnbull wrote:
I think for many of us (specifically me, but I don't think I'm alone) it's
> equally important that we aren't persuaded that there's a need for a
> frozenset literal great enough to overcome the normal reluctance
> to add syntax. A number of important cases are already optimized
> to frozensets, and use cases and (more important) benchmarks showing
> that this optimization is important enough to add syntax so the
> programmer can hand-code it are mostly to entirely lacking.
>
On 17 Jan, Serhiy Storchaka wrote to the b.p.o issue Steve D'Aprano
referenced:
As Steven have noted the compiler-time optimization is not applicable here
> because name frozenset is resolved at run-time.
In these cases where a set of constants can be replaced with a frozenset of
> constants (in "x in {1,2,3}" and in "for x in {1,2,3}") the compiler does
> it.
And I don't think there is an issue which is worth changing the language.
> Creating a frozenset of constants is pretty rare, and it is even more rare
> in tight loops. The most common cases (which are pretty rare anyway) are
> already covered.
This is message 96 in this thread. Perhaps something bad (or good) will
happen when we get to message 100.
https://www.theregister.com/2022/01/27/linux_999_commits/
--
Jonathan
___
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/S2ARN3TXNFYGTSZIZAMH7DPPSR373EDZ/
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP 505: None-aware operators
Hi All To start this thread, on 18 July, Steve Dower wrote: > Possibly this is exactly the wrong time to propose the next big syntax > change, since we currently have nobody to declare on it, but since we're > likely to argue for a while anyway it probably can't hurt (and maybe this > will become the test PEP for whoever takes the reins?). On 26 July, Raymond Hettinger wrote: > It probably is the wrong time and probably can hurt (by introducing > divisiveness when we most need for be focusing on coming together). [...] +10 Here's some good news for Raymond. On 23 July, Steve Dower wrote: --- > [...] I'm going to duck out of the discussions > here now, since they are not as productive as I'd hoped, and once we have a > BDFL-replacement I'll reawaken it and see what is required at that point. --- and this is Steve's last post (so far) to the discussion. +10 If you've not seen this message from Steve before, you're forgiven. This topic has about 200 messages. Who's got time to read them all them all? If you want to have a go, they're listed by date at https://mail.python.org/pipermail/python-ideas/2018-July/thread.html#52036 Regarding discussion of PEP 505, I'll follow the advice and example of Raymond and Steve. Which is to pick it up again later, once we've got proper cover for the BDFL's vacation. Have a nice holiday, Guido. -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Can we add "zip and assert equal length" to the standard library?
Hi Peter Thank you for your deferred default values idea, which we're now working on together. https://github.com/petered/peters_example_code/blob/master/peters_example_code/deferral.py You wrote: > I find that about 90% of the time I want want to zip iterators together, I > expect them to be the same length and want to throw an exception if they > aren't. Yet there is not currently a solution for this in the standard > library for this, and as a result I always have to take this function > everywhere I go [function definition snipped] You need this function wherever you go. You can solve that problem right now by putting it into PyPI. And if you put it on github, perhaps someone will fork it and contribute. (Note to self. I should do the same for my own useful little tools.) You asked about putting in the standard library. There's a process for that. https://www.python.org/dev/peps/pep-0001/ You might also want to look at the PEP index, to find a successful PEP that's similar to yours. https://www.python.org/dev/peps/ Here's one I've found that looks similar. It proposes the inclusion of a third-party module, pathlib, in the standard library. https://www.python.org/dev/peps/pep-0428/ Putting your code into PyPI into PyPI solves your immediate problem. It also also gives you a reference implementation. https://www.python.org/dev/peps/pep-0001/#what-belongs-in-a-successful-pep I hope your next post will be URL for code on github. I'd be interested in making a fork. Best wishes Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Can we add "zip and assert equal length" to the standard library?
Hi All I've followed my own advice, earlier in this thread. The newly created repository https://github.com/jfine2358/py-jfine2358 contains personal Python code that others might find useful. And you'll find in it: === https://github.com/jfine2358/py-jfine2358/blob/master/jfine2358/itertools.py def zipclose(*argv, close): '''As zip(*argv), but call close before raising StopIteration. [snip]''' === Given zipclose, we can solve Peter's problem by writing a suitable close function. And some other problems can be solved, by using a different close function. Comment on my code at https://github.com/jfine2358/py-jfine2358/issues (preferred), or on this thread. Finally, thank you Peter for another good problem. -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] As-do statements/anonymous blocks in python
Hi James This is an attempt to respond to the issues that be lying behind your request for code blocks in Python. It's my two cents worth (https://en.wikipedia.org/wiki/My_two_cents) of opinion. I really do wish we could have language that had all of Ruby's strengths, and also all of Python's. That would be really nice. Quite something indeed. But most strengths, in another situation, can be a weakness. Language design is often a compromise between conciseness and readability, ease of use and performance, good for beginners and good for experts, and many other factors. Such as innovation and stability. Guido's decisions, as BDFL, have shaped Python and its community into what it is now. It is one set of compromises. Other languages, such as Ruby, have made different compromises. Now that the BDFL is on vacation, the challenge is to maintain the essence of Python while continuing to innovate. Python's compromises and implementation give the language a large sweet spot. === https://en.wikipedia.org/wiki/Sweet_spot_(sports) The sweet spot is a place where a combination of factors results in a maximum response for a given amount of effort. === Languages do influence each other. Ruby is good at internal Domain Specific Languages (DSLs). And there's Perrotta's influential book on Ruby Metaprogramming. That's something I think Python could learn from. But I don't see any need (or even benefit) in adding new language features to Python, so it can do better at DSLs. It's fairly easy to write a decorator that turns a class into a dictionary of 'code blocks'. I think that might be what you really want. I'd be pleased to hear what you have to say about this. with best regards Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] slice[] to get more complex slices
Hi Stephan I took a look at your personal web site. Your PhD sounds interesting. Quantum coherence and photosynthesis. But off-topic here. (Sadly, personal web sites are a bit of mess.) You wrote: > I'd really like to move this proposal forward in some form. +10 > As a next step, would it be helpful to summarize the use cases and reasoning > in a PEP? 0 Here's my two cents worth of opinion. By all means start a PEP (on github) if you find it helps you. I think it's too early. If this problem has a pure Python solution, then I think it best to develop it as a third party module. I suggest the name slicetools. When slicetools is established, has users and is stable. That would be the time to submit the PEP. I think it would give a smoother and easier path. For example, PEP 428 proposes the inclusion of a third-party module, pathlib, in the standard library. https://mail.python.org/pipermail/python-ideas/2018-July/052255.html https://www.python.org/dev/peps/pep-0428/ For more on my general approach to building a third-party library, see my posts. https://mail.python.org/pipermail/python-ideas/2018-July/052464.html https://mail.python.org/pipermail/python-ideas/2018-July/052470.html That's the end of my two cents. Oh, and those who have time and energy to contribute. They get the biggest vote. best regards ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Redefining method
Hi Jamesie Thank you for your question. You asked why not > c = MyClass > o = c() > > def c.foo(cls): ... > def o.bar(self): ... I've the same same query, but never had the courage to ask. So that you for asking. And also giving me a chance to share my thoughts. In Ruby, I believe, you can 'open up' an existing class, and add new methods to it. You can even do with core classes. I think what you asking might amount to a wish to do the same in Python. I think the Python way to 'open up' an existing class is to create a subclass, and add methods to that. Python design and development is quite pragmatic. So instead of us saying why it's not there, why don't you tell why you think it might be good idea. Based of course on examples. Particularly code taken from successful real-world applications. By the way, your >>> def o.var(self): ... won't work as you expect. To get a bound method, the method must be an attribute of the class (in other words type(o)) of the object o. That's the way Python is. What you've written does work in JavaScript. It's perhaps a bit technical and short of examples, but https://docs.python.org/3/reference/datamodel.html would be a good starting point. Can anyone else recommend some other URLs for this. Once again, thank you for asking this question. I look forward to reading other answers (and of course your response). -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP 505: None-aware operators
David Mertz wrote: > `spam?.eggs?.cheese?.aardvark` is NOT redundant for > `spam?.eggs.cheese.aardvark`. The two expressions simply do different > things [...] I agree, assuming ?. is a binary operator. Given this, in Python (+ PEP 505) one can write tmp = spam ?. eggs val1 = tmp ?. cheese ?. aardvark# For spam?.eggs?.cheese?.aardvark val2 = tmp . cheese . aardvark# For spam?.eggs.cheese.aardvark No special knowledge of PEP 505 is needed. If val1 is always equal to val2, then the dot and None-dot operators must be the same. From the assumptions, this is something that can be mathematically proved. By the way, there's a widely used programming language in which val = a.method() and tmp = a.method val = tmp() are not always equivalent. Can you guess which language it is? The answer is in: https://www.slideshare.net/jonathanfine/javascript-the-easiest-quiz-in-the-world-ever (question 6: Dot binds). I'll now go back to following the example of Steve Bower and Raymond Hettinger, which in my words is to wait until we have proper cover for the BDFL's vacation. -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP 505: None-aware operators
Stephan Houben wrote: > Nope, the introduction of the tmp variable changed the semantics. It isn't a > "chain" anymore so it breaks shortcutting. I'm confused. Assume 'a' is not defined. With Python's dot (attribute access) we have >>> a.b.c NameError: name 'a' is not defined >>> a.(b.c) SyntaxError: invalid syntax >>> (a.b).c NameError: name 'a' is not defined I'd expect, after PEP 505 is added to Python that we'd get >>> a ?. b ?. c NameError: name 'a' is not defined >>> a ?. (b ?. c) SyntaxError: invalid syntax >>> (a ? . b) ?. c NameError: name 'a' is not defined If this is not correct, please some do tell me what we would get. Now assume 'a' is defined. I'd also expect, for any value for 'a', that >>> tmp = (a ?. b) >>> val = tmp ?. c give val the same value as >>> val = (a ?. b) ?. c If this is not so, then can the second val be computed from tmp? And if so, how? -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP 505: None-aware operators
Hi All I have two further questions. I'm keen to clarify what is the behaviour specified by PEP 505. I'm not, at this time, interested in why and how PEP 505 specifies behaviour. I just wish, through explicit examples, to clarify the behaviour that is specified. Here 'a' is an identifier. Consider the following 12 expressions (I use the word loosely). 1) a . b . c 2) (a . b) . c 3) a . (b . c) 4) a ?. b . c 5) (a ?. b) . c 6) a ?. (b . c) 7) a . b ?. c 8) (a . b) ?. c 9) a . (b ?. c) 10) a ?. b ?. c 11) (a .? b) ?. c 12) a ?. (b ?. c) Question A: Which of the expressions are NOT valid (Python + PEP 505) syntax? Question B: Which of the valid (Python + PEP 505) expressions are equivalent, for all possible values of 'a'. The answer depends, of course, on the exact text of PEP 505. I've not read PEP 505 that closely. My expectations, based on my Python experience, are that PEP 505 would be written so that: Answer A: Expressions 3, 6, 9 and 12 are invalid. The others are valid. Answer B: 1 and 2 are equivalent. Similarly 4 and 5. Similarly 7 and 8. Similarly 10 and 11. There are no other equivalences (for all values of 'a'). I would like to know if my answers to my questions are correct, and if not please may I be given correct answers. Thank you in advance. -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP 505: None-aware operators
Hi Chris Thank you for your prompt reply. You wrote > Incorrect. The short-circuiting behaviour ends at any sort of > grouping. It's like how "a < b < c" is not equivalent to "(a < b) < > c", nor to "a < (b < c)". You've told me that my answer B is wrong. But you've not provided your correct answer. I'd be most grateful if you could tell me what are the equivalences between the 12 expressions I provided. -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP 505: None-aware operators
Hi Chris You wrote: > Oh. The equivalent ones are #1 and #2, and #7 and #8, where this > proposal doesn't change anything. Otherwise, they're not equivalent. Are you sure. I'd also expect #10 and #11 to be equivalent. By the way, there's a typo in my examples: 11) (a .? b) ?. c -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP 505: None-aware operators
Hi Chris Thank you for your reply. I think we're making good progress. You wrote >> 10) a ?. b ?. c >> 11) (a ?. b) ?. c > > I would parse those differently, but you may be right that they'll > always have the same final result. I'd like to get some certainty on this. I'm not aware of any value of 'a' for which #10 and #11 give different values. Can you (or anyone else) think of any such value? > Technically they should result in different code, though. Maybe. We need to think. Should can be a difficult word. Elsewhere you have, as I recall, pointed out that if None: do_something() generates no code. Perhaps the compiler should collapse #11 to #10, if they are equivalent. But this is a side issue. So, are there any values of 'a' for which #10 and #11 don't give the same result? -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP 505: None-aware operators
Hi Chris We're discussing. > 10) a ?. b ?. c > 11) (a ?. b) ?. c I asked > So, are there any values of 'a' for which #10 and #11 don't give the > same result? You replied > I'm not prepared to put my neck out and say "They are absolutely > identical" and have people jump on me with some technicality. What is > your point here? I am willing to put my neck out and say a.b.c and (a.b).c are equivalent. And my understanding for PEP 505 is that #10 and #11 is that they are equivalent. You're right to be cautious. My understanding of PEP 505 is that #13. a ?. b ?. __str__ #14. (a ?. b) ?. __str__ are not equivalent. The first is None, and the other is None.__str__. That looks like a gotcha. (By the way, it was not my intention to catch you out. I'm simply looking for clarity. I wasn't aware of the gotcha until I started answering myself the question I had asked you.) However, the None object is somewhat special, in that all it's methods and double-under (dunder) methods. And one of them is __bool__. And we can't add or change the attributes of None. Chris, you don't have to reply to this. But I would be pleased if an expert could either tell me that my neck is safe, or produce a value of 'a' that cuts it off (so to speak). -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP 505: None-aware operators
Hi Stephan
You wrote
> Let me stand up and claim that if a chain consists *only* of None-coalescing
> operations, then breaking up the chain by adding parentheses does not
> matter, ever.
You missed a post I made, 17 minutes before yours. I then believed
that PEP 505 specified.
#1. (None ?. dne) is None
#2. (None ?. dne ?. __str__) is None
#3. (None.__str__) is not None
#4. ((None ?. dne) ?. __str__) is (None.__str__)
After my last post, you wrote
> None.?__str__
> produces None, even though None has a __str__ attribute.
This surprises me. But I think it follows from the rules in
https://www.python.org/dev/peps/pep-0505/#the-maybe-dot-and-maybe-subscript-operators
My initial reading of
>>> a ?. b
was that if 'a' didn't have a 'b' attribute, then the result was None,
whatever the string 'b'.
In other words, the same as
>> getattr(a, name, None)
But you and I agree, I think, that PEP 505 specifies (in the cited
page fragment)
>>> a ?. anything
is always None, whenever 'a' is None, and for any non-keyword
identifier instead of 'anything'. Thank you for contributing this
clarification.
The abstract to PEP 505 writes
===
The "None-aware attribute access" operator ?. ("maybe dot") evaluates
the complete expression if the left hand side evaluates to a value
that is not None
===
This is, of course, informal prose. I'm now reading it carefully.
Here's a specific example.
>>> (42).__str__
>>> (42).str
Traceback (most recent call last):
AttributeError: 'int' object has no attribute 'str'
>>> (42) ?. str
I don't see how to apply the prose in the abstract to this last
example. The left hand side is not None, so we "evaluate the complete
expression". On one reading, this is a recursion.
I'd very much appreciate some help here.
--
Jonathan
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP 505: None-aware operators
Hi Steve
Thank you for your reply.
We're discussing the abstract to PEP 505, which writes
===
The "None-aware attribute access" operator ?. ("maybe dot") evaluates
the complete expression if the left hand side evaluates to a value
that is not None
===
I gave (42).str as an example. I wrote
> I don't see how to apply the prose in the abstract to this last
> example. The left hand side is not None, so we "evaluate the complete
> expression". On one reading, this is a recursion.
You wrote
> The phrasing could be clearer.
I think the phrasing could be considerably improved (see below).
> Since 42 is not None, it evaluates (42).str
> [...]
Based on this hint, here's what I think is a better statement.
===
Let `lhs` be the value of the left hand side, and RHS the code
fragment on the right hand side. If `lhs` is None, then the whole
expression is `None`. Otherwise, `lhs . RHS` gives the value of the
whole expression.
===
Please would the experts tell me: Is it true? And if true, is it
better? And can it be improved?
--
Jonathan
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP 505: None-aware operators
Chris Angelico wrote: > It may be true, but it isn't better IMO - especially not for the > abstract. It's unnecessarily pedantic. The current wording isn't > ambiguous, because infinite recursion makes no sense. Thank you for this. Please take a look and compare https://www.python.org/dev/peps/pep-0505/#abstract https://www.python.org/dev/peps/pep-0572/#abstract I'd like to get an abstract for PEP 572 that is as concise and clear as that for PEP 505. My previous comment focused just on 'the sharp edge that cut me'. But the more I look at PEP 572, the more I see sharp edges (in the expression of the ideas in the PEP). Having said that, I hope now to return to lurking, until we have cover for the BDFL vacation. -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP 505: None-aware operators: operators ?= and ?? and OR
Hi Eric [Steve Dower: Eric seems to have found a bug in the PEP. Where to report?] You quoted, from PEP 505, Before > mangle_from_ = True if policy is None else policy.mangle_from_ After > mangle_from_ = policy?.mangle_from_ ?? True You then remarked > I cannot see how these are equivalent I don't see the equivalence either. If `policy.mangle_from_ is None` then surely Before gives None, while After gives True. Here's the process for filing bugs in a PEP https://www.python.org/dev/peps/pep-0001/#reporting-pep-bugs-or-submitting-pep-updates As we seem to be in early draft stage, perhaps communicate first with PEP author (Steve Dower, copied). -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP 505: None-aware operators: operators ?= and ?? and OR
Hi Alexandre Thank you for your post. In PEP 505 the context for the example being discussed is: > Some of these are shown below as examples before and after converting to use > the new operators. You wrote: > So yes, *strictly speaking* the two chunks of code are not exactly the same. I see nothing in the context that indicates that given suitable (Python) context, the before and after expressions give different values. I assumed the before and after values were intended to be the same. By the way, I think that even without your *strictly speaking*, the two chunks of code are not exactly the same (in that they can give different values from identical inputs). > In practice, they'll act the same way given sensible inputs. For me, the truth or falsity of this statement requires more than the peep-hole view of the code supplied by the PEP. Your argument for its truth certainly looked beyond the PEP. I think lack of clarity can mislead, and prevents the PEP performing properly one of its key functions === https://www.python.org/dev/peps/pep-0001/#what-is-a-pep The PEP should provide a concise technical specification of the feature and a rationale for the feature [being proposed]. === and so is a bug in the PEP. Fixing it will help the progress of the PEP. Where to report the bug? Either to Steve Dower, or raise an issue on github. https://www.python.org/dev/peps/pep-0001/#reporting-pep-bugs-or-submitting-pep-updates Steve's already been emailed on this. We're waiting to hear back from him. -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Revisiting dedicated overloadable boolean operators
Hi Todd Thank you for your contribution! I've got a couple of comments. The experts, I hope, will have more to say. You wrote: > As to why this is useful, the overall problem is that the current logical > operators, like and, or, and not, cannot be overloaded, which means projects > like numpy and SQLAlchemy instead have to (ab)use bitwise operator > There was a proposal to allow overloading boolean operators in Pep-335 [2], > but that PEP was rejected for a variety of very good reasons. The key thing is, I think, the wish for a domain specific language. I find this to be a wholesome wish. But I'd rather create a broad solution, than something that works just for special cases. And if at all possible, implement domain specific languages without extending the syntax and semantics of the language. This would benefit many existing users and projects now, without having to wait for the introduction of a new version of Python, and their project adopting that version. It may help to build on PEP 465 -- A dedicated infix operator for matrix multiplication https://www.python.org/dev/peps/pep-0465/ This addition allows you (from the PEP) to write >>> S = (H @ beta - r).T @ inv(H @ V @ H.T) @ (H @ beta - r) You my want to extend the syntax and semantics so that >>> S = (H @beta - r).T @ inv(H @ V @ H.T) @ (H @beta - r) invokes double-under methods, whose name might be something like __at_beta__ I'm impressed by > https://en.wikipedia.org/wiki/Fluent_interface > https://martinfowler.com/bliki/FluentInterface.html and encourage work on tools for creating such in Python. There is the problem of short-circuiting evaluation, as in the 'and' and 'or' operators (and elsewhere in Python). This has to be a syntax and semantics feature. It can't be controlled by the objects. However, as Steve Dower pointed out last month, we can use lamda for this purpose. I think it's easy to define a function OR such that the following > EXP_1 or EXP_2 >> OR(lambda: EXP_1, lambda:EXP_2) do pretty the same thing (except refactoring the expressions into the lambdas). In fact, I think OR has to be >>> def OR(fn_1, fn_2): ... return fn_1() or fn_2() I hope this help you solve the underlying problems, and have a better time with Python. -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Syntactic sugar to declare partial functions
Here's my opinion, in a nutshell. A diet with a small amount of sugar is healthy. But too much sugar is not. https://www.nhs.uk/live-well/eat-well/how-does-sugar-in-our-diet-affect-our-health/ I have a similar attitude to syntactic sugar. Sometimes helpful. https://news.ycombinator.com/item?id=16216994 Sometimes, perhaps not helpful. https://github.com/benthor/dictator https://github.com/czheo/syntax_sugar_python Every programming construct has semantics. Here's a suggestion. If you're proposing a syntax change, give a pure Python implementation of the semantics. For example (not tested). The construction >>> EXP_1 or EXP_2 is equivalent to >>> OR(lambda: EXP_1, lambda:EXP_2) where we have >>> def OR(fn_1, fn_2): >>> ...val = fn_1() >>> ...if val: return val >>> ...return fn_2() And if your proposal works with current Python, write and publish a pure Python implementation. And help others use it, listening to their feedback. So do it on github or the like, with an issue tracker. In short, if you have a proposal, publish some working code that implements the proposal. -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] File format for automatic and manual tests
Hi Victor Thank you for your contribution, regarding standards for Python tools. Here is my two cents worth. You wrote: > We need a standard to make PyCharm and others to conform to it. Things don't quite work that way, in the Python community. True, we have a Benevolent Dictator For Life (BDFL), but that's more an expression of respect for Guido, than a position of power. And anyway, he's on well-deserved vacation. For what you're suggesting, it's more that standards emerge through community use, and then are adopted as a PEP Python standard. Wherever possible, start first with an 'ad hoc' standard. You say your proposal enhances PyCharm. So ask PyCharm and its users set something up. As a first step, solve your own personal problem, and put it up somewhere where others can pick it up. Prove that the idea is good by establishing a group of users, starting perhaps with yourself. -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Python certification
Hi Patrick and Oleg Thank you, respectively, for a good question and a helpful response. Patrick asks: > Does anyone know of any PSF approved training or certifications for Python > developers? Oleg writes: > The python-ideas list is for discussing more speculative design ideas of > Python the language and the implementation. According to https://mail.python.org/mailman/listinfo/python-ideas > This list is to contain discussion of speculative language ideas for Python > for possible inclusion into the language. Python's excellent documentation, including https://docs.python.org/3/tutorial/, is in my opinion part of the language. I'm in favour of discussing Patrick's question here, so that we can perhaps develop something of value that can be added to the tutorial. Is there a forum, better than python-ideas, for discussing speculative ideas for improving Python's documentation? -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Python certification
Hi Oleg You wrote >In what way certification programs are related to documentation, > especially to the tutorial? One way is through syllabus. Necessarily, a certification via exam requires a syllabus (or a course of study). There is, implicitly, a syllabus in https://docs.python.org/3/tutorial/. Here's a couple of Python syllabuses (the first proprietary, the second perhaps open) https://www.microsoft.com/en-us/learning/exam-98-381.aspx https://pythoninstitute.org/pcap-exam-syllabus/ I think it would help, to compare such syllabuses to the one implicit in the Python Tutorial. It may be, of course, that there's somewhere better than python-ideas for having the related discussion. I hope this is enough to persuade you that this topic is appropriate for python-ideas. Of course, if you know a better forum for this, that would be welcome. -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Python Community Code of Conduct
https://www.python.org/psf/codeofconduct/ Python Community Code of Conduct The Python community is made up of members from around the globe with a diverse set of skills, personalities, and experiences. It is through these differences that our community experiences great successes and continued growth. When you're working with members of the community, we encourage you to follow these guidelines which help steer our interactions and strive to keep Python a positive, successful, and growing community. A member of the Python community is: Open Members of the community are open to collaboration, whether it's on PEPs, patches, problems, or otherwise. We're receptive to constructive comment and criticism, as the experiences and skill sets of other members contribute to the whole of our efforts. We're accepting of all who wish to take part in our activities, fostering an environment where anyone can participate and everyone can make a difference. Considerate Members of the community are considerate of their peers -- other Python users. We're thoughtful when addressing the efforts of others, keeping in mind that often times the labor was completed simply for the good of the community. We're attentive in our communications, whether in person or online, and we're tactful when approaching differing views. Respectful Members of the community are respectful. We're respectful of others, their positions, their skills, their commitments, and their efforts. We're respectful of the volunteer efforts that permeate the Python community. We're respectful of the processes set forth in the community, and we work within them. When we disagree, we are courteous in raising our issues. Overall, we're good to each other. We contribute to this community not because we have to, but because we want to. If we remember that, these guidelines will come naturally. Questions/comments/reports? Please write to p...@python.org. Note: this email address is to all of the PSF Board of Directors and the PSF Staff. Alternatively, you may reach Ewa Jodlowska, Director of Operations, at e...@python.org. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Toxic forum
Hi All Here's something that's at the core of my approach. Faced with this sort of problem, I read again https://www.python.org/psf/codeofconduct/. And then I compare my intentions, words and actions to the guidelines in this, the Python Community Code of Conduct. Only when I have, so to speak, regained my purpose and composure do I consider the conduct of others. At least, this is what I aspire to do. -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Python docs page: In what ways is None special
Hi I'm pleased to announce that I've completed the first draft of my page. It's viewable on gitub. https://github.com/jfine2358/py-jfine2358/blob/master/docs/none-is-special.md To quote from that page: This page arose from a thread on the python-ideas list. I thank Steve Dower, Paul Moore, Steve D'Aprano, Chris Barker, David Mertz, Jörn Heissler, Anthony Risinger, Michael Selik, Chris Angelico for their contributions and encouragement. Apologies for anyone I've missed. Comments either on python-ideas, or perhaps better, by raising an issue on github. -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Conduct on python-ideas
Hi Everyone Brett Cannon wrote: > I shouldn't be having to explain to adults on how to communicate among > strangers of different cultures, but here we are. I did an entire PyCon US > keynote on why we need to treat open source as a series of kindnesses and > react as such: https://youtu.be/tzFWz5fiVKU?t=49m29s . If we don't treat > everything as a kindness then open source simply doesn't work and people end > up walking way from open source and the Python community. Well, I've just watched that video. Did anyone else? Recommended - it's only 30 minutes. Is that too long? Well, here's two extracts. Video at https://youtu.be/tzFWz5fiVKU?t=4450 > If I had to give guidelines on how to communicate online: > 1. Assume that you are asking *me* for a *favour*. > 2. Assume your *boss* will read what you say. > 3. Assume *your family* will read what you say. Video at https://youtu.be/tzFWz5fiVKU?t=4094 > *If this sounds biased towards maintainers, that's because it is.* > Simply based on scale, maintainers are abused much more > often than contributors. Once again, recommended. I hope you'll watch the video. -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Does jargon make learning more difficult?
Steve Barnes and Greg Ewing wrote: >> * A dinosaur is specifically an extinct terrible (formerly considered) >> lizard > > > Which technically is not a lizard. I can't resist. Puffinus puffinus is the scientific name for (drum roll) no, not the Atlantic (or common) Puffin but (off-pitch fanfare) https://en.wikipedia.org/wiki/Manx_shearwater -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Python docs page: In what ways is None special
Hi Thank you all, for the kind words and appreciation, and the comments and suggestions. I have time now to respond to one comment. Please note that is just my opinion, and your opinion may be different. Rhodri James prefers (https://mail.python.org/pipermail/python-ideas/2018-August/052742.html) > Sometimes a value is required but we're not able to provide one. to my > Sometimes a value is required. But we're not able to provide one. The next sentence is > In Python, we can use None to solve this problem. I chose the punctuation I did, because I wanted to state clearly the problem. Which is, roughly speaking, damned if you do, and damned if you don't. (In the US, between a rock and a hard place.) In other words, a dilemma. https://www.dictionary.com/browse/dilemma a choice between [...] undesirable alternatives. This paragraph > Sometimes a value is required. But we're not able to > provide one. In Python, we can use None to solve > this problem. is in my mind None in a nutshell. Rhodri says my version, exaggerated for effect, reads like > Sometimes a value is required. But (pay careful attention > to this, it's important and there will be a quiz later) > we're not able to provide one. Yes, Rhodri, you've understood what I'm doing. I do want the reader to pay careful attention. If they only remember one thing, this is what I want them to remember. Rhodri say that his version reads more easily. I agree. And that that is why I prefer my version! Sometimes you have to slow the reader down, so that there's time for understanding to catch up. Short sentences catch attention. Long sentences, with many clauses and a variation of ideas, go by like the scenery on a long and monotonous care journey. And little is remembered. The lesson I take from this is not that I am right and Rhodri is wrong. Or the other way round. That depends on context, taste and house style. And often, there are good reasons on both sides of the decision. So the starting point for persuading someone to change their mind might be this: Understand the forces that led them to the position they hold. Sometime before the end of the month, I'll process the remaining contributions and comments. I hope it doesn't take me more than an hour or two. I'll start by looking at github issues, then pull requests, and then python-ideas. Once again, thank you for all the comments and suggestions. And the kind words and appreciation. -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Jump to function as an an alternative to call function
Hi Jacob Thank you for your problem. I'll focus on your simple example (lightly edited for clarity) > Let foo(a, b) be the syntax to call foo(a, b), and foo(a, b)% be the syntax > to jump to foo(a, b) > > c = 5 > > def foo(a): > return a + c > > def bar(a, c): > return foo(a) > > def bazz(a, c): > return foo(a)% > > call = bar(1, 3) # 6, being 1 + 5 > bazz(1, 3) # 4, being 1 + 3 This may allow you to solve your verb and morpheme problem. But I hope there's an easier way. One that can be done using Python as it is now. My understanding is that you want a stack. Similar to the Python's function call stack, but with something extra. So that functions execute in an richer context. Here's an idea. Start by giving us a toy example of a calculation you'd like to do. Then the problem is: how to do this in Python. By the way, are there any existing Python libraries for this sort of thing? I hope this helps. -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Pre-conditions and post-conditions
Hi Marko Thank you for introducing yourself, and clearly stating your question. That helps us all. You asked: > Could somebody update me on the state of the discussion on this matter? I think bring the existing PEP up to date would be a good starting point. Its content hasn't been changed since 2003 (except for PEP-wide admin changes. (Recall that Python 3.0 was released in 2008.) https://www.python.org/dev/peps/pep-0316/ https://github.com/python/peps/commits/master/pep-0316.txt In fact, revising the PEP might be enough to answer your question. What do you think, Marko? Experts: is there a process for revising old PEPs, such as this one? Or at least a precedent we could follow (or adapt)? -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Python docs page: In what ways is None special
Hi Neil Thank you for your post, regarding https://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarchy. You've suggested changing "built-in name None" to "keyword None". I think that's a good change. And similar changes might be welcome elsewhere in the docs, perhaps also for True and False. And I think there's more. The page says > None > This type has a single value. There is a single object with this value. [...] I think it better to write > NoneType > This type has a single value, `None`. The keyword `None` always gives the > value `None`. I think the best way forward here is to raise an issue on https://bugs.python.org/. Would you be willing to do this? If you need it, there's help available at https://devguide.python.org/triaging/. Once again, thank you for your close attention to detail. -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Python docs page: In what ways is None special
Hi Rhodri Thank you for your message. You wrote: > I disagree. That original text looks like it has been very carefully > written to be (almost) true. What you are proposing to replace it with is > less true and confusing to boot. The decision is neither your's nor mine. It is for the Python docs maintainers. I will respect their decision, even if I don't agree with it. I intend, in my page (on why None is special) to continue to quote accurately, and without criticism, the current Python docs. One intention of my post is to move the particular docs discussion from python-ideas and to bugs.python.org. I think that is a better place for it. They're the people who can decide and do (or not do) something about it. -- with best regards Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Python docs page: In what ways is None special
Hi Paul Thank you for your comments. I think different people experience things in different ways, based on who they are. What their background, training, experience are. One person's precision is another's pedantry. An aside. Babbage and Tennyson: https://www.uh.edu/engines/epi879.htm You wrote > in a section called "The standard type hierarchy", > this reads to me as referring to a type, informally > named as "None". When I read the same text, I don't see an informal name. I see a false statement. By the way, here's why I see a false statement: >>> type(int), type(dict), type(str) (, , ) >>> type(None), type(type(None)) (, ) My (pure mathematics research) background leads me to dislike precise statements that are not true. That's the way I am. Rhodri James doesn't like sentences that begin with 'But'. An aside. Reading further in https://docs.python.org/3/reference/datamodel.html, I see three times "This type has a single value." The informal names are None, NotImplemented and Ellipsis. And there are only two Booleans. I'd like to take this to bugs.python.org, if only to provide another route to discovering this (very useful) conversation. Perhaps one day, we'll have here harmony between informality and precision. Perhaps every popular computer language has this as a goal. -- with best regards Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Python docs page: In what ways is None special
Hi Paul We wrote >> I'd like to take this to bugs.python.org, if only to provide another >> route to discovering this (very useful) conversation. > > That's perfectly OK, and entirely your choice. However, if you do so, > I'd hope that you present the dissenting views from this list when you > raise the question on b.p.o. This reinforces my intention to present matters fairly, referencing this thread. I'll post once more to this thread, after I've created the bug. That might not be for a few days. And thank you for the courteous and respectful disagreement. -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Jump to function as an an alternative to call function
Hi Chris
Steve and you wrote:
>> there
>> are times where I have really wanted to access the caller's environment,
>> not the environment where my function was defined.
> what am I missing? can't you get that by passing locals() in to a function?
I think this will fail when values are changed. According to
https://docs.python.org/3/library/functions.html#locals
> The contents of this dictionary should not be modified; changes may not
> affect the values of local and free variables used by the interpreter.
I suspect that Jacob, the original poster, wants to change state, and
also to read changed state. Jacob, could you confirm or correct, that
you want the called function to be able to change state in caller (or
perhaps even further up the stack).
To finish, here's an interactive example of changing the value of locals().
>>> def f(a=1): loc = locals(); yield loc; yield a
>>> it = f()
>>> ctx = next(it)
>>> ctx
{'a': 1} ## This surprised me.
>>>
>>>
>>> def f(a=1): loc = locals(); yield locals(); yield a
>>> it = f()
>>> ctx = next(it)
>>> ctx
{'a': 1, 'loc': {...}}
>>> ctx['a'] = 3
>>> ctx['loc']['a'] = 5
>>> next(it) ## Is it 1 or 3 or 5?
1 ## The value of 'a' hasn't changed.
--
Jonathan
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Jump to function as an an alternative to call function
Hi Jacob
I really like your previous post. I find it really helps me understand
what you want. You wrote
> I wanted the called, jumped to function to change state in the caller.
> From what I tried to do, passing locals() cannot accomplish this. I have
> made it happen in other languages though.
> In the R language, one can do this
> foo = function(){
>localenv = environment()
>eval(bar, environment = localenv)
> The above code captures the environment of the calling function and
> executes the called function as if the calling function's local environment
> was the global environment.
So in a nutshell, you'd like to be able to write code like this, but in Python?
> bar doesn't have to be a function, it can be any
> valid R expression captured with the expr() function, and everything in R is
> an expression thus allowing for the full usage code blocks.
This Python can already do. Any Python expression can be turned into a
function, simply by prefixing it with 'lambda:'.
> Outside of
> lisp-like languages this feat seems to usually be impossible though.
I'm an Emacs user, so I know Lisp. But R is new to me. But this URL
tells me that R is based on Lisp.
https://www.i-programmer.info/programming/other-languages/1706-a-programmers-guide-to-r.html
And, in my view, this makes your problem immediately much more
important for the Python community. Because both Python and R are
major languages in the area of Data Science.
Thank you so much for your previous post, and to all the others whose
posts have contributed to this clarification.
--
best regards
Jonathan
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Jump to function as an an alternative to call function
Jacob Solinsky wrote: > So when getx is executed inside a let form, if it tries to read/write the > value of X it interacts with the X entry in the let form's symbol table > before moving to find X in the global environment, right? The context for this is two (very useful) URLs I sent him off list: https://www.gnu.org/software/emacs/manual/html_node/elisp/Dynamic-Binding.html https://www.gnu.org/software/emacs/manual/html_node/elisp/Variable-Scoping.html -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Does jargon make learning more difficult?
Summary: Discussion of the words 'jargon' and 'chatter'. Recommend that we > learn better how to find a compromise (strike a balance) between precision and simplicity. This thread is, in part, about the meaning, use and usefulness of words. And 'jargon' is what we are talking about. What is the meaning and use of 'jargon'? According to https://www.etymonline.com/word/jargon (discovered https://en.wikipedia.org/wiki/Jargon) === jargon (n.) mid-14c., "unintelligible talk, gibberish; chattering, jabbering," from Old French jargon "a chattering" (of birds), also "language, speech," especially "idle talk; thieves' Latin" (12c.). Ultimately of echoic origin (compare Latin garrire "to chatter"). >From 1640s as "mixed speech, pigin;" 1650s as "phraseology peculiar to a sect or profession," hence "mode of speech full of unfamiliar terms." Middle English also had it as a verb, jargounen "to chatter" (late 14c.), from French. === And according to https://www.etymonline.com/word/chatter === chatter (v.) early 13c., chateren "to twitter, make quick, shrill sounds" (of birds), "to gossip, talk idly or thoughtlessly" (of persons), earlier cheateren, chiteren, of echoic origin. Compare Dutch koeteren "jabber," Danish kvidre "twitter, chirp." Of teeth, "make a rattling noise from cold or fright," mid-15c. === Ordinary words can acquire a specialised technical meaning. For example === https://en.wikipedia.org/wiki/Machining_vibrations Machining vibrations, also called chatter, correspond to the relative movement between the workpiece and the cutting tool. The vibrations result in waves on the machined surface. This affects typical machining processes, such as turning, milling and drilling, and atypical machining processes, such as grinding. === Sometimes, machining vibrations make a ch-ch-ch-ch chattering sound. My opinions are that the correct technical phrase is 'machining vibrations', which is good for learned articles. But 'chatter' is better in the workshop. As in 'lubricate the drill bit to reduce chatter'. And here's another example === https://en.wikipedia.org/wiki/Chatter_(signals_intelligence) Chatter is a signals intelligence term, referring to the volume (quantity) of intercepted communications. Intelligence officials, not having better metrics, monitor the volume of communication, to or from suspected parties such as terrorists or spies, to determine whether there is cause for alarm. === Back to 'jargon'. === https://en.wikipedia.org/wiki/Jargon Accessibility issues With the rise of the self-advocacy movement within the disability movement, jargonised language has been much objected to by advocates and self-advocates. Jargon is largely present in every day language, in newspapers, government documents, and official forms. Several advocacy organisations work on influencing public agents to offer accessible information in different formats. [...] There is a balance to be struck, as excessive removal of technical terminology from a document leads to an equally undesirable outcome—dumbing down. === I think this last quote gets to the heart of the matter we're discussing. I suggest we learn better how to find a compromise (strike a balance) between precision and simplicity. -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Off topic: 'strike a balance' - second language English
Summary: I look at the phrase 'strike a balance' in different languages, and rewrite some wikipedia text on accessibility. I found in https://en.wikipedia.org/wiki/Jargon#Accessibility_issues === There is a balance to be struck, as excessive removal of technical terminology from a document leads to an equally undesirable outcome—dumbing down. === Aside: Found while writing https://mail.python.org/pipermail/python-ideas/2018-August/052819.html. I wondered how the phrase 'strike a balance' would translate into other languages (which is an accessibility issue). Using google translate I did round-tripping and other loops. (Simply curiosity driven, no agenda.) === en: strike a balance fr: trouver un équilibre en: find a balance de: finde ein Gleichgewicht arabic: العثور على التوازن en: Find balance fi: Etsi tasapaino en: Find the balance de: Finde das Gleichgewicht === en: strike a balance al: të krijojë një ekuilibër en: create a balance basque: oreka sortu en: create balance === >From this I found that 'balance' was the key to the phrase. And that the verb could variously be 'strike', 'find' or 'create'. There may be other verbs. The work 'strike' by itself often means 'stoppage' or 'industrial action'. Is this a hazard? So what's good, when English is the reader's second (or third) language? Surely, here, it's best not to use the word 'strike'. (In English 'strike out' means 'remove', not 'find'.) To try this out, let's rewrite: === There is a balance to be struck, as excessive removal of technical terminology from a document leads to an equally undesirable outcome—dumbing down. == How about === There is a balance to be found [or made] ... === Or we could use 'balance' as a verb (rather than as a noun). === It can be hard to balance removal of technical terminology against retaining essential meaning. === Or even not use the word 'balance' === Harmony between removal of technical terminology and retaining essential meaning can be hard. === Which is the best way to write the sentence, for a second-language English speaker? English is my first (and by far best) language. So I lack the experience, to make a good judgement. However, as an English speaker, I prefer the last > Harmony between removal of technical terminology and retaining essential meaning can be hard. By the way: the rewriting has changed the meaning. For this, how about > Removal of technical terminology may also remove essential meaning. -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Does jargon make learning more difficult?
Hi Stephen Thank you for your message. I'll respond just to a few of your comments. HOW MUCH EFFORT ON DOCS == Myself and you wrote: >> Summary: Discussion of the words 'jargon' and 'chatter'. Recommend >> that we learn better how to find a compromise (strike a balance) >> between precision and simplicity. > I'm not a big fan of asking that everybody put such effort into > documentation for code they're developing. IMHO, where available users > should just buy books by professional writers written to their level, > rather than imposing this burden on the software development project. Sections 6 and 7 (out of 31) in devguide for the Python project are on this. === https://devguide.python.org/docquality/ https://devguide.python.org/documenting/ === This is about 6.5%, of the devguide, by section count. There are at present 108 open documentation issues (out of about 6,000). This is about 2%. I'm proposing for example that we review, and if possible improve, these two sections in the devguide. This review would be evidence based. Not everyone need be involved in this. I suggest that doing this now would, over 3 years, significantly improve our Python documentation. AN EXAMPLE - super() == By chance, I wanted today to read about and then use super(). I found === https://docs.python.org/3/library/functions.html#super For practical suggestions on how to design cooperative classes using super(), see guide to using super(). === To my surprise, I found that this links, not to another part of the docs, but to === https://rhettinger.wordpress.com/2011/05/26/super-considered-super/ === This excellent blog post is not, of course, indexed for the docs search. THE GLOSSARY = You wrote: > The missed opportunity is that a good glossary will also serve users > who graduate to "informal write-only documentation" including archives > of mailing lists and group chats, and the issue tracker. Five days ago, I raised an issue (one of the 108 open issues), to improve search in the glossary. And thanks to Ammar Askar, there's already a patch and pull request. This delights me. https://bugs.python.org/issue34398 https://github.com/python/cpython/pull/8773 TRANSLATION You wrote: > Serving non-native-speakers is a tough call. On the one hand, they > would be best served by good translations and glossaries of English > jargon in their native language. There's already prior art on this. See: PEP 545 -- Python Documentation Translations https://www.python.org/dev/peps/pep-0545/ One of the alternatives in PEP 545 is === Simplified English It would be possible to introduce a "simplified English" version like wikipedia did, as discussed on python-dev, targeting English learners and children. === I think this would be a good idea, particularly for the tutorial (and other beginner materials, such as the glossary). -- with best regards Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Does jargon make learning more difficult?
Hi Stephen I've just been reading the (excellent) discussion, started by Victor Stinner [Python-Dev] Translated Python documentation https://mail.python.org/pipermail/python-dev/2017-February/147416.html # Start of thread. You wrote, and asked for comments on: > Finally, before getting the project into the hairy maintenance issues > that go with distributing translations, I suggest the PSF could buy > the high-quality tutorial books and textbooks (and maybe dictionaries > as well) for translators. Very cheap, but the symbolism that > "somebody noticed, and they care!" is a big reward for many > contributors. I very much more prefer Victor's suggestion (I give the whole message): === https://mail.python.org/pipermail/python-dev/2017-February/147485.html IHMO translating the *whole* Python documentation at once by a professional translator can be very expensive, no somthing that the PSF would affort. Which language would you pick? Depending on what? We already have motivated translators for free who only ask us for the permission to make tiny changes to make their life simpler and make the doc more visible. I'm in favor of allowing them to translate and make the translated doc official ;-) IMHO a better usage of the PSF funding would be to organize some local sprints to translate the Python documentation. Such sprints are fun, cheap, and can be a nice opportunity to recruit free and motivated translators. We are looking for people involved to translate the doc the doc is updated, not only translate the doc once and go away. Right? === -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Documentation of locals()
Summary: There's prior art in bug.python.org relating to off-thread topic discussion of locals(). Suggest work on closing open documentation issues relating to locals(). In the thread === Jump to function as an an alternative to call function https://mail.python.org/pipermail/python-ideas/2018-August/052761.html === there was post === https://mail.python.org/pipermail/python-ideas/2018-August/052807.html I wonder why locals doesn't return a Mapping Proxy, or other read-only mapping object? === and a discussion resulted. There's prior art on bugs.python.org, which can be found by searching for 'locals()' in the issue title. (Search for 'locals' gives more results.) One of the items is (created 2013 and still open): === Documentation of globals() and locals() should be improved https://bugs.python.org/issue19737 === In this issue Terry Read writes === https://bugs.python.org/msg204769 In my opinion, vague ideas like this one should go to python-ideas first. === I suggest that those that have time, energy and interest focus on closing the open locals() documentation issues. Such documentation would, I think, provide an excellent starting point for any proposals to change behaviour. There are 13 open issues with 'locals' in the title. -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Jump to function as an an alternative to call function
Hi I've created new thread === Documentation of locals() https://mail.python.org/pipermail/python-ideas/2018-August/052843.html Summary: There's prior art in bug.python.org relating to off-thread topic discussion of locals(). Suggest work on closing open documentation issues relating to locals(). [...] I suggest that those that have time, energy and interest focus on closing the open locals() documentation issues. Such documentation would, I think, provide an excellent starting point for any proposals to change behaviour. There are 13 open issues with 'locals' in the title. === Perhaps the discussion of locals() here could be moved to the new thread. -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Off topic: 'strike a balance' - second language English
Hi Earlier today, I did a search for 'documentation by example python' and found Example of great documentation in Python: Nick Loadholtes (copied) https://ironboundsoftware.com/blog/2017/12/11/great-documentation-python/ The example is: https://docs.python.org/3/library/random.html#examples-and-recipes So who to thank: Here's the history of the source for the doc page. https://github.com/python/cpython/commits/3.7/Doc/library/random.rst I don't have time right now to look at all the history. But most of the recent commits are from Raymond Hettinger. I'll give Nick's web page the last word. Make your docs work as hard as your code does. Clear examples will make your code stand out in a good way. Great documentation is out there, lets make more of it. Here’s what you need to create: * A plain language explanation of what your library does * The shortest possible code example * A quick list of any common issues * Links to where you can learn more details If you can create that for your code, you are doing a great service to us all. -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Off topic: 'strike a balance' - second language English
Nick Loadholtes wrote (elsewhere, quoted in this thread - by me). > Make your docs work as hard as your code does. Clear examples will > make your code stand out in a good way. With a bit more searching I found: https://www.reddit.com/r/Python/comments/70myto/whats_new_in_python_37_python_370a0_documentation/dn4v667/ I'll disagree. Nothing is better than Mathworks documentation. I like documentation by example. Python gives you the dry, technically correct verbiage behind how something works. Matlab says: "Here, copy paste this and it'll work". To the point that the workspace is designed to automatically strip >>> from any copy and pasted commands. Even with most Python examples you can't just copy and paste a chunk of an example from the web or documentation because you need to clean off >>> first. It did me good, to read the resulting discussion on reddit. -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Off topic: 'strike a balance' - second language English
Chris Angelico wrote > Where in the linked-to What's New page is there an example of that? > There are several code blocks that ARE copy/pasteable, even into the > vanilla interpreter. Good question. The reddit user wrote. https://www.reddit.com/r/Python/comments/70myto/whats_new_in_python_37_python_370a0_documentation/dn4zd20/ Take this example for re.sub. [https://docs.python.org/3/library/re.html#re.sub] Trying that out requires 3 separate copy and pastes just to do one example. Or you have to put it in an intermediate file, clean it up then paste it in. The examples are also grouped by sub function not by what they do. I think the problem is the user didn't see the [>>>] toggle at the top right of the code block. I know I didn't just now, when I tried it just now. It was only the strength of your assertion, Chris, that made me go back and try again. https://docs.python.org/3/tutorial/introduction.html In the following examples, input and output are distinguished by the presence or absence of prompts (>>> and …): to repeat the example, you must type everything after the prompt, when the prompt appears; lines that do not begin with a prompt are output from the interpreter. Note that a secondary prompt on a line by itself in an example means you must type a blank line; this is used to end a multi-line command. No mention here, or elsewhere on the page, that [>>>] at the top right of a code example toggles the presence or absence of prompts. -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Off topic: 'strike a balance' - second language English
Hi Steve You wrote: > I would just like to point out that the ipython %paste magic very > handily strips leading >, ... & + characters from the pasted block, > (there is also some clever dedenting done). [useful example, snipped] > Which is ideal. I personally find that many beginners get on a lot > better in the iPython console than in the python one. Thank you very much for this. I didn't know about this solution to the problem. Docs search for ipython brings up https://docs.python.org/3/tutorial/interactive.html One alternative enhanced interactive interpreter that has been around for quite some time is IPython, which features tab completion, object exploration and advanced history management. It can also be thoroughly customized and embedded into other applications. Another similar enhanced interactive environment is bpython. I've now played a little with (both look nice): > https://www.bpython-interpreter.org > https://repl.it/repls/LightcoralMoralDistributedcomputing Perhaps beginners would benefit from something better than the default, but simpler than ipython. But I don't have any experience to support this view. There's related prior art in the well-regarded https://codewith.mu/en/about. (Steve, I'd welcome your comments on this.) So thank you for bringing iPython's nifty %paste trick to my (and the thread's) attention. -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Off topic: 'strike a balance' - second language English
I wrote: > No mention here, or elsewhere on the page, that [>>>] at the top > right of a code example toggles the presence or absence of prompts. Now raised, and cross-referenced as an issue. https://bugs.python.org/issue34451 docs: tutorial/introduction doesn't mention toggle of prompts Perhaps discussion of this should move there. -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Does jargon make learning more difficult?
Hi Abe First, I have reservations about the name lambda. But there's a lot of code out there that uses lambda, and I'd like that code to continue to run. You wrote: > func = value[card.suit] if card not in wilds else wild_value with card I thought I'd try this, and variants, in the Python interpreter. I got # An expression. It's valid syntax, get run-time error. >>> value[card.suit] if card not in wilds else wild_value NameError: name 'card' is not defined # An expression. It's valid syntax. Its value is a function. No run-time error. >>> lambda card: value[card.suit] if card not in wilds else wild_value at 0x7ff815e2bbf8> # If Python were enhanced, an valid expression whose value is a function. >>> value[card.suit] if card not in wilds else wild_value with card SyntaxError: invalid syntax My understanding is that you prefer >>> EXPRESSION with IDEN to >>> lambda IDEN: EXPRESSION How do you feel about this, as a means of defining an anonymous function? >>> with IDEN: EXPRESSION We can't adopt it, of course, because it's already valid syntax, but with semantics. >>> with wibble: ...wobble NameError: name 'wibble' is not defined Now for a trick question. Consider >>> fn = (lambda : EXPRESSION) This produces a function that has zero parameters. How would you write this, using 'with'. Would it be: >>> fn = (EXPRESSION with) I think this looks rather odd. -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] A simple proposal concerning lambda
Here's what I call a simple proposal. Some people might find it
outrageous. Today is not 1st April.
BACKGROUND
Many Python users don't like the name lambda. But many Python users
don't want any change here. This is true because there are millions of
Python users, and even 100 is many. And it's hard to introduce a new
keyword, which might break existing code. (And perhaps even worse,
break the community.)
https://wiki.python.org/moin/LocalUserGroups
> There about 1,637 Python user groups worldwide in almost 191 cities, 37
> countries and over 860,333 members.
SOME VALID PYTHON
==
Here's some valid Python, defining two functions fn and gn, that are
virtually identical.
>>> def fn(a, b=2, c=3):
... return a ** b / c
>>> fn
>>> gn = lambda a, b=2, c=3: a ** b / c
>>> gn
at 0x7ff815e2bbf8>
Notice that fn and gn have the same type, and differ by name.
>>> type(fn), type(gn)
(, )
>>> fn.__qualname__, gn.__qualname__
('fn', '')
And that we can modify the display name of fn and gn.
>>> fn.__qualname__ = 'my_fn'
>>> fn
>>> gn.__qualname__ = 'my_gn'
>>> gn
MY SIMPLE PROPOSAL
Here is my simple proposal. Enhance Python to allow
>>> hn = def a, b=2, c=3: a ** b / c
>>> hn
>>> hn.__qualname__
''
MIGRATION
==
Migration of code would require only a keyword substitution of
'lambda' by 'def'.
And in the docs
1. Note that 'def' can mean 'define' (the current use), and also
'defer' (evaluation of an expression).
2. In the first case, we have a *named function*. In the second case,
we have an *expression function*.
This idea came to me while writing:
https://mail.python.org/pipermail/python-ideas/2018-August/052880.html
--
Jonathan
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Off topic: 'strike a balance' - second language English
Hi Greg You (and a reddit user) wrote: >> Matlab says: "Here, copy paste this and it'll work". >> To the point that the workspace is designed to automatically strip >>> >> from any copy and pasted commands. > Maybe this is something Python's REPL should do? Good idea. Maybe this is something that you (or someone else) should raise on bugs.python.org? And I expect that then, they'll ask for it to be discussed on python-ideas. So what do we get from the bounce? Well, you (or someone else) would be keeping an eye on this. (Aside: I'd like to be the someone else, but I don't have the time.). -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
