OK, If I might tell some story... :)
Main motivation was a use case where we gather command line options, and some
of them are… optional.
Below is a realistic example. Namely options for LLVM Clang:
>>> flags = [“-O3”, “-fomit-frame-pointer”, maybe_pgo(context)]
Here “maybe_pgo” returns either
On Tue, 14 Sept 2021 at 08:38, [email protected]
wrote:
> Main motivation was a use case where we gather command line options, and some
> of them are… optional.
[...]
> And yet I’m solid that we need some compact and nice way for rendering
> strings with command options. That would be a thin
On Tue, Sep 14, 2021 at 11:31:43AM +0400, [email protected] wrote:
> Thus I have collection of options and some of them are empty or None.
> In order to get rendered command line options string I use “compress”
> in conjunction with “join":
>
> >>> opts = " ".join(compress(flags, flags))
Wh
As pointed out, you want metaclass for this. A warning, I've overwritten many
of the dunders on classes for fun and I actually broke the ability to repr my
class in certain situations by overriding __eq__ and/or __hash__ something deep
in ipython/python with the repr. I forget the exact situatio
On Tue, Sep 14, 2021 at 11:30 PM wrote:
>
> I think I implemented __eq__ but not __hash__ and it broke the golden rule of
> x == y => x is y i,.e. hash(x) == hash(y)
>
Not sure what you're referring to there. The rule regarding hashes is
that if x == y, then hash(x) == hash(y). Identity doesn't
Hi all,
I was wondering on whether there is any interest in introducing a "plus-minus"
operator:
Conceptually very simple; instead of:
upper, lower = a + b, a - b
use instead:
upper, lower = a +- b
In recent projects I've been working on, I've been having to do the above "plu
I doubt it, it seems way too specialised to be worth making into a
language feature.
If you want to, you can write a function:
def limits(a, b):
return a+b, a-b
Paul
On Tue, 14 Sept 2021 at 14:55, wrote:
>
> Hi all,
>
> I was wondering on whether there is any interest in introducing a
> "
On Tue, Sep 14, 2021 at 11:58 PM wrote:
>
> Hi all,
>
> I was wondering on whether there is any interest in introducing a
> "plus-minus" operator:
>
> Conceptually very simple; instead of:
>
> upper, lower = a + b, a - b
>
> use instead:
>
> upper, lower = a +- b
>
> In recent pro
Hi Yahbai
You might wish to reconsider your proposal in light of existing behaviour
>>> 1+-1
0
Consider also your proposed
>>> a, b = 2 +- 1
We know that {a, b} = {1, 3}. But which is which?
In your use case you might be better off introducing a custom type
>>> lims = pm(2, 1)
>>> lims.lo, lims.
Add you can call this function plusminus
Then use the funcoperators module to write :
upper, lower = a +plusminus- b
pip install funcoperators
Le mar. 14 sept. 2021 à 16:02, Paul Moore a écrit :
> I doubt it, it seems way too specialised to be worth making into a
> language feature.
>
> If you
May I ask what you are actually doing with upper and lower after creating
them? Are you checking to see if another value is between? Something else?
If they are always being used together and you're doing the same things
with them all the time, it starts to smell like you might want to just
write a
> The signature is wrong.
Thanks for remark. Of course proper signature would be:
def jin(a: Iterable[Optional[str]], sep=“ “):
# …
> Why do you (ab)use compress for that?
Well, it seems that it is subjective. To me “[None, x, y, z]” -> “[x, y, z]”
looks like “compression”. But if community
On Wed, Sep 15, 2021 at 4:03 AM [email protected]
wrote:
>
> > The signature is wrong.
> Thanks for remark. Of course proper signature would be:
>
> def jin(a: Iterable[Optional[str]], sep=“ “):
> # …
>
> > Why do you (ab)use compress for that?
> Well, it seems that it is subjective. To me
[Chris Angelico ]
> ...
> For it to be accepted, you have to convince people - particularly,
> core devs - that it's of value. At the moment, I'm unconvinced, but on
> the other hand, all you're proposing is a default value for a
> currently-mandatory argument, so the bar isn't TOO high (it's not l
On Tue, 14 Sept 2021 at 19:58, Tim Peters wrote:
> Except it's not that simple:
Apologies, Tim, it took me a couple of reads to work out what you were
saying here. I hope you won't mind if I restate the point for the
benefit of anyone else who might have got confused it like I did...
> def
On Wed, Sep 15, 2021 at 4:58 AM Tim Peters wrote:
> Or perhaps the `compress()` implementation could grow internal
> conditionals to use a different algorithm if the second argument is
> omitted. But that would be a major change to support something that's
> already easily done in more than one mo
Hello all,
I sometimes write Python scripts which need to work in specific
work directories.
When putting such code into functions, the outer function typically
does not expect the current work dir (CWD) to be changed, so wrap the
code which need the (possibly) modified CWD using a simply context
On Tue, 14 Sept 2021 at 20:44, Marc-Andre Lemburg wrote:
>
> I sometimes write Python scripts which need to work in specific
> work directories.
>
> When putting such code into functions, the outer function typically
> does not expect the current work dir (CWD) to be changed, so wrap the
> code wh
On 14Sep2021 21:43, M.-A. Lemburg wrote:
>- The context manager is not thread safe. There's no thread safe model
> for the current work dir. OTOH, scripts usually don't use threads,
> so not a big deal.
This is the source of my concerns. Though of course it applies to any
process global state.
On Wed, Sep 15, 2021 at 7:43 AM Cameron Simpson wrote:
>
> On 14Sep2021 21:43, M.-A. Lemburg wrote:
> >- The context manager is not thread safe. There's no thread safe model
> > for the current work dir. OTOH, scripts usually don't use threads,
> > so not a big deal.
>
> This is the source of m
I think that this is a great idea. However, pipes only point to one
character, which can be confusing. (Citation: many tracebacks before 3.10.)
I'm wondering: Could failed assertions step you into `pdb`, if they are
used for testing purposes? Could there be a way to specify different levels
of ass
Here I think we need to drop our perfectionist attitude. When I saw
Marc-Andre's proposal my first response was also "but what about threads."
But really, os.chdir() is the culprit here, and since it's a syscall we
can't fix it. If we can live with that, we can live with the proposed
os.workdir().
If assertions have an associated block, then `pdb` can be invoked within. I
almost never use debuggers, so I don't remember, but I think a recent
Python version introduced the likes of `debug()` to step into the
pre-configured debugger.
About the "power assertions" proposal in this thread, once ev
On 15Sep2021 07:50, Chris Angelico wrote:
>On Wed, Sep 15, 2021 at 7:43 AM Cameron Simpson wrote:
>> I know I'm atypical, but I have quite a lot of multithreaded stuff,
>> including command line code. So while it'd be ok to avoid this context
>> manager for my own code, I fear library modules, ei
On 14Sep2021 15:16, Guido van Rossum wrote:
>Here I think we need to drop our perfectionist attitude. When I saw
>Marc-Andre's proposal my first response was also "but what about threads."
>But really, os.chdir() is the culprit here, and since it's a syscall we
>can't fix it. If we can live with t
On Wed, Sep 15, 2021 at 9:36 AM Cameron Simpson wrote:
>
> On 15Sep2021 07:50, Chris Angelico wrote:
> >On Wed, Sep 15, 2021 at 7:43 AM Cameron Simpson wrote:
> >> I know I'm atypical, but I have quite a lot of multithreaded stuff,
> >> including command line code. So while it'd be ok to avoid t
On Tue, Sep 14, 2021 at 4:36 PM Cameron Simpson wrote:
> On 15Sep2021 07:50, Chris Angelico wrote:
> >On Wed, Sep 15, 2021 at 7:43 AM Cameron Simpson wrote:
> >> I know I'm atypical, but I have quite a lot of multithreaded stuff,
> >> including command line code. So while it'd be ok to avoid th
On Tue, Sep 14, 2021, 5:36 PM Cameron Simpson wrote:
> On 15Sep2021 07:50, Chris Angelico wrote:
> >On Wed, Sep 15, 2021 at 7:43 AM Cameron Simpson wrote:
> >> I know I'm atypical, but I have quite a lot of multithreaded stuff,
> >> including command line code. So while it'd be ok to avoid this
BTW, should it be `WorkDir` instead of `workdir` because it's a class, or
would that be too inconsistent?
On Tue, Sep 14, 2021, 6:47 PM Finn Mason wrote:
>
> On Tue, Sep 14, 2021, 5:36 PM Cameron Simpson wrote:
>
>> On 15Sep2021 07:50, Chris Angelico wrote:
>> >On Wed, Sep 15, 2021 at 7:43 AM
For the stdlib context managers that I know of, all-lowercase seems the
convention. Would it even be a class? The simplest implementation would use
contextlib.contextmanager (unless that’s a undesirable dependency for
os.py).
—Guido
On Tue, Sep 14, 2021 at 17:53 Finn Mason wrote:
> BTW, should
I think this would be convenient.
And yes, it's not thread safe. But neither is os.chdir() to start with.
Someone whose script, or library, wants to chdir can already shoot
themselves in the foot. This makes that slightly less likely, not more.
In terms of the bikeshed color, I think putting this
When working with generators, AFAIK, there's currently no easy way to handle
the case of an empty generator (which can be useful if such case is an error).
Converting the generator to a, say, list, is not a solution if the generator is
intrinsically infinite.
I propose to have an "otherwise" cl
This should have been:
When working with generators in a for statement, AFAIK, there's currently no
easy way to handle the case of an empty generator (which can be useful if such
case is an error).
___
Python-ideas mailing list -- [email protected]
I find that when I run into a similar scenario the reason why I need the
iterable to be non-empty is because I'm trying to find something in it, and for
this the `else` clause works pretty well:
for item in get_items():
if check(item):
do_thing(item)
break
else:
raise Val
On Tue, Sep 14, 2021, 7:58 PM David Mertz, Ph.D.
wrote:
> I think this would be convenient.
>
> And yes, it's not thread safe. But neither is os.chdir() to start with.
> Someone whose script, or library, wants to chdir can already shoot
> themselves in the foot. This makes that slightly less like
On Tue, Sep 14, 2021, 11:17 PM Finn Mason wrote:
> I disagree. The way I see it, `pathlib` is home of *Path(). No functions.
> Just *Path(). Then again, I didn't write pathlib. I could be
> misunderstanding the intent.
>
When I wrote "in" I was thinking more of a method than a function. E.g.
wi
36 matches
Mail list logo
