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"
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.
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
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
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
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,
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,
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:
>
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
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):
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
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
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
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
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
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"
16 matches
Mail list logo
