[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
I think the question is, how is that fundamentally different than the value "None". Once you create this "special value", some function will decide to make it have a meaning as a passed in value, and then need a DIFFERENT "special value" as a default. On 7/23/23 1:13 AM, Dom Grigonis wrote: Or maybe you are not listening to what I am saying. It would only take effect for arguments, which have default value. So. dict().__setitem__(key, NotGiven) type(NotGiven) Exception(NotGiven) getattr(NotGiven, name) Ok, maybe there are some crucial functions, which have argument defaults. But again, there is another solution then, implement efficient decorator in standard library, maybe as part of sentinels, maybe as part of your PEP, maybe separately. I never said that it isn’t hard to write low-level python code. I will do that when the time is right for me. And I am not claiming that it is possible. If you read my language, all of my doubts are clearly expressed. You just seem to read everything as black and white even when it is not so. However, such statements are in no way valid arguments in such discussion. If my idea is not optimal, not necessary, no-one needs it or any other valid responses, why it is not a good one - I can accept it. But commenting that “it makes no sense” without properly explaining to me why after giving it some thought - it’s not fair. Also, if you looked at things from a bit more positive perspective, maybe you could come up with some nice new ways how it could be done. Maybe not exactly what I am proposing, but some alternative, which would make it work. Most likely something much better than I am proposing. After all, I am trying to see how your PEP can be improved, because if it could be used in all cases, where None can be, then at least to me, it would be a no-brainer to use it instead and to adapt it as best practice. DG On 23 Jul 2023, at 07:35, Chris Angelico wrote: On Sun, 23 Jul 2023 at 14:08, Dom Grigonis wrote: IT IS AN OBJECT. Never said otherwise. One that you can't do any of the operations I described. There is no way to use it as an object. `inspect.getcallargs` can seemingly be modified for such behaviour. I just wrote a decorator, which does what I proposed using `inspect` module for a chosen sentinel value. The issue is that it would be a bottleneck if used on any callable, which is continuously used. `inspect.getcallargs`, `signature`, `getfullargspec` are very expensive. If that can be done, theoretically it should be able to be done at lower level as well. After all, behaviour of it should be modelled after what is happening at the function call. Since you clearly are not listening to the discussion, I will leave you with one final recommendation: Write some code. Don't just claim that it's possible; write actual code that makes it happen. You will discover exactly how hard it is. If I am wrong, you will be able to PROVE that I am wrong, instead of merely claiming it. ChrisA -- Richard Damon ___ 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/JEIZYDJGK3RDW77FNZX5TZUP47JJT4XW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Conditional 1-line expression in python (Dom Grigonis)
On 7/18/23 12:03 AM, Dom Grigonis wrote: Ok, thanks. I think what I am aiming at is that there is a pool of suggestions and PEPs that are pointing towards very similar direction and I find myself often wandering in the same space, just trying to figure out what it exactly is. It sometimes feels more verbose than it could be for what it is in the context of how simple python is to use in general. I am fully well aware that current if-else expression is not going anywhere. Chances that another expression is introduced, which does exactly the same thing are close to none. So I am just gauging if it is a matter of conciseness of existing expressions or absence of something that could be there. Conditional if-else is just a place where I got to naturally. Got some useful references to PEPs, python history and opinions. Maybe it will become more clear in the future or maybe something new is already being worked that is going to fill the gap which I am not aware of. I haven’t even started any proposal myself, I was just following e-mail requests and rejected PEPs that were mentioned here. Combined it with my own experience and this is where I got to. Currently seems like it’s a dead end. Decision’s have been made, opinions taken into account, but I still have to write either: a) awkward 1-liner self.value= valueif valueis not None else DefaultClass() b) 3 nicely readable lines with 1 unnecessary assignment. self.value= value if valueis None: self.value= DefaultClass() or, changing around: if value is None: value = DefaultClass() self.value = value since the assignment is fundamental to the operation of the function, that is adding 2 lines to implement an optional default, which isn't that much to implement the feature. it could be simplified to one line as if value is None: value = DefaultClass() (I think this is legal but against PEP8) c) 4 lines, no unnecessary assignments with excellent readability. if valueis None: self.value= DefaultClass() else: self.value= value The issue with b) and c) is that if I use those ones, my constructors become unbearably long and finally lead to the point where development becomes awkward. I would think that for what it does, it shouldn’t be more than 1 line. Max - 2. But a) is somewhat awkward. All (well not all, just several things) taken into account I ended up at inconvenience of `ifelse` expression, which would make a) my natural choice in this case. I am not even suggesting to introduce analogous `ifelse` with different syntax, just trying to get some ideas, references, opinions or alternatives that I don’t know about. - Richard Damon ___ 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/TLOWSO7GPUPU4XW2GP6OOW3IN2NFVWCA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a .whitespace property to module unicodedata
On 6/1/23 2:06 PM, David Mertz, Ph.D. wrote: I'm not sure why U+FEFF isn't included, but that seems to match the current standards, so all good. I think because Zero Width, No-Breaking Space, (aka BOM Mark) doesn't act like a "Space" character. If used as the BOM mark, it is intended that it gets stripped out when read and the UTF-16/UTF-32 data file that follows it be typically just read and have its byte order corrected as the mark indicates. If used elsewhere as the ZWNBSP (which has been deprecated and replaced with U+2060) then it use is intentionally "no-break" so not a space to seperate on. -- Richard Damon ___ 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/7D2NZMF445F4XNKJFVXLDKDLI3NGDK65/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: extend method of the list class could return a reference to the list so that we can chain method calls
On 5/28/23 7:32 PM, Samuel Muldoon wrote:
*Currently, list.extend does not allow method chaining.*
*
*
*parameters = [
"zero or more",
"zero or more".upper(),
"zero or more".lower(),
"Zero or More"
*
*].extend(["(0, +inf)", "[0; +in**f]"])*
*
*
*parameters.extend(["{0, \u221E}"]).append("(0 inf)")
*
*
*
*Samuel Muldoon*
My understanding is that it is a deliberate choice that mutating member
functions return NONE, rather than the object (to allow chaining)
because otherwise it is too easy to think it return a new copy of the
object (like operation that aren't mutations).
Thinking you got a new copy when you are working with the original
object gives hard to find problems.
Since the operations return NONE, mistakenly trying to chain hits an
obvious, and normally easy to fix error.
It just says that "chaining" has become less pythonic.
--
Richard Damon
___
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/YNH65BFGOLMC3BLRB4NCN6ADSXAWWDZ2/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding pep8-casing-compliant aliases for the entire stdlib
On 11/13/21 9:59 AM, Stephen J. Turnbull wrote: Mark Mollineaux writes: > I'll simply say that while I am disappointed that there are so many > frictions here for whatever reason, For your personal use, you can create a module that just does import nonPEP8module pep8name = nonPEP8module.nonpep8name ... Or even import nonPEP8module nonPEP8modue.pep8name = nonPEP8module.nonpep8name to monkeypatch the module to have the pep8name in it. As long as you import this module before you try it, you can then even do from nonPEP8module import pep8nane -- Richard Damon ___ 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/TH6S5LCICSLTWPKAQQNNJ26F267L5IC2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP8 mandatory-is rule
> On Aug 31, 2021, at 9:52 AM, Calvin Spealman wrote: > > > I think the provenance of the "is None" rule comes from before None was a > guaranteed singleton. In older versions of Python, it was possible to > instantiate more instances of None. So it was possible for "x == None" to > fail even if x was *a* None. > > While the community is very used to and invested in the style, from a > practical perspective I don't think "x == None" is necessary wrong anymore. Unless x is a type that redefines == like numpy does. Then you don’t get the answer you might expect. > >> On Mon, Aug 30, 2021 at 2:45 PM Nick Parlante wrote: >> Hi there python-ideas - I've been teaching Python as a first >> programming language for a few years, and from that experience I want >> to propose a change to PEP8. I'm sure the default position for PEP8 is >> to avoid changing it. However, for this one rule I think a good case >> can be made to make it optional, so let me know what you think. >> >> Let me start with what I've learned from teaching students in Java and >> now in Python. In Java, you use == for ints, but you need to use >> equals() for strings. Of course students screw this up constantly, >> using == in a context that calls for equals() and their code does not >> work right. Then for Java arrays a different comparison function is >> required, and so it goes. To teach comparisons in Python, I simply say >> "just use ==" - it works for ints, for strings, even for lists. >> Students are blown away by how nice and simple this is. This is how >> things should work. Python really gets this right. >> >> So what is the problem? >> >> The problem for Python is what I will call the "mandatory-is" rule in >> PEP8, which reads: >> >> Comparisons to singletons like None should always be done with is or >> is not, never the equality operators. >> >> For the students, this comes up in the first week of the course with >> lines like "if x == None:" which work perfectly with == but should use >> is/is-not for PEP8 conformance. >> >> My guess is that this rule is in PEP8 because, within a Python >> implementation, it is within the programmer's mental model that, say, >> False is a singleton. The mandatory-is rule is in PEP8 to reinforce >> that mental model by requiring the is operator. Plus it probably runs >> a tiny bit faster. >> >> However, for "regular" Python code, not implementing Python, forcing >> the use of is instead of the simpler == is unneeded and unhelpful (and >> analogously forcing "is not" when != works correctly). What is the >> benefit of forcing the is operator there? I would say it spreads an >> awareness of the details of how certain values are allocated within >> Python. That's not much of a benefit, and it's kind of circular. Like >> if programmers were permitted to use ==, they wouldn't need to know >> the details of how Python allocates those values. Being shielded from >> implementation details is a Python strength - think of the Java vs. >> Python story above. Is Java better because it builds an awareness in >> the programmer of the different comparison functions for different >> types? Of course not! Python is better in that case because it lets >> the programmer simply use == and not think about those details. >> Understanding the singleton strategy is important in some corners of >> coding, but forcing the is operator on all Python code is way out of >> proportion to the benefit. >> >> As a practical matter, the way this comes up for my students is that >> IDEs by default will put warning marks around PEP8 violations in their >> code. Mostly this IDE-coaching is very helpful for students learning >> Python. For example, It's great that beginning Python programmers >> learn to put one space around operators right from the first day. >> Having taught thousands of introductory Python students, the one PEP8 >> rule that causes problems is this mandatory-is rule. >> >> As a teacher, this is especially jarring since the "just use ==" rule >> is so effortless to use correctly. In contrast, the mandatory-is rule >> adds a little pause where the programmer should think about which >> comparison operator is the correct one to use. It's not hard, but it >> feels unnecessary. >> >> As a contrasting example, in the language C, programmers need to >> understand == vs. is right from the first day. You can't get anything >> done in C without understanding that distinction. However that is just >> not true for regular (not-Python-implementation) Python code, where == >> works correctly for the great majority of cases. >> >> Here is my proposal: >> >> Add the following parenthetical to the mandatory-is rule: (this rule >> is optional for code that is not part of an implementation of Python). >> >> So in effect, programmers outside of a Python implementation can >> choose to use == or is for the "if x == None:" case. In this way, PEP8 >> conforming code before the change is still conforming. Moving
[Python-ideas] Re: NAN handling in statistics functions
On 8/28/21 6:23 AM, Marc-Andre Lemburg wrote: > To me, the behavior looked a lot like stripping NANs left and right > from the list, but what you're explaining makes this appear even more > as a bug in the implementation of median() - basically wrong assumptions > about NANs sorting correctly. The outcome could be more or less random, it > seems. It isn't a 'bug in median()' making the wrong assumption about NANs sorting, it is an error in GIVING median a NAN which violates its precondition that the input have a total-order by the less than operator. Asking for the median value of a list that doesn't have a proper total order is a nonsense question, so you get a nonsense answer. It costs too much to have median test if the input does have a total order, just to try to report this sort of condition, that it won't be done for a general purpose operation. -- Richard Damon ___ 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/KHXUA6JWCC3LGWTBTQEEGKD6Z22YY345/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Implementing a 'but' statement in for-iterations
On 6/28/21 5:40 PM, Max Shouman wrote: > This is more of a syntactic sugar than an actual new feature, but... > Exactly, 'but' is the idea: a special keyword to be used in for statements to > exclude values from the iterable. > > E.g., when iterating over a generator: >>>> for i in range(0, 10) but (2, 8): > would implicitly create a new generator comprehensively, as in: >>>> for i in (j for j in range(0, 10) if j not in [2, 8]): > It might not add such a feature to justify the definition of a but_stmt in > python.gram, but it's fully compliant with Python's philosophy of concise, > clear and elegant code. > > #road to a programming natural language (jk) Wild idea, but could we avoid a new keyword by reusing one that can't go there, like except? for i in range(0,10) except (2, 8): don't know if it is actually worth it, but at least it doesn't add a new keyword. -- Richard Damon ___ 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/EKASCDKVQT75UY7HSLYFVW62IDH7DRTU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Extension methods in Python
On 6/24/21 7:09 AM, Simão Afonso wrote: > On 2021-06-24 20:59:31, Steven D'Aprano wrote: >> Seriously, there's a time to realise when arguments against a feature >> devolve down to utterly spurious claims that Python programmers are >> idiots who will be confused by: >> >> from extensions use flatten >> mylist.flatten() >> >> but can instantly understand: >> >> from extensions import flatten >> flatten(mylist) > Does this mean importing a module can modify other objects, including > builtins? Should this spooky-action-at-a-distance be encouraged? > > OTOH, this already happens in the stdlib with rlcompleter, I assume > using monkey-patching. This is a special case for interactive use, > though. > > https://docs.python.org/3/library/rlcompleter.html Yes, importing a module runs the global code in that module, and that code can not only define the various things in that module but can also manipulate the contents of other modules. This doesn't mean that spooky-action-at-a-distance is always good, but sometimes it is what is needed. You need to be aware of the power that you wield. -- Richard Damon ___ 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/I555D55DJBOV4V3MTZ2IJQ3MIDDOHQKV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Custom-Strings: Combine f-strings and condtional_escape()
I think one fundamental problem is that you can’t detect programmatically if a string needs to be escaped or not. For instance, the sequence might be an already escaped & or it might be the text to tell you how to escape an ampersand and needs to be converted to amp; Promoting sloppy coding by handling the most common cases is the way to it easier to create security vulnerabilities. Maybe if escaped strings had a different type than unescaped strings, but then you need a bunch of different types for different rules for escaping. ___ 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/MLXST2LDBO7O2QAKNPAYQDYGRQEPFF37/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Introduce constants in Python (constant name binding)
On 5/26/21 7:40 AM, Steven D'Aprano wrote:
> On Wed, May 26, 2021 at 11:26:17AM -, Shreyan Avigyan wrote:
>> Reply to Richard Damon:
>>
>> The values can be changed. It can be mutated (if mutable). This idea
>> suggests we can't reassign anything to the name. Suppose,
>>
>> constant x = ["List"]
>> x.append("something") # OK
>>
>> x = [] # Error
So we only have to check at runtime if name has been marked constant to
handle cases like:
if flag:
constant foo = ["List"]
else:
foo = ["Other"]
or
import mymodule
constant mymodule.foo = ["List"]
or are you going to restrict how constants are created?
>
> At last, a straight answer to the question of what this does. Thank you.
> Your answer here crossed with my previous post.
>
> In the future, can you please try to use standard Python terminology
> instead of ambiguous language?
>
> "The values can be changed" is ambiguous. That can mean mutating an
> object:
>
> x.append(None) # mutation changes the value of x
>
> and it can mean rebinding:
>
> x = None # rebinding changes the value of x
>
>
> So now tell us, what sort of error do you get? Is it a compile-time
> error or a run-time error?
>
>> Think of it as a const *ptr. Don't think of it as const *ptr const.
> What's a const *ptr and a const *ptr const?
He is assuming that people are familiar with C.
--
Richard Damon
___
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/ZACDDCGGNJ32KD3FTAEEFXR5727CZ2AK/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Introduce constants in Python (constant name binding)
On 5/26/21 5:55 AM, Shreyan Avigyan wrote: > Reply to Steven - > > Literals mean 10 or 20. Can you assign something to literal? No. But you can > assign something to a variable to point to another value. That's why I said > constants should behave like literals. Point is constants are names bind to a > value. We can change the value but not the name to point to a different > value. Simply think "const type *pointer" not "type *pointer const". > > And by debugging I meant it would immediately be detectable if someone tries > to change the constant or not. (Not a good argument in constant's favor > though) I think the biggest problem is that basically, by definition, to actually enforce this requires a attribute lookup on EVERY rebinding or mutating operation. One stated goal was that constant mylist = [1, 2, 3] was to generate an error if you do mylist.append(4) but that also means we need to catch yourlist = mylist yourlist.append(4) and since that binding could happen on a cross module function call, every mutating operation needs a run-time check to see if this object has been bound to a constant. We also need to test everytime we bind/rebind a name, as the creation of that constant binding might be hidden behind mechanisms that we can't determine at compile time. Things like can another module inject a constant into our module? If so, we need to check every name binding to see if that name has been made a constant. This can add up to a noticable run time cost. Using the alternative of type hints says that the checker can warn us of many of the violations, and you have the OPTION of turning on run time checking if you think you have a problem (or you can just choose to always turn it on and pay the cost). -- Richard Damon ___ 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/RSFAX56IETA4UZ7WOQGOFEHZZ6SRQWOZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: division of integers should result in fractions not floats
On 5/14/21 12:58 PM, Martin Teichmann wrote: > Hi Richard, > >> I would say that I have enough code that does division of numbers that >> might be integers that expect it to be relatively efficient as floats, >> and I suspect so do others, that the backwards breaks would be >> significant. > Could I please see an example? This is a real question, by now I ran my > prototyped interpreter through quite some libraries, and none made problems > like this. > > Real world examples I am talking about. Sure, I can easily code an > approximation for pi which goes out of hand quickly, but doing this in Python > would be just wrong unless you are writing a text book. > > Cheers > > Martin Do to company rules, I can't publish the actual code, but the input data is all integers, and I am building up a curve fit where I sum thousands of distinct values, some of which are ratios of data. If that division became an fraction, because the denominators are all different values, the resultant sum would get to be very big numbers (basiclly the least common multiple of hundreds of numbers in the range of thousands. As floats, this sumation is quick. If done with 'exact fractional' math, I suspect it slows down by several orders of magnitude, going from sub second to maybe an hour. That would be totally unacceptable. Yes, the fix would likely be changing one line of the program to force the results to be a float, but if the program is on the factory floor and just working. If IT at some point updates the version of python being used due to some security release being needed, suddenly programs like this just stop running as they grind to a halt. ___ 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/M2QCN47WWUAIYWWKYO4OMN3UB54KFMRM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: division of integers should result in fractions not floats
On 5/14/21 12:16 PM, Ricky Teachey wrote: > On Fri, May 14, 2021 at 12:02 PM Chris Angelico <mailto:ros...@gmail.com>> wrote: > > On Sat, May 15, 2021 at 1:47 AM Martin Teichmann > mailto:martin.teichm...@gmail.com>> > wrote: > > > > Hi David, > > > > > A toy example with a half dozen operations won't make huge > fractions. A > > > loop over a million operations will often be a gigantic memory > hog. > > > > I do not propose to do that, and I agree that it would be > stupid. Usually, the fraction gets very quickly converted into a > float, and your millions of operations will be done with floats. > > > > But if integer division gave a Fraction, then at what point would it > be converted into a float? As long as all the literals are integers, > it would remain forever a rational, and adding fractions does get > pretty costly. > > ChrisA > > > I think most of the time, people just want to do an accurate enough > division operation and don't really have an opinion what the output > type is (so long as it works), but for the situations where the type > really really does matter, you can choose the type by using > Fraction(1,2) or 1/2. If precision is critical, you can already have > it with the Fraction choice. > > But I would also assume there are probably some fraction (tee hee) of > situations where people specifically want/need a float from an integer > division operation and NOT a fraction, and would either have to take > the extra step to convert it. If you're in a loop doing millions of > conversions, seems like that could get slow. > > A way around this would be to add a new integer division operation > that returns float: > > >>> 1/2 > Fraction(1, 2) > >>> 1//2 > 0 > >>> 1///2 # new float division operator > 0.5 > > But that doesn't seem like a very optimal solution to me. > > So +1 for fraction literal PEP (not sure I would want it approved or > not, but it should get a full hearing), -1 for changing the output > type of integer division. > > --- > Ricky. > > "I've never met a Kentucky man who wasn't either thinking about going > home or actually going home." - Happy Chandler > If anything like this was done, the NEW operator needs to be the fraction and the original / the float, for backwards compatibility. I would say that I have enough code that does division of numbers that might be integers that expect it to be relatively efficient as floats, and I suspect so do others, that the backwards breaks would be significant. The cases where you really need the fraction are much smaller, and if you do, having a convenient way to ask for it could be useful, but not so useful that it is worth breaking all the code that expects floats. It wouldn't be quite as bad as the python2 -> python3 string/bytes changes, but the comparison isn't totally out of line. -- Richard Damon ___ 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/WHXATVLUK33YROFZNC3U3ALMLQWIVURP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Bring back PEP 501
On 5/7/21 5:56 PM, Nick Humrich wrote:
> Marc,
>
> You might have misunderstood me. I am not recommending sending the
> database raw strings without parameters, but rather that i-strings
> turn things into parameters and its impossible to mess up. Let me
> explain a little.
>
> In sqlalchemy, you can use a format such as "update items set a=:value
> where id=:item_id" then you tell it the value of the parameters.
> SQLAlchemy then takes the :something part of the string and turns it
> into a parameter ($1, $2, etc). The problem being however, there is
> nothing stopping me from doing an f string on accident: f"update items
> set a={something} where id=:value". Because f-strings are eager,
> sqlalchemy cant protect you, you are now vulnerable to injection.
> But with i-strings, because they are not eager, it would actually know
> that you passed in the value as a variable, and turn it into a
> parameter. It knows the difference between the static part of the
> query and the dynamic part of the query, so it can actually protect
> you from yourself, or protect early engineers who don't even know what
> injection is.
>
> Nick
>
I think the issue is what would the result of the i-string actually be?
The database APIs want typically a string + a tuple or a dictionary, two
seperate things. Are you suggesting that to use i-stings, all the API's
need to be adjusted to accept some new type of object that is a
string/dictionary combo?
--
Richard Damon
___
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/VX4QLIKNONV2UE6KNBJK6KA42MTVIUM7/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Accepting a function argument of a particular type specified by the user
On 4/25/21 3:08 PM, Shreyan Avigyan wrote: > Thanks for clarifying. And I agree with you. Not writing checking code will > make the function more flexible. > > Thanking you, > With Regards My experiance is that the type annotaions let my IDE warn me of wrong parameters, or give me hints as to what type it wants. I generally don't need to explicitly test the type, as if it is of the wrong type (at least a wrong type of duck) then it will throw an error when I do something it doesn't know how to do it. Thus, unless the exact type of exception is important (and it usually isn't) there is no need to test and throw a specific type of error. -- Richard Damon ___ 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/KDTCACLLCAYG5Z6WXK2TCY2NAHX7JPEO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Accepting a function argument of a particular type specified by the user
On 4/25/21 9:09 AM, Shreyan Avigyan wrote:
> Think it like this. We have this code in Python :-
>
> def add(a, b):
> return a + b
>
> Here we are taking two arguments a, b and then returning a + b. But we can
> pass in instance of any class like str, int, float, dict, user-defined class,
> etc. But we only want to add int here. Here we can modify it to be,
>
> def add(a, b):
> if type(a) == int and type(b) == int:
> return a +b
> raise Exception("Error")
>
> In this example it's pretty easy to check if the arguments are int. But in
> real world programs as the functions become bigger and bigger it's very
> difficult to check arguments using an if statement. Therefore why not let
> the user specify what parameter types are gonna be? Like,
>
> def add(int a, int b):
> return a + b
>
> If instance of a different class is passed in then raise a TypeError perhaps?
> If parameter types are not given then let the parameter accept any kind of
> class instance.
>
> This kind of functionality will minimize a lot of if statements related to
> parameter types and arguments.
>
> Thanking you,
> With Regards
Well, in Python with type annotations that would be spelled:
def add(a: int, b: int):
return a + b
but the one difference is that, at least by default, that requirement is
advisorary only. You can run a static type checker like mypy at it will
see if it can deduce a case where you pass a non-int to the function.
You could also import a module into your module that will actually do
the check at run-time (I don't know of one, but there probably is one)
maybe needing the function to be decorated to request the type checking.
--
Richard Damon
___
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/7DCIKCAQOD7FLC3SKYYGBDEHUOYBU472/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Reverse polish notation
On 4/3/21 7:16 AM, Greg Ewing wrote: > On 3/04/21 6:15 pm, David Mertz wrote: >> It's a long time ago, but I'm pretty sure I used ticker tape adding >> machines with a big ENTER button to separate numbers... Then the >> operation, usually +, at the end. > > That seems unlikely. If you don't tell it what to do with the > numbers until the very end, it needs a stack big enough to hold > all of them. Early RPN calculators typically had a very small > stack, usually about 4 items. Actually, on the traditional tape based adding machine, the key labeled 'Enter' was really a command to add to the running sum. The + key was actually 'Total' and commanded to print the result to the tape. The minus key was sort of the opposite of Enter, it subtracted the entry from the running sum, and depending on the machine, print the current sum. -- Richard Damon ___ 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/7TMTDTZ3Z2L7W2XRYD4MILFSAY45NNRS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Reverse polish notation
I think python only has 3 unary operations, + - and ~ and only + and - can also be binary operations. unary + has less uses, since it normally just passes its argument, if valid, unchanged, but can be used to validate that its argument has the right type. I am not sure if a type could define its own unary+ to do something special, but I thought it could. On 4/2/21 11:19 AM, John wrote: > True. It gets ambiguous when doing n*(-(x + y)) i.e. n x y + - * > (fail). The simplest solution is n 0 x y + - * > > I can't actually think of any other unary operators. > > On Fri, Apr 2, 2021 at 10:54 AM Richard Damon > wrote: >> One problem with trying to mix RPN with in-fix is that some operators, >> like - can be either a unary or binary operation in the in-fix >> notations, distinguished by context. In RPN you have lost that context. >> >> is x y - - the same as -(x-y) or is it x-(-y) ? or is it waiting for >> another operator and be x ?? (-(-y)) or is it expecting a previous >> operand and is ?? - (x-y) >> >> (same with +) >> >> Typical RPN systems get around this by having unary - be a different >> symbol/key that binary - >> >> -- >> Richard Damon >> >> ___ >> 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/LX5T33N6IU6IMDKXU4KQMA2RP6U627CG/ >> Code of Conduct: http://python.org/psf/codeofconduct/ -- Richard Damon ___ 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/NCAY6SMGQJBRID7AYR6JWOTJGV7CZDGW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Reverse polish notation
One problem with trying to mix RPN with in-fix is that some operators, like - can be either a unary or binary operation in the in-fix notations, distinguished by context. In RPN you have lost that context. is x y - - the same as -(x-y) or is it x-(-y) ? or is it waiting for another operator and be x ?? (-(-y)) or is it expecting a previous operand and is ?? - (x-y) (same with +) Typical RPN systems get around this by having unary - be a different symbol/key that binary - -- Richard Damon ___ 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/LX5T33N6IU6IMDKXU4KQMA2RP6U627CG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: allow initial comma
On 3/16/21 8:22 AM, Roland Puntaier via Python-ideas wrote: > On Mon 21Mar15 15:18, Paul Bryan wrote: >> On Mon, 2021-03-15 at 11:13 +0100, Roland Puntaier via Python-ideas >> wrote: >> >>> I hesitate to call this proposal a language change. It is rather a >>> syntactic allowance, like that of the trailing comma before the >>> terminating token. >> >> If implemented, such a proposal would in fact require a change to the >> language specification. > > Yes. What I meant is, that it is minor, > equivalent to the `,]` change. > >> >>> Can `x=[,1,2]` possibly be used for some future language feature, >>> liking making `[,` a operator of its own? Considering that one has >>> already decided that `,]` will not be allowed to have a separate >>> meaning in the future, then, so should neither `[,`. >> >> It would be helpful to me to understand what friction you're currently >> experiencing without such a change. I'm still struggling to appreciate >> what the benefit would be, beyond aesthetic preference. > > I'd like to write > > def my_long_function_name( > , my_long_option_2 = "some default expression 1".split() > , my_long_option_1 = "some default expression 1".split() > ): > pass > > Then, I'd like to change the order of the lines without having to care > to remove and add a comma. > > To allow `,]` was motivated by aesthetic preferences (PEP8). > To allow both `[,`, and `,]` is aesthetically more neutral. > > So, the proposal is based on the already done `,]` language feature. > The proposal adds some syntactic flexibility, > which avoids errors in situations like the one described. My thought is that there is a line in the Zen > There should be one-- and preferably only one --obvious way to do it. That says that the langauge doesn't desire to be aesthetically neutral, but will intentionally choose a preferred way to do something. Other ways may be possible, if there is a good reason (and sometimes that is just due to backwards compatibility when a better way to do something in discovered). This rule is even literally baked into the language due to 'import this' I think this means you need a stronger motivation than you just want another way to do the same thing, -- Richard Damon ___ 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/US5MJJA2KTE6QVCX5GR5ORZWLSICX6GO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Allow trailing operators [was: allow initial comma]
Simple solution for trailing | is put False on the next line.
> On Mar 12, 2021, at 12:07 PM, Henk-Jaap Wagenaar
> wrote:
>
>
> This is a definite tangent. Trailing commas are great for reducing git diffs,
> not making errors when moving things around (missing commas, which e.g. in
> strings causes concatenation) but I have often wondered whether the same
> could be extended to (some?) logical or arithmetic operators, in particular:
>
> Currently one has to write a logical expression as (using Django Q objects):
> (
>Q(user=user) |
>Q(is_deleted=True)
> )
>
> and then removing/adding clauses is difficult, whereas if "trailing
> operators" where allowed, there would be no such issue:
>
> (
> Q(user=user) |
> Q(is_deleted=True) |
> )
>
> Just like with trailing commas, the "additional" operator would be ignored. I
> guess (technically) it won't have to match the previous operator, it could
> just be any operator with no argument after it.
>
> Unlike with trailing comma, I think an operator on its own would not be
> allowed (e.g. "(|)" or "|") as it's meaning-as-intended will be context
> dependent (e.g. in this example, the correct answer is a Q() object).
>
> I am happy to flesh this out more, but as this discussion was ongoing, I
> thought I would throw it out here and see what people think? Are there
> potential problems with this e.g. with parsing it?
>
>> On Fri, 12 Mar 2021 at 14:28, Paul Bryan wrote:
>> It seems your proposal is intended to address an aesthetic concern. Is there
>> a case where using a leading comma would make something actually easier or
>> more intuitive to express over the use of trailing comma?
>>
>>> On Fri, 2021-03-12 at 10:34 +, roland.puntaier--- via Python-ideas
>>> wrote:
>>> I had posted this as https://github.com/python/peps/issues/1867
>>> The discussion so far is below.
>>>
>>> Please make some arguments.
>>>
>>> The major point to me is, that the symmetry is broken,
>>> which leads to extra editing actions, like removing the comma in the first
>>> line.
>>> I guess, this was the reason to allow the comma after the last line/entry:
>>> `[1,2,]`.
>>> ``[,1,2]`` should also be allowed, too.
>>>
>>> The best argument is one that says: less or more effort in this or that
>>> situation.
>>> For example, with `[1,2,]`, in line-wise formatting,
>>> one can do without special action at the last line (removing the comma
>>> there).
>>>
>>> All code from previous versions of Python would still work
>>> after a `[,1,2]` syntax allowance were introduced.
>>>
>>>
>>> =
>>> rpuntaie wrote:
>>> =
>>>
>>> Allow initial comma
>>> ===
>>>
>>> Final comma works:
>>>
>>> t = (
>>> 1,
>>> 2,
>>> )
>>> x = [
>>> 1,
>>> 2,
>>> ]
>>> y = {
>>> 1,
>>> 2,
>>> }
>>> z = {
>>> 1:11,
>>> 2:22,
>>> }
>>> def fun(
>>> a,
>>> b,
>>> ):
>>> pass
>>>
>>> Initial comma does not work:
>>>
>>> t = (
>>> , 1
>>> , 2
>>> )
>>> x = [
>>> , 1
>>> , 2
>>> ]
>>> y = {
>>> , 1
>>> , 2
>>> }
>>> z = {
>>> , 1:11
>>> , 2:22
>>> }
>>> def fun(
>>> , a
>>> , b
>>> ):
>>> pass
>>>
>>>
>>> To make the syntax symmetric in this regard\
>>> gives more freedom to format the code.
>>>
>>> I occasionally found the restriction an unnecessary nuisance.
>>>
>>> Before writing a PEP, I would like to discuss,
>>>
>>> - whether something like that has been proposed already?
>>> - what counter-arguments there could be?
>>>
>>> =
>>> pxeger wrote:
>>> =
>>>
>>> This is not the appropriate place to propose language changes.
>>> Try the
>>> [python-ideas](https://mail.python.org/mailman3/lists/python-ideas.python.org/)
>>> mailing list. However, I don't think you'll get anyone to agree.
>>>
>>> What kind of code style are you using where you want to put commas at
>>> the start of the line? That is totally non-standard
>>> (see [PEP 8](https://www.python.org/dev/peps/pep-0008)), ugly, and
>>> confusing.
>>>
>>> Arbitrary symmetry is not a good reason for changing the language. We
>>> don't have a `tnirp` function just for the sake of symmetry with
>>> `print` because it would be pointless and add extra complication
>>>
>>>
>>> =
>>> rpuntaie wrote:
>>>
[Python-ideas] Re: list.extend() should return self
On 3/3/21 3:23 PM, Hans Ginzel wrote: > Please, is there a reason why extend() method does not return self? > >>>> a = [1,2].extend((3,4)) >>>> a >>>> type(a) > >>>> b = [1,2] >>>> b.extend((3,4)) >>>> b > [1, 2, 3, 4] I think it just the general principle that mutating methods return None, while methods that create a new object return that object. Thus you use the return type if you expect a new object, and getting None alerts you to the fact that it mutated the original instead of just makeing a new object for the answer. -- Richard Damon ___ 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/DJWSWQQCPTKDXE3EKVTUWESI44QMFZU7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Deprecate/change the behaviour of ~bool
On 2/24/21 12:34 PM, Chris Angelico wrote: > On Thu, Feb 25, 2021 at 4:28 AM Barry Scott wrote: >> >> >> On 23 Feb 2021, at 22:10, Steven D'Aprano wrote: >> >> There are exactly 2**4 = 16 boolean operators of two variables. Python >> only supports two: `and` and `or`. Plus a single unary operator `not` >> (out of four possible unary operators). What makes xnor so special that >> you want it to be an operator? >> >> >> Python implements more then 2 of them: >> >> True >> False >> not >> and >> or >> >> https://en.wikipedia.org/wiki/Boolean_algebras_canonically_defined#Truth_tables >> > True and False aren't operators in Python. Notionally you could say > that "take any input(s) and return True" could be considered an > operator in theory, but you can't write "x True y" to achieve that in > Python. > > ChrisA True, but you aren't really going to define real operators in a language that always ignore one or both of their arguments. Thus, of the 16 theoretical operators in the list, the 6 that don't depend on both values aren't going to get a real operator, and if you actually want that operation, you do have a 'spelling' in Python for it. -- Richard Damon ___ 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/JGI4BCKWGOARIXRC55FAJN6AENH4IXLI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Deprecate/change the behaviour of ~bool
On 2/24/21 12:26 PM, Barry Scott wrote: > > >> On 23 Feb 2021, at 22:10, Steven D'Aprano > <mailto:st...@pearwood.info>> wrote: >> >> There are exactly 2**4 = 16 boolean operators of two variables. Python >> only supports two: `and` and `or`. Plus a single unary operator `not` >> (out of four possible unary operators). What makes xnor so special that >> you want it to be an operator? > > Python implements more then 2 of them: > > True > False > not > and > or > > https://en.wikipedia.org/wiki/Boolean_algebras_canonically_defined#Truth_tables > <https://en.wikipedia.org/wiki/Boolean_algebras_canonically_defined#Truth_tables> > > Barry > Of the unary, python implements them all, the possible opererators for op a are: True False a not a Of the 16 binary operators a op b you can get: * True * False * a * b * not a * not b * a and b * a or b and for things that are already bools, you can use * a < b * a <= b * a == b * a != b * a > b * a >= b The only combinations you can't get with a simple operator are 'not (a and b)' and 'not (a or b)' (nand and nor) assuming you are starting with true bools (or 0 and 1). If you only have 'truthy' values, you only get 1/2 of the possible options. -- Richard Damon ___ 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/Q4TMNRVBDVIM6FC65JDE5DG4YHV5FWQO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Arrow functions polyfill
On 2/23/21 5:01 PM, Rob Cliffe via Python-ideas wrote:
>
>
> On 23/02/2021 17:46, Stéfane Fermigier wrote:
>>
>>
>> On Tue, Feb 23, 2021 at 6:13 PM Richard Damon
>> mailto:rich...@damon-family.org>> wrote:
>>
>>
>> Also note, that I am not saying that 'arrow-functions' can't happen,
>> just that if they are created, a natural consequence is that,
>> like with
>> .format(), the 'old' (lambda) way will need to be marked as
>> 'old', and
>> not the current obvious way.
>>
>>
>> If there is a consensus that arrows are better enough that lambdas,
>> and arrows happen, lambdas will be considered 'old' and automated
>> converters such as pyupgrade will be quick to replace lambdas (and
>> people publishing libraries will have to wait until the EOL of the
>> older versions of Python before being able to run it).
>>
>> And if, otherwise, there is no such consensus, the change will never
>> happen.
>>
>> Same as u"xxx" versus Unicode("xxx"), x**y vs pow(x, y), x @ y
>> vs. matmul(x, y), etc.
>>
>> S.
>>
> As far as I know, there is no case of valid syntax using 'lambda'
> where replacing 'lambda' by 'def' results in valid syntax.
> Can anyone provide a counter-example?
> If not, I would support allowing 'def' as an alternative to 'lambda'
> (allowing 'def' to ultimately become the recommended usage).
> (I'm -0.5 on adding an alternative arrow syntax, but that's a purely
> subjective opinion.)
> Rob Cliffe
My one thought is that if one issue with making a multi-statement lambda
is that the parser can't tell if it needs a statement block or an
expression (for current lambda), that def in this format could be the
syntax to get to the multi-statement 'lambda'.
--
Richard Damon
___
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/OBQGB6QHKKMW3A5ZTFEOG4APO677ID43/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Arrow functions polyfill
On 2/23/21 10:07 AM, Paul Sokolovsky wrote:
> Hello,
>
> On Tue, 23 Feb 2021 09:35:58 -0500
> Richard Damon wrote:
>
> []
>
>> My first thought to the idea of making an alternate syntax is the line
>> from the Zen:
>>
>> There should be one-- and preferably only one --obvious way to do it.
>> Although that way may not be obvious at first unless you're Dutch.
>>
>> This says that if the 'arrow' is a new alternate way of writing
>> lambda, then lambda needs to be, at least informally, deprecated and
>> declared not to be that obvious way to do it (but it can't be
>> actually removed for a long time for backwards compatibility reasons).
> No more than "+" deprecates __add__, or vice-versa. And no more than
> various pop-up novelties (we now have more than one) deprecate sacred
> '"%s" % var' syntax.
The difference with + is that it NEVER was the case that the 'preferred'
way to add two values was with a direct call to __add__ (it was just an
internal implmentation detail for the operator).
As far as formatting strings, yes, there are multiple ways to do similar
things, but there are also significant differences between them. If we
look at 'f-strings' as the example, I beleive f-strings are now
considered the 'preferred obvious' way to do it, when it is applicable,
but that there are still significant cases where you can't use the
f-string, because it is a 'compile' time construct. For things like
translation strings, where the string comes from some string store, and
at run time combined with the variable, you still need do this with the
older % or .format() method.
As far as between % or .format(), I think the documentation is fairly
clear that the % method is 'old' and if not 'formally' deprecated, is no
longer considered the 'obvious' way to do it (even if some people will
still do it that way for the simplest cases).
>> Note, I thought that lambda was currently 'multi-line', it just isn't
>> multi-statement, just a single expression, that could flow to
>> following lines (and since often used inside a function call, being
>> inside the '(' makes the continuation to the next line automatic)
> Yes, people who colloquially say "multi-line", formally mean
> multi-statement. (Alternatively, they mean "multi-line without tricks".)
People colloquially using the wrong words shouldn't get surprised when
they get corrected. It isn't a 'trick' to make a Python expression
'multi-line', it is just standard Python formatting.
Now, if lambda can 'grow up' to be a 'multi-statement expression' (whch
I think is part of the issue) then perhaps there is room for both lambda
and 'arrow functions', just like string formatting has both f-strings
and .format().
That is a big 'IF', as putting statement-blocks into code as pieces of
an expression, is a cognitive barrier, and may well require a syntax
change (perhaps using an anonymous def inside the expression), and I am
not sure how common it can be found (I know in C, it is only available
as a semi-common extension in some compilers).
Also note, that I am not saying that 'arrow-functions' can't happen,
just that if they are created, a natural consequence is that, like with
.format(), the 'old' (lambda) way will need to be marked as 'old', and
not the current obvious way.
--
Richard Damon
___
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/IQOPRB4NQBLXNGGHGOETIKYPAWQAMPUE/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Arrow functions polyfill
On 2/23/21 7:57 AM, Paul Sokolovsky wrote:
> Hello,
>
> On Tue, 23 Feb 2021 23:29:33 +1100
> Steven D'Aprano wrote:
>
>> On Tue, Feb 23, 2021 at 11:27:12AM +0100, Stéfane Fermigier wrote:
>>
>>> Also: I know there are several modern computer languages that use
>>> arrows to represent anonymous functions (JS, Kotlin, Scala...).
>> Javascript: first release was 1995, making it 25 years old. It's
>> older than most Javascript programmers.
>>
>> Kotlin is only 9 years old. But Scala is 17 years old.
>>
>> (By the way, Julia calls the -> arrow "the stab operator". I think
>> that's amusing.)
>>
>> Python has a long history of taking inspiration from other languages,
>> but we've had anonymous functions for longer than Javascript has
>> existed. This proposed arrow function would just be an alternative
>> spelling for the same thing. It adds no more power, and no more
>> expressiveness to the language.
>>
>> It would be just one more thing to learn, one more decision to make
>> ("lambda or arrow?"), one more question to be asked a thousand times
>> ("what's the difference between lambda and arrow?").
> So, (unlike JS) we should make sure that there's no (semantic)
> difference between lambda and arrow functions, and the answer to
> "which?" should be "what you want or whatever your boss says".
>
> (Btw, syntactically, there may be difference. I hope that we'll
> eventually extend lambda to multiline, I'm not so sure about arrow. Of
> course, with braces syntax variant both will be multiline).
>
My first thought to the idea of making an alternate syntax is the line
from the Zen:
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
This says that if the 'arrow' is a new alternate way of writing lambda,
then lambda needs to be, at least informally, deprecated and declared
not to be that obvious way to do it (but it can't be actually removed
for a long time for backwards compatibility reasons).
Note, I thought that lambda was currently 'multi-line', it just isn't
multi-statement, just a single expression, that could flow to following
lines (and since often used inside a function call, being inside the '('
makes the continuation to the next line automatic)
--
Richard Damon
___
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/QTV5QBZUKSNDT4EYFSRJO3KECO2BPWY6/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding `open_text()` builtin function. (relating to PEP 597)
On 1/24/21 1:18 PM, MRAB wrote: > On 2021-01-24 17:04, Chris Angelico wrote: >> On Mon, Jan 25, 2021 at 3:55 AM Stephen J. Turnbull >> wrote: >>> >>> Chris Angelico writes: >>> > Right, but as long as there's only one system encoding, that's not >>> > our problem. If you're on a Greek system and you want to decode >>> > ISO-8859-9 text, you have to state that explicitly. For the >>> > situations where you want heuristics based on byte distributions, >>> > there's always chardet. >>> >>> But that's the big question. If you're just going to fall back to >>> chardet, you might as well start there. No? Consider: if 'open' >>> detects the encoding for you, *you can't find out what it is*. 'open' >>> has no facility to tell you! >> >> Isn't that what file objects have attributes for? You can find out, >> for instance, what newlines a file uses, even if it's being >> autodetected. >> >>> > In theory, UTF-16 without a BOM can consist entirely of byte values >>> > below 128, >>> >>> It's not just theory, it's my life. 62/80 of the Japanese "hiragana" >>> syllabary is composed of 2 printing ASCII characters (including SPC). >>> A large fraction of the Han ideographs satisfy that condition, and I >>> wouldn't be surprised if a majority of the 1000 most common ones do. >>> (Not a good bet because half of the ideographs have a low byte > 127, >>> but the order of characters isn't random, so if you get a couple of >>> popular radicals that have 50 or so characters in a group in that >>> range, you'd be much of the way there.) >>> >>> > But there's no solution to that, >>> >>> Well, yes, but that's my line. ;-) >>> >> >> Do you get files that lack the BOM? If so, there's fundamentally no >> way for the autodetection to recognize them. That's why, in my >> quickly-whipped-up algorithm above, I basically had it assume that no >> BOM means not UTF-16. After all, there's no way to know whether it's >> UTF-16-BE or UTF-16-LE without a BOM anyway (which is kinda the point >> of it), so IMO it's not unreasonable to assert that all files that >> don't start either b"\xFF\xFE" or b"\xFE\xFF" should be decoded using >> the ASCII-compatible detection method. >> >> (Of course, this is *ONLY* if you don't specify an encoding. That part >> won't be going away.) >> > Well, if you see patterns like b'\x00H\x00e\x00l\x00l\x00o' then it's > probably UTF16-BE and if you see patterns like > b'H\x00e\x00l\x00l\x00o\x00' then it's probably UTF16-LE. > > You could also look for, say, sequences of Latin characters and > sequences of Han characters. > Yes, if you happen to see that sort of pattern, you could perhaps make a guess, but since part of the goal is to not need to read ahead much of the file, it doesn't become a very reliable test to confirm UTF16 file in case they don't begin with Latin-1 characters. -- Richard Damon ___ 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/KU7YLC3MZP3SVOAP2YPBQO5H4DIRUBWQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding `open_text()` builtin function. (relating to PEP 597)
On 1/24/21 6:00 AM, Chris Angelico wrote: > Sorry, let me clarify. > > Can anyone give an example of a current system encoding (ie one that > is likely to be the default currently used by open()) that can have > byte values below 128 which do NOT mean what they would mean in ASCII? > In other words, is it possible to read in a section of a file, think > that it's ASCII, and then find that you decoded it wrongly? EBCDIC is one big option. There are also some National Character sets which change a couple of the lower 128 characters for use with characters that language needed. (This was the cause of adding Trigraphs to C, to provide a way enter those characters on systems that didn't have those characters. One common example was a Japanese character set that replaced \ with the Yen sign (and a few others) and then used some above 128 codes for multi-byte sequences. Users of such systems just got used to use the Yen sign as the path separator. The EBCDIC cases would likely be well know on those systems, and planned for. Having a system with a few of the lower 128 being substituted for could be a bigger surprise for a system. -- Richard Damon ___ 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/24PLMY635JZAS32BY2G5YVHBXTQPEFE5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Standard tool for iterating over recursive data structures?
It might not be that surprising to use a list if you are already using that list to keep track of your position in the hierarchy. You can probably assume that most of the time the depth is fairly low so the cost of scanning is low enough that the cost of building and updating the set costs enough that there aren't significant savings. On 1/1/21 7:38 PM, Samuel Freilich via Python-ideas wrote: > Interesting to look at the code for some of this. > > list.repr and dict.repr seem to be taking the "construct a set of seen > items" approach. Except it's not using a set of ids, it's doing a > linear pass over a list of visited PyObjects each time (which seems > somewhat surprising to me, though it's only O(n*d) where d is the > nesting depth, not O(n^2)): > https://github.com/python/cpython/blob/3bf05327c2b25d42b92795d9d280288c22a0963d/Objects/object.c#L1974 > <https://github.com/python/cpython/blob/3bf05327c2b25d42b92795d9d280288c22a0963d/Objects/object.c#L1974> > > copy.deepcopy keeps track with a dict: > https://github.com/python/cpython/blob/3bf05327c2b25d42b92795d9d280288c22a0963d/Lib/copy.py#L138 > <https://github.com/python/cpython/blob/3bf05327c2b25d42b92795d9d280288c22a0963d/Lib/copy.py#L138> > > (That uses a sentinel object as the default for the lookup so it can > tell if that's explicitly set to None, though that seems convoluted > compared to just checking whether the value is None or not. Is that > considering that "copy.deepcopy(x) is None and x is not None" might be > true?) > > Peace, > -Sam > > On Fri, Jan 1, 2021 at 7:07 PM Greg Ewing <mailto:greg.ew...@canterbury.ac.nz>> wrote: > > On 2/01/21 6:14 am, Jeff Allen wrote: > > we may as > > well say that the required result takes the form of an iterable > of the > > nodes, which may subsequently be iterated by a consumer. > > In general you need more than that, I think. If you're printing > a representation of the graph, you want to know about the structure, > not just get a flat list of nodes. > > > But we must have to do something > > very similar to pickle arbitrary (potentially cyclic) > structures, which > > is likewise dependent on special help from the particular > built-in type. > > Can something be founded on |||__getstate__| ? > > I don't think so. All the logic for dealing with cycles is buried > inside pickle -- __getstate__ just gets info about one object. > > -- > Greg > -- Richard Damon ___ 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/M55CUGTDN56E34WJANQ4CZZPKPBDMP74/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Standard tool for iterating over recursive data structures?
On 1/1/21 2:00 PM, Jonathan Fine wrote: > 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 > Second problem first, Two numbers that are equal may or might not be stored in the same object. It is unspecified. As to the first, just because to points have equal values doesn't mean that we have recursion. That is why I put the id()s in the set, the id()s are by definition hashable, and an object always has the same id() and no two different objects can have the same id(). Simple example: list1 = [ ['one', 'two'], ['one', 'two'] ] The first and second member of the above list are equal, but not the same object. Thus there is no reason to want to try to trim the second from an output. list1 = ['one', 'two'] list2 = [list1, list1] now the first and second member of the list list2 are both equal and the same object. Perhaps we might want to indicate this in a dump, but maybe not. list1 = ['one', 'two'] list1.append(list11) Now the third element of the list list1 IS the same object as list1, so we definitely want to not try and show it when we display the value of list1, but instead indicate that we have recursion. Even further: list1 = ['one', 'two'] list1.append(list1) list2 = ['one', 'two', list1] Now list2 will be equal to list1 but is a distinct object. Now the expansion of list2 will be: ['one', 'two', ['one', 'two', [...]]] We don't want to test for EQUAL nodes, we want to test for SAME nodes (same object, same id()) -- Richard Damon ___ 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/QVRB4IT3WT6NS3L64CNL2Z2QLCH5DO2H/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Standard tool for iterating over recursive data structures?
On 1/1/21 12:14 PM, Jeff Allen wrote: > On 01/01/2021 14:50, Jonathan Fine wrote: >> ... >> To summarise, it's loops / cycles in the representation of the data >> that's the problem. ... . >> >> Final idea. Perhaps a tool to detect cycles in data might be a good idea. >> > Detecting cycles will involve a lot of bikeshedding. (Sorry, couldn't > resist.) > > 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). > > If memory serves me right, what we're talking about is finding and > walking a "spanning tree" of the graph. There is a twist in our case > that we would like to insert a special object where a link was elided > to break the cycle: an object that maybe contains the original > reference but would reproduce as "..." in print. > > Since it appears necessary to create a data structure with as many > nodes as there are in the tree, just to remember where we've been, we > may as well say that the required result takes the form of an iterable > of the nodes, which may subsequently be iterated by a consumer. > Actually, I can think of two styles of iterator: one where "..." > objects are skipped by a "processing" iterator, and one where they are > delivered by a "print" iterator. It is valid to do this with objects > that can't be hashed, so the structure is perhaps a dict keyed by id. > > Would this be possible as a general capability? I think only if the > references were in the __dict__ of each instance. With a built-in, one > is at the mercy of the implementor. But we must have to do something > very similar to pickle arbitrary (potentially cyclic) structures, > which is likewise dependent on special help from the particular > built-in type. Can something be founded on |||__getstate__| ? > > Happy New Year > > Jeff Allen > 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. -- Richard Damon ___ 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/OXZ4GP27ZWDEONUZQ3MCBOHPQYAM2FZJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Standard tool for iterating over recursive data structures?
ld
today).
Once you move the listing of links into the node itself, as opposed to
having a separate listing of all the vertices, and make the links to
node rather than names (to avoid an extra unneeded lookup) then you get
the recursive data structure.
For your example you say that can not be represented, let us build a
graph G as a dictionary, with the key being the name and the value being
the 'Node' for that person. (This assumes names are unique, otherwise it
might just need to be a list)
That node will be a dictionary, where we can store all sorts of
properties, but lets define one with a key 'secure' that has as its
value a listing of all the nodes this node knows how to directly send to.
Thus we could define the graph as:
g = {
'Alice': {'secure': []},
'Bob': {'secure': []},
'Carol': {'secure': []},
'Dave':, {'secure': []}.
'Eve':, {secure': []},
}
now we can add connections with something like:
g['Alice']['secure'].append(g['Bob'])
Note that this structure doesn't really even need g to exist at all, it
is only needed to initially find the nodes, the nodes could easily be
independent variables, or perhaps different nodes are in different
structures if they are obtained from different sources. (Node likely
will have a property in them to provide a human recognizable name for them).
Yes, perhaps at this point it might make sense to make the nodes an
actual class as opposed to just a dict, which sort of breaks the cycle
as by default __repr__ and such don't expand through class objects, but
that then changes the mindset from a data-driven to an object based
design, and depending what else the program needs to interface to one or
the other might be more complicated.
--
Richard Damon
___
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/KN6UQTIIGHLXYFYOAMY2PWLM44SNONE6/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Standard tool for iterating over recursive data structures?
On 1/1/21 9:50 AM, Jonathan Fine wrote: > Hi > > I'd say the problem isn't recursion. Here I'm using the definitions > given in: > https://en.wikipedia.org/wiki/Recursion > <https://en.wikipedia.org/wiki/Recursion> > https://www.cs.utah.edu/~germain/PPS/Topics/recursion.html > <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. 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) Maybe more generally the nodes would be dicts of properties, one of which is a connection property with that list of nodes, but you still end up with the same recursion. > > 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 > <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 > -- Richard Damon ___ 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/HC6KXTAD2ROTXRSZXTXD4CVZ25SB2L2Q/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Move semantics
On 11/26/20 12:07 PM, Guido van Rossum wrote: > This reminds me of something in C++. Does it exist in other languages? > A key point is that C++ needs 'move' behavior as its variables are buckets of bits, and assigning one variable to another, like in a call, requires copying that whole bucket of bits, and if it refers to other buckets of bits, may need to copy them too. One thing that can be done when making this assignment, if the original isn't going to be needed is to 'steal' those buckets that the first object pointed to, possibly saving a lot of work. Python doesn't need to do this, as it isn't based on a bucket of bits type model, but its names are just bound to objects, and can readily share. Another way to think of the issue is it is mostly an issue with using Call By Value, which is the basic way to pass parameters in C and C++ (there is also a 'Call By Reverence' which is really just a Call by Value, where the value is a pointer, maybe with syntactic sugar to hide the pointerness) Python doesn't use Call by Value, but its method is better described as Call by Binding, the parameters in the function are bound to the pbjects specified in the call. If those objects are mutable, the function can change the object that the caller gave, but can't 'rebind' any variable names in the call statement to new objects. -- Richard Damon ___ 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/5VKCC6OIDEFX74UUYAA77RZR4KJREUO4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Circular Indexing
On 11/24/20 2:36 PM, Mathew M. Noel via Python-ideas wrote: > > Python uses an index of -1 to index the last element in a list. Since > -1 occurs before 0 we might think of the elements of the linear list > are being bent into a circle making the last element occur before the > 0th element. Consider a list with n elements: it would be perfectly > reasonable to address the element 0 of the list using an index of n > since n occurs after n-1 (if we assume that the list is bent into a > circle). This feature can prove to be extremely useful. Consider the > following example: > > > days_of_the_week = > ["Sunday","Monday","Tuesday","Wednesday","Thursday","Friday","Saturday"] > It would be nice if > days_of_the_week[0] > is the same as > days_of_the_week[7] is the same as > days_of_the_week[14] etc In other words use modular indexing. In other > words if the index is outside the range 0 to n-1, we simply take the > remainder when the index is divided by n as the index. Because of the > close relationship between finite length sequences and periodic > sequences this feature might simplify scientific computing(circular > convolution etc). If I wanted this sort of indexing, using % works very well. Losing the error detection of out of bounds indexing would be very bad in most cases. As I think about this, the only cases that I would likely do this will have a fixed sized list (like the 7 days of the week) it makes it fairly trivial. -- Richard Damon ___ 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/4JY7TYHM3FZYEFSPVTOGBXZQETAWZPSZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding PyInstaller to the standard library
On 11/19/20 7:04 PM, Oscar Benjamin wrote: > On Thu, 19 Nov 2020 at 23:13, Chris Angelico wrote: >> On Fri, Nov 20, 2020 at 10:05 AM Eric V. Smith wrote: >>> I just don't think we need to be immediately dismissive of people's >>> desire to create a platform native executable that disguises the fact >>> that the code is written in Python. >>> >> I never said it shouldn't happen. But having zipapp in the standard >> library and all native executable creators as third party apps gives a >> clear indication that a .pyz file should be considered first, and a >> native executable only if that isn't suitable. > In my experience there is a wide spectrum of different end "users" to > be targeted when thinking about packaging an application. I quite > often find myself in the situation where I'm providing code to people > who are also able to write code and I can just point them to github or > wherever and they can read the README and get everything set up. At > the other extreme I work with people who have no idea what "Python" is > and might struggle to use my application even if it was actually > configured and installed on their computer and in the applications > menu, had great instructions etc. > > Somewhere in this spectrum there is a usecase for zipapp which is > something like "all my users have Python already installed but do not > necessarily know how to use it". I haven't personally found a > situation where this applies and haven't used zipapp as a result. > > Packaging applications is something where Python's usability could be > improved enormously. Other languages also suffer around this in > different ways but if Python had a simple and reliable (if not full > featured approach) then that would be very useful. There has been a > lot of progress with packaging and distributing Python libraries which > is very welcome but support for distributing even very simple > applications is lacking. > > > Oscar Yes, I am working an a application. I know that a lot of people who will want to be able to use it, really will need for it to be just a file they can download and run on windows. They probably could handle getting a file they run to 'install' the program which they can then run from the Windows start menu or Desktop. I will probably also see about packaging it to run easily like that on a Mac. I will also make the source available for the minority of users that will be able to install python and the needed modules (and who hopefully will be able to submit improvements or continue support when I can't anymore) It would be nice, if there was a built in way to easily package a program for these sorts of people, but as long as there is a way to do it, it is ok. (Need to look over my options and figure out which one(s) will work the best). -- Richard Damon ___ 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/SB3HTATI3WAQC65RODAQYQSQJCNVKSQR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add _KB, _MB, _GB to numeric literals
On 10/13/20 1:06 AM, malin...@163.com wrote: > PEP 515 added underscore to numeric literals, it brings better readability. > > PEP 515 -- Underscores in Numeric Literals > https://www.python.org/dev/peps/pep-0515/ > > Is it possible to add _KB, _MB, _GB to numeric literals, for example: > > 200_KB (200*1024) > 150_MB (150*1024*1024) > 2_GB (2*1024*1024*1024) > > Do you think it's a good code style? That is easy enough to do with just a slight change in syntax: KB = 1024 MB = 1024*1024 GB = 1024*1024*1024 200*KB 150*MB 2*GB -- Richard Damon ___ 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/7J6C7KWMQUXUF2GJZX34R6BTRV3MPP4F/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Exceptions as function calls to kill boilerplate
On 10/12/20 10:18 PM, William Pickard wrote: > Once against, need I remind you that Python doesn't support defining output > variables like C#/.NET does, the only way to do it is via the globals/locals > dict objects which must either be manually provided or fetched from the > stacktrace. Python supports output variables in a limited fashion, you can pass in a mutable object (like a list), that the function can mutate to return an 'output' value. What Python can't do is rebind a name provide by the caller to a new object, thus a parameter bound to an immutable object (like a number or string) can't have its value changed. -- Richard Damon ___ 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/OUHNCBZT54Q7M52JWNYUHRNSG4R7UJM3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
On 10/11/20 5:47 PM, Wes Turner wrote: > Indeed, perhaps virtual particles can never divide by zero and thus > the observed laws of thermodynamic systems are preserved. > > Would you please be so kind as to respond in the main thread so that > this is one consecutive thread? > > No, 2 times something is greater than something. Something over > something is 1. > If we change the division axiom to be piecewise with an exception > only for infinity, we could claim that any problem involving > division of a symbol is unsolvable because the symbol could be > infinity. > This is incorrect: > x / 2 is unsolvable because x could be infinity > x / 2 > x / 3 (where x > 0; Z+) is indeterminate because if x is > infinity, then they are equal. > > > Which of these are you arguing should fail if Python changes to > returning [+/-]inf instead of raising ZeroDivisionError? > > > assert 1 / 0 != 2 / 0 > assert 2*inf > inf > assert inf / inf == 1 > All of them will fail. n / 0 is inf or -inf depending on whether n is positive or negative (and I believe 0/0 is NaN) n * inf is inf, for all n > 0 inf / inf in NaN (if I remember right). infinity is NOT just a number that behaves like any finite number. Maybe you should look into the rules for transfinite mathematics, a lot of the rules that apply for finite mathematics don't work when you allow for non-finite numbers. Note, that for example you last example, the answer of Z+ is correct, as Z+ does NOT include infinity, so the case where x is infinity, is outside the domain Z, or even R. Also note, the the Axioms like the Division Axiom apply to the domains of Finite numbers, and not all of them apply when you get Infinities. This is just like some properties in the Real do not apply when you move to the Complex plane. > > On Sun, Oct 11, 2020 at 5:41 PM Richard Damon > mailto:rich...@damon-family.org>> wrote: > > On 10/11/20 5:04 PM, Wes Turner wrote: > > So you're arguing that the scalar is irrelevant? > > That `2*inf == inf`? > > > > I disagree because: > > ```2*inf > inf``` > > > > And: > > > > ```# Given that: > > inf / inf = 1 > > > > # When we solve for symbol x: > > 2*inf*x = inf > > 2*x = 1 > > x = 1/2 > > > > # If we discard the scalar instead: > > 2*inf*x = inf > > inf*x = inf > > x = 1 > > > > # I think it's specious to argue that there are infinity solutions; > > that axioms of symbolic mathematics do not apply because infinity > > ``` > > > Treating inf as any other number because it works out > 'symbolically' is > one of the recipes that allow you to prove that 1 == 2, thus symbolic > math needs to work with certain preconditions that avoid the > generation > of 'numbers' like infinity into the system (or somewhat related, > avoid a > divide by 0) > > -- > Richard Damon > ___ > Python-ideas mailing list -- python-ideas@python.org > <mailto:python-ideas@python.org> > To unsubscribe send an email to python-ideas-le...@python.org > <mailto:python-ideas-le...@python.org> > https://mail.python.org/mailman3/lists/python-ideas.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/SQNY5WFVPRPWXRZ7FW3H3RUGM3UCLCCL/ > > <https://mail.python.org/archives/list/python-ideas@python.org/message/SQNY5WFVPRPWXRZ7FW3H3RUGM3UCLCCL/> > Code of Conduct: http://python.org/psf/codeofconduct/ > <http://python.org/psf/codeofconduct/> > > > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/4VUULYAKSLEO46HZ5TO4EIFIFDFV4TK3/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Richard Damon ___ 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/VXUGORIKP75EZD24LJYCKTHGQCGZFDM3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
On 10/11/20 5:04 PM, Wes Turner wrote: > So you're arguing that the scalar is irrelevant? > That `2*inf == inf`? > > I disagree because: > ```2*inf > inf``` > > And: > > ```# Given that: > inf / inf = 1 > > # When we solve for symbol x: > 2*inf*x = inf > 2*x = 1 > x = 1/2 > > # If we discard the scalar instead: > 2*inf*x = inf > inf*x = inf > x = 1 > > # I think it's specious to argue that there are infinity solutions; > that axioms of symbolic mathematics do not apply because infinity > ``` > Treating inf as any other number because it works out 'symbolically' is one of the recipes that allow you to prove that 1 == 2, thus symbolic math needs to work with certain preconditions that avoid the generation of 'numbers' like infinity into the system (or somewhat related, avoid a divide by 0) -- Richard Damon ___ 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/SQNY5WFVPRPWXRZ7FW3H3RUGM3UCLCCL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
On 9/14/20 12:34 PM, Stephen J. Turnbull wrote: > That's fine, but Python doesn't give you that. In floats, 0.0 is not > true 0, it's the set of all underflow results plus true 0. So by your > argument, in float arithmetic, we should not have ZeroDivisionErrors. > But we do raise them. Actually, with IEEE, 0.0 should be all numbers, when rounded to the nearest representation give the value 0. When we get to very small numbers, the 'sub-normals', we get numbers that are really some integral value times 2 to some negative power (I think it is something like 2 to the -1022 for the standard 64 bit floats). This says that as we approach 0, we have sequence of evenly spaced representable values, 3*2**-1022, 2*2**-1022, 1*2**-1022, 0*2**-1022 Thus the concept of "Zero" makes sense as the nearest representable value. Now, as been mentioned, "Infinity", doesn't match this concept, unless you do something like define it as it represents a value just above the highest represntable value, but that doesn't match the name. -- Richard Damon ___ 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/LDQKH6J2GISGQ26TVWZQJNJE5S2TBV3Y/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
On 9/12/20 8:48 PM, Paul Bryan wrote: > I meant to ask, why is nan not comparable? Even: > > >>> math.nan == math.nan > False It's the IEEE definition of nan, a nan will compare unequal to ALL values, even another nan. It is also neither greater than or less than any value. -- Richard Damon ___ 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/MPNZG6PXMDDLLCLMPL5R53JLPSMG2FGE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?
On 8/28/20 8:24 AM, David Mertz wrote: > > As a side note, I don't really get why everyone else thinks a > try/except is the most natural approach while a ternary seems more > obvious to me for this situation. But it kinda connects to me liking > list.get() better, I think... since "not enough items" doesn't seem as > *exceptional* to me as it apparently does to some others. try/except is specifically looking for the error in question, index out of bounds. The ternary requires restating in other words the bounds limit. For instance, for a list of N items, the allowable subscripts are -N to N-1, and the sample ternary is only checking for the upper bound, not the lower, so fails an too small of an index (maybe you know you are only using positive indexes?) Missing this won't happen with try/except. -- Richard Damon ___ 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/XGEFOQIG7DHNXYV3R554TG2KJ6J6R7BM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: FEATURE REQUEST: Make `logging` Module more Pythonic
On 8/24/20 10:39 PM, Adam Hendry wrote: > In the spirit of CHB's recommendation, this is my proposal: > > Would an update/addition/alternative API to the logging module be > considered for inclusion in the stdlib? > > - Use properties and magic methods instead of getter and setter > methods > - Add flag tfor `sys.excepthook` to choose whether to route all > unhandled exceptions to the root logger > - PEP8ify to make source code more readable and "pretty" > - Make module-level `getLogger()` a class singleton, as it's only > to be used once (warrants further discussion; I don't know if this is > unnecessary) > - Provide context managers for loggers to prevent race conditions > (e.g. rather than `getLogger()` have `with logger(__name__)" (warrants > further discussion; I don't know if this is unnecessary) > - Enable iteration over all existing loggers by writing `__len__`s > and `__getitems__` for logging (warrants further discussion; I don't > know if this is unnecessary) > > Again, these are just my thoughts. Mike Miller is right in that the > `logging` module is EXTREMELY intimidating to the new user. This keeps > new users from logging, which (arguably) should be done as best practice. > > On Mon, Aug 24, 2020 at 7:23 PM Adam Hendry > mailto:adam.grant.hen...@gmail.com>> wrote: > > Hello Everyone, > > Uh-oh, I think you misunderstood me. I was trying to be funny. > Raymond always does his "fist-slamming" thing in a funny way, so I > was trying to emulate that. I'm not mad. This is my first feature > request post. > > The `logging` module works, so there's nothing that needs to be > fixed. Believe me, I'm a content-over-form programmer every day of > the week and twice on Sunday. We could make it more Pythonic though. > > One feature I would like to have added though is a flag I can set > to route all unhandled exceptions to the root logger. I need this > for my production GUIs, for example, and I have to override > `sys.excepthook()` to get this to work right now. Not a huge > problem currently, but I think this would be a nice addition to > the module. > > Adam > One comment on getLogger(), my understanding is that this is NOT required to be called just once (but one common code style does), but it has a promise: Multiple calls to getLogger() with the same name will always return a reference to the same Logger object. Now it does have the slight weirditty that the string given is effectively a path into a hierarchy using dots. One strategy is to call it getLogger(__name__) in a file, and if you do that, it is more efficient to set a module level global to it so you don't need to keep calling it (but you can) Following CHB, you might introduce a module object logging.logger that you can use to access the loggers, but the fact that it isn't a flat dictionary makes some of the suggestion not quit as appropriate. -- Richard Damon ___ 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/HWYMAW4MHDE76ZG5UYX67OJQRYMP7MSV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add parse_duration to datetime - a golang like fucntion to parse duration
On 8/23/20 8:16 AM, Stephen J. Turnbull wrote: > Richard Damon writes: > > > As for holidays, why do holidays matter for time. > > They don't. They matter for durations, because humans regularly do > things like schedule a meeting for "one week from today" and then have > to it because it will fall on a holiday observed by their employer. > Why use units like months and cubits? Because "Man is the measure of > all things." People think in terms of such units, and then are > surprised when computers do "stupid" things with them, like convert > them to intervals measured in seconds that are applied to TAI dates, > and so schedule meetings on a holiday. > > Now, if you aren't thinking like a human, all you need are seconds. > Why mess with such a complicated representation combining weeks and > minutes and microseconds? So the OP is evidently thinking in service > of humans. This protocol *will* be used by humans, and I'll guarantee > you those users will occasionally be surprised and annoyed by the > results. > > Steve But a week from Dec 18th IS Dec 25th, just ask any kid. The business logic of special cases like a regularly scheduled event happening on an inappropriate day falls to a higher level of logic. The definition of what is an appropriate day is well beyond the scope of this sort of class, as it is very domain specific, and even event specific. -- Richard Damon ___ 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/NCQB4NG7DQTM5LCWQLXNFAACNEVBEN5S/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add parse_duration to datetime - a golang like fucntion to parse duration
On 8/23/20 7:21 AM, Stephen J. Turnbull wrote: > Richard Damon writes: > > > One issue with allowing Months here is then suddenly an interval > > becomes dependent on when it is, so needs to be keep in a complex > > form, as a month (and year) are variable length time units. > > This is the paradigmatic reason why I don't want this in the stdlib. > There's an irreducible ambiguity between what humans mean by "a month > later" and what timedelta can deal with natively. But if it's going > to be in the standard library, it should be a standard protocol. > > Note that hours have the same problem in jurisdictions that observe > daylight savings time, and minutes have the same problem because of > leap seconds. Weeks have a different problem (or ambiguity): suppose > "1 week later" falls on a holiday? > > So, "consenting adults." The documentation can warn about these > issues. You could also add a flag to accept years and months (and > hours and minutes? ;-). But does something that needs such a flag > belong in the stdlib? You get around leap seconds by just using the right time base, if you use UT1 or TAI then there are no leap seconds, so no problem there. Similarly for Daylight Savings Time, that is only an issue if you are in a frame that changes, if you define you time as a uniform frame (like GMT) then there is no DST to worry about (only when you convert your 'universal time measure' to a 'Local Clock Time' do you need to worry about that. As for holidays, why do holidays matter for time. A week after Dec 18th is Dec 25th, even if much of the world treats that day as differently. Now, if you want to deal with 'Work Weeks' or 'Work Days' then you need something more complicated, just like we had with months. -- Richard Damon ___ 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/M32JGMFHN7CLT3JRZ2YC4URANRKS2GGO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add parse_duration to datetime - a golang like fucntion to parse duration
On 8/22/20 1:07 PM, Stephen J. Turnbull wrote: > If anything is to be added, I would prefer using ISO 8601 durations. > > https://en.wikipedia.org/wiki/ISO_8601#Durations > > The main differences are use of "P" and "T" to signal that it is a > duration and allow both minutes and months to be identified by "M", > and decimal fractions of the smallest unit present are permitted, and > seconds is the smallest unit, so the above would be represented One issue with allowing Months here is then suddenly an interval becomes dependent on when it is, so needs to be keep in a complex form, as a month (and year) are variable length time units. Also, the math gets funny when you do things like this. Jan 31st + 1 month is Feb 28th (or 29th) + 1 month is March 28th (or 29th), but Jan 31st + 2 Months is March 31st, Similarly, adding a month and then subtracting a month doesn't always get you back to your starting time. -- Richard Damon ___ 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/PAHZ6QSHPFZ5ZT57GMJDLTZLCAKQOVZ6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: raise TypeError when giving wrong type of argument in functions
On 8/22/20 11:59 AM, rawmin...@gmail.com wrote: > Oh OK Thank you. > But just a question: do you know any of these modules? The other thread someone suggested: https://github.com/agronholm/typeguard https://github.com/FelixTheC/strongtyping/issues/33 https://github.com/seandstewart/typical/issues/24 -- Richard Damon ___ 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/VKYSAAIBUOYBMAQVENEM2WYQDWQBGZJS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: raise TypeError when giving wrong type of argument in functions
On 8/22/20 10:34 AM, rawmin...@gmail.com wrote: > No. I wanted to know if they can add this suggestion in next versions It has been decided that Python will NOT enforce type annotations itself. There are modules where you can add an annotation to your function to add the checking yourself. -- Richard Damon ___ 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/EAJTYVOKGYW4MYQYTK35P4COG2QXQUC6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Universal set
On 8/10/20 7:20 AM, haael wrote: > myset = set.UNIVERSAL > myset.remove(element) You do realize that set.UNIVERSAL isn't the set of everything anymore? You bound myset to be an alias for set.UNIVERSAL and then modified it. You likely wanted to make a copy of set.UNIVERSAL, not just bind an alias to it here. -- Richard Damon ___ 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/B5U23UQFG5UNWNDDRPG5K6DGOS6XVNQP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: default parameter in fuctions to clean up flow
On 7/27/20 10:01 AM, Peter Moore wrote: > I have had a long standing unanswered question on on stackoverflow: is it > possible to pass a function to a default parameter so that you could do in > essence things like this. > > def time_diff(target_time, curr_time= lambda : datetime.now() ): > return curr_time - target_time > > this would be an syntactical improvement over this style where you have if > statement to initialize a missing parameter. > > def time_diff(target_time, curr_time=None): >if curr_time == None: > curr_time = datetime.datetime.now() >return curr_time - target_time I will point out that you CAN pass a function as the default value of a function parameter, and it means that the parameter will be bound to the function itself, so it becomes a callable (so doesn't help you in your case). But this does become an impediment to trying to define it this way, you need somehow to distinguish between the function itself being the default value, or some magically invocation of the function at each call. -- Richard Damon ___ 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/64ZTCJWJO74KD2EFUOSICOPT6XTSBO2R/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Thoughts about implementing object-compare in unittest package?
On 7/26/20 4:09 PM, Marco Sulla wrote: > You're quite right, but if you don't implement __eq__, the hash of an > object is simply a random integer (I suppose generated from the > address of the object). > > Alternatively, if you want a quick hash, you can use hash(str(obj)) > (if you implemented __str__ or __repr__). > And if you don't implement __eq__, I thought that the default equal was same id(), (which is what the hash is based on too). The idea was (I thought) that if you implement an __eq__, so that two different object could compare equal, then you needed to come up with some hash function for that object that matched that equality function, or the object is considered unhashable. -- Richard Damon ___ 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/NWVR4JJPJYJLJDVINNYTZSR4AAPKNHXK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Thoughts about implementing object-compare in unittest package?
On 7/26/20 1:47 PM, Marco Sulla wrote: > On Sun, 26 Jul 2020 at 19:33, Henry Lin <mailto:hlin...@gmail.com>> wrote: > > * Any class implementing the `__eq__` operator is no longer hashable > > > You can use: > > def __hash__(self): > return id(self) I thought that there was an assumption that if two objects are equal (via __eq__) then their hashes (via __hash__) should be equal? Which wouldn't hold for this definition, and thus dictionaries wouldn't behave as expected. -- Richard Damon ___ 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/T5DLPPPMWLGYAYNZ7LXG2IZJJWD5RWF6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add builtin function for min(max())
On 7/5/20 11:07 PM, Bruce Leban wrote: > > On Sun, Jul 5, 2020 at 5:49 PM Steven D'Aprano <mailto:st...@pearwood.info>> wrote: > > On Sun, Jul 05, 2020 at 11:58:58AM -0700, Bruce Leban wrote: > > But using a NAN is not an unreasonable operation. > > > I didn't say that it was. A NaN is the /result/ of an operation that > cannot produce a number. I didn't intend the word "unreasonable" to > mean anything more than that, just as you don't have to be crazy to > use irrational numbers. > > > There is a perfectly > sensible interpretaion available for using NANs as bounds, and it is > one which is supported by the IEEE-754 recommended treatment > of minimum and maximum: missing values. > > > Supported, yes. Recommended, no. IEEE-754 specifies that the *minimum > *operation propagates NaNs while the /alternate /*minimumNumber > *operation drops NaNs. > > image.png > It should be noted, this is a change in the Standard that is just 1 year old. The previous version did define minimum as similar to the minimumNumber version. The change was made because it handled sNans differently (it defined minimum(sNan, x) to be qNaN) and that definition turned out to be non-associative (it mattered whether the sNan was the last number or not) so they needed to change it. In doing the change, the also apparently decided that the 'Nan-poisoning' version was to be preferred and the Nan ignoring to be just an alternate with the change of behavior from the previous version with sNan. > > --- Bruce -- Richard Damon ___ 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/BNWP2GASN5VT7H2FWBUTG756JWGFZMLN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: json library: non-standards-compliant by default, and what to do about it.
On 6/27/20 8:51 AM, Serhiy Storchaka wrote: > 27.06.20 10:23, Steven D'Aprano пише: >> On Wed, Jun 17, 2020 at 09:18:00AM +0300, Serhiy Storchaka wrote: >>> Adding NANs and INFs to JSON will break virtually every software which >>> reads JSON because many (most?) of existing standard-conforming >>> implementations do not support them. >> >> It won't break anything that doesn't actually include NANs or INFs. > > If it does not include NANs or INFs you do need the ability to > serialize them. > >> I don't know anyone who likes the fact that JSON cannot round-trip all >> Javascript numbers. Its a source of pain to anyone who deals with such >> numbers where infinities and NANs might appear. JSON has changed in the >> past, breaking backwards compatibility, and I dare say it will change >> again in the future. Why is it unthinkable for this issue? > > Javascript numbers are unrelated to Python. Python floats include NaNs > and infinities, and it may be a problem if they are occurred in a > serialized data. But Python has a non-standard extension (enabled by > default for historical reasons) to solve this problem. It is important > to understand that it is a non-standard extension, and the result may > be not compatible with other JSON implementations. > > Maybe future JSON standards will support NaNs and infinities, and > other things. But this is not our business. The json module just > implements the current standard, and supports compatibility with past > implementations. Another way to look at this is that currently, the JSON standard doesn't handle some values (like NAN and INF) that a Python program might try to send to a JSON. The JSON encoder has a couple of choices of what to do: 1) (The Current) Use an 'extension' to the JSON standard to output the value in a way that JSON dosn't strictly allow. 2) It could quietly accept the value, and output some legal value, making the JSON not round trip, and perhaps be considered 'lying' on the output. This could be something like output the maximum real value for infinity (or even a number bigger so it might actually come back as infinity). NAN might be harder to think of a reasonable value, some might use 0 or -. 3) It could complain (loudly our quietly) about the bad value, and if it quietly complained, it might generate an output based on one of the previous methods. Quietly would be returning an error code, loudly would be throwing an exception. Depending on the actual application, any of these could be the 'right' choice. Fundamentally, we end up back at the maxim of being generous of what we accept, and rigorous in what we generate, but run into the quandary of if we accept a value that JSON can't handle, what is the right trade off of being generous and rigorous (we CAN'T be totally both) -- Richard Damon ___ 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/HGS53FAGOS4Z3VKBLO7PW2HT2TTLPGAM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Permanent code objects (less memory, quicker load, less Unix Copy On Write)
One thought that I had is the fact that this whole proposal seems to be based on code blocks never needing to be collected? given the program: def fun1(v): return v def fun2(v) return v+1 fun1 = fun2 The function code block that was originally bound to the name fun1 should now be collected, as it is no longer referenced. And, if this code is all in module mod1, there could be way off somewhere else, in code that imports this module a statement like mod1.fun1 = fun2 The classic "Monkey Patch" So the compiler can't know if the code object really will be eternal, at best it knows that the code object can only be generated once by how it was compiled, so if we allow it to be leaked we have a finite loss. ___ 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/JY5PZT7IVTNUUH6UXMMBYYKSVIHT47UZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: "return if "
On 6/17/20 5:42 AM, artem6191 wrote: > So yeah, we can "if : return", but why not? > >From Pep 20 (The Zen) There should be one-- and preferably only one --obvious way to do it. We don't add a second way to do something just because we can, there needs to be some clear need that the existing way doesn't handle. -- Richard Damon ___ 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/6KQWWP4NCKUA3TSOK3N5KCPXIQCNW6U4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Optional keyword arguments
On 5/28/20 3:00 AM, Greg Ewing wrote: > On 28/05/20 12:38 pm, Rob Cliffe wrote: >> why not go further (as the OP suggested as far as I recall) >> and allow the more concise >> >> def order(eggs = 4, spam ?= Spam()): >> etc. > > That clutters up the header with things that are not part of > the function's signature. All the caller needs to know is that > the spam argument is optional. The fact that a new Spam object > is created on each call if he doesn't supply one is an > implementation detail. > But default values for arguments are really part of the responsibility for the caller, not the called function. The classic implementation would be that the caller passes all of the explicitly, and implicitly defined parameters (those with default arguments). If the language allows, you could have unpassed arguments that are passed as 'not provided' and that the called function detects and fills in with a value that isn't part of the API (which is sort of what the = None default does). This can also be done in Python with the *args and **kwargs parameters where the function can detect if something was passed there. -- Richard Damon ___ 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/RAXOC6RCAMMDPOR7GTLBR7S4MM5U4FT2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: len(path) == len(str(path))
On 5/24/20 7:27 AM, Ram Rachum wrote: > Hi everyone, > > I submitted a PR today, and Serhiy decided it needs a discussion on > python-ideas and agreement from core developers before it could go > forward. > > BPO: https://bugs.python.org/issue40752 > PR: https://github.com/python/cpython/pull/20348 > > Today I wrote a script and did this: > > sorted(paths, key=lambda path: len(str(path)), reverse=True) > > But it would have been nicer if I could do this: > > sorted(paths, key=len, reverse=True) > > So I implemented `PurePath.__len__` as `str(len(path))`. > > Serhiy and Remi objected, because it might not be obvious that the > length of the path would be the length of string. > > What do you think? Can I get some +1s and -1s for this change? > > > Thanks, > Ram. While the length of the string representation might be one definition of length, so might the 'depth' (how many directory levels down does it go), and that might be considered more fundamental, and thus a better choice if anything was defined as its 'length' (which I am not sure it should). Length (as you are using it) is really a sequence like property, and paths are that much like a sequence. -- Richard Damon ___ 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/7ZQM3E6EZ4N456HYGWN65GGDV3HEIVPR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Optional keyword arguments
On 5/18/20 9:06 AM, James Lu wrote: > "There should be one-- and preferably only one --obvious way to do it." *obvious* multiple ways are allowed as long as there is one clear preference. -- Richard Damon ___ 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/PCAVU6BEI4KUYUUVL7F3CKV2EQ7ZPBPK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Ensuring asserts are always on in a file
On 5/18/20 5:25 AM, Alex Hall wrote: > On Mon, May 18, 2020 at 12:03 AM Richard Damon > mailto:rich...@damon-family.org>> wrote: > > On 5/17/20 5:04 PM, Alex Hall wrote: > > Some people (like myself, or the coworkers of [this > > person](https://mail.python.org/archives/list/python-ideas@python.org/thread/PLXOXKACKGXN4ZKISDVXLKMFIETWTF63/)) > just like to use asserts as a convenient way to check things. We > don't want asserts to ever be turned off. Maybe there could be > some kind of compiler directive which means "in this file, even > with -O, keep the asserts". Maybe the line `assert __debug__`? > > > My answer to that is 'Your doing int wrong', that is like asking > for an > if statement to not bother checking some of its conditionl. > > the assert operation has, like forever, been a debugging aid to > say this > condition should ALWAYS/NEVER occur, check for it in Debug Builds, but > not for production builds. In some cases (some languages) the compiler > might even optimize to code based on the knowledge that the condition, > even in code executed before the condition (if it can be sure the > assert > will be reached). > > > That bit about other languages is fascinating! And a bit scary... > > > To quote the documentation: > > Assertions should *not* be used to test for failure cases that can > occur > because of bad user input or operating system/environment > failures, such > as a file not being found. > > > I understand this, but I still don't understand in what situation > people use assertions 'correctly'. To me an assert implies: > > 1. If the condition is false: that's bad, and the code shouldn't keep > running. > 2. I'm not 100% sure the condition is always true (a bug in my code is > always a possiblity) and I need code to check for me. > > In that case I want the check there even more in production than in > development. It never makes sense to me for such checks to be turned off. > > I understand the reason to turn them off is performance, but this > always seems like a minor optimisation. I don't want code to be > significantly slower without -O. For me it makes development and > testing slow and painful, for users it pushes them to use a global > switch to solve a local problem at the cost of safety. Really slow > correctness checking is generally reserved for continuous integration > tests. I've never wanted to put something significantly slow in an > assert and I've never seen anyone else do that, or write in their > documentation "this code is best used with -O". So the tradeoff always > seems clear - accept a small performance hit for better peace of mind > of correctness. If I was really concerned about speed, Python is > already the wrong language. The idea is that during debug, you have added sentinel checking the pre- and post- conditions to routines. Pre-conditions are those requirements that MUST be met to call the function, things that the caller was supposed to make sure were true to begin with (either from other routines post conditions or what it has checked itself. A failure of a per-condition indicate a bug in the caller, and routines have these asserts to help find errors in the caller. The post conditions are the things the routine promises to deliver, a failure of a post condition indicates a bug in this routine. One part of asserts is there presence documents what the routines pre- and post-conditions are (in addition to their debugging help) Many of these tests are trivial (thing like simple tests on values) and for these the removal may not matter that much (but sometimes a 1% gain is important, maybe not so much in Python though). Some of the tests may be very expensive, test like 'tree is balanced' or 'list has no duplicate values' may require more work to verify then the routine itself, and these can be important to remove in production releases. For the 'cheap' asserts, if you want to keep the test in the code because you aren't sure you have debugged enough, you can replace the assert with an if, with the assert statement in the conditional (or just raise the exception yourself, or better use a custom problem report routine). The normal reason to not want to do this is that the asserts output isn't really friendly to the average user, but is designed for the developer. In some cases, it might even reveal information that the end user isn't really supposed to know. -- Richard Damon ___ 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/Q4DHIKGZW6P6YVTONUAURYPM2H4VJMHT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Ensuring asserts are always on in a file
On 5/17/20 5:04 PM, Alex Hall wrote: > Some people (like myself, or the coworkers of [this > person](https://mail.python.org/archives/list/python-ideas@python.org/thread/PLXOXKACKGXN4ZKISDVXLKMFIETWTF63/)) > just like to use asserts as a convenient way to check things. We don't want > asserts to ever be turned off. Maybe there could be some kind of compiler > directive which means "in this file, even with -O, keep the asserts". Maybe > the line `assert __debug__`? > My answer to that is 'Your doing int wrong', that is like asking for an if statement to not bother checking some of its conditionl. the assert operation has, like forever, been a debugging aid to say this condition should ALWAYS/NEVER occur, check for it in Debug Builds, but not for production builds. In some cases (some languages) the compiler might even optimize to code based on the knowledge that the condition, even in code executed before the condition (if it can be sure the assert will be reached). To quote the documentation: Assertions should *not* be used to test for failure cases that can occur because of bad user input or operating system/environment failures, such as a file not being found. Instead, you should raise an exception, or print an error message, or whatever is appropriate. One important reason why assertions should only be used for self-tests of the program is that assertions can be disabled at compile time. Basically the statement assert cond is the same as if __debug__ and not cond: raise AssertionError If you really what what you describe, add the following to your code: if not __debug__: raise AssertionError, "Please don't disable assertions" (This won't enable the assertions, but will let the user know that you need them enabled) -- Richard Damon ___ 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/JO5EBPHA5IZMG37KNVXMYT5NE2Y4LHIM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Making asserts non-recoverable.
On 5/13/20 10:54 PM, Greg Ewing wrote: > On 14/05/20 8:55 am, Richard Damon wrote: >> On 5/13/20 2:03 PM, Rhodri James wrote: >>> >>> I'm sorry, but I think the correct response is to give them a spanking >>> in code review. I certainly wouldn't pass any code that actually >>> relied on assert doing anything. >>> >> My thought was he just needs to add that case to the unit tests. > > This person seems to be a new team member who doesn't have the > power to force the others to do anything against their will. > So suggestions like this aren't going to help him. > > Mind you, changing the language as he requests probably wouldn't > help him either, as the other developers would just refuse to > upgrade to this new version that breaks their code. > But normally getting a test case added to unit tests is easier that establishing policy. You file a bug report that code fails with the -O option, an and a unit test to reproduce. (Which would seem justifiable unless the spec actually says -O not supported). To remove the test, someone is likely going to need to go on record that -O is not supported, which if it isn't really the policy, they would likely be a bit hesitant to do. -- Richard Damon ___ 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/M5BY3OBO72T7K2CN7WUAK3UK7I76HZID/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Making asserts non-recoverable.
On 5/13/20 2:03 PM, Rhodri James wrote: > On 13/05/2020 17:20, chris.the.develope...@gmail.com wrote: >> I'm working with developers that have decided to use asserts every >> time they want to throw an exception. I feel that their should be >> something that dissuades this behavior in the language design. > > I'm sorry, but I think the correct response is to give them a spanking > in code review. I certainly wouldn't pass any code that actually > relied on assert doing anything. > My thought was he just needs to add that case to the unit tests. -- Richard Damon ___ 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/GZ6HB5YRGIF3GGWEXLBLZM6IWYMGNV2X/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Improve handling of Unicode quotes and hyphens
On 5/13/20 2:22 AM, Stephen J. Turnbull wrote: > MRAB writes: > > On 2020-05-11 09:21, Chris Angelico wrote: > > > On Mon, May 11, 2020 at 6:09 PM Steve Barnes > wrote: > > > >> Actually, in the case of the “wrong quotes” it puts the pointer > > >> under the character before the space character or at the end of > > >> the line (if you have a fixed spacing font – worse if you don’t) > > >> – it still doesn’t tell you which character is invalid. > > > > This is actually a good point. > > But it's a different point: > > > > Having an invalid character in an identifier shows the caret at > > > the end of the identifier, regardless of where in the identifier > > > the error is. That's something that could be improved on, > > > regardless of the quote issue. There's a new parser on its way > > > (PEP 617), so it'd be something to consider on that basis. > > This isn't a parsing problem as such. I am not an expert on the > parser, but what's going is something like this: the parser > (tokenizer) sees the character "=" and expects an operator. Next, it > sees something that is not "=" and not whitespace, so it expects a > literal or an identifier. " “" is not parsable as the start of a > literal, so the parser consumes up to the next boundary character > (whitespace or operator). Now it checks for the different types of > barewords: keywords and identifiers, and neither one works. > > Here's the critical point: identifier fails because the tokenizer > tries to match a sequence of Unicode word constitituents, and " “" > isn't one. So it fails the sequence of non-whitespace characters, and > points to the end of the last thing it saw. But that is the problem, identifier fails too late, it should have seen at the start that the first character wasn't valid in an identifier, and failed THERE, pointing at the bad character. There shouldn't be a post-hoc test for bad characters in the identifier, it should be a pre-test in the tokenizer. > > So I see no reason why we need to transition to the new parser to fix > this. (And the new parser (as of the last comment I saw from Guido) > probably doesn't help: he kept the tokenizer.) We just need to make a > second pass over the invalid identifier and identify the invalid > characters it contains and their positions. There is no need to rescan/reparse, the tokenizer shouldn't treat illegal characters as possibly part of a token. > > > I wouldn't object if the syntax error reported that, say, the wrong type > > of quote was being used and included something like: Do you mean "? > > > > Wrong kind of quote (not "). Wrong kind of hyphen or minus (-). Etc. > > As a permanent resident of Japan, I DEMAND that YOU PERSONALLY > implement the SAME TEST for all the Japanese "full-width" operator > characters. :-) (This is actually a very common user error, and it's > very hard to tell the difference by sight in many fonts, same as > directed quotes vs. ASCII quotes in English, but for the whole ASCII > repertoire.) This could get really ridiculous. > > I think the suggestion that whatever test it is that identified the > "invalid character in identifier" defect be fixed to report both the > position of the first such character and the list of all such > characters is appropriate. > > The "wrong kind of quote" stuff belongs elsewhere, and in particular > in a linter. Here's an quasi-algorithmic suggestion for that: use the > Unicode confusables list (and I think there are many properties such > as "related" and "paired" characters that can be indicative). Haven't > looked at it in a while; it may not catch all the issues here. But it > would be a good start, and quite comprehensive. It might suggest > other things linters could be doing, too. > > Steve > _______ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/76BSFQ2AVRQM2BHFJZ4AE3KMAI7KX2N5/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Richard Damon ___ 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/HONT7LKB745XHUGR76VQKHPXBCI5DJKA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Improve handling of Unicode quotes and hyphens
A lot of this reminds me of a story told by a programming instructor in the 70's, he submitted a FORTRAN program deck to the machine, the complier gave him a warning on a statement which read INTEGER misspelled, it than ran the program, but IGNORED the statement, even though it clearly understood what he meant, and got wrong answers because the compiler just used the default REAL type for the variable, which took him a while to figure out what the error was. (Computer time was limited enough then that you didn't want to just rerun fixing the typo that it pointed out). He was confused about how the program obviously knew what he meant by the message, but didn't process the program right. An error like character (whatever) is not a quote (or is not a minus sign) seems similar. It is one thing to not recognize a funny character in the language, but to actually parse it well enough to give a message that says in effect, that may look like a quote to you, but I am not going to treat is as one, sounds perverse in the language. If we are going to go to the effort to detect that particular character, it makes more sense to make it actually DO the obvious thing. If not, the the current error seems fine, especially if we could include more details. An 'invalid character' message, that doesn't tell you WHICH character is invalid seems like it is holding back, If it included the bad character, or pointed to it, then the error becomes a lot more clear. ___ 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/XN7FNTM4Q5DNSA3CB4DHKCK7NFFHDLK4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Equality between some of the indexed collections
On 5/6/20 3:04 AM, Greg Ewing wrote: > On 6/05/20 1:58 pm, Henk-Jaap Wagenaar wrote: >> I'd say the difference is just one of semantics and as a >> mathematician I would consider tuples and sequences as "isomorphic", >> in fact, the set-theoretical construction of tuples as functions is >> *identical* to the usual definition of sequences: i.e. they are just >> two interpretations of the the same object depending on your point of >> view. > > Maybe the small subset of mathematicians that concern themselves > with trying to define everything in terms of sets, but I don't > think the majority of mathematicians think like that in their > everyday work. It's certainly at odds with the way I see tuples > and sequences being used in mathematics. > > As well as the same type vs. different types thing, here are > some other salient differences: > > - Infinite sequences make sense, infinite tuples not so much. > > - Sequences are fundamentally ordered, whereas tuples are not > ordered in the same sense. Any apparent ordering in a tuple is > an artifact of the way we conventionally write them. If we were > in the habit of labelling the elements of a tuple and writing > things like (x:1, y:2, z:3) then we wouldn't have to write them > in any particular order -- (y:2, x:1, z:3) would be the same > tuple. > In my mind, tuples and lists seem very different concepts, that just happen to work similarly at a low level (and because of that, are sometimes 'misused' as each other because it happens to 'work'). To me, tuples are things when the position of the thing very much matters, you understand the meaning of the Nth element of a tuple because it IS the Nth element of the tuple. It isn't so important that the Nth is after the (N-1)th element, so we could define our universe of tuples in a different order then it might still make sense, but we then need to reorder ALL the tuples of that type. A coordinate makes a great example of a tuple, we think of the 1st element of the coordinate as 'X' due to convention, and in the tuple it gets in meaning from its position in the tuple. A list on the other hand is generally not thought of in that way. A list might not be ordered, or it might be, and maybe there is SOME value in knowing that an item is the Nth on the list, but if it is an ordered list, it is generally more meaningful to think of the Nth item in relation to the (N-1)th and (N+1)th items. Adding an element to a tuple generally doesn't make sense (unless it is transforming it to a new type of tuple, like from 2d to 3d), but generally adding an item to a list does. This makes their concepts very different. Yes, you might 'freeze' a list by making it a tuple so it becomes hashable, but then you are really thinking of it as a 'frozen list' not really a tuple. And there may be times you make a mutable tuple by using a list, but then you are thinking of it as a mutable tuple, not a list. And these are exceptional cases, not the norm. -- Richard Damon ___ 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/XJSZTXSSUZYE723NDWA3YLNZPQQ2ZCZ4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Equality between some of the indexed collections
On 5/3/20 8:40 AM, Ahmed Amr wrote: > Thanks, I do appreciate all the discussion here about that. > > Initially, I was thinking about having lists/arrays/tuples match the behavior > of other instances in python that compare across their types like: > 1) Sets (instances of set or frozenset) can be compared within and across > their types As Dominic mentioned. > 2) Numeric types do compare across their types along with fractions.Fraction > and decimal.Decimal. > 3) Binary Sequences( instances of bytes or bytearray) can be compared within > and across their types > (All points above stated in python reference in > https://docs.python.org/3/reference/expressions.html) > > but after the discussion here, I think backword compatibility dominates for > sure against that, Thanks! I think the issue is that the set/frozen set distinction (and bytes/bytes array) is a much finer distinction than between arbitrary sequence types, as it is primarily just a change of mutability (and hash-ability), and all the Numeric types are really just slight different abstractions of the same basic set of values (or subsets thereof). The various containers don't have the same concept that they are essentially representing the same 'thing' with just a change in representation to control the types sort of numbers they can express and what sort of numeric errors the might contain (so two representations that map to the same abstract number make sense to be equal) Different types of sequences are more different in what they likely represent, so it is less natural for different sequences of the same value to be thought of as always being 'the same' There may be enough cases where that equality is reasonable, that having a 'standard' function to perform that comparison might make sense, it just isn't likely to be spelled ==. There are several questions on how to do thing that might need to be explored, Should the ignoring of sequence type be recurcively ignored or not, i.e. is [1, [2, 3]] the same as (1, (2, 3)) or not, and are strings just another sequence type, or something more fundamental. This doesn't make it a 'bad' idea, just a bit more complicated and in need of exploration. -- Richard Damon ___ 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/BNHD4SNJ4TSKGXCB4HXQPGDSU7LGHGUF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Equality between some of the indexed collections
On 5/2/20 5:13 PM, Serhiy Storchaka wrote:
> 02.05.20 23:32, Alex Hall пише:
>> On Sat, May 2, 2020 at 9:51 PM Serhiy Storchaka > <mailto:storch...@gmail.com>> wrote:
>> 02.05.20 21:34, Ahmed Amr пише:
>> > I see there are ways to compare them item-wise, I'm suggesting to
>> bake
>> > that functionality inside the core implementation of such indexed
>> > structures.
>> > Also those solutions are direct with tuples and lists, but it
>> wouldn't
>> > be as direct with arrays-lists/tuples comparisons for example.
>>
>> If make `(1, 2, 3) == [1, 2, 3]` we would need to make `hash((1,
>> 2, 3))
>> == hash([1, 2, 3])`.
>>
>>
>> Would we? Is the contract `x == y => hash(x) == hash(y)` still
>> required if hash(y) is an error? What situation involving dicts could
>> lead to a bug if `(1, 2, 3) == [1, 2, 3]` but `hash((1, 2, 3))` is
>> defined and `hash([1, 2, 3])` isn't?
>>
>> The closest example I can think of is that you might think you can do
>> `{(1, 2, 3): 4}[[1, 2, 3]]`, but once you get `TypeError: unhashable
>> type: 'list'` it'd be easy to fix.
>
> You are probably right.
>
> Here is other example: if make all sequences comparable by content, we
> would need to make `('a', 'b', 'c') == 'abc'` and `hash(('a', 'b',
> 'c')) == hash('abc')`. It may be deifficult to get the latter taking
> into account hash randomization.
Doesn't it also imply that ('a',) == 'a' and that you couldn't get a
dict to use both of these as keys?
--
Richard Damon
___
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/TWLVKAOHBHP7UP5SKB6B6OFB2TI6LTRK/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: list.append(x) could return x
On 4/20/20 11:25 AM, J. Pic wrote: > Hi all, > > Currently, list.append(x) mutates the list and returns None. > > It would be a little syntactic sugar to return x, for example: > > something = mylist.append(Something()) > > What do you think ? > > Thanks in advance for your replies I think the main idea of returning None is that if you started to do: something = mylist.append(foo) Then you might be tempted to forget that mylist got changed. Fairly consistently Python makes mutating members return None, and non-mutating members return the result, so it is clear which is which. Yes, it says that you can't do mylist.append(foo).append(bar) but that really isn't isn't that bad. -- Richard Damon ___ 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/4DCS2MDEKOX7NTZKBZ3NKLMZMLUSDMNJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Keyword arguments self-assignment
On 4/19/20 12:04 PM, David Mertz wrote: > > Sure. But what I gave was a simple case. There are all kinds of > complications like this person_record being passed around from call to > call without actually accessing `.telephone` in a particular scope. > Or doing something dynamic with the attributes/keys that won't show up > in a `grep telephone`. Or the string telephone occurring lots of > times in unrelated structures/objects. Or lots of other cases where > lots of name changes makes refactoring more difficult. I mean, I've > DONE it, and I'm sure you have as well. Clearly refactoring isn't > impossible with different names across scopes... and this goal is one > of several in picking names, not the single predominant one. > > The fact that the name of the variable changes shouldn't affect the refactoring. If the scope doesn't reference the telephone attribute, then it shouldn't be affected by the refactoring. Yes, the dynamic cases says we need to look for the string telephone as well as the direct reference of the attribute telephone. The fact that we get telephone showing up in unrelated structures is likely a plus, as if we find that it isn't good enough to store just a single phone number in this sort of record, we likely should be thinking about how we did it elsewhere, especially the way it was described as the data flowing through various forms and not just a single structure. In some ways this show the danger of coercing the programmer to reuse names for unrelated things, it encourages bad names. The mere fact that the record had a single field called 'telephone', as even decades ago many people had more than 1 phone number, they at least had a home_phone and and work_phone (and later a cell_phone). -- Richard Damon ___ 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/V6MEQ2P43PZZAIUHIZEWRM7TANYKEEJT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Keyword arguments self-assignment
On 4/19/20 11:28 AM, David Mertz wrote: > On Sun, Apr 19, 2020, 7:24 AM Richard Damon <mailto:rich...@damon-family.org>> wrote: > > One of the key motivations of this proposal is to make nicer a > call with a lot of key word arguments where the local > variable name happens (intentionally) to match the keyword > parameter name. > > > I think Stephen said that this "same name across scopes" is an > anti-pattern. I mostly disagree, though obviously agree that it varies > between different code. He mentioned something like: > > process_account(name=name, email=email) > > And that would be better with email_john and email_jane as names in > outer scope. > > I've worked with large code bases where the equivalent complex object > is used in many places. Not necessarily as a continuous life of an > actual object, but sometimes sent as JSON, other times read from > database, other times calculated dynamically, etc. > > For example, maybe there is a 'person_record' that has as > attributes/keys/whatever name and email. But in this existing code, a > different name is used through a call chain and in different corners > of the code. E.g. we read json_record, which calls something naming it > dynamic_record, which eventually arrives at a function that saves > db_record. But these are all actually the same object layout or even > the same object. > > When it comes time to refactor—now we need to rename 'telephone' as > 'home_phone' and add 'cell_phone'—finding all the locations to change > is a PITA. If only we could grep 'person_record' globally, it would > have been easy. As with most anti-patterns, there tend to be cases where they actually help (which is why some think of them as a useful pattern), but then it get applied beyond the cases where it is actually useful, and then becomes the anti-pattern. My personal thought on the case you are presenting, is that I would be tempted to grep for telephone, to change that because the change likely affects not just this given structure, but may also impact related structures which also assumed a single phone number. -- Richard Damon ___ 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/PFSCBT3GATRPUPSQR4DFX4SVCJXFJUTH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Keyword arguments self-assignment
On 4/19/20 1:48 AM, Stephen J. Turnbull wrote: > Chris Angelico writes: > > > Except that render_template isn't one of my own functions. It's part > > of the templating engine (this is a Flask web app). There is no > > refactoring to do - that IS the correct way to call it. > > So NOW you tell me! ;-) Just kidding: of course I recognized that as a > library call. Of course cases where one calls a library function with > a plethora of keyword arguments and large fraction of them are going > to take same name variables as keyword arguments are going to exist. > The question is are they frequent enough to justify an IMO ugly syntax > change. There are a lot of other factors involved, such as why there > are so many randomly-assorted variables that are nevertheless related > by this function call, whether this particular call is repeated with > the same objects (so that it might be worth wrapping it in a > marshalling function with appropriate defaults), if it would be > conceptually useful to have a library manager object that collects all > of the assorted variables, and so on. One thing that came to mind as I think about this proposal that may be something to think about. One of the key motivations of this proposal is to make nicer a call with a lot of key word arguments where the local variable name happens (intentionally) to match the keyword parameter name. IF we do something to make this type of call nicer, then there is now an incentive to make your local variables that are going to be passed into functions match the name of the keyword parameter. This incentive might push us from using what be a more descriptive name, which describes what we are doing in our particular case, to match the more generic name from the library. There is also the issue that if we are building a function that might be used with another function, we will have an incentive to name our keyword parameters that there is a reasonable chance would also be passed to that other function with the same keyword name, even if that might not be the most descriptive name. This will cause a slight reduction in readability of code, as cases of foo = phoo, start to stand out and get changed to just foo (by renaming the variable phoo). It is a natural outcome of you get what you make special cases for. -- Richard Damon ___ 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/GB2IZAFLXMFI2KSWJFIGHLKIIFPREWKS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: New explicit methods to trim strings
On 3/23/20 3:31 PM, Andrew Barnert via Python-ideas wrote:
> On Mar 23, 2020, at 04:51, Chris Angelico wrote:
>> Right, which is why for a proposal like this, it's best to start with
>> the simple and straight-forward option of case sensitivity and precise
>> matching. Removing a prefix of "a\u0301" will not remove a leading
>> "\xe1" and vice versa (just as those two strings don't compare equal).
> Agreed, but I think it’s not just “to start with”, but forever, or at least
> as long as Python strings are sequences of Unicode code points. If
> "Café".startswith("Cafe\u0301") is false, "Café".stripprefix("Cafe\u0301")
> had better not strip anything. And as long as "é" in "Cafe\u0301" and
> any(ch=="é" for ch in "Cafe\u0301" are false, startswith is correct.
>
> By comparison, in Swift, "Café".hasPrefix("Cafe\u{0301}") is true, because
> "Cafe\u{0301}" is a sequence of four Unicode scalars, the fourth of which is
> 'é', as opposed to Python where it’s a sequence of five Unicode code points.
> And of course Swift also has a slew of methods to do things like localized
> vs. default case-insensitive equality, substring, etc. testing, none of which
> Python has, or should have, as long as its strings are made of code points
> rather than scalars (or EGCs or whatever).
I wasn't familiar with the term Scalar as used in Unicode so I looked it
up, and I think you are incorrect here. From the Glossery:
Unicode Scalar Value. Any Unicode code point except high-surrogate and
low-surrogate code points. In other words, the ranges of integers 0 to
D7FF16 and E00016 to 1016 inclusive.
Thus Scalar ARE just codepoints (but exclude the surrogate pairs). What
you may be thinking of is the Grapheme. It may be that Swift does some
automatic conversion to a canonical form, to make the strings match. In
fact, just because the text displays as Café doesn't help you know how
many code-points their are, as the glyph/graheme é can be expressed as
either a single code point \u00E9 (NFC), or the sequence e \u0301 (NFD),
and Python can express it as either.
A basic rule with unicode strings, is if you are going to be doing these
sorts of comparison, you should make sure you have both strings in the
same normal form.
--
Richard Damon
___
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/BGJ52L4FLIN7XFI57DJRIXKVTI5IZ3VY/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: New explicit methods to trim strings
On 3/23/20 4:33 AM, Chris Angelico wrote: > On Mon, Mar 23, 2020 at 7:06 PM Alex Hall wrote: >> I think I'm missing something, why is case insensitivity a mess? >> > Because there are many characters that case fold in strange ways. > "ıIiİ".casefold() == 'ıiii̇' which means that lowercase dotless ı > doesn't casefold to the same thing that uppercase dotless I. Some > characters case fold to strings of different lengths, such as "ß" > which casefolds to "ss". I haven't even tried what happens with > combining characters vs combined characters. And Unicode case folding > is already a simplified version of reality; what actual humans expect > can be even more complicated, such as (I think) German case folding > rules being different for names and for book titles, and the way that > umlauted letters are case folded. > > On the other hand, this might actually mean it's *better* to have a > dedicated case-insensitive-cut-prefix operation. It would be difficult > to define it in easy terms, but basically it should be such that the > returned string (if not identical to the original) is the longest > suffix to the original string such that, if the returned string were > appended to the prefix and the result case folded, it would be the > same as the original string case folded. But there could be other > definitions, just as complicated, and not necessarily more correct. > > In any case, this can (and in my opinion should) be deferred for > later. Start with the simple one that doesn't care about all these > complexities, and then expand from there as the need is found. > The issue is that cases in Unicode are difficult, and can be locale dependent (Unicode calls this Tailoring). In the above example with the i-s, casefold would have needed to be told that we were dealing with the Turkish Language (or maybe some other language with the same issue), but currently the Python casefold function doesn't support the needed Tailoring (and I don't know if there is an exhaustive listing somewhere of the needed tailoring) Fully handling Unicode so as to meet all National expectations is VERY difficult, It doesn't surprise me that the Python Standard Library doesn't attempt to get it totally right, but settles for just dealing with the 'default' processing. The biggest part of this mess is that Unicode had to accept some compromises in defining Unicode (because the languages themselves present problems and inconsistencies), and when you hit a spot where the compromise goes against what you are trying to do at the moment, it gets difficult. -- Richard Damon ___ 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/Q2COUQV323JKW2FEANXXHCXEP3RWXV2P/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Magnitude and ProtoMagnitude ABCs — primarily for argument validation
On 3/9/20 7:45 AM, Steven D'Aprano wrote: > On Mon, Mar 09, 2020 at 06:39:10AM -0400, Richard Damon wrote: >> On 3/9/20 12:41 AM, Steven D'Aprano wrote: >>> Wait, no, that's not right either... each element doesn't compare less >>> than the previous element? >>> >> If the elements of the list don't form a total order, then sort makes NO >> promises about the data returned, other than it is the input data in >> some order. > I think we can tell more than that from the guarantee that sort only > calls `<` and not any other comparison. > > If the output of sort is [a, b, c, d] then I think that we know that: > > b < a returns False > c < b returns False > d < c returns False > > but not necessarily anything else. > > I'm making this judgement based on Tim's earlier post, where he > describes the comparisons used in sorting a list of sets, not from > reading the source code or experimentation. There may be more, or less, > that we can be sure about. > > For example, I'm confident that sort has to do at least one comparison > on each element (there are no elements that never get looked at; every > element gets inspected at least once). > > I'm also confident (absolutely sure actually) that it *doesn't* compare > every *pair* of elements. But it might compare every pair of > *consecutive* elements. > > Of course this isn't a language guarantee, it will depend on the > implementation. Bubblesort will probably behave very differently from > Heapsort. But we know the implementation used in CPython, and that's > what I'm discussing. > > But you can create a type that behaves sufficiently bad that it can't do that. Say we have the opposite of a NaN, lets call it an AnA (its any number), that return true for all comparisons, since there is some number that makes the comparison true. Such a type first makes your guarantee impossible, and will totally mess up any algorithm that is based on transitivity (if a < b and b < c then a < c, since if b is an AnA that won't necessarily hold). NaNs perhaps cause a smaller problem because people tend to not use the form of transitivity that comes from a total order in the negative, i.e. if a is not less than b, and b is not less than c, then a is not less than c. -- Richard Damon ___ 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/Q5RFMMCWHVEX2EIN4LIYPX5YXXDAI5PG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Magnitude and ProtoMagnitude ABCs — primarily for argument validation
On 3/9/20 12:41 AM, Steven D'Aprano wrote: > Wait, no, that's not right either... each element doesn't compare less > than the previous element? > If the elements of the list don't form a total order, then sort makes NO promises about the data returned, other than it is the input data in some order. I suppose the last elements compared will be in order, but it doesn't promise that for the rest of them. In particular, if a comparison causes a swap, it doesn't go back and check that the resulting new pairs are in order, unless the algorithm, based on the assumption of total order, thinks it might need to. -- Richard Damon ___ 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/X7SNS3UDRKENL6HH5DKF42HM37UUSF3Z/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Magnitude and ProtoMagnitude ABCs — primarily for argument validation
On 3/5/20 1:37 PM, Andrew Barnert via Python-ideas wrote: On Mar 5, 2020, at 05:24, Richard Damon wrote: On 3/4/20 11:07 PM, Andrew Barnert via Python-ideas wrote: On Mar 4, 2020, at 19:12, Richard Damon wrote: Yes, because of the NaN issue, you sort of need an 'Almost Total Order' and 'Really Truly a Total Order', the first allowing the small exception of a very limited (maybe only one) special value that breaks the true definition of Total Order so that we could call Floats to be an Almost Total Order. The obvious answer is to have PartialOrder < NaNOrder < TotalOrder, where a type is NaN-ordered if it’s partially ordered, and its subset of all self-equal objects is totally ordered. I can’t imagine when a generic AlmostTotalOrder that didn’t specify how it fails could be useful; a NaNOrder is useful all over the place. A median that ignores NaN values requires NaNOrdered input. Even a median that does something stupid with NaN—see below. Of course there might be other kinds of almost total orders that might be useful. If anyone runs into one, they can write their own ABC with the proper relationships to the stdlib ones. Or even propose it for the stdlib. But they couldn’t do anything useful with a general AlmostTotalOrder if it had to handle both NaN and whatever their different case was. I think your NaNOrder is my Almost Total Order, except that the name NaNOrder implies that it is only NaN is the special case, and thus we are dealing with numbers, but there may well be some other user type that has a similar 'exceptional' value with properties like NaN, but since the items aren't numbers, the Not-A-Number tag isn't really appropriate. The important thing is that it implies that there’s a subset of values that are totally ordered, and that the only values outside that subset are not self-equal. This means, for example, that you can test whether set is actually orderable in linear time with all(x==x for x in xs). So you can write a median that skips NaN values, or raises on them, just by checking each value as it comes up. But your almost total order only implies that there are some values that break the total order in some way. So you can only test whether a set is actually orderable in quadratic time with all(not(x Yes, the Almost Total Order classification needs a bit of work for a full definition. One simple one is that you have functions that really want Total Order classes, but will take an Almost Total Order with a promise that you aren't giving it any of the funny values. Is slightly more involved version might provide a testing function to all a routine to verify this promise. It is quite possible to write something that does something reasonable with an Almost Total Order, even without knowing the characteristics of the breakdown of total order, it the usage is defined as only working on the values that don't include those that break the total order. Float with its NaN issue is a good common example, many programs deal with floats, and don't intend to have NaNs creep in, so treating the float class as being float - nans and thus a total order might be reasonable. -- Richard Damon ___ 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/CCT6FUGBVZSVDHEKPS2FO2JGJWTHJC5G/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Magnitude and ProtoMagnitude ABCs — primarily for argument validation
On 3/5/20 9:10 AM, Steven D'Aprano wrote: On Thu, Mar 05, 2020 at 08:23:22AM -0500, Richard Damon wrote: Yes, that is the idea of AlmostTotalOrder, to have algorithms that really require a total order (like sorting) Sorting doesn't require a total order. Sorting only requires a weak order where the only operator required is the "comes before" operator, or less than. That's precisely how sorting in Python is implemented. Here is an interesting discussion of a practical use-case of sorting data with a partial order: https://blog.thecybershadow.net/2018/11/18/d-compilation-is-too-slow-and-i-am-forking-the-compiler/ Reading that, yes, there are applications of sorting that don't need total order, but as the article points out, many of the general purpose sorting algorithms do (like the one that Python uses in sort) but we really need to use a type that has these exceptional values. Imagine that sort/median was defined to type check its parameter, No need to imagine it, sort already type-checks its arguments: py> sorted([1, 3, 5, "Hello", 2]) TypeError: '<' not supported between instances of 'str' and 'int' If you consider that proper type checking, then you must consider that the proper answer for the median of a list of numbers that contain a NaN is any of the numbers in the list. If Sort had an easy/cheap way to confirm that values passed to it met its assumptions, then it could make are reasonable response. and that meant that you couldn't take the median of a list of floats (because float has the NaN value that breaks TotalOrder). Dealing with NANs depends on what you want to do with the data. If you are sorting for presentation purposes, what you probably want is to sort with a custom key that pushes all the NANs to the front (or rear) of the list. If you are sorting for the purposes of calculating the median, it depends. There are at least three reasonable strategies for median: - ignore the NANs; - return a NAN; - raise an exception. Personally, I think that the first is by far the most practical: if you have NANs in your statistical data, that's probably because they've come from some other library or application that is using them to represent missing values, and if that's the case, the right thing to do is to ignore them. There was not that long ago about that very topic. All those options can be reasonable, but ignoring seems to me to be one of the worse options for a simple package (but reasonable for one where the whole package uses that convention). The danger of it is that if you get a NaN as a result of a computation generating your data, that error gets hidden by having the data just be ignored. I would say that in Python, it would make a lot more sense to use None as the missing data code, and leave NaN for invalid data/computations. That way you keep things explicit. The use of NaN here goes back to the use of strictly static typed languages for doing this, where NaN was a convenient special value to mark it. (prior to the invention of NaN you just used an impossible value for these). -- Richard Damon ___ 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/S2OY6FFW32JP2ACQFQ4645NGYP4ZZKQT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Magnitude and ProtoMagnitude ABCs — primarily for argument validation
On 3/4/20 11:07 PM, Andrew Barnert via Python-ideas wrote: On Mar 4, 2020, at 19:12, Richard Damon wrote: Yes, because of the NaN issue, you sort of need an 'Almost Total Order' and 'Really Truly a Total Order', the first allowing the small exception of a very limited (maybe only one) special value that breaks the true definition of Total Order so that we could call Floats to be an Almost Total Order. The obvious answer is to have PartialOrder < NaNOrder < TotalOrder, where a type is NaN-ordered if it’s partially ordered, and its subset of all self-equal objects is totally ordered. I can’t imagine when a generic AlmostTotalOrder that didn’t specify how it fails could be useful; a NaNOrder is useful all over the place. A median that ignores NaN values requires NaNOrdered input. Even a median that does something stupid with NaN—see below. Of course there might be other kinds of almost total orders that might be useful. If anyone runs into one, they can write their own ABC with the proper relationships to the stdlib ones. Or even propose it for the stdlib. But they couldn’t do anything useful with a general AlmostTotalOrder if it had to handle both NaN and whatever their different case was. I think your NaNOrder is my Almost Total Order, except that the name NaNOrder implies that it is only NaN is the special case, and thus we are dealing with numbers, but there may well be some other user type that has a similar 'exceptional' value with properties like NaN, but since the items aren't numbers, the Not-A-Number tag isn't really appropriate. This wouldn't help the median issue as having median reject being given Float values because they don't form a true Total Order would be much worse than the issue of it getting confused with NaNs. Well, if you want to handle floats and Decimals and do something stupid with NaN values so the user has to be careful, it seems to me the right thing to do is require NaNOrder but document that you do something stupid with NaN values so the user has to be careful. Yes, that is the idea of AlmostTotalOrder, to have algorithms that really require a total order (like sorting) but we really need to use a type that has these exceptional values. Imagine that sort/median was defined to type check its parameter, and that meant that you couldn't take the median of a list of floats (because float has the NaN value that breaks TotalOrder). The presence of NaN in the float system does add a significant complexity to dealing with floating point numbers. Sometimes I wonder if since Python supports dynamic typing of results, might not do better by removing the NaN value from Floats and Decimals, and make the operations that generate the NaN generate an object of a special NaN type. The thing is, in most cases you’d be duck typing and get no benefit, because float and floatnan both have the same methods, etc. Sure, when you’re type-checking with isinstance you could choose whether to check float|floatnan or just float, but how often do you write such type checks? And if you really want that, you could write a Float ABC that does the same thing, although IIRC ABCs only have a subclasshook rather than an instancehook so you need a new metaclass: class FloatMeta(ABCMeta): def __instancecheck__(self, instance): return isinstance(instance, float) and not math.isnan(instance) class Float(metaclass=FloatMeta): pass People have experimented a lot with similar things and beyond in static type systems: you can define a new type which is just the non-NaN floats, or just the finite floats, or just the floats from -1 to 1, or just the three floats -1 or 0 or 1, and the compiler can check that you’re always using it safely. (If you call a function that takes one of those non-NaN floats with a float, unless the compiler can see an if not isnan(x) or a pattern match that excludes NaN or something else that guarantees correctness, it’s a TypeError.) Fitting this into the type algebra (& and | and -) is pretty easy. I’m not aware of anyone translating that idea to dynamic type systems, but it could be interesting. The problem with trying to make NaN a special type in a static typed language is that suddenly you can't define any of your variables to be of type 'float' if they might have a NaN value, as that would have the wrong type to store it. Your basic fundamental float type suddenly needs to use the dynamic typing system within the static type system that handles type hierarchies. That would be a BIG efficiency hit in a language like C++. A Dynamically typed language like Python, since it already takes that hit (and leverages that it always takes the hit to add functionality) has much more flexibility here. I will add, that the whole concept of the NaN value was an invention to handle the problem that a totally statically typed language, like C, couldn't efficiently handle t
[Python-ideas] Re: Magnitude and ProtoMagnitude ABCs — primarily for argument validation
On 3/5/20 1:27 AM, Greg Ewing wrote: On 5/03/20 4:08 pm, Richard Damon wrote: Sometimes I wonder if since Python supports dynamic typing of results, might not do better by removing the NaN value from Floats and Decimals, and make the operations that generate the NaN generate an object of a special NaN type. I don't see what problem that would solve. All it would do is enable us to claim that the float type was totally ordered, without technically lying. Any operation on floats would still be able to return a NaNType value that would get mixed in with your other float operations, so it would make no practical difference. What it would allow would be for the Float type to say it was Totally Ordered, and sort (and related functions) could check that the sequence passed to them consisted of just totally ordered items, and throw an exception if some item passed to it wasn't Totally Ordered. I suppose that since Python is not only Dynamically typed, also supports Duck Typing, the float type could declare itself to be Totally Ordered and the Nan just remove that characteristic from itself. (Since Float is built in, that might need some implementation magic to do that). -- Richard Damon ___ 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/UGKRESHETRSOX4V6M6IVEDOVPJ6MUQOS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Magnitude and ProtoMagnitude ABCs — primarily for argument validation
On 3/4/20 11:43 AM, Steven D'Aprano wrote: On Wed, Mar 04, 2020 at 04:21:46PM +, Mark Dickinson wrote: I'd argue that on a practicality-beats-purity basis, it wouldn't be unreasonable to register both `Decimal` and `float` as implementing `TotalOrdering` (or whatever the ABC ends up being called). And that seems perfectly practical until somebody tries to compare or sort floats and discovers that they actually don't implement a total ordering if any NANs have crept into their data. This can be a genuine pain point: https://mail.python.org/archives/list/python-ideas@python.org/message/K35GTWPKNS2DSUMH63VTSWXQWVN6JASW/ https://bugs.python.org/issue33084 and various other discussions. Yes, because of the NaN issue, you sort of need an 'Almost Total Order' and 'Really Truly a Total Order', the first allowing the small exception of a very limited (maybe only one) special value that breaks the true definition of Total Order so that we could call Floats to be an Almost Total Order. This wouldn't help the median issue as having median reject being given Float values because they don't form a true Total Order would be much worse than the issue of it getting confused with NaNs. The presence of NaN in the float system does add a significant complexity to dealing with floating point numbers. Sometimes I wonder if since Python supports dynamic typing of results, might not do better by removing the NaN value from Floats and Decimals, and make the operations that generate the NaN generate an object of a special NaN type. -- Richard Damon ___ 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/ML3BYS4BEJP3VYYBLIZSXLDW7ZT6CEK4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Magnitude and ProtoMagnitude ABCs — primarily for argument validation
> On Mar 4, 2020, at 10:09 AM, David Mertz wrote: > > > This thread feels very much like a solution looking for a problem. > > But on one narrow point, I'm trying to think of everything in the standard > library or builtins that actually forms a total order with elements of the > same type. > > * Not floats > * I think not strings with unicode canonical equivalence, decomposition, and > normalization > * Definitely not sets, tuples, lists, dicts, etc. > * Arguably not Decimal because it is sensitive to decimal context > * Complex clearly not > * I think not datetimes under timezone issues (although any ordering is > certainly *wrong* given the vagaries of timezones) > * Queues, deques, etc. don't even try, nor should they > * Do array.array's lack even a partial order? > > So really I think we are left with wanting a test for whether something is > "int or Fraction". I think strings do have the Total Order property, because string equality & etc does NOT get into the issues of Unicode canonical equivalence, I.e. the equality test is that they are the same sequence of code points, ignoring that multiple sequences of code points might be represent the same same canonical character, in part because there isn’t a single definition of that, as there is NFD/NFC and NFKD/NFKC equivalences which are different. ___ 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/7IYMILSM7OCLYYNLZK55ZDJKNIMDUMDC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Make ~ (tilde) a binary operator, e.g. __sim__(self, other)
On 2/24/20 7:24 AM, Rhodri James wrote: This seems a lot like trying to shoehorn something in so one can write idiomatic R in Python. That on the whole sounds like a bad idea; a friend of mine use to say he could write FORTRAN in any language but no one else could read it. Wouldn't it be more pythonic (or more accurately anything-other-than-R-ic) to use an interface that was more like I have seen many times someone in a forum for language X say that they have used language Y and it has this nifty feature that they wish language X had, so lets modify language X so it is more like language Y. Quite often language X and Y are very different languages with different purposes. My feeling is that if you really want the features that language Y provides, you probably should be programming in language Y, not some very different language X. Perhaps it makes sense to ask for a better integration between language X and Y, so you can call a procedure written in one from the other (but we need to realize that sometimes this might not be possible as they have very different run time requirements). I don't know if this comes from external requirements, someone tells the Y programmer to write a program in X, or they find that the language Y isn't well supported in some environment, but language X is. Either way, making language X look more like Y is rarely the right answer. If the matter is more appearance (you can do it but it looks very different) then perhaps the right answer is to really learn language X and get used to writing in its style (or just keep writing in language Y, but USE language Y). If language X is really missing some capability of language Y, then if the capability really is within the wheelhouse of what language X should be able to do, then adding it to the language might make sense, but it doesn't need to look the same as language Y if that notation doesn't make sense in X. It should also be remembered that not all languages need to be good at all things, and each language has a set of things it does well, and you don't want to hurt that set to add something new. Also, all languages (well, maybe almost all) are Turing complete, so anything that you can do in one, it possible in the other, it just might not look pretty or be simple. -- Richard Damon ___ 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/7YNSC77OEBYIEKWFGWBXWAOSZOHT7G3W/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Incremental step on road to improving situation around iterable strings
On 2/23/20 5:01 PM, Sebastian Berg wrote: The main issue is generic code. Sequence like lists and tuples are often iterated over: You work with the elements inside. However, in the same code, often strings are actually not desired to be handled as sequences. I.e. some code uses strings as sequences of characters, but most code probably uses the meaning that a string is a word, or sentence: the individual character has no useful meaning on its own. And in this case I don't see the string test as that special. In fact, in most case I would think the structure is normally always built from a single type of sequence, (like always a list) and anything that isn't a list is a terminal (or maybe some other type of structure that would be iterated differently) so you wouldn't actually be checking for strings, but for lists (and iterating further on them). -- Richard Damon ___ 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/6NEOVXY7I34R4ULS3GDR3W2AGYH7ATQP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Incremental step on road to improving situation around iterable strings
On 2/23/20 1:49 AM, Christopher Barker wrote: I think that the "strings are an iterable of strings", i.e. an iterable of iterables onto infinity... is the last remaining common dynamic type issue with Python. However, I'd like to see the "solution" be a character type, rather than making strings not iterable, so iterating a string would yield chars, and chars would not be strings themselves, and not be iterable (or a sequence at all). This would be analogous to other iterables -- they can contain iterables, but if you keep iterating (or indexing), eventually you get to a "scalar", non iterable value. This works well, for, e.g. numpy, where each index or iteration reduces the rank of the array until you get a scalar. And we don't seem to have constant problems with functions that expect an iterable of, say, numbers getting passed a single number and thinning it's an iterable of numbers. But, as stated by the OP, it'll be a long path to get there, so I doubt it's worth it. In any case, there should be some consensus on what the long term goal is before we start proposing ways to get there. -CHB I would agree with this. In my mind, fundamentally a 'string' is a sequence of characters, not strings, so as you iterate over a string, you shouldn't get another string, but a single character type (which Python currently doesn't have). It would be totally shocking if someone suggested that iterating a list or a tuple should return lists or tuples of 1 element, so why do strings to this? Why does string act differently? I'm not sure, but I suspect it goes back to some decisions in the beginning of the language. Making strings non-iterable would be a major break in the language. Making the results of iterating over a string not be a string, but a character type that had most of the properties of a string, except it could hold only a single character and wasn't iterable would break a lot less. Probably the only way to see would be try implementing this on a branch of the compiler, and see how many of existing libraries and open source projects break due to this. -- Richard Damon ___ 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/SG3ZXSTBMXPGFPYUUZ75LB57C4K4O5XS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add Binary module.
On 2/17/20 7:08 AM, ananthan ananthan wrote: At last found what I was trying to convey. A new class>>BinaryInt(n: Integer *, bits,signed=False) It should accept float values.(now >> "bin(5.8)".. will raise an error). BinaryInt(-2,4) 0b1110 I would expect this to be an error, as 'unsigned' binary integers can't be negative, or perhaps accept the C-like wrapping characteristics which would get you the above value. Int(BinaryInt(-2,4)) In this case would be 14. BinaryInt(5,4) 0b0101 BinaryInt(-2,4,True) -0b010 I would expect that to be 0b1110, i.e. signed BinaryInts use their MSB as the sign bit, and the others as value bits, not to have a separate sign outside the bits. -- Richard Damon ___ 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/ME6LFKYULGSRXWBESU6MWEK3BNGVXFKH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Perhaps allow leading zeroes in integer literals
On 2/6/20 7:03 AM, Jonathan Fine wrote: SUMMARY = It was once a good idea, for Python 3 to forbid leading zeroes in integer literals. Since then circumstances have changed. Perhaps it's now, or soon will be, a good time to permit this. A SURPRISE == I was surprised by: >>> 0 0 >>> 00 0 >>> 000 0 >>> 001 SyntaxError: invalid token Just thinking a bit, it should be safe to relax the prohibition for numbers with only 1 significant digit. 02 is ok, 020 is not, since numbers with 1 significant digit can't be misinterpreted. As to when it would be safe to totally remove that protection, Python 2.x isn't dead yet, and really won't be for awhile. It may be that the python developer have declared that support for it from them is over (though there still is that last release in April still to come), but it will still be alive, maybe on life support, while the various Long Term Support distributions maintain it. That won't end till some time next year by my understanding. And then you have people who will still use the unsupported 2.7 while they work on switching over and trying to figure out how to make their ancient code work on these new systems. This doesn't mean that Python 3.x needs to bend over backwards to cater to 2.7 users, but thought should be made that there are, and will be for a while, People used to Python 2.x In this particular case, since many other langagues and some operating systems use as simple leading zero to indicate octal, it may make sense to just keep the ambiguous numbers invalid forever. If we admit that the reasoning is ambiguity, then allowing the single digit numbers could make sense even if it does mean that writing the rule as a grammar is complicated. -- Richard Damon ___ 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/465IXJDGDM5KKC3RAZBY4WT5BRYWUDQL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: addition of "nameof" operator
On 2/3/20 12:02 AM, Bruce Leban wrote:
People keep mentioning refactoring. It's a red herring.
No refactoring tool needs a nameof operator added to the language in
order to do its job. And certainly an operator that requires running
the program in order to use it is not going to be helpful. Refactoring
tools analyze the program; they don't run it.
And f-strings are another red herring. There is nothing magical about
expressions inside f-strings compared to those outside.
Ignoring the red herrings, I see no utility in a nameof operator and
no way for it to actually do anything useful.
--- Bruce
IF Python had a proper refactoring tool (see my other message where I
question the ability to do that) then the nameof operator would clearly
help keep logging/debug strings in line with the program definitions.
A statement like print("bar", foo.bar) would be very hard to notice that
the "bar" match the foo.bar, while
print(nameof(foo.bar), foo.bar) makes the connection explicit.
This is where such an operation could help with refactoring, having an
actual Python attribute reference that the refactoring operation could
see, so it knows that the string is based on that attribute and not
something else.
As I mentioned elsewhere, the issue is that in Python, if we change the
attribute bar in class Foo, then we have the problem that we often can't
tell if in foo.bar if foo is of type Foo, so we should apply the change.
This isn't a problem is statically typed languages, as there we can
determine the type of foo, and see if the change applies (at least in
most cases).
--
Richard Damon
___
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/COJJ4EG4B5J2DKXZIZSQV7D2USZ3QGCS/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: addition of "nameof" operator
On 1/31/20 10:58 PM, Andrew Barnert via Python-ideas wrote: When refactoring code to rename something, there is no way to tell whether a string—or a substring in a larger string—that matches the name should be changed. But a nameof expression is unambiguously a reference to the name, and therefore the tool knows that it needs to change. Thinking about this, I have a question, IS there existing a refactoring program that can do the rest of the job in Python well. I am not sure there can be. Take an example refactoring problem: We have a logging module to save diagnostic information about program operation. The logging class currently has a member log that we want to change to log_file. In a statically type language, this is fairly easy, scan through the source code, find all references to the symbol log, see if they refer to the logging module or something else (which is easily solvable in a statically typed language, as the compiler needs to do this) and if they refer to the logging module, change the reference. The refactoring program just needs about the same smarts as the compiler. We can't easily do this in Python. In general, we come to the sequence foo.log, in order to determine if we want to change this, we need to know what foo will be every time it gets there. To determine this we need to back track to figure every path of execution to here. In fact, the transformation may not be possible (or may require other changes beyond what we want) as there may be a usage that handles many different types, all that happen to have a log member, so to change one class, we need to change them all (this can also happen in C++ templates which also can use duck typing). This lack of local type information makes the refactoring MUCH harder, and as you make the program smart enough to work on handling this, including strings might not be that hard. My guess is that any such refactoring is going to need to ask the programmer about a number of cases of the usage that the program can't determine, and thus can include strings that match too. -- Richard Damon ___ 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/TJLFZANF54K7JZM6NBQC3JI7GCCUKKPV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: addition of "nameof" operator
On 1/31/20 9:28 PM, Christopher Barker wrote: I am really confused by this whole thread: (I know this has all been said in this thread, but I’m summarizing to get us on the same page for the following comments) Python has names, and it has values (objects, whatever) when we write Python, we bind names to values with the = operator. (And other namespace trickery). Some types of objects do have a __name__ attribute: classes, functions created with def. But that name is only sometimes the same as the name(s) it might be bound to in any given namespace. So what the heck is nameof() supposed to mean? A few examples: >>> x = 5 >>>nameof(x) OK, I suppose that’s “x” — but what is the point of that? You have to know the name already. What about: y = 5 x = 5 (Or x = y) What is nameof(x) And nameof(y)? What about nameof(5)? Now: def fun(): pass I suppose nameof(fun) is “fun”, but again, is that useful? And now: Fred = fun What’s nameof(Fred) If it’s “Fred” then again, useless. If it’s “fun” then what about x and y before? And: def fun(): y = something return y lst.append(fun()) nameof(lst[-1]) In short, if it means “what is the name of this name” that seems completely useless? If it means: what name is this object bound to in this namespace? Than I can see how one might think that would be useful, but the answer could be: No name at all More than one name A name different than the object’s __name__ And then there is the question of the local vs global namespace, the list goes on. This thread has been going on a while: What am I missing? -CHB My understanding is that the impetus of the request is that if you start from an expression like nameof(foo.bar) to get to "bar" then if you refactor your code you have a chance that the tool will be able to see the variable expression foo.bar, and process that like other references to the item, and thus be able to change it. Just using the string "bar" would be very hard to see the connection between foo.bar and "bar". -- Richard Damon ___ 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/SLUI4AHPPDS3FB35SZ5EL6QX4ZIA4HDB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: addition of "nameof" operator
On Jan 31, 2020, at 11:01 AM, Soni L. wrote: > > Consider: > > x=nameof(foo.bar) > > in today's python becomes: > > foo.bar > x="bar" > > and when running this you get an AttributeError or something. > > the benefit is that "bar" is only typed once, and the attribute access (and > thus error-raising code) is tied to the resulting string. either you change > both the attribute access *and* the resulting string, or you get an error. > (correct me if I'm wrong.) > One issue I am seeing is that x = nameof(foo.bar) is crossing the line between compile time and run time behaviors. The resultant string, “bar” needs to be generated at compile time, but the operation still needs to do a check at run-time to determine if that IS the right result, as if foo doesn’t have a bar attribute it needs to raise an error instead. ___ 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/NKRZ4POX6RUODA32RBWYNATMXR6W6OM5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: addition of "nameof" operator
On 1/22/20 7:08 AM, Rhodri James wrote:
On 22/01/2020 12:03, Anders Hovmöller wrote:
He was pretty clear in saying he wanted the same thing as in C#. That
no one in this thread seems to have looked that up is really not his
fault in my opinion.
Oh, plenty of people have looked it up. The problem is that it relies
on part of the nature of C# (variables are lvalues) that simply isn't
true in Python, which I don't think the OP realised.
Or to expand on that, in C# and related languages, variable names
actually HOLD some value (which might be a special type of value called
a pointer), and a given object will either be in a specific variable
name, or off somewhere in the heap with no name. We might have a
variable with a pointer value to another object, and there it can be
useful to query the object through that pointer and ask what is the name
of the variable you are in, as we might not know it at the site of usage.
In Python, variables don't hold values, but refer to them. A given value
can easily be referred to by many names equally, and there is no such
thing as a pointer (which gets you to a name) only multiple references
to the same object.
Thus nameof(x) can ONLY be "x" in Python (or an error is x isn't
something that is a name), as at best x is referring to some object, but
that object doesn't have a special name to refer to it that is its
holder. Yes, one example where that linkage might be useful is it
documents in the code that the string value is actually supposed to be
the name of the variable, so a refactoring that changes the variable
should change the string too, such a semantic link between a variable
and its spelling is ill advised, and would only be used in a debugging
environment with something like print("x", x) or some similar purpose
function, and in that context, such prints should not normally be long
lived or are part of long term logging in which case the stability of
the label might actually be preferred to not break parsers for the log
output.
--
Richard Damon
___
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/RSBOLYY7JEIMOMXVCB5MBKZFWMNUNCIR/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: more readable "if" for multiple "in" condition
On 12/31/19 12:49 PM, Andrew Barnert via Python-ideas wrote: On Dec 31, 2019, at 08:03, Richard Damon wrote: IF I were to change the syntax ( which I don't propose), I believe the construct like foo or bar or baz in foobar to give you issues parsing. An alternative which is, in my opinion, more readable would be if any(foo, bar, baz) in foobar (and the alternative if all(foo, bar, baz) in foobar). But any(foo, bar, baz) already has a meaning (and so does all), so this is already valid but with the wrong result. Giving the exact same code a second meaning is obviously ambiguous. And there doesn’t seem to be any obvious way that either the any function or the compiler could resolve that ambiguity without reading your mind. Yes, I forgot that any and all are already defined by Python. That’s really the same problem the OP’s proposal already has. If the proposed syntax were an error today it might be conceivable to give it a new meaning, but it already has a meaning, so giving it a second one makes it ambiguous. Notice that you can actually use any here, although it’s not quite as simple as you want: if any(thing in foobar for thing in (foo, bar, has)): Maybe looking for a way to shorten that generator expression is worth pursuing, but I can’t think of anything obvious that makes sense. maybe it could be if (foo, bar, baz) any in foobar: since that is (I believe currently an error), but I agree it isn't that great of a syntax. I suspect this is really a maybe 'nifty' solution looking for a real problem, as you show, the generator expression really is a clean way to do it, and not THAT verbose. To do this any and all could make a specially tagged tupl which interacts with operators like 'in' in a special way where it applies each of its members and or/ands the results. It may even be possible to do this with the existing Python by defining a suitable class any and all with an appropriate constructor and implementing its own version of things like in. (not sure if we can override 'is') No, you can’t override is. And you can override in, but only from the container side, not the element side. Most other operators do have a “reversed” method (like __radd__ for overriding + from the left or just __gt__ for overriding < from the left), but even that will only fire if the right side doesn’t know how to handle the left side’s type or if the left side is an instance if a subclass of the right side’s type. And I don’t think you’d want these classes to be “magical” things that can override operators in a way that you couldn’t write yourself, so the only way to make this proposal work is to change the entire operator data model in a pretty drastic way. Ok, so you can't implement this with Python as it is. -- Richard Damon ___ 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/QDW3PFZE7RJNZFIFBH4N7JITSCSRX4DT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: more readable "if" for multiple "in" condition
On 12/31/19 1:20 AM, iman.h.a.kha...@gmail.com wrote: Hi I think the following syntax's: if foo in foobar or bar in foobar or baz in foobar: pass if foo in foobar and bar in foobar and baz in foobar: pass can be more readable and shorter if written as: if foo or bar or baz in foobar: pass if foo and bar and baz in foobar: pass maybe for "is" instead of: if foobar is foo or foobar is bar or foobar is baz: pass if foobar is foo or bar or baz: pass now the recommended syntax translate to this: (I think so) if foo (IS NOT '0' or None or empty) or bar (IS NOT '0' or None or empty) or baz in foobar so probably we must introduce a new type of 'or' (I recommend the CAPITAL "OR","AND") so this: if foo OR bar OR baz in foobar: pass translates to this: if foo in foobar or bar in foobar or baz in foobar: pass IF I were to change the syntax ( which I don't propose), I believe the construct like foo or bar or baz in foobar to give you issues parsing. An alternative which is, in my opinion, more readable would be if any(foo, bar, baz) in foobar (and the alternative if all(foo, bar, baz) in foobar). To do this any and all could make a specially tagged tupl which interacts with operators like 'in' in a special way where it applies each of its members and or/ands the results. It may even be possible to do this with the existing Python by defining a suitable class any and all with an appropriate constructor and implementing its own version of things like in. (not sure if we can override 'is') -- Richard Damon ___ 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/VGN4PW5LV7LMDA3ORP33BYBHJDEFMEGU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Philosophy of floating-point (was Fix statistics.median())
On 12/30/19 6:55 PM, David Mertz wrote: > The order he generates is very close to the IEEE total order, the difference are: > 1) It doesn't seperate -0 for +0, which shouldn't matter for most applications. > 2) It doesn't provide an order between NaNs, but unless you are taking special measures to distinguish the NaNs anyway, that doesn't really matter. And it also doesn’t distinguish equal but distinct-bit-pattern subnormal values. This is more in the category of "things that definitely do not matter", but I had forgotten about subnomal floating-point values. How does IEEE totalOrder mandate ordering those vs. equivalent normal numbers? So yes, my implementation of totalOrder probably has another incompleteness for the IEEE spec. It was THREE LINES of code, and I never claimed the goal was useful even if done correctly. IEEE BINARY floating point doesn't have subnormal values the equivalent of normal numbers. The binary format has an assumed leading one to the mantissa for exponents greater than 0 (and less than all ones which are the Infinities and NaNs). This assumed one makes multiple representations for most values impossible, it one happens for 0, having +0 and -0. The first level of the ordering is the basic value of the number, which provides a total order for all finite numbers but 0 in the binary format. Other floating point bases, like decimal floating point or hex based, don't have a consistent leading digit, so it isn't omitted, and you could have subnormal values if the leading digit is 0. The clause on handling different representations really just apply to those non-binary formats. -- Richard Damon ___ 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/RZQ7KDPCXYRU3NP3DTWPNR7TXW54K3V7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Fix statistics.median()?
On 12/30/19 4:22 PM, Andrew Barnert via Python-ideas wrote: On Dec 30, 2019, at 06:50, Richard Damon wrote: On 12/30/19 12:06 AM, Andrew Barnert wrote: On Dec 29, 2019, at 20:04, Richard Damon wrote: Thus your total_order, while not REALLY a total order, is likely good enough for most purposes. Well, it is a total order of equivalence classes (with all IEEE-equal values being equivalent, all negative NaNs being equivalent, and all positive NaNs being equivalent). But whether it’s good enough for most purposes depends on what those purposes are. I’m having a hard time imagining any purposes where “some well-defined but arbitrary, unnatural, and idiosyncratic total order of equivalence classes of the binary64 values” is of any use at all. Maybe that’s just a failure of my imagination. But “the specific well-defined but arbitrary, unnatural order that almost every other similar bit of code in every language is likely to use” seems a lot more likely to be useful. (And, needless to say, so does “this specific order that I defined myself”. I don’t know why the OP wanted to treat all NaNs as equivalents values greater than inf, but presumably he does know, and that’s fine. So, I don’t think that needs to be built into the module as one of the options, but I don’t see why he shouldn’t be able to specify it explicitly.) But it DOESN'T make all positive NaNs equivalent, as they do not compare 'equal'. Neither is less than the other, but they don't compare equal. If you use a sort function (not the one that Python currently uses) that uses an equality test as part of its sort (rather than just letting the falsehood of a < b and b< a imply that a == b) then it will break and perhaps return illogical results. This is getting into the weeds of corner cases, so may not be important. Yes it does. If all positive NaNs sort the same with this key function and the Python sorted function, they form an equivalence class under that function. The fact that they wouldn’t form an equivalence class under a different function is irrelevant. It’s like arguing that 1 and 8 can’t be in the same equivalence class for mod 7 addition because they’re not equivalent under mod 11 addition. And I don’t even know what you’re trying to argue here. That we shouldn’t allow this key function because it wouldn’t provide a total order if someone monkeypatched builtins to replace sorted? And therefore we should invent some “better” order that nobody has asked for and offer that? The issue is that the functions generates keys of the form (1, nan) for NaNs, and two of these do not compare equal, so not an equivalency class. IF the sort routine only uses <, and assumes that if neither a < b or b < a then they are equal, but not all sort routine use that method. I think the current sorted function just uses <, so it works as a key, it just isn't guaranteed to work for all sort algorithms. Basically, if a sort ever compares with a Nan using normal comparison rules, you have opened the door to problems. In this case we will only ever compare a NaN to another NaN, and depending on the sort routine, it still might work, and if the algorithm never uses an equality test to see that they aren't equal (and few sorts actually test for equality) it won't cause a problem. One simple solution is to just make the nan tuples be (1, 0) or (-1, 0) and just make all NaNs a real equivalence class. If you want NaN to sort by their representation, then you could could make that the second term of the tuple (as an int) I will admit that if you want to sort a list that contains a mix of floats, Decimals, and Rationals, then the tuple approach might be better then the conversion to a 64 bit int as the key, since that doesn't work for the other types except by converting them to float first. Better for what? If there’s no good use for the OP’s order or the tuple order or IEEE total order, we shouldn’t try to provide any of them; figuring out which one “makes sense” or coming up with one that “makes more sense” when we don’t even know what case we’re trying to make sense of is pointless. Inventing a new order that nobody asked for and nobody can even imagine a use for doesn’t help anyone, it’s just more code to write and maintain and one more option to confuse users with that benefits nobody. It doesn’t matter what properties that new order has. If there is a good use for any of them, on the other hand… inventing a different order that isn’t one any of them asked for still doesn’t help anyone. We need to provide what they actually asked for, or give them a way to do so (most obviously, with a key parameter), or just reject their use as unimportant. Building the 64 bit int key to sort floats by IEEE total_order only works if all the values are floats, as that key won't compare properly with other types of numbers. If your data does have other types of numbers, than making the t
[Python-ideas] Re: Fix statistics.median()?
On 12/30/19 12:45 PM, David Mertz wrote: On Mon, Dec 30, 2019 at 12:37 PM Richard Damon mailto:rich...@damon-family.org>> wrote: My preference is that the interpretation that NaN means Missing Data isn't appropriate for for the statistics module. You need to tel the entire PyData ecosystem, the entire R ecosystem, and a pretty much all of Data Science that they are wrong then. I would generally prefer a different sentinel value as well, but you are saying to refuse to interoperate with hundreds of millions of lines of code that do not meet the rule you have now declared. I suppose purity beats practicality though. First, for R and other languages where arrays of data are single typed, NaN is a sort of reasonable (or at least a least wrong) value. That is the environment where the convention stated. There Practicality beats trying to be pure, and once you decide you need a No Data value, NaN is better than -9. (one of the other historical choices) In the domain of advanced statistical packages, that derive from that history, I can accept that usage, when used by people who understand its implications, and use packages adapted to Python from that domain. The statistics package does NOT come from that history, and explicitly refers people to package that are for those usages. I would note that if median ignored NaNs, then so should things like mean, and stdev which don't, but return nans. This would be an argument that the 'poison' option maybe should be the default option for median if a nan policy is added. -- Richard Damon ___ 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/P3CIUBRFRW6CBZYNLY772A7OSZTX24ND/ Code of Conduct: http://python.org/psf/codeofconduct/
