[Python-ideas] Re: pathlib enhancements
Does anyone have any further thoughts on these? Should I split these into separate threads? On Sun, Nov 22, 2020 at 10:05 PM Todd wrote: > On Sun, Nov 22, 2020 at 9:49 PM Matt Wozniski wrote: > >> > I suggest adding an "exist_ok" argument to all of these, with >> > the default being "True" for backwards-compatibility. This argument >> name >> > is already in use elsewhere in pathlib. If this is False and the file >> is >> > not present, a "FileNotFoundError" is raised. >> >> For Path.mkdir, exist_ok=True inhibits an error if a directory already >> exists. >> You're proposing that for Path.is_dir, exist_ok=True should inhibit an >> error if >> the directory does not exist. >> >> A parameter to enable that behavior sounds reasonable to me, but it >> definitely >> shouldn't have the name "exist_ok"; it does the opposite of what exist_ok >> does. >> > > Good point, perhaps "missing_ok" then. > ___ 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/ATT5CC55ETKBVS26PXFUKUCC4OLNXGNL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Making the for statement work better with nested functions
On Tue, Dec 1, 2020 at 10:25 AM Marco Sulla wrote: > > On Mon, 30 Nov 2020 at 23:26, David Mertz wrote: > > Somehow "dire" doesn't strike me as the right word Maybe you were > > looking for "conceivably useful in niche cases."? > > Well, I think const can be useful for: > * multiprocessing. Now, for example, dict is passed between processes > using MappingProxyType, which is slow. > * avoid side effects. I expect that my object will not change and I > want to be sure I'll not change it by mistake. Mistake that I made a > lot of times. > * contract. A function marks a parameter as const will guarantee that > the object will not be changed. It's something complementar to > annotations. > * possible future speed improvements. For example, if an iterable is > const, you can skip a lot of checks about mutability on iteration and > make it more fast. Are you assuming that "const" means "will not be rebound" or "is immutable"? Or both? 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/YFDQCVIIJAXAUJ54C7C4D7L6WQFKJ3EI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Making the for statement work better with nested functions
On Mon, 30 Nov 2020 at 23:26, David Mertz wrote: > Somehow "dire" doesn't strike me as the right word Maybe you were looking > for "conceivably useful in niche cases."? Well, I think const can be useful for: * multiprocessing. Now, for example, dict is passed between processes using MappingProxyType, which is slow. * avoid side effects. I expect that my object will not change and I want to be sure I'll not change it by mistake. Mistake that I made a lot of times. * contract. A function marks a parameter as const will guarantee that the object will not be changed. It's something complementar to annotations. * possible future speed improvements. For example, if an iterable is const, you can skip a lot of checks about mutability on iteration and make it more fast. ___ 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/GVYJJCPRBYTTXFJ7GYTUMSDVYUWJZUJU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Making the for statement work better with nested functions
On Mon, Nov 30, 2020, 5:20 AM Paul Sokolovsky > So, if anything, we're re-tracing JavaScript steps. We're in dire need > of const'ness in the language. Somehow I've used Python for 22 years without experiencing that direness. I've taught thousands of students already experienced in other languages (most with constants) without anyone noting the need). I've been *read* by MILLIONS of readers using Python without mentioning the need to me. Somehow "dire" doesn't strike me as the right word Maybe you were looking for "conceivably useful in niche cases."? ___ 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/V7Y4DMR2HALJDMK4FA2J2NZ2LFAGHYZ7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add decorator_with_params function to functools module
Is it really worth it? Fact is, while it can shave off some lines of code, I think it is interesting to know _which_ lines of code - Usually when one writes a decorator, it is expected that they will know what they are writing, and will want to be in control of their code. Delegating this to a decorator-decorator that is to be copied and pasted, and will definitely change call-order, and when your decorator is called, is something that I, at least, would be wary to use. Meanwhile, when I want this pattern, it really takes me 2 LoC inside the decorator to have the same functionality, and still be 100% in control of when my function is called: ``` from functools import partial def mydecorator(func=None, /, *, param1=None, **kwargs): if func is None: return partial(mydcorator, param1=None, **kwargs) # decorator code goes here ... ``` So, yes, your proposal has some utility - but I consider it to be marginal - it is the kind of stuff that I'd rather see on a 3rdy party package with extra-stuff to help building decorators than on stdlib. On Mon, 30 Nov 2020 at 17:04, Yurii Karabas <1998uri...@gmail.com> wrote: > The idea of `decorator_factory` is to eliminate boilerplate code that used > to create a decorator with parameters. > > A perfect example is how `dataclass` decorator can be simplified from this: > ``` > def dataclass(cls=None, /, *, init=True, repr=True, eq=True, order=False, > unsafe_hash=False, frozen=False): > def wrap(cls): > return _process_class(cls, init, repr, eq, order, unsafe_hash, > frozen) > > # See if we're being called as @dataclass or @dataclass(). > if cls is None: > # We're called with parens. > return wrap > > # We're called as @dataclass without parens. > return wrap(cls) > ``` > To this: > @functools.decorator_factory > def dataclass(cls, /, *, init=True, repr=True, eq=True, order=False, > unsafe_hash=False, frozen=False): > return _process_class(cls, init, repr, eq, order, unsafe_hash, frozen) > ``` > ___ > 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/NMCDVBOYFXEKZ4L3ASLNYL2NBATJ3VCX/ > 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/OU4VVMBE74KXK6HF6G7LEFP735AJM4G2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add decorator_with_params function to functools module
The idea of `decorator_factory` is to eliminate boilerplate code that used to create a decorator with parameters. A perfect example is how `dataclass` decorator can be simplified from this: ``` def dataclass(cls=None, /, *, init=True, repr=True, eq=True, order=False, unsafe_hash=False, frozen=False): def wrap(cls): return _process_class(cls, init, repr, eq, order, unsafe_hash, frozen) # See if we're being called as @dataclass or @dataclass(). if cls is None: # We're called with parens. return wrap # We're called as @dataclass without parens. return wrap(cls) ``` To this: @functools.decorator_factory def dataclass(cls, /, *, init=True, repr=True, eq=True, order=False, unsafe_hash=False, frozen=False): return _process_class(cls, init, repr, eq, order, unsafe_hash, frozen) ``` ___ 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/NMCDVBOYFXEKZ4L3ASLNYL2NBATJ3VCX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add decorator_with_params function to functools module
After discussion at the python issue tracker, the better name
`decorator_factory` was proposed.
I have just gone through the standard library code to find places where
`decorator_factory` can be used.
1. `dataclasses.dataclass`
```
def dataclass(cls=None, /, *, init=True, repr=True, eq=True, order=False,
unsafe_hash=False, frozen=False):
"""Returns the same class as was passed in, with dunder methods
added based on the fields defined in the class.
Examines PEP 526 __annotations__ to determine fields.
If init is true, an __init__() method is added to the class. If
repr is true, a __repr__() method is added. If order is true, rich
comparison dunder methods are added. If unsafe_hash is true, a
__hash__() method function is added. If frozen is true, fields may
not be assigned to after instance creation.
"""
def wrap(cls):
return _process_class(cls, init, repr, eq, order, unsafe_hash, frozen)
# See if we're being called as @dataclass or @dataclass().
if cls is None:
# We're called with parens.
return wrap
# We're called as @dataclass without parens.
return wrap(cls)
```
```
@functools.decorator_factory
def dataclass(cls, /, *, init=True, repr=True, eq=True, order=False,
unsafe_hash=False, frozen=False):
"""Returns the same class as was passed in, with dunder methods
added based on the fields defined in the class.
Examines PEP 526 __annotations__ to determine fields.
If init is true, an __init__() method is added to the class. If
repr is true, a __repr__() method is added. If order is true, rich
comparison dunder methods are added. If unsafe_hash is true, a
__hash__() method function is added. If frozen is true, fields may
not be assigned to after instance creation.
"""
return _process_class(cls, init, repr, eq, order, unsafe_hash, frozen)
```
2. `functools.lru_cache`
```
def lru_cache(maxsize=128, typed=False):
"""Least-recently-used cache decorator.
If *maxsize* is set to None, the LRU features are disabled and the cache
can grow without bound.
If *typed* is True, arguments of different types will be cached separately.
For example, f(3.0) and f(3) will be treated as distinct calls with
distinct results.
Arguments to the cached function must be hashable.
View the cache statistics named tuple (hits, misses, maxsize, currsize)
with f.cache_info(). Clear the cache and statistics with f.cache_clear().
Access the underlying function with f.__wrapped__.
See:
http://en.wikipedia.org/wiki/Cache_replacement_policies#Least_recently_used_(LRU)
"""
# Users should only access the lru_cache through its public API:
# cache_info, cache_clear, and f.__wrapped__
# The internals of the lru_cache are encapsulated for thread safety and
# to allow the implementation to change (including a possible C version).
if isinstance(maxsize, int):
# Negative maxsize is treated as 0
if maxsize < 0:
maxsize = 0
elif callable(maxsize) and isinstance(typed, bool):
# The user_function was passed in directly via the maxsize argument
user_function, maxsize = maxsize, 128
wrapper = _lru_cache_wrapper(user_function, maxsize, typed, _CacheInfo)
wrapper.cache_parameters = lambda : {'maxsize': maxsize, 'typed': typed}
return update_wrapper(wrapper, user_function)
elif maxsize is not None:
raise TypeError(
'Expected first argument to be an integer, a callable, or None')
def decorating_function(user_function):
wrapper = _lru_cache_wrapper(user_function, maxsize, typed, _CacheInfo)
wrapper.cache_parameters = lambda : {'maxsize': maxsize, 'typed': typed}
return update_wrapper(wrapper, user_function)
return decorating_function
```
```
@decorator_factory
def lru_cache(user_function, /, maxsize=128, typed=False):
"""Least-recently-used cache decorator.
If *maxsize* is set to None, the LRU features are disabled and the cache
can grow without bound.
If *typed* is True, arguments of different types will be cached separately.
For example, f(3.0) and f(3) will be treated as distinct calls with
distinct results.
Arguments to the cached function must be hashable.
View the cache statistics named tuple (hits, misses, maxsize, currsize)
with f.cache_info(). Clear the cache and statistics with f.cache_clear().
Access the underlying function with f.__wrapped__.
See:
http://en.wikipedia.org/wiki/Cache_replacement_policies#Least_recently_used_(LRU)
"""
# Users should only access the lru_cache through its public API:
# cache_info, cache_clear, and f.__wrapped__
# The internals of the lru_cache are encapsulated for thread safety and
# to allow the implementation to change (including a possible C version).
if isinstance(maxsiz
[Python-ideas] Re: Making the for statement work better with nested functions
Hello, On Mon, 30 Nov 2020 12:26:53 + Rob Cliffe wrote: > On 30/11/2020 08:01, Paul Sokolovsky wrote: > > Hello, > > > > On Sun, 29 Nov 2020 18:53:57 -0800 > > Christopher Barker wrote: > > > >> This is a massively less ambitious idea, and doesn't solve the > >> original problem, but: > >> > >> I'd like to see a scope for names that are "obviously ;-)" meant > >> to be short lived. At the moment that's the for loop "counters" > >> and those created by context managers: > >> > >> for i in something: > >> # use i as usual > >> more_code > >> # now i is not defined > > What other language(s) implement such a scoping discipline? I know > > of none. > > > > On the other hand, block-scoped variables are implemented in: > > > > * C > > * C++ > > * Java > > * Rust > > * Lua > > * JavaScript (not by default, as opt-in) > > * Scheme > > * Common Lisp (as opt-in) > > * ML > > * Ocaml > > * Haskell > > * very long list of other languages... > > > > > > The aim of the block scoping proposal is to make Python *not worse* > > than these other languages, instead of adding funny workarounds > > again. > > > > [] > > > > CHB's proposal may or may not be a good idea. But please treat it on > its merits, Absolutely. I appreciate all the discussion and alternative ideas people put into this. I, on my side, may have a "strong opinion" that ideas I utter are "right", but that doesn't mean I'm not mistaken. These matters really require good consideration from as wider as possible Python community. > instead of saying, as you seem to be, "No other language > does this, so it's bound to be a bad idea which will make Python > worse". That's why I try to choose words carefully ;-). I said that if Python does it like many other languages, it definitely won't be worse than them. I said nothing what happens if it doesn't do it like that ;-). All in all, it's just an argument, as anyone else's. But I do think about those matters, I have to admit. And I'd hate yet another advanced Python programmer to leave for Haskell, Go, Rust, Julia, because, from their PoV, Python has a culture of applying workarounds instead of best-practice solutions. > With that attitude, there would never be any innovation in > language design. I'm first to subscribe under that. Recent example: Pattern Matching, a common mantra is "we did it like that because other languages do it like that" (example: https://mail.python.org/archives/list/python-...@python.org/message/EWX3GWNTVA6DJMTGT3GG67DOSGDD4L52/) My response: But did you consider Python's situation? Both "minor" issues, like lack of constants, which requires ugly workarounds, and overall audience of Python? Was the option to use sigils to mark capture (i.e. assignment) targets *really well* considered? They said yes. Ok. Works for me, and I tried to do as much noise as possible to draw other people's attention to that. > Best wishes Rob Cliffe [] -- Best regards, Paul mailto:pmis...@gmail.com ___ 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/4UEOAQG52BJO7OMQ272QVGKFYUPS6JWP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: adding a timeit.Timer context manager and decorator to time code/functions
On Mon, 30 Nov 2020 at 03:39, Chris Angelico wrote: > > No, Serhiy meant that you can pass a function to timeit. Aaah, didn't know this. On Mon, 30 Nov 2020 at 12:21, Steven D'Aprano wrote: > > On Mon, Nov 30, 2020 at 12:11:01AM +0100, Marco Sulla wrote: > > > You can get the code of a function as a string using `inspect`. > > *Sometimes*. > > > >>> import inspect > >>> def func(): > ... return 1 > ... > >>> inspect.getsource(func) > Traceback (most recent call last): > [...] > OSError: could not get source code So `inspect.getsource()` does not work in the REPL. It does make sense. Anyway, usually I use cProfile, I find the "most slow" function and then I measure the more suspicious lines. So personally I'm more interested in a context manager for timeit than a decorator. I know that PyCharm can report you the speed line per line, but not the free version. On Mon, 30 Nov 2020 at 12:21, Steven D'Aprano wrote: > I have been using a variant of this for years now: > > > https://code.activestate.com/recipes/577896-benchmark-code-with-the-with-statement/ I think it's not a bad idea to have it in timeit. ___ 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/KGNVKZEOTGAYPW5CNUU6BVGVGYCW3XKJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: adding a timeit.Timer context manager and decorator to time code/functions
On Mon, Nov 30, 2020 at 12:11:01AM +0100, Marco Sulla wrote: > You can get the code of a function as a string using `inspect`. *Sometimes*. >>> import inspect >>> def func(): ... return 1 ... >>> inspect.getsource(func) Traceback (most recent call last): [...] OSError: could not get source code I have been using a variant of this for years now: https://code.activestate.com/recipes/577896-benchmark-code-with-the-with-statement/ It's not suitable for timing microbenchmarks, since the overhead of the with statement could be greater than the code you are timing, but sometimes you want a quick time measurement for something, and this is much better than import time t = time.time() # run code here t = time.time() - t *especially* when you're typing code in the interactive interpreter. -- 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/ANIJLXDFQ4KZMWRYEG4URN4VMQ4UAJ5D/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Making the for statement work better with nested functions
Hello, On Mon, 30 Nov 2020 08:48:21 + Paul Moore wrote: [] > > > > On the other hand, block-scoped variables are implemented in: > > > > * C > > > > * C++ > > > > * Java > > > > * Rust > > > > * Lua > > > > * JavaScript (not by default, as opt-in) > > > > * Scheme > > > > * Common Lisp (as opt-in) > > > > * ML > > > > * Ocaml > > > > * Haskell > > > > * very long list of other languages... > > > > > > How many of these languages don't require any sort of variable > > > declaration for all but a tiny minority of variables? > > > > I don't see to what your question applies. The proposal to introduce > > block-scope variables in Python relies on a special keyword to > > introduce them. So, any language with support for block-scoped vars > > would require "declaration", Python including. (But Python and some > > other languages keep non-block-scoped vars without any decls.) > > To cover some of the languages I know, > > C, C++ and Java require *every* variable to be declared. > Rust requires every variable to be declared, at least to the point of > using "let". You can't introduce a variable just by using it. > In Lua, variables introduced by assignment are global, even > function-local variables need "local". > > Conversely, in Python, x=12 introduces a function-local name x, if > used in a function. Without any sort of "declaration", or keyword. That feature stays. > You seem to be treating "block-scoped" variables as different from > function-local variables. Literally, block-scoped vars are block-scoped, and require special syntax to introduce them. Do *you* treat them much differently beyond that? > I know of *no* other language that makes > such a distinction, much less requiring different syntax for them. Well, Python is special ;-). More seriously, JavaScript have had the same scoping discipline as Python - variables are function-local, though their introduction requires "var" keyword. But recently, that changed. Well, how recently - a few years ago, now unalienable part of JavaScript, with Python falling behind its biggest competitor. So what they did: So, any language is in dire need of immutable variables (some have such by default, some only such). JavaScript needed them too (dynamic languages actually need them more than static). So, they introduced it. And they introduced it. But per the modern best practices, they introduced it block-scoped. So, they introduced block-scoped immutable variables. Ant to not leave accidental gap (https://en.wikipedia.org/wiki/Accidental_gap) in the language, they also introduced mutable block-scoped, with the "let" keyword. Now, the "const" is the great hit in JavaScript (heck, it was in the *dire* need). What about "let"? Well, it's there, so that the *current* JavaScript designers aren't laughed at for designing it in 2 weeks while on holiday drinking things. It has its usages too, in great demand for egghead phd's, laid off haskell developers who couldn't find better job than to code javascript, all that crowd, you know. Also, scientific studies show that much less people leave JavaScript for Haskell now in the first place. So, if anything, we're re-tracing JavaScript steps. We're in dire need of const'ness in the language. We'll introduce it as annotation first, but likely it will be so useful, that we'll want to make it a keyword. Then a question of scope for variables declared with it will raise. We should not make mistakes then. The stage should be setting already now. [] > > They won't be common, if people don't find common need for them > > (they shouldn't). If they do... oh, people! > > So you're saying this proposal is to add new syntax and semantics to > Python for an uncommon situation? You can't have it both ways. Is this > proposal useful to a lot of people (and hence worth new > syntax/semantics) or is it uncommon (and as a result, likely not worth > the disruption). > > I'm ambivalent, with a bias towards saying that we don't need this, to > the proposal. But I'm finding your arguments confusing and > inconsistent. It feels like it's almost impossible to discuss the > specifics of the proposal, as you're not taking a consistent position > to debate against. So, the quest is for the fundamental, "atomic", orthogonal yet well-composable features which can be (re)used to address various (ideally, as many as possible) Python language design challenges and issues. This necessary makes the discourse topic wide, and people constantly bring up fringe issues like "but C has mandatory variable declarations!", "what about debuggers?", "what about locals()?". All that makes following the mailing list discussion hard, yes. I guess, for now we reached its limits. People interested in the topic should find enough food for reading and thought. But those fundamental, orthogonal language features under scrutiny are clear and simple: 1. Const'ness aka variable immutability. 2. Block-level scope. -- Best regards, Paul
[Python-ideas] Re: Making the for statement work better with nested functions
On Mon, 30 Nov 2020 at 08:29, Paul Sokolovsky wrote: > > Hello, > > On Mon, 30 Nov 2020 08:11:07 + > Paul Moore wrote: > > > On Mon, 30 Nov 2020 at 08:03, Paul Sokolovsky > > wrote: > > > On the other hand, block-scoped variables are implemented in: > > > > > > * C > > > * C++ > > > * Java > > > * Rust > > > * Lua > > > * JavaScript (not by default, as opt-in) > > > * Scheme > > > * Common Lisp (as opt-in) > > > * ML > > > * Ocaml > > > * Haskell > > > * very long list of other languages... > > > > How many of these languages don't require any sort of variable > > declaration for all but a tiny minority of variables? > > I don't see to what your question applies. The proposal to introduce > block-scope variables in Python relies on a special keyword to > introduce them. So, any language with support for block-scoped vars > would require "declaration", Python including. (But Python and some > other languages keep non-block-scoped vars without any decls.) To cover some of the languages I know, C, C++ and Java require *every* variable to be declared. Rust requires every variable to be declared, at least to the point of using "let". You can't introduce a variable just by using it. In Lua, variables introduced by assignment are global, even function-local variables need "local". Conversely, in Python, x=12 introduces a function-local name x, if used in a function. Without any sort of "declaration", or keyword. You seem to be treating "block-scoped" variables as different from function-local variables. I know of *no* other language that makes such a distinction, much less requiring different syntax for them. > > > The aim of the block scoping proposal is to make Python *not worse* > > > than these other languages, instead of adding funny workarounds > > > again. > > > > One of the ways in which Python is *better* than these languages is in > > not requiring variables to be declared. Let's not make the proposed > > Python *worse* than the current version of Python, by making variable > > declarations common. > > They won't be common, if people don't find common need for them (they > shouldn't). If they do... oh, people! So you're saying this proposal is to add new syntax and semantics to Python for an uncommon situation? You can't have it both ways. Is this proposal useful to a lot of people (and hence worth new syntax/semantics) or is it uncommon (and as a result, likely not worth the disruption). I'm ambivalent, with a bias towards saying that we don't need this, to the proposal. But I'm finding your arguments confusing and inconsistent. It feels like it's almost impossible to discuss the specifics of the proposal, as you're not taking a consistent position to debate against. Paul ___ 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/3ULDSE3W7T3S3ZGSS2WTKJ6HJQFZ4CMG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Making the for statement work better with nested functions
Hello, On Mon, 30 Nov 2020 08:11:07 + Paul Moore wrote: > On Mon, 30 Nov 2020 at 08:03, Paul Sokolovsky > wrote: > > On the other hand, block-scoped variables are implemented in: > > > > * C > > * C++ > > * Java > > * Rust > > * Lua > > * JavaScript (not by default, as opt-in) > > * Scheme > > * Common Lisp (as opt-in) > > * ML > > * Ocaml > > * Haskell > > * very long list of other languages... > > How many of these languages don't require any sort of variable > declaration for all but a tiny minority of variables? I don't see to what your question applies. The proposal to introduce block-scope variables in Python relies on a special keyword to introduce them. So, any language with support for block-scoped vars would require "declaration", Python including. (But Python and some other languages keep non-block-scoped vars without any decls.) > > The aim of the block scoping proposal is to make Python *not worse* > > than these other languages, instead of adding funny workarounds > > again. > > One of the ways in which Python is *better* than these languages is in > not requiring variables to be declared. Let's not make the proposed > Python *worse* than the current version of Python, by making variable > declarations common. They won't be common, if people don't find common need for them (they shouldn't). If they do... oh, people! > Paul -- Best regards, Paul mailto:pmis...@gmail.com ___ 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/VHXFRQWQ7OE766S5AAD7J6NXVLJ5WS7T/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Making the for statement work better with nested functions
On Mon, 30 Nov 2020 at 08:03, Paul Sokolovsky wrote: > On the other hand, block-scoped variables are implemented in: > > * C > * C++ > * Java > * Rust > * Lua > * JavaScript (not by default, as opt-in) > * Scheme > * Common Lisp (as opt-in) > * ML > * Ocaml > * Haskell > * very long list of other languages... How many of these languages don't require any sort of variable declaration for all but a tiny minority of variables? > The aim of the block scoping proposal is to make Python *not worse* > than these other languages, instead of adding funny workarounds again. One of the ways in which Python is *better* than these languages is in not requiring variables to be declared. Let's not make the proposed Python *worse* than the current version of Python, by making variable declarations common. Paul ___ 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/4QKGFAYTXCPQZG3KTNM3WT2QIGMEATDT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Making the for statement work better with nested functions
Hello, On Mon, 30 Nov 2020 12:56:59 +1300 Greg Ewing wrote: > On 29/11/20 11:02 pm, Paul Sokolovsky wrote: > > It will be much more obvious if there's a general (standalone) > > "const", > > I don't think it will. There's nothing about the problem > that points towards constness as a solution, so it doesn't > matter how many other places in the language "const" appears. As was mentioned, there's no replacement for reading docs/tutorials. And all that applies the same to "for new". > And even if you're told about it, you need two or three steps > of reasoning to understand *why* it solves the problem. > > > that's why I'm saying we can't really consider "for const" without > > just "const" > > I agree with that. Good. > > > And it's "pretty obvious" to someone who considered various choices > > and saw pieces falling into their places. Also might be pretty > > obvious for someone who used other languages. > > I strongly suspect it's something that's obvious only in > hindsight. The same for "for new". But at least "for const" fits better with other usages of "const", including in other languages (so much less of NIH syndrome). > > -- > Greg [] -- Best regards, Paul mailto:pmis...@gmail.com ___ 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/ZHPFYSEICSXEFNXACLDWZL34UFP7WUHL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Making the for statement work better with nested functions
Hello, On Sun, 29 Nov 2020 18:53:57 -0800 Christopher Barker wrote: > This is a massively less ambitious idea, and doesn't solve the > original problem, but: > > I'd like to see a scope for names that are "obviously ;-)" meant to be > short lived. At the moment that's the for loop "counters" and those > created by context managers: > > for i in something: > # use i as usual > more_code > # now i is not defined What other language(s) implement such a scoping discipline? I know of none. On the other hand, block-scoped variables are implemented in: * C * C++ * Java * Rust * Lua * JavaScript (not by default, as opt-in) * Scheme * Common Lisp (as opt-in) * ML * Ocaml * Haskell * very long list of other languages... The aim of the block scoping proposal is to make Python *not worse* than these other languages, instead of adding funny workarounds again. [] -- Best regards, Paul mailto:pmis...@gmail.com ___ 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/4RXUCIMGP5V4XZTQRFIKR7UZNO5DLVDT/ Code of Conduct: http://python.org/psf/codeofconduct/
