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
+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
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
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
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
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
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
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
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 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
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
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
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
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
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.
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 <
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
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
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
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
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>
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
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
+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
>
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") ==
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
> 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
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
28 matches
Mail list logo
