[Python-ideas] Re: Revisiting a frozenset display literal
On Wed, Jan 19, 2022 at 6:31 PM Ben Rudiak-Gould wrote:
>
> My preferred syntax for a frozenset literal would be something like
>
> {1, 2, 3}.freeze()
>
> This requires no new syntax, and can be safely optimized at compile time (as
> far as I can tell).
>
> set.freeze would be a new method of sets which could also be used at run
> time. It would return a new frozenset object and wouldn't alter the set
> object (so perhaps the name I suggested isn't ideal). Of course
> frozenset.freeze would just return itself.
>
+0.5. I'm not sure if CPython is currently optimizing this (I tried
"spam".upper() and it didn't constant-fold), but it certainly could.
Making this work would depend on several optimizations:
1) Recognize literal.method() as being potentially constant-foldable
2) Marke some methods as pure and therefore optimizable
3) Recognize that the (mutable) set to the left of .freeze() can be
frozen just as "a in {1,2,3}" can
But yes, in theory, this could work. There's no way that it can be
semantically wrong, no way to shadow that method.
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/YDESIUXVULQMTYTRT65FT7SSWER3EELA/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Revisiting a frozenset display literal
+1
On Wed, 2022-01-19 at 07:20 +, Ben Rudiak-Gould wrote:
> My preferred syntax for a frozenset literal would be something like
>
> {1, 2, 3}.freeze()
>
> This requires no new syntax, and can be safely optimized at compile
> time (as far as I can tell).
>
> set.freeze would be a new method of sets which could also be used at
> run time. It would return a new frozenset object and wouldn't alter
> the set object (so perhaps the name I suggested isn't ideal). Of
> course frozenset.freeze would just return itself.
>
> ___
> 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/LYGTXEHMUVVPC3DAHUDLMKLP2574GX5L/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/TG7HGCXR3OVR25GPSWXVDRROSUALBES6/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Revisiting a frozenset display literal
My preferred syntax for a frozenset literal would be something like
{1, 2, 3}.freeze()
This requires no new syntax, and can be safely optimized at compile time
(as far as I can tell).
set.freeze would be a new method of sets which could also be used at run
time. It would return a new frozenset object and wouldn't alter the set
object (so perhaps the name I suggested isn't ideal). Of course
frozenset.freeze would just return itself.
___
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/LYGTXEHMUVVPC3DAHUDLMKLP2574GX5L/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Allowing non-ASCII bracket and quote characters in source code
On 2022-01-19 00:02, Steven D'Aprano wrote:
On Wed, Jan 19, 2022 at 10:12:23AM +1100, Chris Angelico wrote:
Not sure about Python, but C and C++ have digraphs and trigraphs as
alternatives for certain symbols, specifically because some
OS/keyboard/language combinations may not be able to easily type the
originals.
I believe that those C digraphs date back to days when ASCII was not a
guaranteed lowest common denominator, and there were computers that did
not support characters such as braces {}. And then C++ just inherited
them from C.
Pascal had the same thing: comments were either {comment} or (*comment*)
specifically because in the 1970s there were lots of computers and OSes
that did not support braces. It wasn't until the early 80s that the
ASCII character set became more or less universally supported in the
English-speaking world.
> Okay. Without looking it up, how would *you* type ⟮ U+27EE "Mathematical
> Left Flattened Parentheses"? On your honour now, don't look it up.
Be careful: don't give people the codepoint number in these
challenges, because a lot of input systems let you enter any character
by keying in the codepoint.
So David has made it clear.
Here's a better challenge: Type five unique open parenthesis signs,
without looking up their key sequences or codepoints.
Yes :-)
"Icon" is/was an interesting language. It did automatic conversions such
as between numbers and strings.
The problem with that was that it needed more operators.
For example:
"+" for addition and "++" for union.
"|" for alternation, "|" for string concatenation and "|||" for
list concatenation.
"=" for numerical equals, "==" for string equals and "===" for
value equals.
It can be difficult to remember what each of a set of similar operators
is used for.
Python already has 3 pairs with (), [] and {}, and 2 of them have more
than one use.
___
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/RS3CSRQTX6EFHS4276YIMH7ERXFXRHZT/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Revisiting a frozenset display literal
On 2022-01-18 23:50, Steven D'Aprano wrote: On Wed, Jan 19, 2022 at 11:30:36AM +1300, Greg Ewing wrote: I'd also be happy with making frozenset a keyword. - int, float, str, tuple, dict, set, exceptions, len, etc are not keywords, so they can be shadowed (for good or bad); - alone out of all the builtin types and functions, frozenset is a keyword. Shadowing of builtin functions is a double-edged feature. But I think that, having made the decision to make them *not* keywords, they should either *all* be keywords, or *none*. It is weird to have some of them shadowable and some of them not. None, True and False are special values, in a category of their own, so I don't think the inconsistency there is important. But having frozenset _alone_ out of the builtin functions and types a keyword would be a real Wat? moment. I know about "foolish consistency", but then there is also foolish inconsistency. If we could just make one builtin function/type a keyword, with all the optimization advantages that allows for, would we *really* choose frozenset as the most important? I don't know, the answer isn't clear to me. But it certainly wouldn't be my first choice. A suggestion (that you're probably not going to like!) would be to have a way of indicating explicitly that you're referring a builtin, e.g. `frozenset` (using backticks). You could redefine "frozenset", but `frozenset` still refers to the builtin "frozenset". ___ 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/2TEC75RRPQNK3RUPZGXDH56QHK565A62/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Allowing non-ASCII bracket and quote characters in source code
On Wed, Jan 19, 2022 at 11:10 AM Steven D'Aprano wrote:
>
> On Wed, Jan 19, 2022 at 10:12:23AM +1100, Chris Angelico wrote:
>
> > Not sure about Python, but C and C++ have digraphs and trigraphs as
> > alternatives for certain symbols, specifically because some
> > OS/keyboard/language combinations may not be able to easily type the
> > originals.
>
> I believe that those C digraphs date back to days when ASCII was not a
> guaranteed lowest common denominator, and there were computers that did
> not support characters such as braces {}. And then C++ just inherited
> them from C.
C++ added some of its own, but I believe the justification was the same.
It's not just about ASCII though; it's about keyboards and input
methods, and I'm unsure when that stopped being a concern. Maybe it
still hasn't, in some places in the world.
Worth noting: In many places in the world, ASCII Latin letters are not
the ones used for normal text. What's the normal way to write language
keywords and builtins? Do people switch keyboard layouts? Is there a
standard way to quickly enter a Python keyword and have it
transliterated? Would love to hear from someone who uses Python in
Russian, Greek, Korean, Arabic, or any other non-Latin language.
> Pascal had the same thing: comments were either {comment} or (*comment*)
> specifically because in the 1970s there were lots of computers and OSes
> that did not support braces. It wasn't until the early 80s that the
> ASCII character set became more or less universally supported in the
> English-speaking world.
Huh. I remember the (*comment*) style being the dominant one. Didn't
know it was due to charset limitations.
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/KA6RZVNWK6KOLHQWFFGQRUQOTBC7TFLW/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Allowing non-ASCII bracket and quote characters in source code
On Wed, Jan 19, 2022 at 10:12:23AM +1100, Chris Angelico wrote:
> Not sure about Python, but C and C++ have digraphs and trigraphs as
> alternatives for certain symbols, specifically because some
> OS/keyboard/language combinations may not be able to easily type the
> originals.
I believe that those C digraphs date back to days when ASCII was not a
guaranteed lowest common denominator, and there were computers that did
not support characters such as braces {}. And then C++ just inherited
them from C.
Pascal had the same thing: comments were either {comment} or (*comment*)
specifically because in the 1970s there were lots of computers and OSes
that did not support braces. It wasn't until the early 80s that the
ASCII character set became more or less universally supported in the
English-speaking world.
> > Okay. Without looking it up, how would *you* type ⟮ U+27EE "Mathematical
> > Left Flattened Parentheses"? On your honour now, don't look it up.
>
> Be careful: don't give people the codepoint number in these
> challenges, because a lot of input systems let you enter any character
> by keying in the codepoint.
So David has made it clear.
> Here's a better challenge: Type five unique open parenthesis signs,
> without looking up their key sequences or codepoints.
Yes :-)
--
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/NELWLYP7EPTF7TU24NUFZ636JBHJEERG/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Revisiting a frozenset display literal
On Wed, Jan 19, 2022 at 11:30:36AM +1300, Greg Ewing wrote: > I'd also be happy with making frozenset a keyword. - int, float, str, tuple, dict, set, exceptions, len, etc are not keywords, so they can be shadowed (for good or bad); - alone out of all the builtin types and functions, frozenset is a keyword. Shadowing of builtin functions is a double-edged feature. But I think that, having made the decision to make them *not* keywords, they should either *all* be keywords, or *none*. It is weird to have some of them shadowable and some of them not. None, True and False are special values, in a category of their own, so I don't think the inconsistency there is important. But having frozenset _alone_ out of the builtin functions and types a keyword would be a real Wat? moment. I know about "foolish consistency", but then there is also foolish inconsistency. If we could just make one builtin function/type a keyword, with all the optimization advantages that allows for, would we *really* choose frozenset as the most important? I don't know, the answer isn't clear to me. But it certainly wouldn't be my first choice. -- Steve ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/GCGTIGNJRFXFK66FRR57TEWATQPRLEQE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Allowing non-ASCII bracket and quote characters in source code
On Tue, Jan 18, 2022, 5:46 PM Steven D'Aprano > Okay. Without looking it up, how would *you* type ⟮ U+27EE "Mathematical > Left Flattened Parentheses"? On your honour now, don't look it up. > You've kind of given away the game. I'd press "shift-ctrl-u 2 7 e e ". I'm not even at my computer, but on my tablet, now I'm not arguing to add these. Those keystrokes are more cumbersome, and if you hadn't just told me I'd have no idea of that codepoint. ___ 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/XLUC2KCQU7UGKY6MUVEIBVBSBW5CYXI5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Allowing non-ASCII bracket and quote characters in source code
On Wed, Jan 19, 2022 at 9:47 AM Steven D'Aprano wrote:
>
> On Tue, Jan 18, 2022 at 07:40:40AM -0700, 2qdxy4rzwzuui...@potatochowder.com
> wrote:
> > On 2022-01-18 at 12:07:15 +1100,
> > Steven D'Aprano wrote:
> >
> > > I would be more sympathetic to this idea if:
> >
> > > 1. I knew how to easily type all those brackets on the keyboard,
> > > without having to use a GUI character picker.
> >
> > That's between you and your OS.
>
> Is there any other Python syntax which is likewise OS-dependent?
Not sure about Python, but C and C++ have digraphs and trigraphs as
alternatives for certain symbols, specifically because some
OS/keyboard/language combinations may not be able to easily type the
originals.
Over time, a particular set of symbols seems to have settled in as the
standard ones that most programmers can use, such that anyone who
can't easily type them will learn how to work around that problem. For
example, REXX supports two spellings of its negation operator: REVERSE
SOLIDUS "\" and NOT SIGN "¬", but almost nobody uses the latter.
Would love to hear from people whose keyboards lack these characters.
> Okay. Without looking it up, how would *you* type ⟮ U+27EE "Mathematical
> Left Flattened Parentheses"? On your honour now, don't look it up.
Be careful: don't give people the codepoint number in these
challenges, because a lot of input systems let you enter any character
by keying in the codepoint.
Here's a better challenge: Type five unique open parenthesis signs,
without looking up their key sequences or codepoints.
> Do you think that the majority of Python programmers, especially
> beginners, will be keen to memorize a dozen or so key combinations to
> write parentheses and brackets?
One crucial question is whether the different types of brackets would
have semantic meaning or not.
1) No semantic difference: the various characters are all absolutely
equivalent to ( or ). This is the easiest and safest, but also kinda
useless.
2) Real, crucial semantic difference: unique symbols that have special
meaning (like using a pair of non-ASCII brackets to surround a
frozenset literal).
3) Optional semantic difference: 【1, 2, 3】 is exactly the same as (1,
2, 3), but 【1, 2, 3) would be an error.
In the first case, nobody needs to learn input methods, since they can
just use other types of bracket no problem. But this is useless. You
can get nearly all the same benefit by using the same brackets
everywhere and then getting your editor to colour them for you.
The second definitely forces people to learn the symbols, although if
the use-cases are sufficiently rare, it might not be a big deal to
copy and paste them ("you can make frozenset literals by using these
symbols, or just use the word frozenset").
The third is an interesting hybrid, and if Python supported it, I
would definitely make use of it in a few places. There are times when
it'd be nice to be able to mark a specific call or something, thus
creating a boundary within a sea of close parentheses. Trouble is,
that kind of code shows up more in my JavaScript than in my Python, so
it wouldn't be all that helpful :) But still, there would be places
I'd use it in Python.
> > Someone on this list keeps saying that everyone wants to know how to
> > play the piano, but that no one wants to put in the hard work to learn
> > to play the piano. ;-)
>
> I read close to every email on this list and I've never seen anyone use
> that phrase before. Maybe I've missed it. Or maybe you're thinking of
> another list?
Maybe it's one of the people who's banned from the list, and is only
seen on the newsgroup? I haven't seen that turn of phrase either.
> In this wonderful world of the Internet era, where code collaboration,
> sharing of open-source software, and forums where people can post code
> for public viewing, how do I know that the parentheses and brackets I
> choose will be visible to all my readers?
>
> If I post code asking for help "why am I getting a SyntaxError here?"
>
> spam(1, eggs(2, cheese(3, fe(), fi(), fo(
>
> using fancy Unicode parentheses, how do I know that the people I am
> asking for help will see what I see, instead of
>
> spam 1, eggs 2, cheese 3, fe , fi , fo
>
> or
>
> spam□1, eggs□2, cheese□3, fe□□, fi□□, fo□
>
> or similar?
If a popular language makes use of a particular set of characters,
there would be a strong push to support those characters in code
editors. I think it's not a problem to expand that set occasionally,
as long as there's enough justification for it.
> We have to live in the world we have, not the world we want. Given the
> state of Unicode support in typefaces, editors, IDEs, web forum
> software, etc, what percentage of the time do you think that using fancy
> parentheses would *enhance* communication and collaboration, rather than
> degrade it?
Font choice is already an important consideration with code sharing.
Can we get a list of the most popular fonts for reading code in
[Python-ideas] Re: Allowing non-ASCII bracket and quote characters in source code
On Tue, Jan 18, 2022 at 07:40:40AM -0700, 2qdxy4rzwzuui...@potatochowder.com
wrote:
> On 2022-01-18 at 12:07:15 +1100,
> Steven D'Aprano wrote:
>
> > I would be more sympathetic to this idea if:
>
> > 1. I knew how to easily type all those brackets on the keyboard,
> > without having to use a GUI character picker.
>
> That's between you and your OS.
Is there any other Python syntax which is likewise OS-dependent?
To be clear, using non-ASCII strings or identifiers is certainly
supported, and that's fine, but beyond that narrow use, are there Python
keywords or operators or other syntactic forms that require people to
learn a different, OS-dependent input method for those forms?
I think the answer is no, but I am privileged enough to us a US-ASCII
keyboard. Maybe there are people using, oh I don't know, Bulgarian
keyboards, who can type *nearly all* of Python syntax just fine on their
keyboard but have to use a special input method for typing decorators
and bitwise operators.
> I believe all the major ones have ways
> to enter arbitrary characters and/or switch keyboards without a GUI (I
> use Linux, and I know for sure that it does).
Okay. Without looking it up, how would *you* type ⟮ U+27EE "Mathematical
Left Flattened Parentheses"? On your honour now, don't look it up.
Do you think that the majority of Python programmers, especially
beginners, will be keen to memorize a dozen or so key combinations to
write parentheses and brackets?
> Someone on this list keeps saying that everyone wants to know how to
> play the piano, but that no one wants to put in the hard work to learn
> to play the piano. ;-)
I read close to every email on this list and I've never seen anyone use
that phrase before. Maybe I've missed it. Or maybe you're thinking of
another list?
> > 2. I had a guarantee that all of the bracket characters would be both
> > available and easily distinguishable in any typeface I used.
>
> You don't have that gurantee now, unless you check for all those things
> yourself ("easily distinguishable" is subjective) before you use a
> typeface. *only half a wink*
Indeed. That is my point.
Let me make it a little more clear then.
In this wonderful world of the Internet era, where code collaboration,
sharing of open-source software, and forums where people can post code
for public viewing, how do I know that the parentheses and brackets I
choose will be visible to all my readers?
If I post code asking for help "why am I getting a SyntaxError here?"
spam(1, eggs(2, cheese(3, fe(), fi(), fo(
using fancy Unicode parentheses, how do I know that the people I am
asking for help will see what I see, instead of
spam 1, eggs 2, cheese 3, fe , fi , fo
or
spam□1, eggs□2, cheese□3, fe□□, fi□□, fo□
or similar?
We have to live in the world we have, not the world we want. Given the
state of Unicode support in typefaces, editors, IDEs, web forum
software, etc, what percentage of the time do you think that using fancy
parentheses would *enhance* communication and collaboration, rather than
degrade it?
--
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/5FXMEQQASFXR3JK6DP6GPAZJWAZGOQ7Z/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Revisiting a frozenset display literal
On 19/01/22 6:41 am, Rob Cliffe via Python-ideas wrote:
I'm happy with the
f{ ... }
Fine with me too.
I'd also be happy with making frozenset a keyword. It's hard to
imagine it breaking any existing code, it avoids having to make any
syntax changes, and all current uses of frozenset() on a constant
set would immediately benefit from it.
--
Greg
___
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/DWNELMJRPH5MJDKS2USTCS2FU5O4RY7H/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Revisiting a frozenset display literal
On 19/01/22 6:41 am, Rob Cliffe via Python-ideas wrote:
I'm happy with the
f{ ... }
Fine with me too.
I'd also be happy with making frozenset a keyword. It's hard to
imagine it breaking any existing code, it avoids having to make any
syntax changes, and all current uses of frozenset() on a constant
set would immediately benefit from it.
--
Greg
___
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/X72PHEE2Y7IO5VI7XDGZM7MJTG3XSSID/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: mimetypes.guess_type should not return deprecated mimetype application/x-javascript
On 18Jan2022 13:21, Jelle Zijlstra wrote: >Perhaps there should be a guess_all_types() function in addition to >guess_type() that returns all possible types, so that the user can select >the type they want using any criterion. This would be nicely symmetrical >with the existing guess_extension and guess_all_extensions functions. Indeed. +1 That would allow applying policy beyond the mime.types file ordering. Cheers, Cameron Simpson ___ 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/ML3OET5QHSVHLGP6B2X66SIJETZS6ADU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: mimetypes.guess_type should not return deprecated mimetype application/x-javascript
Perhaps there should be a guess_all_types() function in addition to guess_type() that returns all possible types, so that the user can select the type they want using any criterion. This would be nicely symmetrical with the existing guess_extension and guess_all_extensions functions. ___ 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/EV5RVLS4JC3XPYKWCJEFMLDTUVHOPU4Z/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Revisiting a frozenset display literal
Not a huge fan of an f-prefix for a frozen set (I prefer just recognizing
the case and optimizing the byte code, I don't think frozensets are used
often enough to justify its own syntax), but I love {,} for an empty set.
On Tue, Jan 18, 2022 at 4:13 PM Rob Cliffe via Python-ideas <
python-ideas@python.org> wrote:
>
>
> On 18/01/2022 19:42, MRAB wrote:
> > On 2022-01-18 18:54, Neil Girdhar wrote:
> >> Even if f{1} creates a frozenset, I don't think f{} should create a
> >> frozenset. I think it makes more sense to keep f{1: 2} open for
> >> frozendict if it ever makes it in. Also, {} should be consisten with
> >> f{} (both should create dicts). If you want an empty frozenset, you
> >> would have to do it the same way you do it for sets: either
> >> frozenset() or f{*()}.
> >>
> > [snip]
> > An alternative might be to allow {,} for an empty set, which would
> > then let you have f{,} for an empty frozenset.
> I like it!
> Rob Cliffe
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/HXJXYO5A7CO6HZHBQEFYS5Q7IHKSY7Y3/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
-Dr. Jon Crall (him)
___
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/JMTIQSP6IKXZWZSWWWJME2HLPASJVMXM/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Revisiting a frozenset display literal
On 18/01/2022 19:42, MRAB wrote:
On 2022-01-18 18:54, Neil Girdhar wrote:
Even if f{1} creates a frozenset, I don't think f{} should create a
frozenset. I think it makes more sense to keep f{1: 2} open for
frozendict if it ever makes it in. Also, {} should be consisten with
f{} (both should create dicts). If you want an empty frozenset, you
would have to do it the same way you do it for sets: either
frozenset() or f{*()}.
[snip]
An alternative might be to allow {,} for an empty set, which would
then let you have f{,} for an empty frozenset.
I like it!
Rob Cliffe
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/HXJXYO5A7CO6HZHBQEFYS5Q7IHKSY7Y3/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: mimetypes.guess_type should not return deprecated mimetype application/x-javascript
On 18Jan2022 08:43, Paul Bryan wrote: >+1 > >"x-" prefix indicates ad hoc (unofficial), not deprecated. > >I agree, an official MIME type should be preferred over an unofficial >one. Maybe, but I disagree about the proposed solution. There are circumstances where you want a specific MIME type guess, and the best way to do that is the apply a specific ordering to your mime.types file so that the desired type comes first, and is found first. And looking at milahu's example, that's exactly what was there: application/javascript js application/x-javascript js It would be reasonable and generally desireable to take the first one. The problem with saying "oh, let's examine the types and exclude or deprioritise the ones we don't like such as x-*" as that removes control from the user (the caller of mimetypes.guess_type() and the author of /etc/mime.types). It embeds fixed policy _inside_ mimetypes.guess_type() where it can't be turned off without growing a heap of weird mode flags. The better fix it to honour the order of the mime.types file as _expressing_ policy, which is what the OP already has - they just don't have guess_type() doing it that way. Arguments for embedding _policy_ inside guess_type() will be met with my standard example: the ancient Netscape proxy config had regexp based redirect rules, not uncommon. But Netscape prioritised these by the length of the regexp instead of the config file ordering. Insanity abounded with regexp wackiness purely to make some rules longer than others. Cheers, Cameron Simpson ___ 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/4P6G7WKRZR5GR2ZLRGO5QI3OCH7SEVVI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Revisiting a frozenset display literal
On 2022-01-18 18:54, Neil Girdhar wrote:
Even if f{1} creates a frozenset, I don't think f{} should create a
frozenset. I think it makes more sense to keep f{1: 2} open for
frozendict if it ever makes it in. Also, {} should be consisten with
f{} (both should create dicts). If you want an empty frozenset, you
would have to do it the same way you do it for sets: either frozenset()
or f{*()}.
[snip]
An alternative might be to allow {,} for an empty set, which would then
let you have f{,} for an empty frozenset.
On Tuesday, January 18, 2022 at 1:19:30 PM UTC-5 João Bernardo wrote:
One thing to consider is if we're going to have a syntax capable of
creating an empty frozenset, we need one that creates an empty set.
if f{...} exists, then s{...} should also exist?
Regards
João Bernardo
On Tue, Jan 18, 2022 at 2:59 PM Rob Cliffe via Python-ideas
wrote:
I'm +1 on the idea.
I'm happy with the
f{ ... }
syntax (although I did suggest something else).
We already have letter-prefixes, let's stick to them rather than
adding something new (which conceivably might one day find
another use).
Best wishes
Rob Cliffe
On 18/01/2022 15:53, Ricky Teachey wrote:
On Tue, Jan 18, 2022 at 10:02 AM Joao S. O. Bueno
wrote:
> but I don't think we should underestimate the cost of
even this small complexity increase in the language.
Actually, I think _maybe_ in this case the "complexity
increase" cost is _negative_. People might waste
more time looking for a way of spelling a frozenset
literal than just filling in "frozenset()".
I for one, even knowing that the cost of
writing "frozenset({1,2,3})" is negligible, would
"feel" better there was a way to spell that without the
needless conversions.
That said, an appropriate prefix for the {} just as we do
for strigns would be nice, and
I disagree that it would be a significant source for
"bugs". The "@{" is a nice
way out if people think "f{}" would be too close to "f()".
And "<1,2,3>" just for frozensets
are indeed overkill. We already do "literal prefixing"
with `"` after all. and formally extending this
prefix usage as needed for other literals seems like a
nice path.
But, as far as bikeshedding go, we also have "literal
sufixing" (2.0j anyone?)- maybe
"{1,2,3}f" ?
I have been following along with not much to comment but this
response sparked something in me.
After reading all the viewpoints I think I would be +1 on the
basic idea, and a +1 on the postfix/suffix syntax just
suggested... the other syntaxes I'm more of +0.5
I like the way the suffix FLOWS with the act of writing the
program. When I write a set, I am primarily focused on /what I
am going to put in it/, and whether or not it should be
mutable is kind of a later thought/debate in my head after I
have established what it contains.
As a dumb example, if my task at hand is "I need to create a
bag of sports balls", I am mostly thinking about what goes
into that bag at first, so I will write that first:
>>> {Ball("basketball"), Ball("soccer"), Ball("football"),
Ball("golf")}
Now I get to the end of that line, and I then sort of
naturally think "ok does it make sense to freeze this" after i
know what is in it. With the postfix syntax, I then either
type the f:
>>> {Ball("basketball"), Ball("soccer"), Ball("football"),
Ball("golf")}f
...or not. With a prefix type syntax, or a smooth bracket
syntax, either:
A. it takes slightly more "work' at this point to "convert"
the set to a frozenset, OR
B. i have to think about ahead of time-- before i have
actually written what is in the set- whether it will be
frozen, or not.
In contrast, when you are deciding whether to write a list vs
a tuple, you are deciding between two things that are
fundamentally far more different IDEAS than a "bag of things,
frozen or unfrozen". A list is very often more of an open
ended stack than it is "an unfrozen tuple". A tuple is very
often much more of an object that can be used as a dictionary
key, or a member of a set, than it is a container of things
(of course, it is a container of things, too). These
differences make is a lot easier to choose, ahead of time,
which one makes sense before you have even written the line of
code.
Maybe I'm making too much of this, but I really like the idea
[Python-ideas] Re: Revisiting a frozenset display literal
Even if f{1} creates a frozenset, I don't think f{} should create a
frozenset. I think it makes more sense to keep f{1: 2} open for frozendict
if it ever makes it in. Also, {} should be consisten with f{} (both should
create dicts). If you want an empty frozenset, you would have to do it the
same way you do it for sets: either frozenset() or f{*()}.
Best
Neil
On Tuesday, January 18, 2022 at 1:19:30 PM UTC-5 João Bernardo wrote:
>
> One thing to consider is if we're going to have a syntax capable of
> creating an empty frozenset, we need one that creates an empty set.
>
> if f{...} exists, then s{...} should also exist?
>
> Regards
> João Bernardo
>
>
> On Tue, Jan 18, 2022 at 2:59 PM Rob Cliffe via Python-ideas <
> python...@python.org> wrote:
>
>> I'm +1 on the idea.
>> I'm happy with the
>> f{ ... }
>> syntax (although I did suggest something else).
>> We already have letter-prefixes, let's stick to them rather than adding
>> something new (which conceivably might one day find another use).
>> Best wishes
>> Rob Cliffe
>>
>> On 18/01/2022 15:53, Ricky Teachey wrote:
>>
>> On Tue, Jan 18, 2022 at 10:02 AM Joao S. O. Bueno
>> wrote:
>>
>>> > but I don't think we should underestimate the cost of even this small
>>> complexity increase in the language.
>>>
>>> Actually, I think _maybe_ in this case the "complexity increase" cost is
>>> _negative_. People might waste
>>> more time looking for a way of spelling a frozenset literal than just
>>> filling in "frozenset()".
>>> I for one, even knowing that the cost of writing "frozenset({1,2,3})" is
>>> negligible, would
>>> "feel" better there was a way to spell that without the needless
>>> conversions.
>>>
>>> That said, an appropriate prefix for the {} just as we do for strigns
>>> would be nice, and
>>> I disagree that it would be a significant source for "bugs". The "@{" is
>>> a nice
>>> way out if people think "f{}" would be too close to "f()". And "<1,2,3>"
>>> just for frozensets
>>> are indeed overkill. We already do "literal prefixing" with `"` after
>>> all. and formally extending this
>>> prefix usage as needed for other literals seems like a nice path.
>>> But, as far as bikeshedding go, we also have "literal sufixing" (2.0j
>>> anyone?)- maybe
>>> "{1,2,3}f" ?
>>>
>>
>> I have been following along with not much to comment but this response
>> sparked something in me.
>>
>> After reading all the viewpoints I think I would be +1 on the basic idea,
>> and a +1 on the postfix/suffix syntax just suggested... the other syntaxes
>> I'm more of +0.5
>>
>> I like the way the suffix FLOWS with the act of writing the program. When
>> I write a set, I am primarily focused on *what I am going to put in it*,
>> and whether or not it should be mutable is kind of a later thought/debate
>> in my head after I have established what it contains.
>>
>> As a dumb example, if my task at hand is "I need to create a bag of
>> sports balls", I am mostly thinking about what goes into that bag at first,
>> so I will write that first:
>>
>>>>> {Ball("basketball"), Ball("soccer"), Ball("football"),
>> Ball("golf")}
>>
>> Now I get to the end of that line, and I then sort of naturally think "ok
>> does it make sense to freeze this" after i know what is in it. With the
>> postfix syntax, I then either type the f:
>>
>>>>> {Ball("basketball"), Ball("soccer"), Ball("football"),
>> Ball("golf")}f
>>
>> ...or not. With a prefix type syntax, or a smooth bracket syntax, either:
>>
>> A. it takes slightly more "work' at this point to "convert" the set to a
>> frozenset, OR
>> B. i have to think about ahead of time-- before i have actually written
>> what is in the set- whether it will be frozen, or not.
>>
>> In contrast, when you are deciding whether to write a list vs a tuple,
>> you are deciding between two things that are fundamentally far more
>> different IDEAS than a "bag of things, frozen or unfrozen". A list is very
>> often more of an open ended stack than it is "an unfrozen tuple". A tuple
>> is very often much more of an object that can be used as a dictionary key,
>> or a member of a set, than it is a container of things (of course, it is a
>> container of things, too). These differences make is a lot easier to
>> choose, ahead of time, which one makes sense before you have even written
>> the line of code.
>>
>> Maybe I'm making too much of this, but I really like the idea of deciding
>> at the END of the set literal whether to tack on that "f".
>>
>> ---
>> Ricky.
>>
>> "I've never met a Kentucky man who wasn't either thinking about going
>> home or actually going home." - Happy Chandler
>>
>>
>>
>>
>> ___
>> Python-ideas mailing list -- python...@python.org
>> To unsubscribe send an email to
>> python-id...@python.orghttps://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at
>>
[Python-ideas] Re: Revisiting a frozenset display literal
One thing to consider is if we're going to have a syntax capable of
creating an empty frozenset, we need one that creates an empty set.
if f{...} exists, then s{...} should also exist?
Regards
João Bernardo
On Tue, Jan 18, 2022 at 2:59 PM Rob Cliffe via Python-ideas <
python-ideas@python.org> wrote:
> I'm +1 on the idea.
> I'm happy with the
> f{ ... }
> syntax (although I did suggest something else).
> We already have letter-prefixes, let's stick to them rather than adding
> something new (which conceivably might one day find another use).
> Best wishes
> Rob Cliffe
>
> On 18/01/2022 15:53, Ricky Teachey wrote:
>
> On Tue, Jan 18, 2022 at 10:02 AM Joao S. O. Bueno
> wrote:
>
>> > but I don't think we should underestimate the cost of even this small
>> complexity increase in the language.
>>
>> Actually, I think _maybe_ in this case the "complexity increase" cost is
>> _negative_. People might waste
>> more time looking for a way of spelling a frozenset literal than just
>> filling in "frozenset()".
>> I for one, even knowing that the cost of writing "frozenset({1,2,3})" is
>> negligible, would
>> "feel" better there was a way to spell that without the needless
>> conversions.
>>
>> That said, an appropriate prefix for the {} just as we do for strigns
>> would be nice, and
>> I disagree that it would be a significant source for "bugs". The "@{" is
>> a nice
>> way out if people think "f{}" would be too close to "f()". And "<1,2,3>"
>> just for frozensets
>> are indeed overkill. We already do "literal prefixing" with `"` after
>> all. and formally extending this
>> prefix usage as needed for other literals seems like a nice path.
>> But, as far as bikeshedding go, we also have "literal sufixing" (2.0j
>> anyone?)- maybe
>> "{1,2,3}f" ?
>>
>
> I have been following along with not much to comment but this response
> sparked something in me.
>
> After reading all the viewpoints I think I would be +1 on the basic idea,
> and a +1 on the postfix/suffix syntax just suggested... the other syntaxes
> I'm more of +0.5
>
> I like the way the suffix FLOWS with the act of writing the program. When
> I write a set, I am primarily focused on *what I am going to put in it*,
> and whether or not it should be mutable is kind of a later thought/debate
> in my head after I have established what it contains.
>
> As a dumb example, if my task at hand is "I need to create a bag of sports
> balls", I am mostly thinking about what goes into that bag at first, so I
> will write that first:
>
>>>> {Ball("basketball"), Ball("soccer"), Ball("football"),
> Ball("golf")}
>
> Now I get to the end of that line, and I then sort of naturally think "ok
> does it make sense to freeze this" after i know what is in it. With the
> postfix syntax, I then either type the f:
>
>>>> {Ball("basketball"), Ball("soccer"), Ball("football"),
> Ball("golf")}f
>
> ...or not. With a prefix type syntax, or a smooth bracket syntax, either:
>
> A. it takes slightly more "work' at this point to "convert" the set to a
> frozenset, OR
> B. i have to think about ahead of time-- before i have actually written
> what is in the set- whether it will be frozen, or not.
>
> In contrast, when you are deciding whether to write a list vs a tuple, you
> are deciding between two things that are fundamentally far more different
> IDEAS than a "bag of things, frozen or unfrozen". A list is very often more
> of an open ended stack than it is "an unfrozen tuple". A tuple is very
> often much more of an object that can be used as a dictionary key, or a
> member of a set, than it is a container of things (of course, it is a
> container of things, too). These differences make is a lot easier to
> choose, ahead of time, which one makes sense before you have even written
> the line of code.
>
> Maybe I'm making too much of this, but I really like the idea of deciding
> at the END of the set literal whether to tack on that "f".
>
> ---
> Ricky.
>
> "I've never met a Kentucky man who wasn't either thinking about going home
> or actually going home." - Happy Chandler
>
>
>
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to
> python-ideas-leave@python.orghttps://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/T7X3XI3ZQMQIQEMGPSTGLAFOCMXKWWFV/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/VRGSQR7ISWFLKJTFDYWRNBGA47ECFDRU/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
[Python-ideas] Re: Revisiting a frozenset display literal
I'm +1 on the idea.
I'm happy with the
f{ ... }
syntax (although I did suggest something else).
We already have letter-prefixes, let's stick to them rather than adding
something new (which conceivably might one day find another use).
Best wishes
Rob Cliffe
On 18/01/2022 15:53, Ricky Teachey wrote:
On Tue, Jan 18, 2022 at 10:02 AM Joao S. O. Bueno
wrote:
> but I don't think we should underestimate the cost of even this
small complexity increase in the language.
Actually, I think _maybe_ in this case the "complexity increase"
cost is _negative_. People might waste
more time looking for a way of spelling a frozenset literal than
just filling in "frozenset()".
I for one, even knowing that the cost of
writing "frozenset({1,2,3})" is negligible, would
"feel" better there was a way to spell that without the needless
conversions.
That said, an appropriate prefix for the {} just as we do for
strigns would be nice, and
I disagree that it would be a significant source for "bugs". The
"@{" is a nice
way out if people think "f{}" would be too close to "f()". And
"<1,2,3>" just for frozensets
are indeed overkill. We already do "literal prefixing" with `"`
after all. and formally extending this
prefix usage as needed for other literals seems like a nice path.
But, as far as bikeshedding go, we also have "literal sufixing"
(2.0j anyone?)- maybe
"{1,2,3}f" ?
I have been following along with not much to comment but this response
sparked something in me.
After reading all the viewpoints I think I would be +1 on the basic
idea, and a +1 on the postfix/suffix syntax just suggested... the
other syntaxes I'm more of +0.5
I like the way the suffix FLOWS with the act of writing the program.
When I write a set, I am primarily focused on /what I am going to put
in it/, and whether or not it should be mutable is kind of a later
thought/debate in my head after I have established what it contains.
As a dumb example, if my task at hand is "I need to create a bag of
sports balls", I am mostly thinking about what goes into that bag at
first, so I will write that first:
>>> {Ball("basketball"), Ball("soccer"), Ball("football"),
Ball("golf")}
Now I get to the end of that line, and I then sort of naturally think
"ok does it make sense to freeze this" after i know what is in it.
With the postfix syntax, I then either type the f:
>>> {Ball("basketball"), Ball("soccer"), Ball("football"),
Ball("golf")}f
...or not. With a prefix type syntax, or a smooth bracket syntax, either:
A. it takes slightly more "work' at this point to "convert" the set to
a frozenset, OR
B. i have to think about ahead of time-- before i have actually
written what is in the set- whether it will be frozen, or not.
In contrast, when you are deciding whether to write a list vs a tuple,
you are deciding between two things that are fundamentally far more
different IDEAS than a "bag of things, frozen or unfrozen". A list is
very often more of an open ended stack than it is "an unfrozen tuple".
A tuple is very often much more of an object that can be used as a
dictionary key, or a member of a set, than it is a container of things
(of course, it is a container of things, too). These differences make
is a lot easier to choose, ahead of time, which one makes sense before
you have even written the line of code.
Maybe I'm making too much of this, but I really like the idea of
deciding at the END of the set literal whether to tack on that "f".
---
Ricky.
"I've never met a Kentucky man who wasn't either thinking about going
home or actually going home." - Happy Chandler
___
Python-ideas mailing list --python-ideas@python.org
To unsubscribe send an email topython-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived
athttps://mail.python.org/archives/list/python-ideas@python.org/message/T7X3XI3ZQMQIQEMGPSTGLAFOCMXKWWFV/
Code of Conduct:http://python.org/psf/codeofconduct/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/VRGSQR7ISWFLKJTFDYWRNBGA47ECFDRU/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Allowing non-ASCII bracket and quote characters in source code
On Tue, Jan 18, 2022 at 1:15 AM Steven D'Aprano wrote: > I would be more sympathetic to this idea if: > > 2. I had a guarantee that all of the bracket characters would be both > available and easily distinguishable in any typeface I used. > I don't think the "distinguishable" part matters that much; if the different variants of the same type of bracket look the same, we're just back to what we see now. However, it's a problem if they're just displayed as "unknown character" markers, and you can't tell which kind they are, nor whether they're opening or closing. I suspect "rainbow parentheses" in editors is probably going to be a better approach. ___ 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/4IHBRQRBCLSUSN2Y2FSGRW6TZHT4M6NB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: mimetypes.guess_type should not return deprecated mimetype application/x-javascript
+1
"x-" prefix indicates ad hoc (unofficial), not deprecated.
I agree, an official MIME type should be preferred over an unofficial
one.
On Tue, 2022-01-18 at 16:26 +, mil...@gmail.com wrote:
> mimetypes are parsed from the file /etc/mime.types
>
> cat /etc/mime.types | grep javascript
> application/javascript js
> application/x-javascript js
>
> actual:
> mimetypes.guess_type("x.js") == "application/x-javascript"
> -> deprecated mimetype
>
> expected:
> mimetypes.guess_type("x.js") == "application/javascript"
>
> spoiler: here, the "x-" part is deprecated.
>
> mimetypes.guess_type returns the deprecated mimetype
> because python returns the last entry in the /etc/mime.types file
> which is sorted alphabetically
>
> proposed solution:
> use a smarter conflict-resolution when parsing /etc/mime.types.
> when two entries are found for one file-extension,
> avoid using a deprecated mimetype.
> rfc4329 lists 16 items for "unregistered media type"
> these could be hard-coded as set-of-strings, or as regex.
>
> related bug report
> https://bugs.python.org/issue46035
>
> mimetypes.guess_type
> https://docs.python.org/3/library/mimetypes.html#mimetypes.guess_type
>
> unregistered media type
> https://datatracker.ietf.org/doc/html/rfc4329#section-3
> ___
> 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/V53XGQPIY7ZAISMTQHPHKGWZNSN5EXQG/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/ZVFBHYXGD2EIJIDCKFDOL335AZYY42LJ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] mimetypes.guess_type should not return deprecated mimetype application/x-javascript
mimetypes are parsed from the file /etc/mime.types
cat /etc/mime.types | grep javascript
application/javascriptjs
application/x-javascript js
actual:
mimetypes.guess_type("x.js") == "application/x-javascript"
-> deprecated mimetype
expected:
mimetypes.guess_type("x.js") == "application/javascript"
spoiler: here, the "x-" part is deprecated.
mimetypes.guess_type returns the deprecated mimetype
because python returns the last entry in the /etc/mime.types file
which is sorted alphabetically
proposed solution:
use a smarter conflict-resolution when parsing /etc/mime.types.
when two entries are found for one file-extension,
avoid using a deprecated mimetype.
rfc4329 lists 16 items for "unregistered media type"
these could be hard-coded as set-of-strings, or as regex.
related bug report
https://bugs.python.org/issue46035
mimetypes.guess_type
https://docs.python.org/3/library/mimetypes.html#mimetypes.guess_type
unregistered media type
https://datatracker.ietf.org/doc/html/rfc4329#section-3
___
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/V53XGQPIY7ZAISMTQHPHKGWZNSN5EXQG/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Revisiting a frozenset display literal
On Tue, Jan 18, 2022 at 10:02 AM Joao S. O. Bueno
wrote:
> > but I don't think we should underestimate the cost of even this small
> complexity increase in the language.
>
> Actually, I think _maybe_ in this case the "complexity increase" cost is
> _negative_. People might waste
> more time looking for a way of spelling a frozenset literal than just
> filling in "frozenset()".
> I for one, even knowing that the cost of writing "frozenset({1,2,3})" is
> negligible, would
> "feel" better there was a way to spell that without the needless
> conversions.
>
> That said, an appropriate prefix for the {} just as we do for strigns
> would be nice, and
> I disagree that it would be a significant source for "bugs". The "@{" is a
> nice
> way out if people think "f{}" would be too close to "f()". And "<1,2,3>"
> just for frozensets
> are indeed overkill. We already do "literal prefixing" with `"` after all.
> and formally extending this
> prefix usage as needed for other literals seems like a nice path.
> But, as far as bikeshedding go, we also have "literal sufixing" (2.0j
> anyone?)- maybe
> "{1,2,3}f" ?
>
I have been following along with not much to comment but this response
sparked something in me.
After reading all the viewpoints I think I would be +1 on the basic idea,
and a +1 on the postfix/suffix syntax just suggested... the other syntaxes
I'm more of +0.5
I like the way the suffix FLOWS with the act of writing the program. When I
write a set, I am primarily focused on *what I am going to put in it*, and
whether or not it should be mutable is kind of a later thought/debate in my
head after I have established what it contains.
As a dumb example, if my task at hand is "I need to create a bag of sports
balls", I am mostly thinking about what goes into that bag at first, so I
will write that first:
>>> {Ball("basketball"), Ball("soccer"), Ball("football"), Ball("golf")}
Now I get to the end of that line, and I then sort of naturally think "ok
does it make sense to freeze this" after i know what is in it. With the
postfix syntax, I then either type the f:
>>> {Ball("basketball"), Ball("soccer"), Ball("football"), Ball("golf")}f
...or not. With a prefix type syntax, or a smooth bracket syntax, either:
A. it takes slightly more "work' at this point to "convert" the set to a
frozenset, OR
B. i have to think about ahead of time-- before i have actually written
what is in the set- whether it will be frozen, or not.
In contrast, when you are deciding whether to write a list vs a tuple, you
are deciding between two things that are fundamentally far more different
IDEAS than a "bag of things, frozen or unfrozen". A list is very often more
of an open ended stack than it is "an unfrozen tuple". A tuple is very
often much more of an object that can be used as a dictionary key, or a
member of a set, than it is a container of things (of course, it is a
container of things, too). These differences make is a lot easier to
choose, ahead of time, which one makes sense before you have even written
the line of code.
Maybe I'm making too much of this, but I really like the idea of deciding
at the END of the set literal whether to tack on that "f".
---
Ricky.
"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/T7X3XI3ZQMQIQEMGPSTGLAFOCMXKWWFV/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Revisiting a frozenset display literal
> but I don't think we should underestimate the cost of even this small
complexity increase in the language.
Actually, I think _maybe_ in this case the "complexity increase" cost is
_negative_. People might waste
more time looking for a way of spelling a frozenset literal than just
filling in "frozenset()".
I for one, even knowing that the cost of writing "frozenset({1,2,3})" is
negligible, would
"feel" better there was a way to spell that without the needless
conversions.
That said, an appropriate prefix for the {} just as we do for strigns would
be nice, and
I disagree that it would be a significant source for "bugs". The "@{" is a
nice
way out if people think "f{}" would be too close to "f()". And "<1,2,3>"
just for frozensets
are indeed overkill. We already do "literal prefixing" with `"` after all.
and formally extending this
prefix usage as needed for other literals seems like a nice path.
But, as far as bikeshedding go, we also have "literal sufixing" (2.0j
anyone?)- maybe
"{1,2,3}f" ?
On Mon, Jan 17, 2022 at 2:43 PM Christopher Barker
wrote:
> On Mon, Jan 17, 2022 at 9:07 AM Ronald Oussoren
> wrote:
>
>>
>> For example:
>>
>> If flag in {‘the’, ‘allowable’, ‘flags’}:
>> …
>>
>> If a frozen set was even a little bit faster or used less memory, it
>> would be nice to be able to create one directly.
>>
>>
>> Not really relevant for the discussion, but CPython automaticly creates a
>> frozenset here (set display with immutable members) as an optimisation.
>>
>
> I think it's quite relevant to the discussion, because as far as I can
> tell, better performance in particular cases is the primary motivator.
>
> Funny that this has come up -- not too long ago, I did some
> experiments with code like the above: and to the surprise of myself and
> some other long-time Pythonistas I work with, using sets, rather tha tuples
> in those kinds of constructs, e.g.:
>
> if something in :
>
> was always as faster or faster with sets than tuples. That was surprising
> because we assumed that construction of a set would be slower than
> construction of a tuple. And that was probably the case ten years ago. The
> proof is in the pudding,so I never bothered to figure out why, but now I
> know :-)
>
> Back to the topic at hand -- IIUC, set constants are already optimized, so
> the only places having a frozenset display would be when it is a constant,
> and it has to be a frozenset, where a regular one won't do.
>
> And that would only be noticeable if it was in a function that didn't do
> much else, and was called often. And in that case, it could be put in the
> global scope to ameliorate some of that cost.
>
> I believe Stephens' point is that the benefit may be fairly small, but so
> is the cost. I'm not so sure. I kind of like the idea myself, and the cost
> does seem small, but I don't think we should underestimate the cost of even
> this small complexity increase in the language. Sure, folks don't have
> toeven know it exists to write fine code, but it would be one more thing
> that newbies will need to figure out when they see it in others' code.
>
> In fact, there' a lot of what I might call "Python Scripters" that aren't
> even familiar with the set display at all.
>
> -CHB
>
>
> --
> Christopher Barker, PhD (Chris)
>
> Python Language Consulting
> - Teaching
> - Scientific Software Development
> - Desktop GUI and Web Development
> - wxPython, numpy, scipy, Cython
> ___
> 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/Q2VUUY6I4JJHQOHMO2JMMRPZGVZU44N6/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/VB4OI47LQ4PMNG6IQRFIQ2BR2LZII5L3/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Allowing non-ASCII bracket and quote characters in source code
On 2022-01-18 at 12:07:15 +1100,
Steven D'Aprano wrote:
> I would be more sympathetic to this idea if:
> 1. I knew how to easily type all those brackets on the keyboard,
> without having to use a GUI character picker.
That's between you and your OS. I believe all the major ones have ways
to enter arbitrary characters and/or switch keyboards without a GUI (I
use Linux, and I know for sure that it does).
Someone on this list keeps saying that everyone wants to know how to
play the piano, but that no one wants to put in the hard work to learn
to play the piano. ;-) I don't know the entire unicode database, but I
have learned the code points I use often (and how to type them without a
GUI picker).
The unicode database clearly marks open and close parentheses, and even
contains enough data (on initial examination) to match up the pairs
(that doesn't help you easily type them, but it does help utility
programs, GUI or otherwise, help you pick an approprite one at the right
time).
> 2. I had a guarantee that all of the bracket characters would be both
> available and easily distinguishable in any typeface I used.
You don't have that gurantee now, unless you check for all those things
yourself ("easily distinguishable" is subjective) before you use a
typeface. *only half a wink*
___
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/3MANLAJ5DPQD2ON6BE52ZCBX43KHYBXQ/
Code of Conduct: http://python.org/psf/codeofconduct/
