You mean the sentinel is called 'undef'? With undef-coallescing operators?
On Tue, May 26, 2020, 2:14 AM Greg Ewing
wrote:
> Wild idea: Instead of sentinels, have a way of declaring optional
> arguments with no default, and a way of conditionally assigning a
> value to them if they are not bound
On Tue, May 26, 2020 at 4:12 PM Greg Ewing wrote:
>
> Wild idea: Instead of sentinels, have a way of declaring optional
> arguments with no default, and a way of conditionally assigning a
> value to them if they are not bound.
>
> E.g.
>
> def order(eggs = 4, spam =):
> spam ?= Spam(
Wild idea: Instead of sentinels, have a way of declaring optional
arguments with no default, and a way of conditionally assigning a
value to them if they are not bound.
E.g.
def order(eggs = 4, spam =):
spam ?= Spam()
Here the '?=' means "if spam is not bound, then evaluate the
rhs
On Mon, May 25, 2020, 11:56 PM Christopher Barker
> well, yes and no. this conversation was in the context of "None" works
> fine most of the time.
>
How many functions take None as a non-sentinel value?! How many of that
tiny numbers do so only because they are poorly designed.
None already is
On Mon, May 25, 2020 at 6:37 PM Steven D'Aprano wrote:
> > A NOT_SPECIFIED singleton in builtins would be pretty clear.
>
> Guido's time machine strikes again! We already have that "not specified"
> singleton in the builtins, with a nice repr. It's spelled "None".
>
well, yes and no. this conv
On Mon, May 25, 2020 at 11:19:06AM -, redrad...@gmail.com wrote:
> I like the topic on
> https://www.reddit.com/r/Python/comments/bpp9hg/has_the_python_gil_been_slain_subinterpreters_in/
>
> Answer written by CSI_Tech_Dept:
> ```
> ...
> What probably needs to be done is to have a compile op
On Mon, May 25, 2020 at 11:11:14AM -, redrad...@gmail.com wrote:
> We just need to provide two APIs:
> 1) Synchronized: `run`, `run_string`, that will wait until thread
> notify with setting `atomic variable` in true that it finished
> 2) Asynchronized (based on async): `run_async`, `run_stri
On Mon, May 25, 2020 at 06:38:22PM -0400, Edwin Zimmerman wrote:
> No, there isn't a separate GIL for each sub-interpreter. That would
> be a great feature in my mind, but it isn't there.
I believe that it is a long-term goal to eventually move to a separate
GIL for each subinterpreter:
https
On Mon, May 25, 2020 at 02:19:57PM -0700, Christopher Barker wrote:
> > It's an extremely common idiom right up until it doesn't
> > work, and you need:
> >
> > _SENTINEL = object()
> > def fun(..., option=_SENTINEL):
> > if option is _SENTINEL:
> > option = something_else
> >
>
> I'v
On Tue, May 26, 2020 at 11:05 AM Steven D'Aprano wrote:
> If you want the default value to be X, then:
>
> - if you want a fresh X each time, then you want late binding;
>
> - if you want the same X each time, then you want early binding;
>
> - if you don't care, then early binding is likely to be
On Tue, May 26, 2020 at 02:25:38AM +0300, Paul Sokolovsky wrote:
> > > I'd suggest that people should love "explicit is better than
> > > implicit" principle of the language.
> >
> > Explicit meaning that you need to use a specific symbol that means
> > "this is to be late-bound"?
>
> No, it m
On Mon, May 25, 2020 at 06:45:47PM -0400, Eric V. Smith wrote:
> On 5/25/2020 6:37 PM, Chris Angelico wrote:
> >Explicit meaning that you need to use a specific symbol that means
> >"this is to be late-bound"?
> >
> >Or explicit meaning "something that I like", as opposed to implicit
> >meaning "so
Hello,
On Tue, 26 May 2020 08:37:59 +1000
Chris Angelico wrote:
[]
> > def foo(x := a + b)
> >
> > vs
> >
> > c = a + b
> > def foo(x := c)
> >
> > can lead to different results.
>
> def foo(x = None):
> if x is None: x = a + b
>
> c = a + b
> def foo(x = None):
On 5/25/2020 6:37 PM, Chris Angelico wrote:
Explicit meaning that you need to use a specific symbol that means
"this is to be late-bound"?
Or explicit meaning "something that I like", as opposed to implicit
meaning "something that I don't like", which is how most people seem
to interpret that li
On 5/25/2020 8:29 AM, redrad...@gmail.com wrote:
> Edwin Zimmerman wrote:
>> On Monday, May 25, 2020 redrad...@gmail.com [mailto:redrad...@gmail.com]
>> wrote
>>> Edwin Zimmerman wrote:
>>> On 5/25/2020 5:56 AM, redrad...@gmail.com
>>> wrote:
>>> Edwin Zimmerman wrote:
>>> Sub-interpreters are a
On Tue, May 26, 2020 at 8:06 AM Paul Sokolovsky wrote:
>
> Hello,
>
> The more worrying sounds the idea to have a special evaluation context
> for specially marked default arguments. Just imagine - *everywhere* (#1)
> in the language the evaluation is eager, while for specially marked
> default ar
On 5/25/20 6:02 AM, redrad...@gmail.com wrote:
Hi all,
I do not know maybe it was already discussed ...
It's been extensively discussed and attempted.
but the toolchain like LLVM is very mature and it can provide the simpler JIT
compilation to machine code functionality and it will improve
Hello,
On Tue, 26 May 2020 07:34:32 +1000
Chris Angelico wrote:
[]
> > _complex_mutable_default = MyObj(a = 1, b = 2, c = 3, d = 4, e = 5,
> > f = 6, g = 7, h = 8, i = 9, j = 10)
> >
> > def func(x := _complex_mutable_default): ...
> >
> > Above, _complex_mutable_default is NOT immutable-- it i
On Mon, May 25, 2020, 5:33 PM Christopher Barker
> see numba: http://numba.pydata.org/
>
> Also, I"m pretty sure one of the efforts to make a faster python was based
> on LLVM, but it didn't work out as well as hoped -- unladen swallow maybe?
>
Numba is great. Very easy and very fast. Pypy exper
On Sun, May 24, 2020 at 4:59 AM Alex Hall wrote:
> On Sun, May 24, 2020 at 1:42 PM Bernardo Sulzbach <
> berna...@bernardosulzbach.com> wrote:
>
>> ... I would expect len(p) to be the "depth" of the path, which doesn't
>> make a lot of sense if it is not an absolute path.
>>
>
> I agree. I expec
On Tue, May 26, 2020 at 7:19 AM Ricky Teachey wrote:
>
> This late binding is what I was clumsily referring to as option 3 (version
> with no copying). But this is still going to end up having what people would
> consider surprising behavior, is it not?
>
> It is essentially equivalent to this u
On Mon, May 25, 2020 at 3:05 AM wrote:
> I do not know maybe it was already discussed ... but the toolchain like
> LLVM is very mature and it can provide the simpler JIT compilation to
> machine code functionality and it will improve performance of the Python a
> lot !!
>
see numba: http://numb
On Sun, May 24, 2020 at 12:55 PM Chris Angelico wrote:
>
> And it isn't entirely correct, because now None isn't a valid
> parameter.
Which is indeed, an extremely common use case :-)
> It's an extremely common idiom right up until it doesn't
> work, and you need:
>
> _SENTINEL = object()
> d
On Mon, May 25, 2020 at 12:33 PM Chris Angelico wrote:
> On Tue, May 26, 2020 at 2:24 AM Dominik Vilsmeier
> wrote:
> >
> > On 25.05.20 17:29, Ricky Teachey wrote:
> >
> >
> > On Mon, May 25, 2020, 6:49 AM Rob Cliffe via Python-ideas <
> python-ideas@python.org> wrote:
> >>
> >> (Possibly heret
On Mon, May 25, 2020 at 12:19 PM Guido van Rossum wrote:
> It's nice to fantasize about RAM disks, but the code in zipfile.py is
> begging for a simpler solution, just pass in a wrapper that overrides the
> write() method (you may have to make a few changes but you can develop and
> test this sep
On Mon, May 25, 2020 at 10:59 AM Steve Barnes
wrote:
> On Windows
> https://freetechtutors.com/create-virtual-hard-disk-using-diskpart-windows/
> gives a nice description of creating a virtual disk with only operating
> system commands. Note that it shows the commands being used interactively
> b
Subject changed for tangent.
On Sun, May 24, 2020 at 4:14 PM Dominik Vilsmeier
wrote:
> output = []
> for x in data:
> a = delayed inc(x)
> b = delayed double(x)
> c = delayed add(a, b)
> output.append(c)
> total = sum(outputs) # concrete answer here.
>
> Obviously the simple ex
It's nice to fantasize about RAM disks, but the code in zipfile.py is
begging for a simpler solution, just pass in a wrapper that overrides the
write() method (you may have to make a few changes but you can develop and
test this separately from the fix for your bug).
--
--Guido van Rossum (python
Forgot to mention - according to
https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/diskpart
this process applies to Windows 10, Windows 8.1, Windows 8, Windows 7, Windows
Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012,
and Windows Ser
On Windows
https://freetechtutors.com/create-virtual-hard-disk-using-diskpart-windows/
gives a nice description of creating a virtual disk with only operating system
commands. Note that it shows the commands being used interactively but it can
also be scripted by starting diskpart /s script.txt
On Tue, May 26, 2020 at 02:36:16AM +1000, Steven D'Aprano wrote:
> On Mon, May 25, 2020 at 02:03:49AM +0100, Rob Cliffe via Python-ideas wrote:
>
> [quoting Dominik Vilsmeier]
> > >It looks like the most common use case for this is to deal with
> > >mutable defaults
>
> It might be the most comm
On Mon, May 25, 2020 at 06:22:14PM +0200, Dominik Vilsmeier wrote:
> It wouldn't copy the provided default, it would just reevaluate the
> expression. Python has already a way of deferring evaluation, generator
> expressions:
>
> >>> x = 1
> >>> g = (x for __ in range(2))
> >>> next(g
On 25.05.20 18:29, Chris Angelico wrote:
On Tue, May 26, 2020 at 2:24 AM Dominik Vilsmeier
wrote:
On 25.05.20 17:29, Ricky Teachey wrote:
On Mon, May 25, 2020, 6:49 AM Rob Cliffe via Python-ideas
wrote:
(Possibly heretical) Thought:
ISTM that when the decision was made that arg default
On Mon, May 25, 2020 at 02:03:49AM +0100, Rob Cliffe via Python-ideas wrote:
[quoting Dominik Vilsmeier]
> >It looks like the most common use case for this is to deal with
> >mutable defaults
It might be the most common use case, but it's hardly the only use case.
The PEP talks about special ca
On Mon, May 25, 2020 at 6:24 PM Dominik Vilsmeier
wrote:
> On 25.05.20 17:29, Ricky Teachey wrote:
>
>
> On Mon, May 25, 2020, 6:49 AM Rob Cliffe via Python-ideas <
> python-ideas@python.org> wrote:
>
>> (Possibly heretical) Thought:
>> ISTM that when the decision was made that arg default value
On Tue, May 26, 2020 at 2:24 AM Dominik Vilsmeier
wrote:
>
> On 25.05.20 17:29, Ricky Teachey wrote:
>
>
> On Mon, May 25, 2020, 6:49 AM Rob Cliffe via Python-ideas
> wrote:
>>
>> (Possibly heretical) Thought:
>> ISTM that when the decision was made that arg default values should be
>> evaluat
On 25.05.20 17:29, Ricky Teachey wrote:
On Mon, May 25, 2020, 6:49 AM Rob Cliffe via Python-ideas
mailto:python-ideas@python.org>> wrote:
(Possibly heretical) Thought:
ISTM that when the decision was made that arg default values
should be evaluated
once, at function de
On Mon, May 25, 2020, 6:49 AM Rob Cliffe via Python-ideas <
python-ideas@python.org> wrote:
> (Possibly heretical) Thought:
> ISTM that when the decision was made that arg default values should be
> evaluated
> once, at function definition time,
> rather than
> every time the func
On Sun, May 24, 2020 at 01:38:26PM -0400, David Mertz wrote:
> The pattern:
>
> def fun(..., option=None):
> if option is None:
> option = something_else
>
> Becomes second nature very quickly. Once you learn it, you know it. A
> line of two of code isn't a big deal.
Sure, but whe
Really,
I don't think new syntax is needed for that, as it is trivially resolved
by a function call
(I would type an example but Ricky's answer covers it)
Moreover, such a callable, or other helper-callables
can trivially enable ways of connecting the piped
values through specific (positional/nam
On Fri, May 22, 2020 at 03:54:30PM +0100, Rob Cliffe via Python-ideas wrote:
> I find having a RAM drive is very handy. Could this be another use for it?
Could be, if there's a standard way to create a RAM drive on all windows
machines without needing to install specialist RAM drive software fr
On 25.05.20 03:03, Rob Cliffe via Python-ideas wrote:
On 24/05/2020 21:03, Dominik Vilsmeier wrote:
On 24.05.20 18:34, Alex Hall wrote:
OK, let's forget the colon. The point is just to have some kind of
'modifier' on the default value to say 'this is evaluated on each
function call', while
On 22/05/2020 12:15, Steven D'Aprano wrote:
On Fri, May 22, 2020 at 08:09:29AM +, Steve Barnes wrote:
Unfortunately we have no control over where the tests may be run – if
run on Windows from the C: drive it could potentially brick the entire
machine, (which of course some people might co
Edwin Zimmerman wrote:
> On Monday, May 25, 2020 redrad...@gmail.com [mailto:redrad...@gmail.com]
> wrote
> > Edwin Zimmerman wrote:
> > On 5/25/2020 5:56 AM, redrad...@gmail.com
> > wrote:
> > Edwin Zimmerman wrote:
> > Sub-interpreters are a work in progress. The API is not anywhere near
> >
On Monday, May 25, 2020 redrad...@gmail.com [mailto:redrad...@gmail.com] wrote
> Edwin Zimmerman wrote:
> > On 5/25/2020 5:56 AM, redrad...@gmail.com wrote:
> > > Edwin Zimmerman wrote:
> > Sub-interpreters are a work in progress. The API is not anywhere near
> > being finalized.
> > True parall
redradist@gmail.com wrote:
> Chris Angelico wrote:
> > On Mon, May 25, 2020 at 7:58 PM redrad...@gmail.com
> > wrote:
> > >
> > Edwin Zimmerman wrote:
> > Only if your workload is CPU bound. Python optimizes IO bound workload
> > performance by
> > releasing the GIL while doing IO. Green threads
Chris Angelico wrote:
> On Mon, May 25, 2020 at 7:58 PM redrad...@gmail.com
> wrote:
> >
> > Edwin Zimmerman wrote:
> > Only if your workload is CPU bound. Python optimizes IO bound workload
> > performance by
> > releasing the GIL while doing IO. Green threads generally do not offer
> > this op
Edwin Zimmerman wrote:
> On 5/25/2020 5:56 AM, redrad...@gmail.com wrote:
> > Edwin Zimmerman wrote:
> > Only if your workload is CPU bound. Python optimizes IO bound workload
> > performance by
> > releasing the GIL while doing IO. Green threads generally do not offer
> > this option.
> > Real
On 5/25/2020 5:56 AM, redrad...@gmail.com wrote:
>>> Edwin Zimmerman wrote:
> Only if your workload is CPU bound. Python optimizes IO bound workload
> performance by
> releasing the GIL while doing IO. Green threads generally do not offer this
> option.
>
> Real threads is not needed in Python:
On 24/05/2020 21:03, Dominik Vilsmeier wrote:
On 24.05.20 18:34, Alex Hall wrote:
OK, let's forget the colon. The point is just to have some kind of
'modifier' on the default value to say 'this is evaluated on each
function call', while still having something that looks like
`arg=`. Mayb
On Mon, May 25, 2020 at 7:58 PM wrote:
>
> >> Edwin Zimmerman wrote:
> Only if your workload is CPU bound. Python optimizes IO bound workload
> performance by
> releasing the GIL while doing IO. Green threads generally do not offer this
> option.
>
> Real threads is not needed in Python:
> 1) R
Hi all,
I do not know maybe it was already discussed ... but the toolchain like LLVM is
very mature and it can provide the simpler JIT compilation to machine code
functionality and it will improve performance of the Python a lot !!
___
Python-ideas mai
>> Edwin Zimmerman wrote:
Only if your workload is CPU bound. Python optimizes IO bound workload
performance by
releasing the GIL while doing IO. Green threads generally do not offer this
option.
Real threads is not needed in Python:
1) Real threads do not work parallel
2) Real threads only con
Kyle Stanley wrote:
> While I'm -1 on the original proposal, I think the idea of PurePath.__len__
> returning the number of components in the path may be worth some further
> consideration.
FYI PEP 428 says:
In this proposal, the path classes do not derive from a builtin type. This
contrast
On 25.05.2020 03:34, Cameron Simpson wrote:
> On 24May2020 13:46, M.-A. Lemburg wrote:
>> It would be surprising to have an object which implements .__len__(),
>> but otherwise doesn't allow any indexing, so -1 on such a change.
>
> set() ? I personally don't have a fundamental problem with somet
While I'm -1 on the original proposal, I think the idea of PurePath.__len__
returning the number of components in the path may be worth some further
consideration. Also, I'm not convinced that having indexing is a necessary
prerequisite to pursue it further.
On Sun, May 24, 2020 at 8:14 AM Steven
56 matches
Mail list logo