[Python-ideas] Re: Introduce constant variables in Python

[Shreyan Avigyan]

Reply to Steve D'Aprano -

I am talking about constant name binding. Once the name is bind it cannot be 
changed. The data will remain immutable or mutable.

> That seems very odd. That would mean that you can't pass constants to 
> functions, or put them in lists or dicts, since that would create new 
> references to the object.

Well I thought about constant name binding with freeze protocol but it didn't 
seem to be Pythonic. So I changed my initial idea to have constant name 
binding. Now we can create multiple references.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/EFDQMW4JBQ4F7ZQYQRU3DGB6DLJFSMWL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Currying syntax with multiple parameter lists

[Joren Hammudoglu]

> Flat is better than nested.

I remember being confused a lot when I was learning how to write my first 
decorator. Now eight years later, with the last two spent full-time writing 
Python, I introduced a bug in production because I forgot to return the inner 
function from within a decorator. 

By introducing multiple parameter lists when defining a function, Scala does a 
great job at improving readability for curried functions 
(https://docs.scala-lang.org/tour/multiple-parameter-lists.html). 
In Python, that could look like e.g.:

def log(level=logging.DEBUG, logger=logging.root)(func)(*args, **kwargs):
logger.log(level, 'call: %s', func.__qualname__)
return func(*args, **kwargs)

Which would be sugar for:

def log(level=logging.DEBUG, logger=logging.root):
def _log(func):
def __log(*args, **kwargs):
logger.log(level, 'call: %s', func.__qualname__)
return func(*args, **kwargs)
return __log
return _log

The obvious problem in this example, is that `functools.wraps` is missing. One 
solution would be for me to flex my 8 years of experience, and present these 
two (super/meta-)decorators:

def wraps_decorator(decorator: Callable[[F], F]):
@functools.wraps(decorator)
def _wraps_decorator(func):
return functools.wraps(func)(decorator(func))
return _wraps_decorator


@wraps_decorator
def wraps_decorator_factory(decorator_factory)(*args, **kwargs):
return wraps_decorator(decorator_factory(*args, **kwargs))

Applying the latter on the first example, it becomes

@wraps_decorator_factory
def log(level=logging.DEBUG, logger=logging.root)(func)(*args, **kwargs):
logger.log(level, 'call: %s', func.__qualname__)
return func(*args, **kwargs)

which is equivalent to:

def log(level=logging.DEBUG, logger=logging.root):
def _log(func):
@functools.wraps(func)
def __log(*args, **kwargs):
logger.log(level, 'call: %s', func.__qualname__)
return func(*args, **kwargs)
return __log
return _log


Implementation-wise, I think it's very feasible since it's only sugar. And I'm 
sure that the required grammar changes are possible with the shiny new parser.

And considering PEP 659, I can imagine that this syntax is beneficial because 
the closure variables coincide with the parameter lists.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/2HGGXLQGGIUOG2ENLNAAT3YY6GPDD3DF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators on variables

[Ethan Furman]

On 5/24/21 6:36 PM, micro codery wrote:

> Variable decorators have been suggested here before, as have new statements
> that could also achieve the same level of access to the binding name. However
> I propose a much more restricted syntax that would make for less edge cases
> where what is actually passed to the decorator callable may be ambiguous.

> #instead of GREEN = "GREEN"
> @str GREEN

> #instead of Point = namedtuple("Point", "x y z")
> @namedtuple("x y z") Point

> #instead of Point = make_dataclass("Point", [("x", int), ("y", int), ("z", 
int)])
> @make_dataclass([("x", int), ("y", int), ("z", int)]) Point

> #instead of Colors = Enum("Colors", "RED GREEN BLUE")
> @Enum("RED GREEN BLUE") Colors

> class Colors(Enum):
>  @str RED
>  @str GREEN
>  @str BLUE

> #instead of UUIDType = NewType("UUIDType", str)
> @NewType UUIDType: str

I think that looks very interesting.

--
~Ethan~
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/CFFC2TCFTGCR3BY6U5JY5KHB6QB46U6P/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators on variables

[Ricky Teachey]

I don't have much of substance to say other than this proposal really made
me go "oh I like that" several times. There may be downsides/arguments
against I'm not considering, but I look forward to following the
conversation and hope it gets a serious hearing.

On Mon, May 24, 2021, 9:38 PM micro codery  wrote:

> Variable decorators have been suggested here before, as have new statements
> that could also achieve the same level of access to the binding name.
> However
> I propose a much more restricted syntax that would make for less edge cases
> where what is actually passed to the decorator callable may be ambiguous.
>
> Basically this would add syntax to python that would transform
> @decorator("spam this") variable
> into
> variable = decorator("variable", "spam this")
>
> The decorator would be limited to being on the same line as the variable
> name.
> Additionally, the variable can not also be assigned to on the same line, so
> @decorator("spam this") variable = eggs
> would be a SyntaxError. Annotating these variable would be allowed
> @decoratopr("spam this") variable: Food
> The actual decorator would follow the same rules as current decorators in
> that
> the parentheses can be omitted if no other arguments are required to the
> function and any arbitrary expression can be used, however the same
> restraint
> should be cautioned as is for current decorators post PEP 614.
>
> The most straightforward use of this decorating would be that str() could
> be
> used without change to declare variables that are strings of the same name,
> generally cutting down on repeating yourself when declaring constants.
>
> #instead of GREEN = "GREEN"
> @str GREEN
>
> The classic example of a factory that needs its target name as a string
> value
> is namedtuple. I don't think this example is enough alone to sway this
> list but
> I bring it up as it has also been at the front of past ideas to allow
> variable
> decorating.
>
> #instead of Point = namedtuple("Point", "x y z")
> @namedtuple("x y z") Point
>
> I have sometimes heard that dataclasses make this no longer an issue,
> implying
> that dataclasses can be used in place of namedtuple in any new code.
> Putting
> aside that dataclasses are not a strict replacement for namedtuple, the
> dataclasses module continues this factory design with the make_dataclass
> function.
>
> #instead of Point = make_dataclass("Point", [("x", int), ("y", int), ("z",
> int)])
> @make_dataclass([("x", int), ("y", int), ("z", int)]) Point
>
> Enum is one more case where there is a factory equivalent to the class
> declaration.
>
> #instead of Colors = Enum("Colors", "RED GREEN BLUE")
> @Enum("RED GREEN BLUE") Colors
>
> If you want each enum member value to match its name there is even more
> repetition, however by using the original example for decorated variables,
> this
> can be reduced when using the more common class style.
>
> class Colors(Enum):
> @str RED
> @str GREEN
> @str BLUE
>
> One final standard library module that I will mention because it seems to
> keep
> adding similar factory functions is typing. It already has the factory
> functions
> NewType, TypeVar, ParamSpec, TypedDict, NamedTuple. Their use with the new
> variable decorator would look much the same as earlier examples, but here
> would
> be one case where type hinting the variable in such a statement could aid
> the
> decorator function
>
> #instead of UUIDType = NewType("UUIDType", str)
> @NewType UUIDType: str
>
> If adopted, no change to these functions would be necessary to allow their
> use
> as a variable decorators as they all already take the name as a string in
> the
> first argument. Additionally, as variable decorators are actually
> callables just like
> the current decorators, no new restrictions are being forced on users of
> the language.
> If a user really wants to create a namedtuple with a typename of Foo but
> assign
> the result to a variable named ___trippleS33cret___name__here_ the language
> will not stop them.
>
>
> I would very much like to know if any module maintainers are interested in
> this
> syntax. Convincing arguments from the standard lib (whether you consider
> the
> above convincing or not) are probably not enough to get a syntax change
> into
> python. But if enough third party modules want to use this functionality I
> believe that would be the real push to get it done.
>
> Specifically this idea first started growing when I read on another ideas
> message that using the module sympy would often start with a line like
> x = symbol('x')
> which, with no change, could be used as a variable decorator
> @symbol x
> Now what may be even more typical (I really have never used the module
> myself)
> is defining all needed symbols on one line with
> x, y, z = symbol('x y z')
> which could conceivably be rewritten like
> @symbol x, y, z
> However I have not yet been able to decide if multi-assignment would be
> overall
> beneficial to this new syntax. Probably not,

[Python-ideas] Decorators on variables

[micro codery]

Variable decorators have been suggested here before, as have new statements
that could also achieve the same level of access to the binding name.
However
I propose a much more restricted syntax that would make for less edge cases
where what is actually passed to the decorator callable may be ambiguous.

Basically this would add syntax to python that would transform
@decorator("spam this") variable
into
variable = decorator("variable", "spam this")

The decorator would be limited to being on the same line as the variable
name.
Additionally, the variable can not also be assigned to on the same line, so
@decorator("spam this") variable = eggs
would be a SyntaxError. Annotating these variable would be allowed
@decoratopr("spam this") variable: Food
The actual decorator would follow the same rules as current decorators in
that
the parentheses can be omitted if no other arguments are required to the
function and any arbitrary expression can be used, however the same
restraint
should be cautioned as is for current decorators post PEP 614.

The most straightforward use of this decorating would be that str() could be
used without change to declare variables that are strings of the same name,
generally cutting down on repeating yourself when declaring constants.

#instead of GREEN = "GREEN"
@str GREEN

The classic example of a factory that needs its target name as a string
value
is namedtuple. I don't think this example is enough alone to sway this list
but
I bring it up as it has also been at the front of past ideas to allow
variable
decorating.

#instead of Point = namedtuple("Point", "x y z")
@namedtuple("x y z") Point

I have sometimes heard that dataclasses make this no longer an issue,
implying
that dataclasses can be used in place of namedtuple in any new code. Putting
aside that dataclasses are not a strict replacement for namedtuple, the
dataclasses module continues this factory design with the make_dataclass
function.

#instead of Point = make_dataclass("Point", [("x", int), ("y", int), ("z",
int)])
@make_dataclass([("x", int), ("y", int), ("z", int)]) Point

Enum is one more case where there is a factory equivalent to the class
declaration.

#instead of Colors = Enum("Colors", "RED GREEN BLUE")
@Enum("RED GREEN BLUE") Colors

If you want each enum member value to match its name there is even more
repetition, however by using the original example for decorated variables,
this
can be reduced when using the more common class style.

class Colors(Enum):
@str RED
@str GREEN
@str BLUE

One final standard library module that I will mention because it seems to
keep
adding similar factory functions is typing. It already has the factory
functions
NewType, TypeVar, ParamSpec, TypedDict, NamedTuple. Their use with the new
variable decorator would look much the same as earlier examples, but here
would
be one case where type hinting the variable in such a statement could aid
the
decorator function

#instead of UUIDType = NewType("UUIDType", str)
@NewType UUIDType: str

If adopted, no change to these functions would be necessary to allow their
use
as a variable decorators as they all already take the name as a string in
the
first argument. Additionally, as variable decorators are actually callables
just like
the current decorators, no new restrictions are being forced on users of
the language.
If a user really wants to create a namedtuple with a typename of Foo but
assign
the result to a variable named ___trippleS33cret___name__here_ the language
will not stop them.


I would very much like to know if any module maintainers are interested in
this
syntax. Convincing arguments from the standard lib (whether you consider the
above convincing or not) are probably not enough to get a syntax change into
python. But if enough third party modules want to use this functionality I
believe that would be the real push to get it done.

Specifically this idea first started growing when I read on another ideas
message that using the module sympy would often start with a line like
x = symbol('x')
which, with no change, could be used as a variable decorator
@symbol x
Now what may be even more typical (I really have never used the module
myself)
is defining all needed symbols on one line with
x, y, z = symbol('x y z')
which could conceivably be rewritten like
@symbol x, y, z
However I have not yet been able to decide if multi-assignment would be
overall
beneficial to this new syntax. Probably not, at least at this stage. It
would
not be hard for a decorator function to return multiple values, but how
would
the multiple names be passed in? A string with whitespace like this
original,
and namedtuple's field_names, is possible as no valid identifier can have a
space in it. However, it forces any would-be variable decorator to know this
and check if a space is in its first argument, even if it cannot produce
multiple values. Another option is to pass in an iterable, but the same
additional effort would be placed on decorators tha

[Python-ideas] Re: Introduce constant variables in Python

[Steven D'Aprano]

"Constant variables" is a contradiction in terms. If it is constant, it 
cannot be a variable, and vice versa. Can we be more precise in the 
language used please?

We have two independent concepts here:

* name bindings: names can be bound to a value, or unbound with 
  the `del` statement;

* values can be mutable or immutable.

"Constant" might refer to immutability. `1` is a constant, but `[]` is 
not, because the list can be mutated. In some languages (not Python), we 
can "freeze" a mutable object and turn it immutable.

Or it might refer to bindings: a perhaps a constant name cannot be 
unbound or rebound to a new object, but the object may be either mutable 
or immutable.

Can you explain what combination of these three features (binding of 
names, mutability of objects, a "freeze" protocol) you are looking for?

You say:

> Usually if we have a constant we don't create another reference to it. 
> So do not support two references. Why not? Many reasons, especially 
> deallocation problems.

That seems very odd. That would mean that you can't pass constants to 
functions, or put them in lists or dicts, since that would create new 
references to the object.

What if an object has already got more than one reference?

>>> import gc
>>> count = len(gc.get_referrers(None))
>>> print(count)
1771

With more than 1700 references to the None object, I guess we can't 
create a constant None. That's going to go straight into the list of 
Python WTFs. Small ints also have many references:

>>> len(gc.get_referrers(1))
65

I think people would be surprised if they can't make a constant 1. I 
know I would be.


-- 
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/CGFSWYONRHM65BY2NTYEJSUPSAUDMH63/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: match expressions in python 3.10

[Valentin Berlier]

On the other hand I think extending the walrus operator would make the change 
less intrusive and the syntax more easily discoverable:

if match := re.match(r"...", some_string):
print(match[1], match[2])

if [_, a, b] := re.match(r"...", some_string):
print(a, b)  # Assuming match objects would then be made into proper 
sequences

Also, since it's not a new operator there's no need to worry about operator 
precedence. And since the current behavior of the walrus operator would already 
implement a subset of the proposed changes, I think it would reduce friction 
when deciding whether or not to adopt it.

One last point is that the new operator would lead to two equivalent constructs:

if thing.value matches foo:
...

if foo := thing.value:
...

I think using the "matches" operator like this would probably be frowned upon 
but that's yet another thing you would need to explain when teaching the 
language. Also, I can easily imagine some codestyle where the walrus operator 
would be considered obsolete as it would overlap with the "matches" operator 
while only providing a subset of the functionality, thus leading to 
fragmentation in the ecosystem.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/6YUVCSL23YKSCKRDJXVUZW2XSGXAYCJM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: match expressions in python 3.10

[Steven D'Aprano]

On Mon, May 24, 2021 at 07:55:07PM -, Tyler F wrote:

> with the addition of PEP 634 and the new match/case syntax in python 
> 3.10, it seems fitting to be able to use these new match statements 
> inside of expressions as well,

Python 3.10 isn't even showing up on the Downloads page yet:

https://www.python.org/downloads/

It is still in beta, the first production-ready version is not due out 
until October.

https://www.python.org/dev/peps/pep-0619/#schedule

So how much real-world practical experience do you have now with the 
match/case syntax? Do you think that the community overall has as much 
experience with this syntax as you?

Normally we have years of practical experience with a feature before 
being able to judge its true worth and ability to extend it to new 
features. It was many years between if statements and the if operator; 
many years between for loops and comprehensions. We still don't have a 
try...except expression.

> However, this should be used sparingly (ideally for single 
> comparisons), similar to list comprehensions versus for loops.

o_O

In my experience, list comprehensions are used more than for loops now. 
But even if they aren't used literally more often than for loops, we can 
hardly say that comprehensions are used *sparingly*. They are an 
extremely popular and common feature.


So what does this matches operator return? You have this example:

if variable matches ["example", *files]:
print(files)


but we can extract the matches expression outside of the if statement.

(It's an expression, so we must be able to extract it out of the 
statement and use it alone, like any other expression.)


variable matches ["example", *files]


I can't interpret what that should do or what it would return. Suppose I 
assigned it to a variable, or printed it:


spam = variable matches ["example", *files]
print(variable matches ["example", *files])


What's the value of `spam` (or what gets printed)?

If we can use it in an if statement, it has to return a value that can 
be either truthy or falsey, possibly even True or False itself.

How does that reconcile with the multi-branching match statement? A 
match statement can take an arbitrarily large number of cases, and each 
case is a block. How do you get the same effect in an expression?

Match statements also have binding side-effects. Binding in Python is 
*almost* entirely done with statements:

spam = eggs # assignment
import spam
for spam in iterable: ...
except Exception as err: ...

etc. The only expression that performs binding is the walrus operator, 
and that is still new and remains controversial. This would be a second 
one.


-- 
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/G6SIIWILJ2QWGURSXXEFTH4PQMGK7XSL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce constant variables in Python

[Chris Angelico]

On Tue, May 25, 2021 at 8:09 AM Joren  wrote:
>
> We could define "change" in terms of the hash of the object the name points 
> to, as well as the name itself (the pointer to the object).

The hash of a random.Random() object doesn't change when its state
does (its derived solely from its id). Nor does the hash of a class.
Nor an instance of a class defined simply as "class Thing: pass".

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/7RNAMRPFYCEKQORLMW34YW27V35YQZ36/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: match expressions in python 3.10

[Tyler F]

ehhh in my opinion its more pythonic to use a keyword in this case, especially 
since that seems to be the main way it is currently done with statements being 
turned into expressions
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/7RXYKTOMKFUGZ2EMJTYOLLGRXAQJT7QX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce constant variables in Python

[Stestagg]

-1 for all of this unless it’s included as part of a bigger change that has
proven performance benefits when constants are used

On Mon, 24 May 2021 at 23:10, Joren  wrote:

> We could define "change" in terms of the hash of the object the name
> points to, as well as the name itself (the pointer to the object).
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/ODOBGGTZPKOEBHADPRDOJLXBMGWZRKQC/
> 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/T5SMHNA5NB6BBDZP4EGXX6UJ626MUJCE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce constant variables in Python

[Joren]

We could define "change" in terms of the hash of the object the name points to, 
as well as the name itself (the pointer to the object).
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ODOBGGTZPKOEBHADPRDOJLXBMGWZRKQC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: symbolic math in Python

[Joren]

Aside from the type conversion dunders (e.g. `__bool__`), and the `and`, `or` 
and `in` operators, this is possible right now: 
You can create a `Symbol` class that returns another `Symbol` in the compatible 
operator dunder methods, while internally maintaining a list of (operator, 
args, kwargs). Then you can "replay" all the operations when you evaluate the 
symbol by in some way binding it to a value. You could even go as far as to 
build an AST from the operations list, and compile it to a function or lambda 
(its argument is the value you bind to), so you avoid the (significant) 
overhead of looping through the operations and applying then.

It's unfortunate that there is no way to have e.g. `'spam' in my_symbolic_set` 
evaluate to something else than a boolean. Also, this approach will not work 
with everything else for which there is no dunder method, e.g. 
`math.sin(my_symbolic_value)` cannot be tricked into returning a Symbol.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/EK6F7RZQW7G5N4LDSNAB7AONUB2TPAKZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce constant variables in Python

[Chris Angelico]

On Tue, May 25, 2021 at 7:30 AM Joren  wrote:
>
> typing.Final actually means something like "cannot be reassigned", whereas 
> constant variable means "cannot change". Consider e.g.
>
> class Spam:
> def __init__(self):
> self.eggs = 0
>
> @final   # method cannot be overridden (which is more related to 
> "reassignment" than to "change")
> def more(self):
> self.eggs += 1
>
> spam: Final[Spam] = Spam()
> spam.more()  # This is allowed, but spam changed
> del spam  # Allowed as well
>

What's the definition of "cannot change"? Which of these counts as a change?

x = (42, ["spam"])
x[1][0] = "ham" # This?

lst = ["spam"]
y = (42, lst)
lst[0] = "ham" # This?

r = random.Random()
r.randrange(10) # This?

class C: pass
class D(C): pass # Is this changing X?

x is a tuple, and we already know that they're immutable. Yet its
value changed when something else changed. In y's case, the assignment
never even mentions the tuple, yet y's value still changes. The Random
instance has internal state which changes every time you ask for a
random number. And you can ask a class for all of its subclasses, so
the detectable behaviour of it changes when you add a new subclass.

Requiring that a name not be rebound is well-defined and testable.
Requiring that an object not change is either trivial (in the case of,
say, an integer) or virtually impossible (in the case of most
objects).

What would be the advantage of such a declaration?

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/C4LZ2F2U3F45EWLDF5WG2UASSOH433RU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: match expressions in python 3.10

[Valentin Berlier]

There was a discussion about this a couple months ago but instead of adding a 
new keyword the idea was that the walrus operator could be upgraded from simply 
being a binding operator to matching patterns supported by the match statement.

if ["example", *files] := variable:
print(files)

If the pattern doesn't match the expression would evaluate to None instead of 
the right hand side value. The current syntax would still work the same as it 
would be interpreted as an unconditional name binding pattern.

foo = [1, 2, 3]
assert ([] := foo) is None
assert ([a, b, c] := foo) is foo
assert (bar := foo) is foo  # No special case needed for the current behavior
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/67C6OWL5YOFYKXJGY6XI34JKJC6WBUGT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce constant variables in Python

[Joren]

typing.Final actually means something like "cannot be reassigned", whereas 
constant variable means "cannot change". Consider e.g.

class Spam:
def __init__(self):
self.eggs = 0

@final   # method cannot be overridden (which is more related to 
"reassignment" than to "change")
def more(self):
self.eggs += 1
 
spam: Final[Spam] = Spam()
spam.more()  # This is allowed, but spam changed
del spam  # Allowed as well 


Moreover, `Final` is part of typing, which is strange because it indicates a 
property of the variable name itself, not of its type. Perhaps the constant 
keyword can become a replacement for the confusing `typing.Final`.

So "constant" is semantically different than `typing.Final` (and 
`typing.final`), and it makes more sense to have it be a keyword (e.g. 
`constant spam`), instead of it being an annotation; it only should be used 
when declaring variables and attributes (e.g. `def f(a: Final)` is not allowed).
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IDERCN7SGKKV34ISDROFMTCEJJIND4NH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] match expressions in python 3.10

[Tyler F]

with the addition of PEP 634 and the new match/case syntax in python 3.10, it 
seems fitting to be able to use these new match statements inside of 
expressions as well, which is why I think we should have a new `matches` 
keyword (similar to if/else, is, for, not, etc.) for use in expressions. This 
makes many more complex if/else statements much less complex (see example use 
cases at #2), and overall looks much more pythonic in practice. The expression 
would be higher on the order of operations than the boolean operators, but 
higher than the comparisons, but this is subject to change. (see #1) However, 
this should be used sparingly (ideally for single comparisons), similar to list 
comprehensions versus for loops.

1. GRAMMAR MODIFICATIONS:
```
inversion:
| 'not' inversion 
| match_expression

matches_expression:
| comparison 'matches' patterns # patterns is defined in PEP 634
| comparison
```

2. USE CASES:
a.
```
if variable matches ["example", *files]:
print(files)
```
as opposed to:
```
match variable:
case ["example", *files]:
print(files)
```
b. 
```
for x in some_list:
if x matches Class1(attr1=3) | Class2(attr2=4):
print("got a match!")
break
```
as opposed to
```
for x in some_list:
match x:
case Class1(attr1=3) | Class2(attr2=4):
print("got a match!")
break
```
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/FINMYEQ4A4MCG72U4PXJGZ3VCJLA75VD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add support for private variables, methods and functions in Python

[Marco Sulla]

On Sun, 23 May 2021 at 19:50, Chris Angelico  wrote:
>
> On Mon, May 24, 2021 at 3:38 AM Marco Sulla
>  wrote:
> > > > > Do you yearn for actual refactoring tools - which do exist?
> > > >
> > > > Renaming tools of IDE do not work in 100% of the cases. For example,
> > > > if you have _variable in an eval string, it's not replaced.
> > >
> > > Another reason not to use eval.
> >
> > I completely agree, but the world is not perfect. Another example is
> > the use of the _variable in a f-string.
> >
>
> f-strings are code, and should be treated as code by any decent
> refactoring tool.

Ok, but the point is that renaming a variable is always a problem. I
check the result of renaming twice even when I use Java with Eclipse.
It seems to me that modern languages and programming strategies tend
to make refactoring as easy as possible.

>
> Language features shouldn't be dictated by poor tools, nor by poor codebases.
>
> 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/6O6NDZBOWAI6DK7623HHIC7OESQ46KWV/
> 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/ZEQUNJFDFCPFXH5OMSK3Z2NYN76HUAUK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: dict.get_deep()

[Marco Sulla]

On Sun, 23 May 2021 at 19:41, Todd  wrote:
>
> The pytoolz/cytoolz project already has this: 
> https://toolz.readthedocs.io/en/latest/api.html#toolz.dicttoolz.get_in

It seems a project that is used by many people. I think that JSON is
so much used that that function could be added to the builtin dict.

>
> On Sun, May 23, 2021, 11:44 Chris Angelico  wrote:
>>
>> On Mon, May 24, 2021 at 1:24 AM MRAB  wrote:
>> > Also, if the first lookup returns a list or a tuple, and an argument can
>> > be an index of that list, would be make sense to add a similar method to
>> > lists and tuples?
>>
>> Or, better: make it a stand-alone function, not a method of anything.
>> Although that kinda takes it out of python-ideas territory because it
>> could easily be a personal library function instead:
>>
>> _sentinel = object() # or see other proposals
>> def get_deep(obj, *keys, default=_sentinel):
>> if len(keys) == 1: keys = list(keys[0])
>> try:
>> for key in keys:
>> obj = obj[key]
>> except (LookupError, TypeError): # the OP did include TypeError
>> if default is not _sentinel: return default
>> raise
>> return obj
>>
>> Done. Personally, I'd just go with "except LookupError:", but this is
>> another advantage of personal library functions: you don't have to
>> bikeshed them with everyone else :)
>>
>> 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/YM6KCRUJV2ROYV2TC44DWECFJV6TG4A6/
>> 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/MEQM2SZQD5KPVZHUM655DRR4EV42U63Y/
> 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/3VAIGV6CPLOMEY7K2Z4XWIXQ7HXBJXQ6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce constant variables in Python

[Shreyan Avigyan]

Thomas Grainger:
> This is already available with typing.Final and immutable types:
>
> from typing import Final
>
> ham: Final = 3
> ham = 4 # Error
>
> hams: Final[Sequence[str]] = ["ham", "spam"]
> hams.append("meat") # Error

I'm not sure whether it's a reply to me or someone else. But anyways this is a 
convention. mypy will detect it. *But* I have a feeling that constants can have 
performance improvements though I'm not sure.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/2T4N5GCN6VWNZM5T7RXKSRDXSTSRVZBX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce constant variables in Python

[Thomas Grainger]

This is already available with typing.Final and immutable types:

from typing import Final

ham: Final = 3
ham = 4 # Error

hams: Final[Sequence[str]] = ["ham", "spam"]
hams.append("meat") # Error


On Mon, 24 May 2021, 18:40 Abdur-Rahmaan Janhangeer, 
wrote:

> Greetings,
>
> Just a light-hearted note, if ever the idea is taken seriously,
>
> variable: constant = 10
>
> seems more pythonic to me.
>
> constant variable = 10 opens the doors for
>
> int x = 5 etc
>
> Kind Regards,
>
> Abdur-Rahmaan Janhangeer
> about  | blog
> 
> github 
> Mauritius
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/S2CTGF562UST4DM22HO7SLZ3EEWG544G/
> 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/7FK56ZRCC3XP3CIN7DEF3OD3ELUFYGIY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce constant variables in Python

[Abdur-Rahmaan Janhangeer]

Greetings,

Just a light-hearted note, if ever the idea is taken seriously,

variable: constant = 10

seems more pythonic to me.

constant variable = 10 opens the doors for

int x = 5 etc

Kind Regards,

Abdur-Rahmaan Janhangeer
about  | blog

github 
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/S2CTGF562UST4DM22HO7SLZ3EEWG544G/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Introduce constant variables in Python

[Shreyan Avigyan]

Many times a programmer would want a variable that will be a constant. The 
programmer could have been careless and suddenly changed a very important 
variable. Proposed syntax,

constant variable = 10
variable = 20 # Error

Now constant means making a variable value immutable. It means now we can 
neither change the variable to point to another value nor the value itself 
anymore. For example, if we have a list we cannot change it. If we try to then 
"Error". So for lists,

constant variable = ["List"]
variable.append("Some") # Error
variable = ["Another"] # Error

Usually if we have a constant we don't create another reference to it. So do 
not support two references. Why not? Many reasons, especially deallocation 
problems.

Thanking you,
With Regards
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/V2CJQ5C5TYZGOCI5P5BHBTHJZFTT6WTX/
Code of Conduct: http://python.org/psf/codeofconduct/