[Python-ideas] Re: Abstract dataclasses and dataclass fields
On Sat, 23 Dec 2023 at 07:13, DL Neil via Python-ideas wrote: > > On 12/23/23 02:09, Eric V. Smith via Python-ideas wrote: > > On 12/21/2023 4:38 PM, Steve Jorgensen wrote: > >> I am finding that it would be useful to be able to define a dataclass that > >> is an abstract base class and define some of its field as abstract. > >> > >> As I am typing this, I realize that I could presumably write some code to > >> implement what I'm asking for. Maybe it is a good enough idea to make part > >> of the standard API in any case though? I'm thinking that a field would be > >> made abstract by passing `abstract=True` as an argument to > >> `dataclasses.field()`. > > > > You're better off discussing this on discuss.python.org as this mailing > > list is basically dead. > > It can't be dead - you're here! > Eh! He says he's not dead! ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/4DFVWDI736HDLLUP2Y3MOQRK2VR5X3JH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: re.match(pattern, string, require=True)
On Mon, 23 Oct 2023 at 01:14, Juancarlo Añez wrote: > > The re module is a black swan, because most of stdlib raises exceptions on > invalid arguments or not being able to deliver. > This is a comparison function, and like every other comparison function, it signals its results with a return value. It returns a truthy value if the regular expression matches, and a falsy value if it does not. As such, it is perfectly in line with fnmatch.fnmatch(), all of the str.is*() methods, math.isclose(), and pretty much everything else. So I guess by your logic, Python's standard library must have come from Perth, as it is nothing but black swans. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/EM4H4YIL5AIHEOZVA5RTOBFBQFDUIA5F/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: re.match(pattern, string, require=True)
On Sun, 22 Oct 2023 at 11:29, MRAB wrote: > I think what the OP wants is to have re.match either return a match or > raise an exception. Yes, and my point is that simply attempting to access an attribute will do exactly that. It's not a silent failure. Why create a new argument, then mandate that you use it everywhere, just to achieve what's already happening? ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/PUXKLC2K7SSNMIKUCEGGRJCF2NBT5URM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: re.match(pattern, string, require=True)
On Sun, 22 Oct 2023 at 06:37, Ram Rachum wrote: > > On Sat, Oct 21, 2023 at 10:30 PM Chris Angelico wrote: >> >> >> > I love that, but it mostly makes sense for "if there's a match do this, >> > otherwise do that" where most cases fall into "I'm absolutely sure there's >> > a match here and here's what we should do with that match", and when that >> > "absolutely sure" fails, the proper way to deal with that is by raising an >> > exception. >> > >> >> Oh, you mean like AttributeError? >> > > What I propose is like AttributeError in that they are both exceptions, but > unlike AttributeError in that it'll communicate the problem effectively in a > way that's easy to understand, especially by people who aren't Python experts. > > When you and I see this: > > AttributeError: 'NoneType' object has no attribute 'strip' > Which is strong evidence of a bug in your code. You're trying to tell me that you want a way to enforce that, if the regex doesn't match, it's a bug in your code. This seems to do that perfectly well. If it's NOT a bug when the regex doesn't match, you have the standard conditional form available. I'm not seeing a problem here. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/OCGJC5PUPLW4NFEW2JOACALTNO6MEXJC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: re.match(pattern, string, require=True)
On Sun, 22 Oct 2023 at 06:11, Ram Rachum wrote: > > On Sat, Oct 21, 2023 at 10:01 PM Chris Angelico wrote: >> >> On Sat, 21 Oct 2023 at 21:57, Ram Rachum wrote: >> >> What about an if with the match inside it? >> >> if m := re.match(...): >> ... >> >> That's one of the motivating examples behind the walrus after all. > > > I love that, but it mostly makes sense for "if there's a match do this, > otherwise do that" where most cases fall into "I'm absolutely sure there's a > match here and here's what we should do with that match", and when that > "absolutely sure" fails, the proper way to deal with that is by raising an > exception. > Oh, you mean like AttributeError? ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/CAG7AI2MKNSB6RTGHBYLQSD6MAOQO3AN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: re.match(pattern, string, require=True)
On Sat, 21 Oct 2023 at 21:57, Ram Rachum wrote: > > It's a little similar to the reasoning behind PEP 618 (adding the `strict` > argument to `zip`). Not quite, since without strict, zip will truncate - it doesn't have a different return value. > A keyword argument is easier to add, and makes the code less ugly, then an > `if` clause. When I don't have that `if` clause you mentioned in my code, > it's not because I forgot, it's because I don't want an extra clause for > something I don't think is going to happen. Also, a keyword argument enables > code linters to enforce a rule that the `require` argument must always be > specified. (Example.) > What about an if with the match inside it? if m := re.match(...): ... That's one of the motivating examples behind the walrus after all. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/EDPVFGDI53HULMSYZUDFZSXTHRD4GAG4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Extract variable name from itself
On Mon, 25 Sept 2023 at 22:04, Dom Grigonis wrote: > > I think a lot has been said by this time and I have nothing to add. > > If this is something that is of value, I am sure it will be picked up when > the time is right. > > One last thing that I think could be of some use is a poll: > > https://take.supersurvey.com/QCVZKTDY0 > > It will not take more than few seconds. Appreciate your time. Polls are utterly useless. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/N2KIKNPULOLSBXTJ4472ZWMTUAV623XH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Extract variable name from itself
On Mon, 25 Sept 2023 at 10:05, Dom Grigonis wrote: > > What is your position on this? > > Do you think that such thing is worth having? > > If yes, do any of the 3 final options seem sensible to you? > My position is that so far, you haven't shown it to be of much value. Which might be because the idea has no value, but more likely, it's because I just haven't understood from your posts why this should be added to the language. So far, you've shown that this should be an editor feature, but you haven't convinced me that the language should take any notice of it. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/NFCXP5SILAEJIV7HWS6RDY23WP7H4LVO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Extract variable name from itself
On Mon, 25 Sept 2023 at 07:05, Dom Grigonis wrote: > What I meant is that functions in __builtins__ are low level, with > functionality which is hidden from the user. > What does that even mean? ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ERAO66OAI73EO4YYCG3ODI3TPFSKYUEG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Extract variable name from itself
On Mon, 25 Sept 2023 at 00:15, Dom Grigonis wrote:
> I see what you mean, but this property is arguably intrinsic to what it is.
> And is part of f-strings vs explicit formatting property too:
>
> variable = 1
> print(f'{variable=} and b={variable}')
> # VS
> msg = 'variable={v} and b={v}'
> print(msg.format(v=variable))
>
> Especially, where msg can be pre-stored and reused.
What do you mean by that? Are you suggesting that there's a massive
cost in constructing a string literal and thus reusing it with
.format() is more efficient than an f-string? Because that's, uhh,
kinda not the point of str.format().
And if that isn't what you mean, what is it? Your posts are often
distinctly unclear. I get the impression that you think everyone else
understands your idea.
ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/GZPWQBKAGSIQEF5QAFMZ3XYYT34WIPAT/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Extract variable name from itself
On Sat, 16 Sept 2023 at 19:48, Jeff Allen wrote: > It needs language (parser) support because it does what you identified early > on: "take whatever is given and put it in quotes", where "whatever is given" > is the text of the expression only available at run-time. > I didn't say "and put it in quotes". I said "return the text string unchanged". This is, fundamentally, a problem of an editing tool. Teach the tool that a string literal inside nameof() should be parsed for variables. This is no harder than taking the program source and parsing it for variables - in fact, it's the exact same thing, just done a second time. I have done exactly this sort of parsing, using the Python ast module. It's not difficult. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/IRT4UNFBKPEP6U2PENVGQEAQQQ3WSBW2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Extract variable name from itself
On Sat, 16 Sept 2023 at 10:20, Dom Grigonis wrote: > > So following this thread, from your perspective and from what has been said > you can’t see or noticed any parts of it needing interpreter? Correct. Trying to get a variable name from an object is nonsensical, and trying to get a variable name from a text string is simply "return the text string unchanged". ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/5DGG4NECPJ4UNCNTRNBE2OM7F2JGCGT3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Extract variable name from itself
On Sat, 16 Sept 2023 at 10:07, Dom Grigonis wrote:
>
>
> > def nameof(x): return x
> >
> > print("This " + nameof("thing") + " is:", thing)
> Can you explain what you meant by this code? How would this work in editor?
>
Frankly, I have no idea, because your **entire proposal** is
predicated on some sort of automated tool for renaming variables.
Without knowing the details of that tool, how can I tell you how this
would work?
But if that tool can be taught that nameof indicates a variable name,
then it can rename inside it just like it would rename anything else.
Your problem here is a limitation of the variable renaming tool. I'm
suggesting a solution to that problem. This is not a language problem,
it's an editor problem, so it needs an editor solution.
ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/I6KUD7LCGYV4JES77A7PZDVBHWVIKXF3/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Extract variable name from itself
On Sat, 16 Sept 2023 at 08:50, Jeff Allen wrote:
> The parallel with f-string = is helpful, for which compile-time support is
> essential, of course.
It's really something that needs editor support, not compiler support.
As far as the Python interpreter is concerned, this is just a string.
So why not just make it an editor feature?
def nameof(x): return x
print("This " + nameof("thing") + " is:", thing)
As far as I can tell, this isn't a Python feature at all. It's an
editor refactoring feature.
ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/MRHSRDWF3IR6ZEC7HFE5VBPS2YW4CITX/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Extract variable name from itself
On Tue, 12 Sept 2023 at 20:05, Dom Grigonis wrote: > > Please read the next part of my e-mail too. It actually answer your question. > I did read it, and it didn't answer the question. Your desired semantics are not clear. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/P5RHZPHTVREEYOG2VSBZYLA6UU33T2X3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Extract variable name from itself
On Tue, 12 Sept 2023 at 19:51, Dom Grigonis wrote: > > It wouldn’t. I know this is weird and not in line of how things work. This is > more about simply getting reference variable name in locals() from the > reference itself. But how would one access the variable name, when once > called it returns the object it points to, not itself. So this would > obviously require an exception in parser itself. > > a = object() > b = a > print(a.__varname__) # ‘a' > print(b.__varname__) # 'b' > print((a + b).__varname__) # Undefined??? ‘a + b’? > I don't understand your desired semantics. Do you just want to take whatever is given and put it in quotes? ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ZWO3FPC2G2AWA5TNINBX4ZHDMKFBWQZN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Have del return a value
On Thu, 7 Sept 2023 at 23:51, Daniel Walker wrote: > > Perhaps this is a solution in search of a problem but I recently encountered > this situation in one of my projects. > > I have an object, foo, which, due to the references it contains, I'd rather > not keep around longer than necessary. > > I use foo to instantiate another object: > > bar = Bar(foo) > > bar is free to manipulate foo however it wants and even del it if necessary. > However, since the foo name is still around, those resources won't get > cleaned up even if bar is done with them. The simple solution is > > bar = Bar(foo) > del foo > bar.do_stuff() > > I think it would be a nice (and, I hope, painless) addition to the Python > grammar to have del return a reference to the underlying object. That way, I > could simply do > > bar = Bar(del foo) > > What do y'all think? Juice not worth the squeeze? > If you consider that a namespace is very much like a dictionary, what you're really doing is a dict.pop() operation - a destructive read. So it definitely does make sense. However, "del" is a statement, so it would be a bit awkward to retrofit. Maybe it'd work? It certainly is a sensible thing to do. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/5EZ5APBGMJO55CCXWAIGOYW4QTRY2ZC7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: factory for sentinel objects
On Thu, 31 Aug 2023 at 18:55, Tim Hoffmann via Python-ideas wrote: > > The standard pattern to create a sentinel in Python is > > >>> Unset = object() > > While this is often good enough, it has some shortcomings: > > - repr(Unset) is unhelpful: > Looks like you may be thinking of this: https://peps.python.org/pep-0661/ There are a few options here, including classes, enums, and a dedicated sentinel type. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/6C2FSMYQ2PBRUXRU7MVXTN2J6OJH64NZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: while(tt--)
On Tue, 22 Aug 2023 at 05:34, Wes Turner wrote:
>
> On Sat, Aug 19, 2023, 7:27 PM Celelibi wrote:
>>
>> 2023-08-04 8:18 UTC+02:00, daniil.arashkev...@gmail.com
>> :
>> > Currently in Python we have construction like this:
>> >
>> > tt = 5
>> > while t:
>> > # do something
>> > tt -= 1
>> >
>> > It would be great if in Python we have something like this:
>> > tt = 5
>> > while (tt--):
>> > # do something
>> >
>> > It is exists in C++. And in my opinion it is very Pythonic
>>
>> Just as a reminder of C/C++: {pre,post}-{inc,dec}rementations bring
>> their lot of issues with the language. Mostly the infamous *undefined
>> behavors*. If you've done some C or C++ this very expression might
>> send shivers down your spine.
>
>
> From "Increment (++) and decrement (--) operators should not be used in a
> method call or mixed with other operators in an expression"
> https://rules.sonarsource.com/cpp/RSPEC-881/ :
>
We already know that C programmers are unnecessarily scared of a
construct that, in Python, would not be scary.
Anyway, rules like that have nothing to do with undefined behaviour,
they could just violate a style guide. For example,
https://rules.sonarsource.com/cpp/RSPEC-1774/ is a completely
arbitrary style rule. And
https://rules.sonarsource.com/cpp/RSPEC-1712/ enforces duplicate
functions rather than using argument defaults. And
https://rules.sonarsource.com/cpp/RSPEC-1142/ and, excuse me,
https://rules.sonarsource.com/cpp/RSPEC-909/ ?? Yeah, I don't think
this is anything more than a style guide.
ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/VBNDQIHB7ESMQUUHNUDMZFTGM4SDNFW2/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: while(tt--)
On Sun, 20 Aug 2023 at 09:28, Celelibi wrote:
> Just as a reminder of C/C++: {pre,post}-{inc,dec}rementations bring
> their lot of issues with the language. Mostly the infamous *undefined
> behavors*. If you've done some C or C++ this very expression might
> send shivers down your spine.
The ONLY reason that this is undefined is to allow different compilers
to optimize differently. Python does not need to hyper-optimize and
could easily give this a clear definition.
> Assuming a = 0, what's the value of a after: a = a++ ?
> What's the value of the expression (a++) + (++a) ?
> What values are passed to the function with: f(a, a++, a) ?
>
> I am not sure these would be welcome in python. And allowing such
> syntax wouldn't feel really pythonic.
It would be trivially easy for the language to simply pick a
definition. For example, here's a consistent evaluation pattern for
all of them:
1) a = a++
LOAD a
INCREMENT a
STORE a
Result: a has not changed
2) (a++) + (++a)
LOAD a
INCREMENT a
INCREMENT a
LOAD a
BINARY_ADD
Result: a gets incremented twice, and the final sum is equal to 2a+1
(for the original a).
3) f(a, a++, a)
LOAD f
LOAD a
LOAD a
INCREMENT a
LOAD a
FUNCTION_CALL 3 args
Result: f(a, a, a+1) and a ends up incremented once.
This is using a pseudo-bytecode similar to CPython's, with a new
operation "INCREMENT" that can be considered to be equivalent to "a +=
1" (which otherwise can't be inserted in the middle of an expression).
> The worst part is not that the evaluation order is not always defined.
> It's that even if it were, most people wouldn't remember the rules
> since they're not obvious from the syntax. I'm not even sure most C
> programmers know what a "sequence point" is.
It hardly matters, because again, it's only because C needs the
freedom to hyper-optimize. Python doesn't. Python can simply define
that the increment happens immediately.
> Some of the backlash about the walrus operator was precisely that it
> makes the order of evaluation much more important to know in order to
> understand a program.
> Assuming a = 0, what does this do: print(a, (a := a + 1), a) ?
Python evaluates left-to-right. This is a language guarantee. It will
print out "0 1 1".
> At least python makes it defined and obvious *when* the side effect
> occurs... As long as you know that expressions are evaluation left to
> right.
Exactly.
I don't think Python needs pre-increment or post-increment, since
their best value is in situations that can be handled differently
(example: an array with its index or denoter can be stepped with
"arr[d++]", but in Python, you could take its iterator and step it
with "next(it)", with no great cost other than that you can't
implement Star Wars merge sort using "arr1[d1++]" and "arr2[d2++]").
If you really DO need a post-incremented value, it wouldn't be too
hard to have a "moving box" class:
class Box:
def __init__(self, value):
self.value = value
def next(self):
ret = self.value
self.value += 1
return ret
Sure, it's not as clean, but the bar for syntax is high and the value
here doesn't really reach that.
But it wouldn't be undefined or underdefined.
ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/AW2TYG3YWG2LPFEH3MVSLSIJL435AZ7A/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: else without except
On Tue, 8 Aug 2023 at 00:09, Celelibi wrote:
> Actually, now that I think about it, I guess a 'try' block without an
> 'except' and just a 'finally' would probably be a good candidate for a
> context manager. (Which I'm a big fan of. ^^)
Yeah, context managers are often a good way of writing a try/finally.
Certainly not *always*, but they can be very elegant.
> Here's what I think could be a not so far fetched example: writing a
> structured file through a serializing class. Conceptually the code
> could look like this:
>
> myfile = MySerializer("foo.bin")
> try:
> # Write data with myfile.write()
> else:
> # Write footer with myfile.write()
> finally:
> myfile.close()
>
> You might want to keep it as a 'try' statement instead of a 'with'
> because in the future you might want to handle some the exceptions
> generated by MySerializer but not those generated by the OS. (Although
> I agree, you can have a 'try' in a 'with'.)
Not sure how the generalization would go here, but in order to make
"try-else" useful, it has to be highly likely that the "else" block be
capable of raising the same exception that would be caught in the
hypothetical "except" (and, importantly, that you not want this). I'm
having trouble imagining what sort of exception would be like this,
since a partly-written file is almost certainly not going to parse a
useful footer.
Maybe it's like a PKZIP file where the footer is actually measured
from the end of the file?? Not a common technique by any means,
although given Zip's ubiquity, maybe it deserves more consideration.
Still, that would probably want to be coded as two entirely separate
blocks, since - as per your comment - the "write out the central
directory" part would have to happen when there's a serialization (or
in this case, perhaps compression) problem, but NOT when there's other
types of problem, or Ctrl-C, or anything like that.
> And in the real world, that code might look something like this.
> It write two blocks of data, each preceeded by the data length and
> followed by a checksum. And the footer is the checksum of the whole
> data.
>
> assert len(data) <= 256
> myfile = MySerializer("foo.bin")
> try:
> myfile.write(128)
> myfile.write(data[:128])
> myfile.write(crc32(data[:128]))
> myfile.write(len(data) - 128)
> myfile.write(data[128:])
> myfile.write(crc32(data[128:]))
> myfile.write(crc32(data))
> finally:
> myfile.close()
>
> I don't know about you, but I don't think it's obvious which 'write'
> should be put in an 'else' block when an 'except' gets added. Even if
> we added comments to identify the data blocks and footers, it's not
> obvious that the exceptions that could be raised by writing the footer
> shouldn't be captured by the future 'except'.
Yeah, if there's a problem in any of these blocks, I have no idea what
should get written. If the line "myfile.write(data[128:])", fails...
do you write out its CRC? Do you write out the global CRC? You've
already successfully written the length here, so I'd say the file is
irreparably broken at that point, and all you can do is report that
serialization failed.
This is why real-world examples are so important. Inventing examples
invariably leads to this sort of thing. You've had a marvellous
attempt at it, and...
> This example is not perfect, but here it is.
... exactly.
ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/OVVK6I6A7JAOOOSWYAPL5HZFMGRNYJOK/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Conditional 1-line expression in python
On Sat, 5 Aug 2023 at 22:49, Dom Grigonis wrote: > 3. The Python syntax is easily understandable to anyone who knows English as > it follows English syntax: "What are you doing tonight?" "I'm going to the > movies, if I manage to leave work on time, otherwise I'll just stay home.” > * Is the english sentence “If I manage to leave work on time, I’m going to > the movies, otherwise, I’ll just stay home” incorrect? This is a VERY common objection to Python's syntax. No, the English sentence you provide isn't wrong, and the "follows English syntax" argument is not saying that C's way of laying it out is wrong. English happily supports both orders. But that's a relatively weak justification, since this is the same English that has a purple fruit called a "grape", and then a completely different fruit in a different family called a "grapefruit"; and where there's no well-accepted word for "the day after tomorrow", but after some incidents in Prague, came up with the glorious word "defenestration", which can also refer to shutting down your GUI and returning to terminal mode. So I would say this is only really of value as a rebuttal to "Python's conditional syntax makes no sense", by saying "yeah well, it's no worse than English". Which is kinda like saying "banging your head against a wall doesn't hurt **that** much, it's not as bad as maintaining a PHP web site.". ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/72VRUQKNWFLCL4KJFBIXYFT2DCX57PNY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Conditional 1-line expression in python
On Sat, 5 Aug 2023 at 22:49, Dom Grigonis wrote: > 9. Python has a syntax for conditional expressions. Learn it, if you want to > use Python. No need to create multiple syntaxes for the same thing. > * Hello Chris A? :) Nope. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/6GDLIOAM6BBF4SNO4MVVYU64UBCPZCCQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: else without except
On Wed, 2 Aug 2023 at 08:22, Mitch wrote: > > If `except` is omitted, then catch the generic exception and do nothing and > exit. > Not sure what you mean here. If you have a try-finally with no except clause, no exceptions will be caught; the try will be run, then the finally, and then you'll see any exception from the try block. Perhaps what you're intending is for an omitted except clause to behave like "except: raise"? Because that would probably have most of the effect of the proposed "try-else", without a dangling else. And I'd still like to see an actual real-world (or "near-real-world") example that would benefit from this. Would adding "except: raise" be a problem? ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/OK5LMB7PAF2RRHQE7FHE2E7X6CYIFUDD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: else without except
On Wed, 2 Aug 2023 at 04:03, Mitch wrote: > I'll ask the same question as OP: "Is there a reason why else without except > has to be invalid syntax?" > A better question is: "Is there a reason why else without except should be valid syntax?" ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/BMYQ2U5EX7XH46DAUQTGC373TSU5IGVC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: else without except
On Wed, 2 Aug 2023 at 02:02, Celelibi wrote: > If later on an "except" is added, the developper doing the > modification should be reminded to move the call to > no_error_occurred() into an "else". With real-world non-trivial code, > it might not be so simple to see. > Can you give us an example of real-world non-trivial code that would benefit from this? ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/XOWJDT2SX4CSSWJBFWGJO5V6I7OWX3YL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: "Curated" package repo?
On Wed, 26 Jul 2023 at 01:20, Jonathan Crall wrote: > > > On Mon, Jul 24, 2023 at 10:04 AM Chris Angelico wrote: > > can you tell me what this vetting procedure proves that isn't already > > proven by mere popularity itself? > > I think that's what this thread is trying to discuss. Do I have the exact > perfect implementation? No. But I imagine it to be akin to peer-review. I > can't prove this, but I think it adds signal that complements popularity. > So you're suggesting nothing, only that there might be a possible suggestion to be made. Do you have an actual concrete proposal? > > And are you also saying that packages should be *removed* from this curated > > list? > > Yes, absolutely. If packages fall out of maintenance, are deprecated, or > end-of-life, they should no longer be this curated list. I imagine the > mechanism would be a series of snapshots of what the state of the list is at > a particular point in time. What is the mechanism for determining the trigger > to remove a package? No clue right now. There are a lot of problems - most > of them social - that need to be sorted out to make a useful curated package > list a reality. I don't claim to have the answers, but I'm willing to > participate in discussion to find them. > So who's going to actually do the work? You? > > More robust in what way? > > It's curated by people I trust more than the average bear. I trust the average bear a lot more than most people. They are pretty awesome. Did you see the one that tried to eat Tom Scott's gopro camera? I'd trust that bear (and stay out of its way). > > If not, how is it different from "yet another collection"? > > We are discussing details about it here instead of just posting what we think > should be there on github right now. I'm putting a bit of trust in this group > to find a way to do that. I do think that separating the opinions of experts > (however we choose to define that group - but I hope you agree that it should > be possible to find some reasonable definition) as an auxiliary re-ranking on > top of popularity is a good differentiator. > So yeah, you have no concrete proposal. Okay then. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/WNFRRVBMX3KTWVG4KXEJILXR26HMCQCS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Proposal for get_or function in Python dictionaries
On Tue, 25 Jul 2023 at 01:03, Dom Grigonis wrote: > I think what would be nice to have is a set of dimensions that are deemed to > be of importance when deciding on a language constructs. > plot(dim1, dim2, dim3) > dim1 - number of lines > dim2 - number of terms > dim3 - number of operations > dim4 - frequency of usage > dim5 - ... > Don't think I fully understand, but aren't three out of those four just different forms of brevity? Is that really so important to you? ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/6RF4PMZAZQM74OKWCX5HP7ZN5B4Z5C5U/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: "Curated" package repo?
On Mon, 24 Jul 2023 at 23:28, Jonathan Crall wrote: > > If popular packages weren't favored that would be a problem. Popularity > should be correlated with "trustworthiness" or whatever the metric this > curated repo seeks to maximize. I think the important thing is that the > packages are both popular and have passed some sort of vetting procedure. > Okay, but can you tell me what this vetting procedure proves that isn't already proven by mere popularity itself? > For instance, for a very long time Python2 was far more popular than Python3, > but any expert in the field would encourage users to move to Python3 sooner > rather than later. Python2 is popular, but it wouldn't have made the cut on > some expert-curated list. > Experts were divided for a very long time. I'm not sure what your point is here. And are you also saying that packages should be *removed* from this curated list? Because if so, what's the mechanic for this? (Python 2 absolutely WOULD have made the cut on any expert-curated list prior to Python 3's inception.) > So it helps in that it reranks popular packages (and also excludes some) for > those who want to adopt a more strict security / reliability posture. > > By no means do I think this would replace pypi as the de-facto packaging > repository. Its low barrier to entry is extremely important for a thriving > community, but I also wouldn't mind having something a bit more robust. > > I also think this project would have to careful not to become yet another > "awsome-python-package" collection. Those certainly have value, but based on > the initial proposal, I'm interested in something a tad more robust. > More robust in what way? What exactly are the requirements to be part of this list? Will all experts agree? If not, how is it different from "yet another collection"? (Also, PLEASE don't top-post. There's no value in it. Show what you're responding to.) ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/HCTAH2YI2F3AX5POPKMLNJVYKJ7NJPNB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: "Curated" package repo?
On Mon, 24 Jul 2023 at 21:02, James Addison via Python-ideas wrote: > ... some thoughts on how to build a scalable, resilient trust network based > on user ratings; I can't guarantee that it'll change your opinion, though! > This still has the fundamental problems of any sort of user rating system: popular packages are inherently favoured. And we can already get a list of popular packages, because download stats are available. So how would this scheme help? ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/LU6BFQGNCMZZVESCUUCPSVKWPKJEJB7H/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
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 ___ 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/TPY2JHOBXUQIRNRYUUBUX46Y3HS4GQVK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
On Sun, 23 Jul 2023 at 12:20, Dom Grigonis wrote: > > > > There is no way to have a value that isn't a value, in Python. The > > concept doesn't make sense and would break all kinds of things. > > (That's why, when a special function like __getitem__ has to be able > > to return literally anything, it signals "nothing to return" by > > raising an exception.) > > I accept that it might be difficult to implement. > I see that it would break things at cpython. > Will definitely break some of the stdlib. E.g. inspect stuff. > It wouldn’t break any of the existing python code. > So yes, might not be a minor change. > > Could it be done nicely and easily by someone with relevant experience? I > don’t know. > > > But I fail to see why it doesn’t make sense - that’s a strong statement. > > It would be a value, just a value that is treated with exception in this > particular case. > There is definitely code at that level - resolving args, kwargs, dealing with > “/" and “*” in relation to arguments provided, etc. > > It would take effect only on keyword arguments with defaults, if so then > fairly contained matter. > It could be a default of a keyword argument itself, would have a type and > everything as any other object. > Okay. You now have an object that you can't do anything with, because it can't be a function argument. So... Show me how you would put this value into a dictionary. Show me how you would find out the type of this value. Show me how you would refer to this in an exception. Show me how you would access an attribute of this object. Show me how you would do ANYTHING WHATSOEVER with this object. It does not make sense to have an object that isn't an object. And in Python, every value *is* an object. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/AHM6KHYJRFPLY3QUWV6MNCZ33BWSNR3Q/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
On Sun, 23 Jul 2023 at 09:15, Dom Grigonis wrote: > This works ok: > > ``` > def foo(bar=None): > if bar is None: > bar = A() > > class A: > pass > ``` > > If PEP is aiming to replace the latter example, then it would be great if it > kept all of its advantages. I.e. not having to change the definition order in > the module, which could be preferred as it is for other reasons. > Well, yes, it would work, but I still wouldn't recommend it. This is confusing to read. But since the default would be evaluated at call time, it would behave exactly as you describe. > And also to come back to my previous notice that there is no way to enforce > the default in case of function chain with cascading arguments. You said it > is a known limitation. Is there no easy & sensible approach to not have it? > E.g.: > > a) Any object which has certain dunder attribute, which evaluates to True? > b) NotGiven sentinel value which does exactly that. > c) A special constant, which, if present, at lower level makes things behave > the same way as the argument wasn’t provided at all. Such constant could be > very useful outside the scope of this PEP as well. Could be a great place to > introduce such constant? And to me it seems it could be a well justified one, > given it actually is special and does not fall under umbrella of generic > sentinel values. > > It would be great if it was to retain all the benefits of the latter example. > Then (at least from my POV) this PEP would be an excellent addition, and I am > most likely be using it now if it existed. > There is no way to have a value that isn't a value, in Python. The concept doesn't make sense and would break all kinds of things. (That's why, when a special function like __getitem__ has to be able to return literally anything, it signals "nothing to return" by raising an exception.) The only way to not pass an argument in Python is to not pass it. That means, at best, something like *a or **kw, where the sequence/dict either has something or doesn't, depending on whether you want to pass the argument. None of this is changed by PEP 671 and I don't think there's a lot of point trying to, as it would only cause more problems elsewhere. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/34HFL6N6FMEIEHB5A22BBBXBAUIXXUBP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Conditional 1-line expression in python
On Fri, 21 Jul 2023 at 19:58, Dom Grigonis wrote: > > Did not mean that it is easy, but it seems achievable and although a deep dig > might be needed, my gut feeling is that it is possible to achieve this fairly > elegantly. I might be wrong ofc. > Start on that deep dig, then, and figure out what the implications are. Remember, anyone can do this: func = Break and now func() has to behave as a break statement. Good luck. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/PWRCDEBV7YPGSUIZSXLOOHHMSLPPVT2R/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Conditional 1-line expression in python
On Fri, 21 Jul 2023 at 19:15, Dom Grigonis wrote: > However, it could be done differently as well. If `Break()` takes effect in > the scope where it is evaluated. Then: > You say that as if it's easy. How would this work? How do you have a function that, when called, causes the current loop to be broken out of? ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/IOTCAVRMSJKS72D7KTPEZQBDR7QFNDI2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Conditional 1-line expression in python
On Fri, 21 Jul 2023 at 11:08, Dom Grigonis wrote: > Also, can't find a way to ONLY force evaluation without any additional > operations in this specific library. A simple callable which evaluates if > unevaluated & returns would do. Then: > > def IF(condition, when_true, when_false): > if condition: > return ensure_eval(when_true) > else: > return ensure_eval(when_false) > > Controls evaluation if deferred objects are provided, but can also be used > with `normal` values. > Let's tackle just this one part for a moment. What does "ensure_eval" do? Evaluate a proxy object but not evaluate anything else? That seems simple, but might very well be straight-up wrong. Consider: def test_proxy(x): x_ = Proxy(x) y = ensure_eval(x_) y_ = ensure_eval(y) assert x is y assert x is y_ This should always succeed, right? Well, what if x is itself a Proxy object? How does it know not to reevaluate it? ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/GTCRUPQOFP63VA2T2N7BVBO6JKR3D7I6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Conditional 1-line expression in python
On Fri, 21 Jul 2023 at 05:53, Random832 wrote: > > On Mon, Jul 17, 2023, at 16:41, Dom Grigonis wrote: > > Would be interesting to see if my preference is an outlier or not really. > > I think this is a false dichotomy. We should consider VB-like conditional > expressions if(condition, when_true, when_false) as well. > Why? That sort of expression would be syntactically a function call, which you can already create, but which would eagerly evaluate both its arguments. The entire value of an actual conditional expression is that it WON'T evaluate the expression it isn't using. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/XCD7BX764Q7VZXICBX6PPHFSG3PZJPJ5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Proposal for get_or function in Python dictionaries
On Thu, 20 Jul 2023 at 22:27, Stephen J. Turnbull wrote: > > Chris Angelico writes: > > On Thu, 20 Jul 2023 at 15:33, Stephen J. Turnbull > > wrote: > > C'mon Chris, "that was then, this is now". Catch up, I've changed my > position. ;-) > That's fair :) Maybe I'll dust off that proposal again at some point. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/5ZL7OWZQLFTL4NGDAA7Y773GJT6VIJUQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Proposal for get_or function in Python dictionaries
On Thu, 20 Jul 2023 at 19:34, Dom Grigonis wrote: > And ideally, adding 2 builtin(or imported from stdlib) functions: `Break` and > `Continue`, which if called act as `break` and `continue` statements. > How would they work? Would every function call have to provide the possibility to return to a location that wasn't where you would otherwise go? if random.randrange(2): func = Break else: def func(): pass def wut(): for i in range(1, 10): if i % 3: func() print(i) wut() Please, tell me how this would behave. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/77JRIT2DXV3NGPLAJPHZAPFBTTVEZSB2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Proposal for get_or function in Python dictionaries
On Thu, 20 Jul 2023 at 18:16, Greg Ewing wrote: > > On 20/07/23 6:30 pm, James Addison via Python-ideas wrote: > > result = default if bar is None else bar > > or if you prefer > > result = bar if bar is not None else default > > Would it shut anyone up if we had another logical operator: > > x otherwise y > > equivalent to > > x if x is not None else y > > ? > https://peps.python.org/pep-0505/ ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/IVA55XWEGYUIALEJQNCPFKA6EWHU7GLW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Proposal for get_or function in Python dictionaries
On Thu, 20 Jul 2023 at 17:09, Dom Grigonis wrote: > > On 20 Jul 2023, at 09:48, anthony.flury wrote: > In Python then a better way might be > > result = temp := bar() if temp else default > > This way only bar() and default are evaluated and invoked once. > I presume you want a more complicated expression than just "if temp", since this is no better than "bar() or default". But if you DO want some other condition, this would be how you'd write it: result = temp if (temp := bar()) is None else default Or, better: result = bar() if result is None: result = default ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/FI376QAZ7FAA7ZFJPELG73LXR5VFIHBD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Proposal for get_or function in Python dictionaries
On Thu, 20 Jul 2023 at 15:33, Stephen J. Turnbull wrote: > I didn't like that PEP then; I was in the camp of "let's get genuine > Deferreds, and use them to cover some of the use cases for PEP 671." You're almost certainly never going to get that, because "genuine Deferreds", as well as being nearly impossible to pin down, can't actually cover all the use-cases of PEP 671. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/RKT76MFBWNFQB32UJ6MA3BZPV6G2MZD7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Conditional 1-line expression in python (Dom Grigonis)
On Wed, 19 Jul 2023 at 11:51, Dom Grigonis wrote: > > Coming back to deferred evaluation, > > https://peps.python.org/pep-0671/ > These 2 aren’t really orthogonal in functionality. Maybe in implementation. > But PEP671 is a certain subset of deferred evaluation as it can achieve the > same with 1 extra line at the start of the function’s body. No, it's not a subset of deferred evaluation, as has been stated clearly in the PEP and discussed many times in the past. Deferred evaluation is HARD. It's easy to handwave everything and pretend that it magically gets evaluated at the exact right time, but how do you actually define that? What are the scoping rules? Does it create a closure? Try creating an actual concrete specification and you may find out why it hasn't been implemented yet. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/UYBQ4VHCDWUQSQ5B7DUU4NPNUKFIORPR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Proposal for get_or function in Python dictionaries
On Wed, 19 Jul 2023 at 06:41, Dom Grigonis wrote: > > When you put it from this perspective, it seems to make sense, however, I do > not agree. > > To me, from first principles it seems it’s all about condensing more > complexity in smaller modular packages. > > That is why I am a bit confused, when someone argues that it is not about > conciseness, but about expressiveness. You're confused, yet you refuse to accept that you might be wrong. I don't think there's any point me continuing to discuss this with you. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/M76SNAINFPIVM6NLVZAAKCTJTM2NRCVG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Proposal for get_or function in Python dictionaries
On Wed, 19 Jul 2023 at 00:55, Dom Grigonis wrote: > Here I am a bit confused, how is this the case in the language containing > list comprehensions? > Do you understand the difference between expressiveness and terseness? You still seem to be focused on the completely wrong thing here. List comprehensions are not about saving lines, they are about expressing the concept of "build a list from a list". ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/HES5J5CLNNBHXAKIMIQA5WV43GBI6Q4W/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Proposal for get_or function in Python dictionaries
On Tue, 18 Jul 2023 at 23:41, Stephen J. Turnbull
wrote:
> 2. Comparing floats, even against zero, is a bad idea. So I would
> wrap them in math.isclose:
>
> val = a ? (not isclose(c, 0) ? c : d) : (not isclose(d, 0) ? d : c)
That's overly simplistic; there are a lot of times when it's
absolutely fine to compare floats for equality, particularly with
zero, where the idea of "close" can be ill-defined. But this is the
difficulty with toy examples - we have no idea how realistic this
actually is. For now, though, I'd be inclined to keep the semantics
unchanged and just look at the syntax.
> In general you will have function calls
> adding parentheses -- and thus confusion. Perhaps there will be
> lists or tuples involved. You can precompute them and assign
> them to short name variables, but then you lose the one-liner-ness.
This is true, almost trivially so; one-liners aren't all that common
because real-world use-cases are often complicated. However, they DO
exist. It'd be nice to have really good examples but we may well not
have that luxury.
> 3. OK, how about ints then? Yes, that would work, but how frequently
> are you going to be comparing against 0? Here's a more realistic
> case, with readable short argument names:
>
> def clamp_int(n: int, lo: int, hi: int):
> # I wouldn't elide this test because if lo > hi you get a
> # plausible but necessarily erroneous value
> if lo > hi:
> raise ValueError(f'lo = {lo} > {hi} = hi')
> val = n < lo ? lo : (n > hi ? hi : n)
> return val
>
> Agreed, the expression using Python's syntax would be worse, but I
> think this is much more readable:
>
> def clamp_int(n: int, lo: int, hi: int):
> if lo > hi:
> raise ValueError(f'lo = {lo} > {hi} = hi')
> if n < lo:
> val = lo
> elif n > hi:
> val = hi
> else:
> val = n
> return val
>
> and it would be more readable yet if you got rid of the
> assignments and just returned the value as soon as you see it:
>
> def clamp_int(n: int, lo: int, hi: int):
> if lo > hi:
> raise ValueError(f'lo = {lo} > {hi} = hi')
> # Hi, David! Default first!!
> if lo <= n <= hi:# Yes, Virginia, valid Python!
> return n
> elif n > hi:
> return hi
> else:
> return lo
>
> (Yes, I know that some folks argue that suites should have one
> entry point and one exit point, but I don't think it's a problem
> here because of the extreme symmetry and simplicity of the
> conditional. IMHO YMMV of course)
def clamp_int(n: int, lo: int, hi: int):
if lo > hi:
raise ValueError(f'{lo = } > {hi = }')
return max(lo, min(n, hi))
Nobody said we weren't allowed to use builtins, right? :)
> Now, you can add a new one that does the same thing, and that's been
> done. IIRC it took a while to get +=
Note that augmented operators are not simply shorthands for the
expanded version. There are a few differences between:
a.b.c.d.e += value
and
a.b.c.d.e = a.b.c.d.e + value
including that the basis object (a.b.c.d) would only be evaluated
once, and especially, the addition is done in-place if supported (eg
with lists).
> and C-like ++/-- increment
> operators have been requested over and over again. AFAIK the async
> syntaxes do nothing that can't be done with generators, but they make
> it a lot easier to do it right in the most common cases.
A plain async function pretty much IS a generator, but without the
risk of removing the last await point and having the function stop
being a generator. But async generators are also a thing, and there's
no easy way to make a generator-generator with two different types of
yield in it.
But yes, in general, these aren't drastically new pieces of
functionality - they're nice improvements to readability and
expressiveness. I can write an application that uses generators
instead of async functions (and my current flagship non-Python project
does exactly that), as long as I'm not using generators for anything
else. I can write something with no augmented assignment operators, as
long as I always use list extend instead of addition, and don't mind
the reevaluation of intermediate components (which, most of the time,
is only a performance matter, not a correctness one). But it's
definitely nice to have them.
ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/4A2NOURRWABHNPKOHHBE5UTZPLRXPUGD/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Conditional 1-line expression in python (Dom Grigonis)
On Tue, 18 Jul 2023 at 19:02, Dom Grigonis wrote: > > Thank you. > > I meant “superset of 671, not 505”… > > One question: > > def bar(a => None); > return foo(a) > > def foo(a => object()): > return a > > How would I force foo’s default from bar’s call? That's a known-hard problem. The best way is probably to use *a,**kw and only pass the args you get, but that doesn't always work. > Would something like this work? > > def foo(a => object() if a is None else a): > return a Yyes, but now you're defining that a could be None, so you may as well go with the classic idiom: def foo(a=None): if a is None: a = object() The point of default argument expressions is that you DON'T need to accept a fake default. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/RYMC4J53X6RO7RCBXFYWOYLVKQ3Z64BT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Conditional 1-line expression in python (Dom Grigonis)
On Tue, 18 Jul 2023 at 16:25, Dom Grigonis wrote: > > Yes, thank you, this would definitely be nice to have. > > Although, "A generic system for deferred evaluation has been proposed at > times“ sound better if it was a superset of PEP505. Could you refer me to any > resources about such considered system? > Hrm, you'd probably have to scour the archives. It's one of those things that comes up periodically and spawns a discussion thread, but never really gets to a concrete proposal. The best I can find is this, which never even got submitted to the official PEP repository, but it's someone's attempt to make something that could potentially become one, so it's a start. https://github.com/DavidMertz/peps/blob/master/pep-.rst The trouble is, it's really REALLY hard to pin down useful semantics for deferred evaluation. We already have lambda functions, which cover a lot of situations, leaving a lot of uncertainty as to what's being handled by this new proposal - and since no proposal ever truly comes from a single person, that results in a certain amount of chaos. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/BEBXTO5WXYRRPNH2IJMWTMIHGCLUFERL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Conditional 1-line expression in python (Dom Grigonis)
On Tue, 18 Jul 2023 at 14:07, Dom Grigonis wrote: > PEP505 would solve this nicely, but it only applies to None and would not > apply to say user-defined sentinels and many other cases where permutations > of different conditionals arise. > PEP 671 would solve this nicely too. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/R4HVE2MYZT7GJAB6SNKHW6UVC2G4OYYO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Conditional 1-line expression in python (Dom Grigonis)
On Tue, 18 Jul 2023 at 10:37, Dom Grigonis wrote: > As opposed to > > if a == 0: >foo, bar = var1, variable2 > else: >foo, bar = default, default2 > > > Again, one is `a == 0`, another is `b == 0`. I didn’t do a good job conveying > this did I… Will try to be more precise and leave less room for > misinterpretation. Would you really go through and change all your variable names if it turns out that what you actually need is "a == 0" and "b == 15"? This sort of alignment is so fragile and unnecessary. Yes, it's nice when it works out, but it should never be a high priority. > foo = foo3 if foo2 == 0 else default > bar = barbarbar if bar2 == 0 else default2 > > # As opposed to > > foo = foo2 == 0 ? foo3 : default > bar = bar2 == 0 ? barbarbar : default2 Extremely artificial. You've shown that, if the conditions are the same lengths but the "if-true" expressions aren't, you can align them using ?: and can't align them using if-else. It's just as valid to show: foo = "yes" if foo2 else "no" bar = "yes" if barbarbar else "no" Like I said, extremely fragile. > I don’t think it is that easy to draw the line here. > Everything in both of those PEPs can be expressed using current constructs. > So maybe they are about more compact expressions? "Can be expressed"? Well, yes. Python is Turing-complete. So is Brainf*. Doesn't mean we want to use it though. Expressiveness is a spectrum or a scale. You can improve on it without the older version being impossible to write. In fact, Python really doesn't NEED all the syntax it has. Have a read of this series of blog posts: https://snarky.ca/tag/syntactic-sugar/ (Brett Cannon also did a talk on this at PyCon US 2023; not sure if that's been made public yet.) There are only a handful of pieces of syntax that you really can't do without. But you CAN skip having an "if" statement. No kidding - you can eliminate the if statement by smart use of the while statement. https://snarky.ca/unravelling-if-statements/ Improvements to expressiveness allow us to write better code, to make it clearer what the *programmer's intent* is. Sometimes that aligns with compactness; sometimes it doesn't. > Was python made for conciseness or expressiveness? Everything it does can > already be done in C isn’t it? So I would argue any abstraction is really > more about conciseness. Expressiveness is more about incorporation of what is > already there, but not in the abstraction, i.e. extension. But python being > interpreted language written in another language, I really FAIL to see how is > all of this NOT about conciseness and modularity? > Expressiveness. It's about how well the source code represents the programmer's intent. You could write all of your code as a massive matrix of logic gates, but that wouldn't improve readability. And since you can implement logic gates with water - see https://www.youtube.com/watch?v=IxXaizglscw for proof - your program source code could be an acrylic sheet with a bunch of buckets glued onto it. But none of us want to write code like that, and definitely none of us want to read code like that. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/B5YRPPGSGQTAMM6WOKGULK2SKVR4H7KT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Proposal for get_or function in Python dictionaries
On Tue, 18 Jul 2023 at 08:56, Dom Grigonis wrote: > > Just to add, I think your statement actually works in my favour rather than > against my proposal. > > People from this group are potentially biased and lack objectivity against > what I am proposing because they are familiar with python and more > experienced ones participated in “carved in stone” decision regarding already > existent `ifelse` expression. > Of course we're biased. Everyone is biased. If you don't think you're biased, you just haven't seen your biases yet. A few of mine: * I have functional eyesight * I have a US-English layout "qwerty" keyboard * My internet connection, while decent, is not nearly as fast as some * I spend many hours a day writing code (as opposed to a novice, student, or very casual programmer, who all will have other priorities) * I use Linux exclusively and have no experience with Windows 11 * And yes, I know C. Also Ruby, Pike, JavaScript, and a ton of others. Each of these affects my opinions of what's good and what's not. And those are just the ones I could think of, off the top of my head. Some of them I actively fight against; others I simply recognize (for example, when people are discussing a change that would only affect Windows users, I'll let other people judge, since I can't adequately assess its impact). > So I expected that my proposal might even look humorous to some. E.g. In > survey I got a comment “to learn python if I want to use it”. I am doing my > best, just some parts of it are hard to digest in the context of other parts > that are so easily digestible. > Humorous? Or just completely pointless? I don't think anyone here has said that your proposal is a joke. > Maybe this 20-year late discussion will have some impact on future python > expressions. E.g. some new expression will be a superset of `ifelse` and this > will be taken into account. Maybe not, but hopefully it had at least a bit of > positive value. > https://peps.python.org/pep-0622/ Yet again, an improvement in expressiveness, though not in compactness. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/IO74FWNAU7FQEM646EDCMSLYEHR3SZBT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Proposal for get_or function in Python dictionaries
On Tue, 18 Jul 2023 at 08:38, Dom Grigonis wrote: > > > Was that really the intention? Because I was there when PEP 572 was > > written, and I don't recall "beautiful one-liners" as one of the > > justifying reasons. Use around if/while conditions was a strong > > reason, and yes, that can save a line, but "beautiful one-liners" > > hasn't generally been a justifying factor in any Python feature. > > Never said about the intention, just stated that I see it as being a part of > their construction. > > However, in the PEP you have referred and also as I remember reading python’s > “what’s new”, list comprehensions and other 1-liners were close to half of > all examples. > That is very true. Compactness makes for great "what's new" entries. They want to be easily skimmable, which means they need to be short. That's a constraint that isn't true of real-world code, and it WILL cause the what's-new entries to be a bit nonrepresentative. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/543NP3DE7NLWUYKYDII5DDLBOUV6MUJJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Conditional 1-line expression in python (Dom Grigonis)
On Tue, 18 Jul 2023 at 08:34, Dom Grigonis wrote: > > I still feel that compared to list comprehension and other functional and > elegant python constructs, python's if-else expression is lacking. I often > choose to go multi-line much more verbose code as opposed to more brief > constructs just because it becomes unreadable - a more elegant and logically > convenient expression would change the decision ratio significantly, at least > for me. > You choose to go multi-line because the one-liner becomes less readable? Then that's a win for the current system. This is NOT a problem to be solved. Everything is working correctly. You have chosen the readable option over the compact one! > # Code becomes easily read when there is a nice alignment in horizontal > space. e.g.: > > variable = None > length_1 = None > somethin = None > variable = length_1 = somethin = None > # I often take this into account on variable name selection. Now: Poor choice IMO. You could have had more consistent variable names by taking advantage of chained assignment. > foo = var1 if a == 0 else default > bar = variable2 if a == 0 else default2 > > # As opposed to > > foo = a == 0 ? var1 : default > bar = a == 0 ? variable2 : default2 As opposed to if a == 0: foo, bar = var1, variable2 else: foo, bar = default, default2 > From what I have gathered, these: > https://peps.python.org/pep-0505/ > https://peps.python.org/pep-0463/ > , and certain number of proposals in this group at their root are pointing > approximately to the same direction. I.e. some things are too verbose (and > too many lines of code) given the simplicity of what is needed to be done. Both of those are about *expressiveness*. This is not the same thing as compactness. The two do sometimes align but the purpose is different. > https://peps.python.org/pep-0308/#detailed-results-of-voting > It seems that C’s expression was ranked 2nd most favourable… The decision was > 3rd. This kinda suggests that I am not as delusional as I initially thought I > might appear to be with this... > Like I said, people who are *already familiar with* C's syntax find it more comfortable than those who are not. But also - this ship has sailed. There's not a lot of point discussing this. If Python had decided against having any conditional expression, then maybe you could reopen the discussion (and I'll be honest, it would have been reopened already by now); but we have a perfectly good conditional expression, so the chances of getting a duplicate syntax added are slim to Buckley's. Adding another way of writing the same thing doesn't materially improve expressiveness. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/DUPGM2O6WWC64XDIMVKJ6OUHTW7KQBM7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Conditional 1-line expression in python
On Tue, 18 Jul 2023 at 06:43, Dom Grigonis wrote: > > Hi everyone, > > I am not very keen on long discussions on such matter as I do not think there > is much to discuss: there is no technical complexity in it and it doesn’t > really change or introduce anything new. It is only a matter of opinion & > style/design preferences with respect to logical order and brevity of a > statement. > > So I thought, if anyone can be bothered on such question and instead of > writing 3-minute e-mail, would take few seconds to answer 3-question poll. > > https://q5yitzu62.supersurvey.com > Your second example needs a "both are abhorrently unreadable" option. But if you've studied anything whatsoever about the history of the conditional expression in Python, you would know that a survey is actually pretty non-indicative here. We've already seen a much more rigorous survey than this, and the results were preserved for posterity. https://peps.python.org/pep-0308/#detailed-results-of-voting ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/FDN6ICOTIHOL7QWJS3CIZBXDQAEZ6MA7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Proposal for get_or function in Python dictionaries
On Tue, 18 Jul 2023 at 06:40, Dom Grigonis wrote: > > We even got a new operator “:=“ to help us with those beautiful one-liners > (or not) to move towards aesthetics and brevity. > Was that really the intention? Because I was there when PEP 572 was written, and I don't recall "beautiful one-liners" as one of the justifying reasons. Use around if/while conditions was a strong reason, and yes, that can save a line, but "beautiful one-liners" hasn't generally been a justifying factor in any Python feature. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/MJI5UNLOCJK4WTFBFNC2YFBE7PXHRAL7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Proposal for get_or function in Python dictionaries
On Tue, 18 Jul 2023 at 04:37, Dom Grigonis wrote: > > This is NOT a good example, my first language was R, second - python, third > matlab, etc. > > I only became familiar with C/C++ after several years of coding experience. > > This is why, I would dare to say that this preference of mine is not affected > by prejudices. > Never said C was your first language, only that you're familiar with it. And that familiarity inevitably WILL affect your perception, as per what I said. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ZC2O5RFH6VC2IVJVV5IFA2YWQAH7XOH5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Proposal for get_or function in Python dictionaries
On Tue, 18 Jul 2023 at 03:13, Dom Grigonis wrote: > Maybe for someone who majored in languages python’s if-else is more easily > understood. To me, personally, 2nd one is unbearable, while 1st one is fairly > pleasant and satisfying. > This is a REALLY good example of how hard it is to be objective about syntax. Being familiar with something really truly does make it immensely better - for you. You're comfortable with the C syntax. That's great! So am I. But that isn't a good indication of how it would be accepted by someone who isn't familiar with either syntax. The ?: syntax has the advantage that the evaluation order is left-to-right, which is the most common (though far from universal) evaluation order. That is a definite advantage, to be sure, but perhaps not as big as you might think. The if/else syntax is more consistent with other Python syntax by using words, though. Ultimately, *all* syntax has to be learned. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/NGJ5GH6JXOZZLSTJT323F4TUEH5YXN3V/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Proposal for get_or function in Python dictionaries
On Sun, 16 Jul 2023 at 04:07, Jothir Adithyan wrote:
>
> Chris Angelico wrote:
> > On Tue, 11 Jul 2023 at 08:05, Jothir Adithyan adithyanjot...@gmail.com
> > wrote:
> > > Assumptions:
> > > The problem statement is based on a few assumptions:
> > >
> > > You prefer chaining `get` statements for cleaner code.
> > > You expect at least some of the `get` methods to return `None`.
> > > You want to avoid the hassle of using `try` and `except` for every `get`
> > > chain.
> > >
> > > The main assumption here is that None is a perfectly valid value in
> > your data, and should be equivalent to the key being omitted. I think
> > this is uncommon enough to be better done with custom code. But
> > fortunately, there's a really cool way to write that custom code, and
> > that's a path lookup - this is a sort of function that I've written in
> > a lot of these situations. Using your examples:
> > > import contextlib
> > > parent_dict = PlayDict()
> > > parent_dict['k1'] = None
> > > parent_dict['k2'] = {"child_key": "val"} # Parent dict can contain nested
> > > dicts
> > > with contextlib.suppress(AttributeError):
> > > result = parent_dict.get("k1", {}).get("child_key") # This will raise
> > > AttributeError
> > > result = parent_dict.get_or("k1", default={},
> > > arbitrary={}).get("child_key") # This will work
> > > I'd write it like this:
> > def lookup(basis, *keys, default=None):
> > for key in keys:
> > basis = basis.get(key)
> > if basis is None: return default
> > return basis
> > result = lookup(parent_dict, "k1", "child_key")
> > This quite tidily expresses the intent ("delve into this dictionary
> > and follow this path, returning None if there's nothing there"), and
> > is compact, with no repetition. It's a relatively short helper
> > function too, and easy to change into other forms. For example, here's
> > another version that I use, which guarantees to always return a
> > dictionary:
> > def lookup(basis, *keys):
> > for key in keys:
> > if key not in basis: basis[key] = {}
> > basis = basis[key]
> > return basis
> > Etcetera. Flexible and very handy.
> > ChrisA
> Hey Chris, thank you for your time and insight.
>
> I've thought about this for some time, and I believe that adding this feature
> could indeed be a useful and concise helper for many Python users, especially
> for API integrations and web scraping where encountering None values is quite
> common. Do you think it would be feasible to modify the existing get function
> to include a new parameter or perhaps introduce a new function altogether?
>
> I'm trying to understand why this idea may not be considered favorable. What
> are the reasons for not having this feature? What makes the current approach
> better than having this additional functionality?
>
The reason it's not a good fit for the language itself is that there
are lots of small variations. I gave you one other slight variant in
my example, and there are myriad other small differences that could
show up. So it's best for it to be part of your own toolkit. I would
strongly recommend giving the "path lookup" function style a try; it's
actually way more expressive than chained lookups, in the situations
that it's appropriate to.
ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/MVQBBSB2ZH3N7ZSIC3X5U6TT7IYKUW32/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Proposal for get_or function in Python dictionaries
On Tue, 11 Jul 2023 at 08:05, Jothir Adithyan wrote:
> Assumptions:
>
> The problem statement is based on a few assumptions:
> - You prefer chaining `get` statements for cleaner code.
> - You expect at least some of the `get` methods to return `None`.
> - You want to avoid the hassle of using `try` and `except` for every `get`
> chain.
>
The main assumption here is that None is a perfectly valid value in
your data, and should be equivalent to the key being omitted. I think
this is uncommon enough to be better done with custom code. But
fortunately, there's a really cool way to write that custom code, and
that's a path lookup - this is a sort of function that I've written in
a lot of these situations. Using your examples:
> import contextlib
> parent_dict = PlayDict()
> parent_dict['k1'] = None
> parent_dict['k2'] = {"child_key": "val"} # Parent dict can contain nested
> dicts
>
> with contextlib.suppress(AttributeError):
> result = parent_dict.get("k1", {}).get("child_key") # This will raise
> AttributeError
>
> result = parent_dict.get_or("k1", default={}, arbitrary={}).get("child_key")
> # This will work
>
I'd write it like this:
def lookup(basis, *keys, default=None):
for key in keys:
basis = basis.get(key)
if basis is None: return default
return basis
result = lookup(parent_dict, "k1", "child_key")
This quite tidily expresses the intent ("delve into this dictionary
and follow this path, returning None if there's nothing there"), and
is compact, with no repetition. It's a relatively short helper
function too, and easy to change into other forms. For example, here's
another version that I use, which guarantees to always return a
dictionary:
def lookup(basis, *keys):
for key in keys:
if key not in basis: basis[key] = {}
basis = basis[key]
return basis
Etcetera. Flexible and very handy.
ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/UIIRM2KIRBUMGHKKZNUU233WWOLSUXIB/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: "Curated" package repo?
On Sun, 9 Jul 2023 at 18:06, James Addison via Python-ideas wrote: > > On Sun, 9 Jul 2023 at 02:11, Cameron Simpson wrote: > > I have always thought that any community scoring system should allow > > other users to mark up/down other reviewers w.r.t the scores presented. > > That markup should only affect the scoring as presented to the person > > doing the markup, like a personal killfile. The idea is that you can > > have the ratings you see affected by notions that "I trust the opinions > > of user A" or "I find user B's opinion criteria not useful for my > > criteria". > > That sounds to me like the basis of a distributed trust network, and > could be useful. > Why distributed? This sounded more like a centralized system, but one where you can "ignore reviews from this user" for any other user. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/IOFZ4NR3XYQDUTD3FY2XUTRRADPMQ7AC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: "Curated" package repo?
On Thu, 6 Jul 2023 at 04:08, Gregory Disney wrote: > > Why not just use gpg signatures and maintain trusted signing keys? There’s no > reason to reinvent the wheel. If a user wants to use a unsigned or untrusted > packages, they have to accept the risk. > As an alternative to a blockchain? No idea, but I've never considered blockchains to be useful for anything more than toys anyway. As an alternative to a curated package list? That just comes down to who holds the trusted keys, so it's the same as the other suggestions, only you're looking at the mechanics for knowing whether it's on the list, as opposed to the mechanics for figuring out which things go on the list - two sides of the same coin, pretty much. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ANBP64KBYAB3MXO4NQDNMQHSXM525ZTN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Double "at" operator for matmul exponentiation
On Thu, 6 Jul 2023 at 04:02, Dom Grigonis wrote: > What I would alternatively propose is to introduce a couple of (meaningless > operators), so that library developers can make use of them as they wish. > What characters aren't used? “$, ?, `” (or are they?). > What should their precedences be? Operators have to be given that, at least. Unfortunately, whatever precedence you choose, it's going to be awkwardly wrong for at least some potential use-cases. That said, though, there are some pretty cool packages out there that create arbitrary operators. Some of them take advantage of multiple operators to allow multiple effective precedences. Consider for example: https://pypi.org/project/infix/ ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/YQDJ5UMH23FYL5FVFNBLWPOROD5ZZQOG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: "Curated" package repo?
On Thu, 6 Jul 2023 at 03:57, James Addison via Python-ideas wrote: > I also agree with a later reply about avoiding the murkier side of > blockchains / etc. That said, it seems to me (again, sample size one > anecdata) that creating a more levelled playing field for package publication > could benefit from the use of some distributed technologies. Even HTTP > mirrors are, arguably, a basic form of that.. there's at least one question > related to recency of data, though. Delaying availability of a package to an > audience -- if it's important enough -- could under some circumstances become > effectively similar to censorship. > A blockchain won't solve anything here. It would be completely and utterly impractical to put the packages themselves into a blockchain, so all you'd have is the index, and that means it's just a bad version of PyPI's own single-page index. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/PTIS3HZHJSFV7ETWE7UP4HKXS4WN2OEO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: [Suspected Spam]"Curated" package repo?
On Wed, 5 Jul 2023 at 17:12, Stephen J. Turnbull wrote: > > 4) A self contained repository of packages that you could point > > pip to -- it would contain only the packages that had met some > > sort of "vetting" criteria. In theory, anyone could run it, but > > a stamp of approval from the PSF would make it far more > > acceptable to people. This would be a LOT of work to get set > > up, and still a lot of work to maintain. > > Why "self-contained"? I always enter PyPI through the top page. I'd > just substitute curated-pypi.org's top page. Its search results would > be restricted to (or prioritize) the curated set, but it would take > me to the PyPI page of the recommended package. Part of the desired protection is the prevention of typosquatting. That means there has to be something that you can point pip to and say "install this package", and it's unable to install any non-curated package. There are many protections against typosquatting (and malware installation in general), but this particular one can be very effective, albeit with some fairly significant costs. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/TUY6PLLPQOVDDKYV2CZE4QYAEKCZCURT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: "Curated" package repo?
On Wed, 5 Jul 2023 at 17:00, Christopher Barker wrote: > I'm noting this, because I think it's part of the problem to be solved, but > maybe not the mainone (to me anyway). I've been focused more on "these > packages are worthwhile, by some definition of worthwhile). While I think > Chris A is more focused on "which of these seemingly similar packages should > I use?" -- not unrelated, but not the same question either. > Indeed, not the same question; but "some definition of worthwhile" is the crucial point here. If there is one single curated package index of "worthwhile" packages, who decides what's on it and what's not? If not everyone can agree, will there have to be multiple such listings? > Technically, conda is similar to pip -- it has a default "channel" (a channel > is an indexed repository of packages) it points to, and you can point it to a > different one, or any number of others, or install a single package from a > particular channel. > > Socially, it's pretty different > - There is no channel like PyPi that anyone can put anything on willy nilly. > - The default channel is operated by Anaconda.com -- and no one else can put > any thing on there. (they take suggestions, but it's a pretty big lift to get > them to add a package) > - The protocol for a channel is pretty simple -- all you really need is an > http server, but in practice, most folks host their channels on the > Anaconda.org server -- it's a free service that anyone can create a channel > on -- there are a LOT -- folks use them for their personal projects, etc. > So, high barrier to entry. Good to know. That's neither good nor bad inherently, but it is a point of note. > - Then there is conda-forge: > It grew out of an effort to collaborate among a number of folks operating > channels focused on particular fields -- met/ocean science, astronomy, > computational biology, ... we all had different needs, but they overlapped -- > why not share resources? Thanks to the heroic efforts of a few folks, it grew > to what it is now: a gitHub and CI -based conda package build system that > published a conda channel on anaconda.org with over 22,000 (wow! I think I'm > reading that right) packages. > > (https://anaconda.org/conda-forge/repo) > > They are curated -- anyone can propose a new package (via PR) -- but it only > gets added once it's been reviewed and approved by the core team. Curation > wasn't the goal, but it's necessary in order to have any hope that they will > all work together. The review process is really of the package, not the code > in the package (is it built correctly? is it compatible with the rest of > conda-forge? Does it include the license file? Is there a maintainer? ...) > But the end result is a fair bit of curation -- users can be assured that: > 1 - The package works > 2 - The package is useful enough that someone took the time to get it up > there. > 3 - It's very unlikely to be malware (I don't think the conda-forge policy > really looks hard for that, but typosquatting and that sort of thing are > pretty much impossible. > Cool. The trouble is, point 1 is nearly impossible to assure except in the very narrowest of definitions, and point 2's value correlates with the height of the barrier to entry, so it's a fairly strict tradeoff. And unless that barrier is extremely high, there will always be the possibility that someone puts in the effort to get malware pushed, although it does become vanishingly improbable. >> What about OS package managers like the Debian repositories? > > I have no idea, other than that the majors, at least, put a LOT of work into > having a pretty comprehensive base repository of "vetted" packages Right; hence the question of how a "vetted Python package collection" would compare. I can type "sudo apt install python-" and add the name of a package, and I get some assurance that: 1) The package works 2) The package is useful enough 3) It's not malware 4) The specific *version* of the package works along with the versions of everything else. This is a very strong set of criteria, much stronger than we'd be looking for here, as they come with correspondingly higher barriers to entry (getting a package update into the Debian repositories becomes harder and harder as the release date approaches). > conda-forge has about 22,121 -- that's enough to be very useful, but a lot of > use-cases are not well covered, and I know I still have to contribute one > once in a while. > > Looking now -- PyPi has 465,295 projects more than 20 times as many -- I > wonder how many of those are "useful"? Contrariwise, the Debian repository has under a thousand "python-*" packages, but with a much stronger requirement that they be useful. It's interesting that there are only twenty on PyPI for every one on conda-forge. I would have expected a greater ratio. It seems that conda-forge is able to be incomplete AND dauntingly large; how successful would you be at guessing
[Python-ideas] Re: "Curated" package repo?
On Wed, 5 Jul 2023 at 15:07, Jonathan Crall wrote: > > I like the idea of a vetted package index that pip can point to. The more I > think about it, the more I think that it needs some sort of peer review > system as the barrier to entry, and my thoughts to to establishing some DeSci > DAO that could distribute the peer review of packages amongst a set of > trusted maintainers while also being a mechanism to add new trusted > maintainers to the peer-review pool. Peer reviewers could be funded via a fee > to submit a package for publishing. There are a lot of open questions of how > this would be done correctly - or even if this is necessary - but I think to > achieve a scalable, funded, decentralized, and trustworthy package index a > DAO makes some amount of sense. > This adds up to a HUGE barrier to entry for new packages. For your proposal to be successful, a good number of users would need to point pip to the vetted index and NOT to the normal one (otherwise there's no benefit - you're just getting non-vetted packages), and in order for a new package to become relevant, it needs to: 1. Pay money. Even if it's not a huge dollar amount, that is already a very significant barrier for casual users. 2. Get reviewed. This is going to take time. 3. Pass the review. If the review system is at all meaningful, it has to knock some packages back, otherwise all you have is "pay to be visible" which is a horrible system. 4. OR, instead of those steps: Convince your users to switch to the "untrusted" package repository. That makes for a very closed-off ecosystem, where an incumbent has a dramatic advantage over anything that comes along. It would almost certainly require that vetted packages not depend on non-vetted packages (otherwise you'd need some bizarre mechanic whereby "pip install package-name" looks at one repository, but it resolves dependencies by looking at a different one), so nothing would have a chance to be seen in the walled garden until you get it vetted AND recognized. So, sure, this would make life easier for those who want to randomly download packages without thinking about them, but at the cost of making the package repository extremely minimalist and insular. It'd make the Python packaging ecosystem look as unfriendly as iPhone app publishing. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/2WLUMPDRTDVWIHWIJ7KINPF6LD4KRDCY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: "Curated" package repo?
On Wed, 5 Jul 2023 at 10:26, Christopher Barker wrote: > The :problem", as I see it. > > - The Python standard library is not, and will never be fully comprehensive > -- most projects require *some* third party packages. > - There are a LOT of packages available on PyPi -- with a very wide range of > usefulness, quality and maintenance -- everything from widely used packages > with a huge community (e.g. numpy) to packages that are release 0.0.1, and > never seen an update, and may not even work. > Remember though that this problem is also Python's strength here. The standard library does not NEED to be comprehensive, and publishing on PyPI is deliberately easy. The barrier to entry for the stdlib is high; the barrier to entry for PyPI is low. > 1) A "clearing house" of package reviews, for lack of a better word -- a > single web site that would point to various resources on the internet -- blog > posts, etc, that would help people select packages. So one might go to the > "JSON: section, and find links to some of the comparisons of JSON parsers, to > help you choose. The authors of this site could even solicit folks to write > reviews, etc that they could then point to. > Chris A: this is my interpretation of your decentralized idea -- please do > correct me if I got it wrong. > That is a correct interpretation of what I said, yes. I'll take it a bit further though and add that this "single web site" would be ideally editable by multiple people. In fact, Python has a place for that sort of thing: https://wiki.python.org/moin/FrontPage Imagine a page like https://wiki.python.org/moin/Python_Package_Recommendations (doesn't currently exist) that would be managed the same way as other recommendation pages like https://wiki.python.org/moin/IntroductoryBooks - anyone can add a link to their blog post about packages, and if they've focused on a specific category (eg "web frameworks"), that can be right there in the wiki page so people can search for it. That way, it's decentralized for editing, but has a central "hub" that people can easily find. > 2) A Python package review site. This could be setup and managed with, e.g. a > gitHub repo, so that there could be a small number of editors, but anyone > could contribute a review via PR. The ultimiate goal would be > reviews/recommendations of all the major package categories on PyPi. If well > structured and searchable, this could be very useful. > - This was proposed by someone on the previous thread -- again, correct me > if I'm wrong. > I suspect this would end up being broadly equivalent to the first option, but with more effort by a core group of people (or a single maintainer), and in return, would have a more consistent look and feel. > 3) A rating system built into PyPi -- This could be a combination of two > things: > A - Automated analysis -- download stats, dependency stats, release > frequency, etc, etc, etc. > B - Community ratings -- upvotes. stars, whatever. > > If done well, that could be very useful -- search on PyPi listed by rating. > However -- :done well" ios a huge challenge -- I don't think there's a way to > do the automated system right, and community scoring can be abused pretty > easily. But maybe folks smarter than me could make it work with one or both > of these approaches. > Huge challenge indeed. Possibly insurmountable. Popularity contests (purely based on download stats and such) have their value, but do not tell you what's best, only what's the most used. Community ratings, as you say, can be gamed all too easily, plus they STILL tend to favour those that are heavily used rather than niche things that are potentially better. Neither of them adequately answers questions like "which is right *for this use-case*", which will leave a lot of packages out in the cold. > 4) A self contained repository of packages that you could point pip to -- it > would contain only the packages that had met some sort of "vetting" criteria. > In theory, anyone could run it, but a stamp of approval from the PSF would > make it far more acceptable to people. This would be a LOT of work to get set > up, and still a lot of work to maintain. > Definitely possible; how would this compare to Conda? What about OS package managers like the Debian repositories? > Personally, I think (4) is the best end result, but probably the most work as > well[*], so ??? > > (1) and (2) have the advantage that they could be useful even without being > comprehensive -- tthey's need to have some critical mass to get any traction, > but maybe not THAT much. Right, and notably, they can be useful without covering every topic. You could write a blog post about database ORM packages, and that's useful right there, without worrying about whether there's any review of internet protocol packages. Hmm. Once that sort of collection gets some traction, someone might say "Hey, anyone know about grammar parsers?" and add that to a "help
[Python-ideas] Re: dict method to retrieve a key from a value
On Sun, 2 Jul 2023 at 16:36, Christopher Barker wrote: > > However, the amount of time the two of us have spent on this thread could > have been used to review the status of quite a few packages :-) > >> >> Indeed. But I expect it'd be easier to get one person to write one >> blog post about their favourite packages than to create some sort of >> comprehensive list of everything that's good :) > > > of course it would, but then you'd only know about a few packages -- not a > great comparison. > And reviewing those few packages would be just as minimal as anything else, because neither of us has any sort of comprehensive knowledge of packages :) But maybe it'd be a start. > However, that's why I like the idea of a centralized package review site -- > then you get that one person to write one review of the PCRE packages and > post a PR. Then a couple hundred such people and you've got something! But > critical mass would be hard to get. > Every review (where a "review" might cover multiple packages) would have to have a date on it, so people know how useful the information is likely to be. Which means your centralized review site is really just a link to a bunch of separate things anyway. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/QG7LVCJFATEA7K2TEBCURA4T2OEAGCXX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: dict method to retrieve a key from a value
On Sun, 2 Jul 2023 at 15:48, Christopher Barker wrote: >> Only re (the one in the stdlib)? What if you want PCREs - >> there's no package called "pcre" but there's "pcre2", "python-pcre", >> and probably others. > > > And are those three (and others?) actually useful maintained packages? Or > someone's abandoned experiment? Who the heck knows without digging into each > one? > Would you know that even if they were on some official curated list? Projects get abandoned at any time, and unless the curators are constantly checking every package for currency, it's no different - except that people will expect it to be different. > NOTE: I did a (very) quick google to see if someone had written a blog about > PCREs in Python that might provide some guidance -- no luck. I like your > decentralized blog idea, but I'm not sure how to get people to write them :-) > Indeed. But I expect it'd be easier to get one person to write one blog post about their favourite packages than to create some sort of comprehensive list of everything that's good :) ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/PHG3HF2BRHEE2Y3LKPSU3AXAEMIXWLBA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: dict method to retrieve a key from a value
On Sun, 2 Jul 2023 at 15:11, Christopher Barker wrote: > The OP of this thread is not alone -- folks want an authoritative source -- > they may not get that An authoritative source is absolutely perfect for someone who wants less choices. "Just give me the one and only option and promise me that it's perfect!" But that isn't the reality we live in, which means that for any non-trivial situation, there won't BE a valid authoritative list of "good packages". As one example, let's try looking for a regular expression parser. The standard library has one already, but PyPI has more. There's "regex", but also 500 pages of other hits for the search "regular expression" (albeit a lot of related tools that aren't actual regex parsers). There's "regular expressions for humans", "regular expressions for objects" (are those two opposites or unrelated?), "structural regular expressions", "objective regular expressions", and that's just from flipping through a couple of pages of summary. Which ones are "good packages"? Only regex? Only re (the one in the stdlib)? What if you want PCREs - there's no package called "pcre" but there's "pcre2", "python-pcre", and probably others. Importantly, the correct answer to this *depends on your use-case*. Which regular expression package do you want? *It depends*. So which one or ones should be in this curated list? Just the one most popular? You can easily find that from a simple web search. All of them? Now we're back to the original problem, but with more barriers to entry for any new package, which will have to appeal to be added to the curated list, lest it dwindle, perish, starve, pine, and die. Just some of them? Which ones? And that's for something relatively simple. How about a web framework? Which ones belong in the curated list? I don't think the PSF or PyPA should be in a position of making this list, because it would carry too much weight, too much importance. But if not them, then who? Hence, decentralization. An authoritative source is the easy solution for the reader, but a terrible one for the publisher, and ultimately, isn't a good solution for the reader either. It's not just a matter of how much work it would be. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/TMAEOBATCWG2H6QUXIF5QSC5C24QOL45/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: dict method to retrieve a key from a value
On Sun, 2 Jul 2023 at 07:00, Dom Grigonis wrote: > > If it’s curated by more experienced members of this mailing list I would feel > more confident in depending on it and more keen to contribute and review PRs. > Maybe, with luck, if some good robust solution arises, it could be > streamlined to python core library, if deemed appropriate. > What if those people disagree? That's why, in my personal opinion, it's personal opinions that should be posted, not any sort of authoritative list. That way, people can give those opinions the weight they deem fit. A nice collection of links to people's own personal recommendations would be both easier to do, and easier to not get wrong, than a formal and centralized listing. This eliminates the question of "who deserves to be the one to say what's good and what's not", and decentralizes the "but what about this one, you forgot this one" problem. However, the bigger problem of "who wants to actually go to the effort to make this happen?" still remains, as it always will. > What’s the worst that can happen? > The less centralized it is, the less bad things can happen. In fact, YOU could post a recommended list of packages if you want to! What *could* go wrong? You might forget to mention a really awesome package. No problem - someone else can. You might mention a package that someone thinks is trash. No problem - it's a personal opinion. You might mention something that doesn't support current versions of Python. Not a huge problem - that sort of thing happens, people have to do their own research anyway. (All of these would be a bit more serious if the listing were centralized, although not THAT big a deal even then.) Want to start things off? ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/IQENZSLY3O4LE5KFAQDLSHXFZJFT7U6N/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: dict method to retrieve a key from a value
On Sat, 1 Jul 2023 at 22:32, Dom Grigonis wrote: > > Another idea, maybe this group could host a simple git repo. > This has the same problem of who is curating it. If it's uncurated, that's PyPI as it already is. If it's controlled by the PyPA or PSF, then it gives too much authority. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/6W7YULJ5WY2JOQEIWUIIGR26VRTI2EHD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: dict method to retrieve a key from a value
On Sat, 1 Jul 2023 at 18:43, Stephen J. Turnbull wrote: > > Chris Angelico writes: > > On Sat, 1 Jul 2023 at 01:15, Christopher Barker > > wrote: > > > > Totally different topic, but I do think that a "curated" package > > > repo would be helpful -- there is a lot of cruft on PyPi :-( > > Sounds like a "standard library". I understand the difference, but > Like Chris A I'm dubious about whether there's really a lane for it, > or whether like bike lanes in Japan you'd just find a lot of illegal > parking in it. ;-) Ouch :) Though I wish more cities could do what Amsterdam's been doing. Especially the city I live in. Would love to see some walkable areas and real viable bike lanes here. The main difference between standard library and "blessed package" would be the update cycle. Standard library modules can only be updated when Python itself is updated; a blessed package (say, for instance, 'requests') can update any time it wants to. > But if somebody's going to put in effort to review PyPI, I'd really > rather see them go after "typo squatters". Most are probably just > clout chasers, but we know that some are malware, far more dangerous > than merely "cruft". They're definitely working on that. > Chris Angelico writes: > > > Instead, what I'd like to see is: Personal, individual blogs, > > recommending packages that the author knows about and can give > > genuine advice about. > > I think this is a good way to go, expecially if reviewers link to each > other, building community as well as providing package reviews. For > example, while my needs are limited enough that I haven't actually > tried any of his stuff, I've found Simon Willison's (datasette.io) > tweetqs interesting. (datasette itself, of course, and he's tweeted a > lot about LLMs recently too, but here I'm referring to his more random > tweets about utilities he's discovered or created.) > > There are also some idiosyncratic curated package collections (the > FLUFL packages, etc), as well as a lot of frameworks (Django, the Zope > components, lazr) that seem to sprout utility packages regularly. I'm > sure there's a lane if somebody wants to go around blogging about all > the "stuff" they see. Yeah. All we need is for people to start ranting on the internet. Can't be THAT hard right? ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/HI63YITPF3D7WGMWIQNYDQZVJRX4N7C2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: dict method to retrieve a key from a value
On Sat, 1 Jul 2023 at 16:09, Christopher Barker wrote: >If the PSF recommends a package > > Who said anything about the PSF? ;-) -- but yes, that would be another way > to go -- a tightly curated collection -- lower barrier to entry than the > standard library, but still pretty high. Who other than the PSF? (PyPA would be, in the general public's eyes, equivalent - everything I said about the PSF would apply.) ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/YA6FO5QXV56EQ66WOJUFFSKT37DUTJRQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: dict method to retrieve a key from a value
On Sat, 1 Jul 2023 at 01:15, Christopher Barker wrote: > Totally different topic, but I do think that a "curated" package repo would > be helpful -- there is a lot of cruft on PyPi :-( > That idea gets thrown around every once in a while, but there are a few problems with it. When you "bless" one package, every other package doing a similar job will suffer, even if they are just as good (but simply haven't been added to the curated collection). If the PSF recommends a package, people will expect a lot of it, which is a huge burden on the developer(s). And someone has to go through all those packages, and then discuss it with whoever else has to be responsible for this curated collection, and come to an agreement. Instead, what I'd like to see is: Personal, individual blogs, recommending packages that the author knows about and can give genuine advice about. Provide YOUR curated collection. Then maybe a metapage on the Python Wiki could link to some useful/interesting blog posts. Decentralize! ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/OGFJOPQPNV4YH6QPOAJXKDWVIMXNHHIS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: List get/pop
On Thu, 15 Jun 2023 at 06:04, Dom Grigonis wrote: > So following Chris’ logic... > If there are 10,000,000 python users on Stack… > And we assume, that every user encounters such need at least 2 times a year > (being very speculative here, would say conservative?). That was me being VERY generous to the other proposal :) At very best, what you're seeing is an *upper bound* on the number of people referenced, but I wasn't actually arguing numbers there so much as disputing the incredulity given. HOWEVER: Your proposal is much easier to make backward compatible. Adding a keyword-only parameter to a method that currently doesn't accept keyword arguments is (a) not going to conflict with current code, and (b) will instantly error out if someone attempts to use this feature on a Python that doesn't support it, so it's not going to cause subtle errors. Though, notably, this would count as another use-case for PEP 463, if anyone felt like reviving that. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/2S6ZFAMP5FBZKDCOSSSTXTU477WFTW2Z/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Warn when iterating over an already exhausted generator
On Wed, 14 Jun 2023 at 09:05, BoppreH via Python-ideas wrote: > > @ChrisA: There are already flags for enabling warnings on dangerous bytearray > comparisons[1] or relying on locale-dependent encodings[2], not to mention a > whole Development Mode flag[3] that adds extra checks. Some of those checks > affect fewer people than my proposal. A "warn on reused generators" flag > would fit right in, maintain backwards compatibility, and help some people > (admittedly less than an opt-out one). > Citation needed, how do you calculate that they affect fewer people than your proposal? The byte/str comparison warning relates to Py2/Py3 changes, which affected huge numbers of people; locale-dependent encodings affect everyone whose systems default to those encodings; and I don't know what the debug build does exactly, but it's specifically meant to cover things that are too expensive to check for normally. Also, question: Would your proposal even be useful to people if they had to run Python with a special parameter to get it? Wouldn't it be just as easy to shadow iter(), like I have already suggested multiple times as a much better way to do this? > And then Chris' messages started rolling in. Backward compatibility is WAY more important than a lot of proposals seem to acknowledge. You're welcome to hate me for saying it, but frankly, you're also welcome to ignore my posts. I don't have to prove anything to you; the onus is on you to demonstrate the value of your proposal, and at the moment, you've shown a benefit in a very small number of cases, contrasted with a potentially huge number of situations where this would create a spurious warning. Blaming me for the pushback is a tad unfair. But that's your prerogative. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/RHQWRDV46TPPHTVD5ZRYFHILQM6PZ53T/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Warn when iterating over an already exhausted generator
On Wed, 14 Jun 2023 at 07:52, BoppreH via Python-ideas wrote: > > Sorry, I'm new to the list and was not aware the burden of proof was so high. > Can you point me to one or two successful posts in Python-ideas where I can > learn how to show there's a real need for a feature? > It's more a matter of the need required for backward incompatibility. Have a look through the mailing list archives; although, something with no controversy will be hard to find, since it's just a couple of posts and then it goes to the tracker and that's that, it's implemented. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/OE3SGKHJTQ2G4IUEBGIH6LZRAYXAVMD6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Warn when iterating over an already exhausted generator
On Wed, 14 Jun 2023 at 07:02, BoppreH via Python-ideas wrote: > > > In close to 10 years of experience with python I have never encountered > > anything like this. > > Here's a small selection of the StackOverflow questions from people who > encountered this exact issue: But now try to find people who would be adversely affected by your proposed change. Unless you do it in a purely backward compatible way such as the local shadowing of iter(), you WILL break other people's code. What you've shown is that a small handful of people have wondered at the reiterability of generators, which is NOT the same as wanting a warning in these situations. Even if we consider that every single upvote represents a person who wants this feature, you've shown, what, a thousand people total? Across the whole world? That's not exactly an overwhelming number of people, and hardly enough to make a backward-incompatible language change. Let's go back to your earlier incredulity: > And I have to say I'm surprised by the responses. Does nobody else hit bugs > like this and wish they were automatically detected? You've found a dozen questions that have been upvoted by a maximum of 124 people, by your own count (I didn't bother going through all the questions to check). Let's make some VERY generous estimates: 1) Every upvote represents a unique person (pretending that nobody browses multiple questions and upvotes them all) 2) Each of those people agrees with your proposal 3) The total upvote count is 1000 (feel free to go and sum them for me, I can't be bothered) 4) For everyone who upvotes, nine others don't bother to upvote That'll give an incredibly generous figure of 10,000 Stack Overflow users who might support your proposal. Stack Overflow has 21 million users [1]. If we assume that those who answer their survey are representative (impossible to prove, but the best we can do), about half of those are Python users [2]. That's roughly 10,000,000 Stack Overflow users who use Python. Even if we assume that Stack Overflow users are representative of the internet at large (they're definitely not, but again, it's good to at least having some figures), that's 0.1% of people. So. yeah, I'm not surprised that none of us here has run into a problem. I strongly recommend reconsidering the "shadow iter() in your own code" solution, as it is entirely backward compatible. ChrisA [1] https://stackexchange.com/sites and select Stack Overflow - it says "21m" [2] https://stackoverflow.blog/2023/06/13/developer-survey-results-are-in/ ___ 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/YOGCY5HPSKXTONCHYZ3GBS7RKSIOY5YR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Warn when iterating over an already exhausted generator
On Wed, 14 Jun 2023 at 01:07, BoppreH via Python-ideas wrote: > And I have to say I'm surprised by the responses. Does nobody else hit bugs > like this and wish they were automatically detected? > Nope, I've never had that happen to me, and I *have* made use of calling iter() on potentially-exhausted iterators (usually implicitly). ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/74AGNILBGV7X44JD7ADURLC5NZ3IXI5J/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Warn when iterating over an already exhausted generator
On Tue, 13 Jun 2023 at 21:03, BoppreH via Python-ideas wrote: > > Any thoughts on logging a warning, perhaps behind an opt-in flag? I could not > find a single false positive scenario, so I expect the signal-to-noise ratio > to be high and prevent lots of bugs. > Shadow the iter() function and make your own. That's your opt-in flag. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/EGCTVJ27ZZJZDMTONCUY3AFRT7L753TD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: yield functionality to match that of await
On Tue, 13 Jun 2023 at 14:54, Greg Ewing wrote: > > On 13/06/23 11:38 am, Chris Angelico wrote: > > (Fun fact: Pike looked at what Python was doing, and came up with a > > concept of "continue functions" > > And I gather that the "async" and "await" keywords came > from C#. Languages are always stealing from each other. :-) Yeah, it's very common to borrow ideas like that. I just find it rather neat that Pike reused an existing keyword rather than creating a new one - Python had the same dilemma and chose to create a weird context-dependent keyword for a few versions, most other languages just made it a keyword and that's that, but Pike chose to go "well, let's call these things 'continue functions', and then we can use that word!". ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/PMGGV7Y7VFEZVQSCGK72L4I5Z3Y23VYR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: yield functionality to match that of await
On Tue, 13 Jun 2023 at 09:33, Greg Ewing wrote: > > On 13/06/23 9:29 am, Dom Grigonis wrote: > > Also, could anyone point me in the direction, where it is explained why new > > await/async syntax was introduced instead of making use of already existing > > yield coroutine functionality? > > To my mind, the fact that coroutines use the same underlying > mechanism as generators is an implementation detail. It's > only like that for historical reasons, and it could change in > the future. > I think they currently use what's basically a copy of the generator implementation. It makes sense to make resumable functions that way. (Fun fact: Pike looked at what Python was doing, and came up with a concept of "continue functions" which work broadly the same way that generators do, but with a declaration - kinda on par with writing "continue def gen():" in Python. Yes, it reuses the "continue" keyword.) ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/KN4SBHIQ4UHIJHANKE6FPX53YHVRUAOA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: yield functionality to match that of await
On Tue, 13 Jun 2023 at 07:33, Dom Grigonis wrote: > > I was wandering if there are any issues in making `yield` usage to be the > same as that of `await` > > Most importantly: > l.append(yield Object()) You should be able to use that, since yield *is* an expression. The only oddity is, you have to parenthesize the yield expression again even though it's inside parentheses: l.append((yield Object())) > Nice to have: > yield with Object(): > yield for i in Object(): These, though, are unlikely to be supported, since "yield " isn't going to support statements. > Also, could anyone point me in the direction, where it is explained why new > await/async syntax was introduced instead of making use of already existing > yield coroutine functionality? > I don't know if there's a full explanation written down, but one important reason is that you can refactor async functions without worrying about suddenly changing their behaviour unintentionally. If you happen to refactor out the last "yield" from a generator, suddenly it's not a generator any more, and you'll have a weird time trying to figure out what happened; but an async function is an async function even if it doesn't (currently) have any await points in it. Another reason is that you can have asynchronous generator functions, which use both await AND yield. It's not easy to create a two-layer yielding system on top of yield alone. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/44CVCAIWAYHTJF6KJSC7XXK2A4EXWYK7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a .whitespace property to module unicodedata
On Sat, 3 Jun 2023 at 10:12, David Mertz, Ph.D. wrote:
>
> Let's call the styles a tie. Using the SOWPODS scrabble wordlist (no
> currency symbols, so False answer):
>
> >>> unicode_currency = {chr(c) for c in range(0x) if
> >>> unicodedata.category(chr(c)) == "Sc"}
> >>> wordlist = open('/usr/local/share/sowpods').read()
> >>> len(wordlist)
> 2707021
> >>> %timeit any(unicodedata.category(ch) == "Sc" for ch in wordlist)
> 176 ms ± 1.75 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)
> >>> %timeit any(unicodedata.category(ch) == "Sc" for ch in set(wordlist))
> 17.8 ms ± 121 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
> >>> bool(set(wordlist) & unicode_currency)
> False
> >>> %timeit bool(set(wordlist) & unicode_currency)
> 18 ms ± 216 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
>
> Of course, this is a small character set of 26 lowercase letters (and
> newline as I did it). A more diverse alphabet might tip the timing
> slightly, but it's going to be a small matter either way.
>
Remember though, the original request was not for a set, but for a
string. Try your timing again when working with a string.
The any() form is almost certainly the most effective, although I
suppose it could be implemented in C for better performance (avoiding
calling back into Python repeatedly). Not sure it's necessary though.
ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/TOAR5FT3MDIEZFBVT7YGR6CTZ2JKCZCQ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a .whitespace property to module unicodedata
On Sat, 3 Jun 2023 at 09:42, David Mertz, Ph.D. wrote: > > Yeah... oops. Obviously I typed the version in email. Should have done it in > the shell. But you got the intention of set-ifying the characters in the > large string. Yep. I thought of that as I was originally writing, but absent benchmarking data, I prefer the simplest way of writing something. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/BVPDSXXOCOWZ5G2THPB3ZVG6VPXDBE24/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a .whitespace property to module unicodedata
On Sat, 3 Jun 2023 at 08:28, David Mertz, Ph.D. wrote: > > This is just bar talk at this point. I think we've shown that this is > easy enough to do that programmers can roll their own. > > But as idle chat goes, note that in your code: > >set(unicodedata.category(ch) for ch in s) > > If `s` is a billion characters long, then we make a billion calls to > the `.category()` method. Python calls are comparatively expensive, > even on well optimized data structures like strings. > > In my version: > > bool(set(s) & set(unicode_categories['Sc']) > > The billion characters are first reduced to a smallish set of hundreds > or thousands of distinct characters without needing method calls. Then > that is intersected with a smallish set of characters in the category. > > You could optimize your version, however, simply by using: > >set(unicodedata.category(set(ch)) for ch in s) Or perhaps: set(unicodedata.category(ch) for ch in set(s)) But measure before considering this worthwhile. > Yours provides more information, since it lists all the categories. > But if you REALLY only care about one category, then you still have to > ask `'Sc' in set(unicodedata.category(set(ch)) for ch in s)`. Which > is fine, that's not a hard question to ask. If you REALLY want to just check whether any category is there, you probably want something like: any(unicodedata.category(ch) == "Sc" for ch in s) which is completely different from what you were suggesting, and still doesn't require the string of all codepoints in the category. Point is, querying the string is almost always going to be more efficient than intersecting with the full gamut of that category. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/KMHZOQJQPILZD6Z3AKKRQXGHXVYFQPER/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a .whitespace property to module unicodedata
On Sat, 3 Jun 2023 at 07:28, David Mertz, Ph.D. wrote: > > Sure. That's fine. With a sufficiently long strings my code is faster, but > for "typical" strings yours will be. Really? How? Your code has to build a set of every character in the string; mine builds a set of every category in the string. Set intersection won't be slower for a smaller set. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/5C7WSPFDJ4A6LRHL67N7UFPXGU4KI56O/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a .whitespace property to module unicodedata
On Sat, 3 Jun 2023 at 07:08, David Mertz, Ph.D. wrote: > > def does_string_have_currency_mark(s): > return bool(set(s) & set(unicode_categories['Sc']) > > def does_string_have_numeric_digit(s): ... > > ... and so on. Those seem like questions one asks often enough. Not > every day, but more than never. > These questions are much better answered with the unicodedata.category() function. First figure out what categories your string has: cats = set(unicodedata.category(ch) for ch in s) And then check whether Sc is in that set, or whatever others you care about. This way, the set contains only the categories, not the characters; there's no reason to do set intersection with all of the characters. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/3EK66S27AO2IFBWPOIJ6ABUEJ6C6W2YB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a .whitespace property to module unicodedata
On Sat, 3 Jun 2023 at 06:54, David Mertz, Ph.D. wrote:
>
> If we're talking PyPI, it would be nice to have:
>
> unicode_categories = {"Zs": [...], "Ll": [...], ...}
>
> For all the various categories. It would just take one pass through
> all the characters to generate it, but then every category would be
> fast to access later. On the other hand, it's a few lines of code
> with a lazy import. Probably not enough code to put on PyPI.
>
Question: What is the advantage of having this? What are the use-cases?
ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/4ZFJWXPYS6TWU7XBA5G63RY5H4KGOSW2/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a .whitespace property to module unicodedata
On Fri, 2 Jun 2023 at 02:27, David Mertz, Ph.D. wrote:
>
> It feels to me like "split on whitespace" or "remove whitespace" are
> quite common operations. I've been frustrated a number of times by
> settling for the ASCII whitespace class when I really wanted the
> Unicode whitespace class.
>
They are indeed, quite common. It's a good thing Python makes those easy.
>>> len("\u2000spam\u2001".strip())
4
>>> "spam\u2002ham".split()
['spam', 'ham']
ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/CJB356TCUPJ7DITRHQE6NPJ2ILWGYXZY/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Visual Python.
On Sat, 20 May 2023 at 02:53, Michael R wrote: > > To whom it may concern: > > Is it possible to create a Visual Python with options and editing tools > similar to Excel? > In the beginning it could be a combo with a command-docker, calling for a > visual Routine. > Indented structure of coding in Python is perfectly suited for it. > In my mind such structure was the first subconscious step in this direction. > It would make programming much easier: almost like playing with LEGO blocks. > Sounds like you want something like Scratch? https://scratch.mit.edu/ It's not as powerful as Python, but it's a great way to get started in programming. Scratch itself has inspired a family of related concepts, including domain-specific languages, that take advantage of that "almost like playing with LEGO blocks" UI style. I wouldn't want to write a large-scale application in that, but I definitely *do* like building channel bot commands that way! ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/24CO4SOKOJINLYDT75S35SEFQJWKFPMB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: @lazy decorator an alternative to functools.partial ?
On Thu, 18 May 2023 at 05:14, Daniel Guffey wrote: > > Apologies, I didn't mean to imply PyPI was inherently untrustworthy, > unusable, or irrelevant. Clearly, it has a place and I use it for packages > that I am familiar with and trust. Then I would advise being careful how you word things, since what you said was a pretty clear recommendation against ever using it. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/XI2JLNJZ7VPFMHNEAPXX2GCXXVC6YLWM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
On Sat, 29 Apr 2023 at 23:01, wrote: > > Ad 4) Wouldn't "<=" be a little more logical than "=>"? The perceived > direction of the "flow" of the default value is exactly opposite, i.e., the > default value is always evaluated and then put *into* the argument. > Using arrows to represent information flow has been done, for example in APL and R, but it's generally not been a significant benefit. C++ uses flow operators in a delightfully cute way that gets old after about the second time you actually use it. (Python has done similarly cute things with certain operators, with mixed results. I think Pathlib has been quite successful, but there are others that are less so.) Flow direction simply isn't a valuable-enough piece of information to be worth reusing an existing operator and thus risking ambiguity. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/G7ZZ3KBI44PAA26O36JXAIQNPCHBNYAT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Allowing `str.format` to format one or more parameters instead of all parameters
On Wed, 26 Apr 2023 at 11:18, Joao S. O. Bueno wrote: > Worst case scenario, one goes from one non-running program to a running > program producing partially incorrect output. > Wording that another way: Buggy code, instead of raising an immediate exception, now produces wrong output. This is a very bad thing. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/THHF2BID5JOJNQNSYKLLMLRPT6WY67XM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Protocols Subclassing Normal Classes
On Fri, 21 Apr 2023 at 22:57, Jordan Macdonald wrote: > However, I then encountered an issue: I could define a Protocol that > specified the 'stop()' method easily enough, but if I annotated the manager > as taking that, it would accept any class which implemented a method named > 'stop()', which was not correct; the manager should only accept threads which > implement such a method. > To what extent is that actually a problem? Does it need any other features of the thread? My guess is that, after stopping the thread, it may want to join() it; in that case, what you could do is add join to the Protocol. Or whatever else is needed. You're trying to hybridize duck typing and inheritance typing, which seems odd. It should be possible to pick one or the other here. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/QTKLFHVPDVB34EZVYXCWXSAU7N7UVSAL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: len(Enum) should raise TypeError
On Mon, 3 Apr 2023 at 17:57, Benedict Verhegghe wrote: > > Well, it's not an object of type 'type' like the list or dict mentioned > by the OP, for which len() give a > TypeError: object of type 'type' has no len() I'm not sure what you mean here. Enum is of type EnumMeta, which is a subclass of type. That means that, according to the normal rules of type hierarchy, Enum is indeed a type. Types add functionality that the parent type (with some Exceptions), so it should be no surprise that EnumMeta can add a __len__ method that type itself didn't have. > Any derived class of Enum will also return True for > isinstance(..., type). Yes, that is correct. Any subclass of Enum will also be a type, and will have a length. >>> class TestEnum(Enum): ... SPAM = 1 ... HAM = 2 ... >>> isinstance(TestEnum, type) True >>> len(TestEnum) 2 > Should the derived classes then neither have a > meaningful result for len()? Enum and derived classes hold a container > with a fixed set of values. It makes perfectly sense to ask for the > number of possible values, even when there are none. > Yeah, and I'm of the opinion that it's not a problem for Enum to have zero possible values, but to have the concept of values. Although it also wouldn't be a problem if it didn't. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/7BC4WQ5SN5AJBWOOWOUVWW7JK2RUSNDQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: len(Enum) should raise TypeError
On Mon, 3 Apr 2023 at 15:54, Benedict Verhegghe wrote: > > Enum is not a type, like the OP suggested: > Well, it is: >>> isinstance(Enum, type) True but it has a metaclass, meaning that the type of Enum is a subclass of type. >>> type(Enum) >>> type(Enum).__bases__ (,) I mean, we wouldn't be subclassing it if it weren't a type. The __len__ method is implemented on the metaclass to allow all Enum subclasses to have lengths (ditto __iter__ to make them iterable), and as a consequence of that, Enum itself has all the attributes that it wants to give to its subclasses. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/V2HVHKTK3HG6CV3NBZFISPV6H5PHTTYL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: len(Enum) should raise TypeError
On Mon, 3 Apr 2023 at 08:28, Greg Ewing wrote: > > On 2/04/23 6:36 pm, Benedict Verhegghe wrote: > > An Enum is functionally a container with a limited set of constants. Why > > should it not be legitimate to ask for the number of constants in it? > > But Enum itself isn't an enum, it's a constructor for enums. > I think len() just happens to work on it as a side effect > of the way enums are implemented. > Enum itself is iterable, so the question is: how important is it to block this? Is it actually a problem that the Enum type acts like it has no elements? ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/3MYSADUPEVP5DJKMRMFF6JKYQAWKAWXK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: C#-style "as" casting syntactic sugar for type hints
On Fri, 24 Mar 2023 at 13:02, Will Bradley wrote:
> It would be nice if I could just write "birthDate":
> date.strftime(r'%m/%d/%Y') as str, like in C#.
I'm sure it would - for you. Unfortunately it would most definitely
NOT be nice to write:
with something as str:
and then be unsure whether you're casting or assigning. Python's "as"
keyword usually indicates a name binding ("import x as y", "except
Exception as e", etc), not a type cast.
Improve your type hinting upstream (by proper use of typeshed), to
avoid the need for these casts. Needing to cast at time of call is
usually a bad sign - it means that not only can you not figure out the
type from the function call (normally the most common way to get
typing information), you also can't figure it out from usage.
ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/G7WRX57EQYRR7P6JELXKHKTAZ76FUDDL/
Code of Conduct: http://python.org/psf/codeofconduct/
