[Python-ideas] PEP 505 -- None-aware operators

[Gustavo Carneiro]

Sorry if I missed the boat, but only just now saw this PEP.

Glancing through the PEP, I don't see mentioned anywhere the SQL
alternative of having a coalesce() function:
https://www.postgresql.org/docs/9.6/static/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL

In Python, something like this:

def coalesce(*args):
for arg in args:
if arg is not None:
 return arg
return None

Just drop it into builtins, and voila.   No need for lengthy discussions
about which operator to use because IMHO it needs no operator.

Sure, it's not as sexy as a fancy new operator, nor as headline grabbing,
but it is pretty useful.

Just my 2p.

-- 
Gustavo J. A. M. Carneiro
Gambit Research
"The universe is always one step beyond logic." -- Frank Herbert
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505 -- None-aware operators

[Gustavo Carneiro]

On 14 October 2016 at 14:19, אלעזר <elaz...@gmail.com> wrote:

> On Fri, Oct 14, 2016 at 4:14 PM Gustavo Carneiro <gjcarne...@gmail.com>
> wrote:
>
>> Sorry if I missed the boat, but only just now saw this PEP.
>>
>> Glancing through the PEP, I don't see mentioned anywhere the SQL
>> alternative of having a coalesce() function: https://www.
>> postgresql.org/docs/9.6/static/functions-conditional.
>> html#FUNCTIONS-COALESCE-NVL-IFNULL
>>
>> In Python, something like this:
>>
>> def coalesce(*args):
>> for arg in args:
>> if arg is not None:
>>  return arg
>> return None
>>
>> Just drop it into builtins, and voila.   No need for lengthy discussions
>> about which operator to use because IMHO it needs no operator.
>>
>> Sure, it's not as sexy as a fancy new operator, nor as headline grabbing,
>> but it is pretty useful.
>>
>>
> This has the downside of not being short-circuit - arguments to the
> function are evaluated eagerly.
>

I see.  short-circuiting is nice to have, sure.

But even without it, it's still useful IMHO.  If you are worried about not
evaluating an argument, then you can just do a normal if statement instead,
for the rare cases where this is important:

result = arg1
if result is None:
   result = compute_something()

At the very least I would suggest mentioning a simple coalesce() function
in the alternatives section of the PEP.

coalesce function:
  Pros:
1. Familiarity, similar to existing function in SQL;
2. No new operator required;
  Cons:
1. Doesn't short-circuit the expressions;
2. Slightly more verbose than an operator;


Thanks.

-- 
Gustavo J. A. M. Carneiro
Gambit Research
"The universe is always one step beyond logic." -- Frank Herbert
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Null coalescing operator

[Gustavo Carneiro]

On 28 October 2016 at 14:13, Barry Warsaw  wrote:

> On Oct 27, 2016, at 07:37 PM, Nick Badger wrote:
>
> >The problem with doing that is that it's ambiguous. There's no way of
> >telling which attribute is allowed to coalesce.
>
> You could of course support exactly the same syntax being proposed as a
> language change, e.g.
>
> from operator import attrgetter
> r = attrgetter('b?.x?.z')
>
> and then you wouldn't even need the `coalesce` argument.
>

The main drawback of this type of approach is that code checking tools will
hardly ever support checking expressions inside the string like that.
Also, you don't get proper syntax highlighting, code completion, etc.

You can do anything you want by writing another programming language that
is passed as string to a function, but that is not the same thing as having
a proper syntax, is it?  Just like type annotations with mypy: sure, you
can add type annotations in comments, but it's not the same...

-- 
Gustavo J. A. M. Carneiro
Gambit Research
"The universe is always one step beyond logic." -- Frank Herbert
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Null coalescing operator

[Gustavo Carneiro]

For what it's worth, I like the C# syntax with question marks.

It is probably more risky (breaks more code) to introduce a new keyword
than a new symbol as operator.

If we have to pick a symbol, it's less confusing if we pick something
another language already uses.  There is no shame in copying from other
languages.  Many of them copy ideas from Python as well ;-)

Thanks.


On 14 October 2016 at 17:10, Guido van Rossum  wrote:

> I actually think the spelling is the main stumbling block. The
> intrinsic value of the behavior is clear, it's finding an acceptable
> spelling that hold back the proposal.
>
> I propose that the next phase of the process should be to pick the
> best operator for each sub-proposal. Then we can decide which of the
> sub-proposals we actually want in the language, based on a combination
> of how important the functionality is and how acceptable we find the
> spelling.
>
> --Guido
>
> On Thu, Oct 13, 2016 at 8:20 PM, Mark E. Haase  wrote:
> > (Replying to multiple posts in this thread)
> >
> > Guido van Rossum:
> >>
> >> Another problem is PEP 505 -- it
> >> is full of discussion but its specification is unreadable due to the
> >> author's idea to defer the actual choice of operators and use a
> >> strange sequence of unicode characters instead.
> >
> >
> > Hi, I wrote PEP-505. I'm sorry that it's unreadable. The choice of emoji
> as
> > operators was supposed to be a blatant joke. I'd be happy to submit a new
> > version that is ASCII. Or make any other changes that would facilitate
> > making a decision on the PEP.
> >
> > As I recall, the thread concluded with Guido writing, "I'll have to think
> > about this," or something to that effect. I had hoped that the next step
> > could be a survey where we could gauge opinions on the various possible
> > spellings. I believe this was how PEP-308 was handled, and that was a
> very
> > similar proposal to this one.
> >
> > Most of the discussion on list was really centered around the fact that
> > nobody like the proposed ?? or .? spellings, and nobody could see around
> > that fact to consider whether the feature itself was intrinsically
> valuable.
> > (This is why the PEP doesn't commit to a syntax.) Also, as unfortunate
> side
> > effect of a miscommunication, about 95% of the posts on this PEP were
> > written _before_ I submitted a complete draft and so most of the
> > conversation was arguing about a straw man.
> >
> > David Mertz:
> >>
> >> The idea is that we can easily have both "regular" behavior and None
> >> coalescing just by wrapping any objects in a utility class... and
> WITHOUT
> >> adding ugly syntax.  I might have missed some corners where we would
> want
> >> behavior wrapped, but those shouldn't be that hard to add in principle.
> >
> >
> > The biggest problem with a wrapper in practice is that it has to be
> > unwrapped before it can be passed to any other code that doesn't know
> how to
> > handle it. E.g. if you want to JSON encode an object, you need to unwrap
> all
> > of the NullCoalesce objects because the json module wouldn't know what
> to do
> > with them. The process of wrapping and unwrapping makes the resulting
> code
> > more verbose than any existing syntax.
> >>
> >> How much of the time is a branch of the None check a single fallback
> value
> >> or attribute access versus how often a suite of statements within the
> >> not-None branch?
> >>
> >> I definitely check for None very often also. I'm curious what the
> >> breakdown is in code I work with.
> >
> > There's a script in the PEP-505 repo that can you help you identify code
> > that could be written with the proposed syntax. (It doesn't identify
> blocks
> > that would not be affected, so this doesn't completely answer your
> > question.)
> >
> > https://github.com/mehaase/pep-0505/blob/master/find-pep505.py
> >
> > The PEP also includes the results of running this script over the
> standard
> > library.
> >
> > On Sat, Sep 10, 2016 at 1:26 PM, Guido van Rossum 
> wrote:
> >>
> >> The way I recall it, we arrived at the perfect syntax (using ?) and
> >> semantics. The issue was purely strong hesitation about whether
> >> sprinkling ? all over your code is too ugly for Python, and in the end
> >> we couldn't get agreement on *that*. Another problem is PEP 505 -- it
> >> is full of discussion but its specification is unreadable due to the
> >> author's idea to defer the actual choice of operators and use a
> >> strange sequence of unicode characters instead.
> >>
> >> If someone wants to write a new, *short* PEP that defers to PEP 505
> >> for motivation etc. and just writes up the spec for the syntax and
> >> semantics we'll have a better starting point. IMO the key syntax is
> >> simply one for accessing attributes returning None instead of raising
> >> AttributeError, so that e.g. `foo?.bar?.baz` is roughly equivalent to
> >> `foo.bar.baz if (foo is not None and foo.bar is not None) 

Re: [Python-ideas] Inline assignments using "given" clauses

[Gustavo Carneiro]

On Thu, 10 May 2018 at 16:49, Ed Kellett  wrote:

> On 2018-05-10 16:10, Guido van Rossum wrote:
> > Please no, it's not that easy. I can easily generate a stream of +1s or
> -1s
> > for any proposal. I'd need well-reasoned explanations and it would have
> to
> > come from people who are willing to spend significant time writing it up
> > eloquently. Nick has tried his best and failed to convince me. So the bar
> > is high.
> >
> > (Also note that most of the examples that have been brought up lately
> were
> > meant to illustrate the behavior in esoteric corner cases while I was
> > working out the fine details of the semantics. Users should use this
> > feature sparingly and stay very far away of those corner cases -- but
> they
> > have to be specified in order to be able to implement this thing.)
>
> Poor prospects, then, but I'll do my best.
>
> I think the most obvious argument (to me) favouring `given` over `:=` is
> that it separates the two things it's doing:
>
> if m.group(2) given m = pattern.search(data):
>
> as opposed to the more-nested := version:
>
> if (m := pattern.search(data)).group(2):
>
> which, at least to me, is more complicated to think about because it
> feels like it's making the .group() something to do with the assignment.
>
> Put another way, I think your use of parentheses when discussing the
> *pronunciation* of this thing is telling. It feels as though one needs
> to start in the middle and then go in both directions at once, first
> explaining the origin (or destination) of the operand in question in a
> parenthesized offshoot, and then switching context and describing what
> is done to it. It's midly mentally taxing. I'm sure we can all live with
> that, but I don't want to: Python's exceptionally-readable syntax is one
> of the bigger reasons I choose it.
>
> There's a striking parallel in C, where the well-known idiom:
>
> while ((c = getchar()) != EOF) ...
>
> has an obviously-nicer alternative:
>
> while (c = getchar(), c != EOF) ...
>
> Most people I show this to agree that it's nicer, despite the fact that
> it manages to repeat a variable name *and* use the comma operator. I
> don't have proof, but I'd suggest that unwrapping that layer of context
> for the reader imparts a significant benefit.
>
> The C example also provides a convenient test: if you think the former
> example is nicer, I can just give up now ;)
>

IMHO, all these toy examples don't translate well to the real world because
they tend to use very short variable names while in real world [good
written code] tends to select longer more descriptive variable names.

Try replacing "c" with  a longer name, like input_command, then it becomes:

while ((input_command = getchar()) != EOF) ...

while (input_command = getchar(), input_command != EOF) ...

In the second example, having to type the variable name twice is an
annoyance that adds almost nothing to readability, so I would definitely
prefer the first one.

The "given" proposals have the same issue.

(a shame we can't use "as", for reasons already stated, it would have been
perfect otherwise)

-- 
Gustavo J. A. M. Carneiro
Gambit Research
"The universe is always one step beyond logic." -- Frank Herbert
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add function readbyte to asyncio.StreamReader

[Gustavo Carneiro]

Well, even if it is worth, i.e. your use case is not rare enough, I would
suggest at least making it private, readexactly can call this specialised
function if nbytes==1:

def _readbyte(self):
   

def readexactly(self, num):
   if num == 1:
  return self._readbyte()
  ... the rest stays the same..


But to be honest, you are probably better off managing the buffer yourself:
Just call, e.g., stream.read(4096), it will return a buffer of up to 4k
length, then you can iterate over the buffer byte by byte until the
condition is met, repeat until the end of stream, or whatever.


On Sun, 22 Jul 2018 at 12:11, Jörn Heissler 
wrote:

> Hello,
>
> I'm implementing a protocol where I need to read individual bytes until
> a condition is met (value & 0x80 == 0).
>
> My current approach is: value = (await reader.readexactly(1))[0]
>
> To speed this up, I propose that a new function is added to
> asyncio.StreamReader: value = await reader.readbyte()
>
> I duplicated readexactly and stripped out some parts. Below code appears
> to work:
>
> async def readbyte(self):
> if self._exception is not None:
> raise self._exception
>
> while not self._buffer:
> if self._eof:
> raise EOFError()
> await self._wait_for_data('readbyte')
>
> data = self._buffer[0]
> del self._buffer[0]
> self._maybe_resume_transport()
> return data
>
> For comparing the speed, I'm receiving a 50 MiB file byte-by-byte.
>
> cpython-3.7.0:
> readexactly: 42.43 seconds
> readbyte   : 22.05 seconds
> speedup: 92.4%
>
> pypy3-v6.0.0:
> readexactly: 3.21 seconds
> readbyte   : 2.76 seconds
> speedup: 16.3%
>
> Thanks
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Gustavo J. A. M. Carneiro
Gambit Research
"The universe is always one step beyond logic." -- Frank Herbert
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Executable space protection: NX bit,

[Gustavo Carneiro]

I'm not a security expert, but I believe the NX bit is a hardware
protection against a specific class of attack: buffer overflow attacks.

These attacks are possible because of the lack of safety in the C
programming language: it is very easy for a programmer to forget to check
the bounds of a receiving buffer, properly, and sometimes data copied from
the network receives machine code.  Or the stack is overwritten with the
return address pointing to some machine code previously injected.

Python is intrinsically a safer programming language and requires no such
hardware protection.

At most, a C library used by a Python extension can still have such bugs,
but then again the OS already sets the NX bit for data segments anyway, so
Python doesn't need to do anything.

On Mon, 3 Sep 2018 at 08:00, Wes Turner  wrote:

> Rationale
> =
> - Separation of executable code and non-executable data is a good thing.
> - Additional security in Python is a good idea.
> - Python should support things like the NX bit to separate code and
> non-executable data.
>
> Discussion
> ==
> How could Python implement support for the NX bit? (And/or additional
> modern security measures; as appropriate).
>
> What sort of an API would C extensions need?
>
> Would this be easier in PyPy or in CPython?
>
> - https://en.wikipedia.org/wiki/NX_bit
> - https://en.wikipedia.org/wiki/Executable_space_protection
>
> Here's one way to identify whether an executable supports NX:
> https://github.com/longld/peda/blob/e0eb0af4bcf3ee/peda.py#L2543
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Gustavo J. A. M. Carneiro
Gambit Research
"The universe is always one step beyond logic." -- Frank Herbert
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Why operators are useful

[Gustavo Carneiro]

On Sat, 16 Mar 2019 at 10:33, Steven D'Aprano  wrote:

> On Fri, Mar 15, 2019 at 10:53:31PM +, MRAB wrote:
>
> > There was also the suggestion of having both << and >>.
> >
> > Actually, now that dicts are ordered, that would provide a use-case,
> > because you would then be able to choose which values were overwritten
> > whilst maintaining the order of the dict on the LHS.
>
> Is that common enough that it needs to be built-in to dict itself?
>
> If it is uncommon, then the conventional solution is to subclass dict,
> overriding the merge operator to use first-seen semantics.
>
> The question this PEP is trying to answer is not "can we support every
> use-case imaginable for a merge operator?" but "can we support the most
> typical use-case?", which I believe is a version of:
>
> new = a.copy()
> new.update(b)
> # do something with new
>

Already been said, but might have been forgotten, but the new proposed
syntax:

new = a + b

has to compete with the already existing syntax:

new = {**a, **b}

The existing syntax is not exactly an operator in the mathematical sense
(or is it?...), but my intuition is that it already triggers the visual
processing part of the brain, similarly to operators.

The only argument for "a + b" in detriment of "{**a, **b}" is that "a + b"
is more easy to discover, while not many programmers are familiar with
"{**a, **b}".

I wonder if this is only a matter of time, and over time programmers will
become more accustomed to "{**a, **b}", thereby reducing the relative
benefit of  "a + b"?  Especially as more and more developers migrate code
bases from Python 2 to Python 3...

-- 
Gustavo J. A. M. Carneiro
Gambit Research
"The universe is always one step beyond logic." -- Frank Herbert
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add «iterate non-blocking» wrapper to prevent blocking loop too long

[Gustavo Carneiro]

On Fri, 14 Jun 2019 at 12:00, Nikita Melentev 
wrote:

> > The problem is that the snippet itself is not very helpful.
>
> Explain please.
>
> The good thing is that, if this snippet will be somewhere (asyncio or
> docs), then user will not decide by its own about "what is a long running
> task", because good default value will be there. This also reduce time to
> fix such cases, sometimes when you write code you don't expect huge data in
> your loops, but if your case allows to "interrupt" your loop by context
> switch, then you can just use wrapper and forget about this.
>

The problem is that there is no good universal default for when to yield.
Yielding too frequently will make the program run slower, yielding too
infrequently will cause latency in coroutine switching (the program you try
to solve).

The problem gets more complicated with nested loops.  Do you yield in all
loop nested levels?  If not, only the outer one, only the inner one?

That said, your code snippet is a nice tool to have in the toolbox.  I've
written something similar but not as complete: my version just yielded
after N iterations, your version also allows yielding after X seconds,
which is nice.

I almost wish such functionality could be built into Python.  But I'm not
sure it can be done without performance penalty.


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


-- 
Gustavo J. A. M. Carneiro
Gambit Research
"The universe is always one step beyond logic." -- Frank Herbert
___
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/E6UFX2KN4RGFA4WUKF2Q4UAGSQMHOYEN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add «iterate non-blocking» wrapper to prevent blocking loop too long

[Gustavo Carneiro]

On Sat, 15 Jun 2019 at 00:26, Greg Ewing 
wrote:

> Gustavo Carneiro wrote:
> > 1. If you don't yield in the for loop body, then you are blocking the
> > main loop for 1 second;
> >
> > 2. If you yield in every iteration, you solved the task switch latency
> > problem, but you make the entire program run much slower.
>
> It sounds to me like asyncio is the wrong tool for this job. You
> want a background task that can be preempted by a foreground task.
> That's what threads are for. Asyncio gives you non-preemptive
> task scheduling.
>

Perhaps.  But using threads is more complicated.  You have to worry about
the integrity of your data in the face of concurrent threads.  And if
inside your task you sometimes need to call async coroutine code, again you
need to be extra careful, you can't just call coroutines from threads
directly.

But I think you do have a point.  If a developer starts reaching for `await
asyncio.sleep(0)` too often, perhaps it is time to start considering
running that code in the default thread pool executor, whatever the cost
may be.


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


-- 
Gustavo J. A. M. Carneiro
Gambit Research
"The universe is always one step beyond logic." -- Frank Herbert
___
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/ALN3KUJFODLKP7HZ3SZ3QOOMVT56UC6G/
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Break multiple loop levels

[Gustavo Carneiro]

On Sun, 12 May 2019 at 18:26, David Mertz  wrote:

> To be clear in this thread, I don't think I'm really ADVOCATING for a
> multi-level break.  My comments are simply noting that I personally fairly
> often encounter the situation where they would be useful.  At the same
> time, I worry about Python gaining sometimes-useful features that
> complicate the overall language and bring it closer to Perl's "everyone can
> write in their own style."
>
> So to answer Chris' question... well, i did find something recent, but it
> has a ton of other extraneous stuff.  But I've simplified to something that
> isn't that much different from my example from my tablet yesterday, but is
> fairly realistic still.
>
> I have an existing function that looks roughly like this:
>
> def find_needle_in_haystacks():
> found_needle = False
> for haystack in glob.glob('path/to/stuff/*'):
> fh = open(fname)
> header = fh.readline()
> if get_format(header) == 'foo':
> for line in fh:
> status = process_foo(line)
> if status = -1:
> found_needle = True
> break
> elif get_format(header) == 'bar':
> for line in fh:
> status = process_bar(line)
> if status = -1:
> found_needle = True
> break
>
> if found_needle:
> break
>
> If I had a "labelled break" feature, I might rewrite it something like the
> following (picking convenient syntax that I'm not per-se advocating as
> best, even if the concept is adopted):
>
> # Hypothetical future labelled break:
> def find_needle_in_haystacks():
> for haystack in glob.glob('path/to/stuff/*') label HAYSTACKS:
> fh = open(fname)
> header = fh.readline()
> if get_format(header) == 'foo':
> for line in fh:
> if process_foo(line) == -1:
> break HAYSTACKS
> elif get_format(header) == 'bar':
> for line in fh:
> if process_bar(line) == -1:
> break HAYSTACKS
>
>
Nice.  Suggestion:
1. replace "label HAYSTACKS" with "as HAYSTACKS", if possible, so no new
keyword is introduced;
2. replace "break HAYSTACKS" with "break from HAYSTACKS"



> In any case, it's often possible to either (a) redefine the inner loop
>>> as some sort of container operation, or (b) redefine the outer
>>> operation as a function, and use "return". So it would be helpful to
>>> have an example that CAN'T be rewritten in one of those ways, to use
>>> as a compelling example.
>>>
>>
> --
> Keeping medicines from the bloodstreams of the sick; food
> from the bellies of the hungry; books from the hands of the
> uneducated; technology from the underdeveloped; and putting
> advocates of freedom in prisons.  Intellectual property is
> to the 21st century what the slave trade was to the 16th.
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Gustavo J. A. M. Carneiro
Gambit Research
"The universe is always one step beyond logic." -- Frank Herbert
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Inspired by Scala, a new syntax for Union type

[Gustavo Carneiro]

I think the "foo | bar" syntax for Union is pretty clear, I like it!

The ~foo for Optional is... not that obvious.  Not sure it's a win.


On Thu, 29 Aug 2019 at 13:49, Philippe Prados 
wrote:

> Hello everybody,
>
> Scala 3 propose the a new syntax for Union type. See here
> . I
> propose to add a similar syntax in Python.
>
> # Operator for Union
> assert( int | str == Union[int,str])
> assert( int | str | float == Union[int,str,float])
> # Operator for Optional
> assert( ~int == Optional[int])
>
> Now, it's possible to write:
>
> def fn(bag:List[int | str], option: ~int = None) -> float | str: ...
>
> in place of
>
> def fn(bag:List[Option[int,str]], option: Optional[int] = None) ->
> Union[float,str]: ...
>
> I think these syntaxes are more clear, and can help with the adoption of
> typing.
>
>
> I test and implement these ideas in a two fork : One for CPython
>  and one for MyPy
> . See the branches add_OR_to_types (for
> Union syntax) or add_INVERT_to_types (for Union and Optional syntax).
>
> How I implement that ? I add the operators __or__ and __revert__ to
> PyType_Type. The C code is similar of :
>
> from typing import *
> def type_or(self,right):
>   return Union[self,right]
> type(type).__or__ = type_or
>
> Actually, the accepted syntax for typing is :
>
> annotation: name_type
> name_type: NAME (args)?
> args: '[' paramslist ']'
> paramslist: annotation (',' annotation)* [',']
>
> I propose to extend the syntax to :
>
> annotation: ( name_type | or_type | invert_type )
> name_type: NAME (args)?
> args: '[' paramslist ']'
> paramslist: annotation (',' annotation)* [',']
>
> or_type: name_type '|' annotation
>
> invert_type: '~' annotation
>
>
> What do you think about that ?
>
> The draft of a PEP is here
> .
>
> 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/FCTXGDT2NNKRJQ6CDEPWUXHVG2AAQZZY/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Gustavo J. A. M. Carneiro
Gambit Research
"The universe is always one step beyond logic." -- Frank Herbert
___
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/P7MFY6L6EJRVIVICXGJCGCKEDVPYCGZF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Inspired by Scala, a new syntax for Union type

[Gustavo Carneiro]

On Thu, 29 Aug 2019 at 14:58, Ricky Teachey  wrote:

> I like this idea.
>
>
>> The ~foo for Optional is... not that obvious.  Not sure it's a win.
>>
>>
>  I agree. Seems like `foo | None` is just as readable. Assuming that None
> would be swapped out for NoneType, of course.
>

Agreed, `foo | None` is short and readable.  There really is no need for
special syntax for Optional.

-- 
Gustavo J. A. M. Carneiro
Gambit Research
"The universe is always one step beyond logic." -- Frank Herbert
___
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/VPDDUPNULDVXMKSR5KSAH53Q6HNUUBMC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Simpler syntax for async generators

[Gustavo Carneiro]

On Sat, 14 Sep 2019 at 16:26, George Fischhof  wrote:

> Hi All,
>
> While I was reading the documentation of asyn generators,
> which shows the following example:
>
>
> async def ticker(delay, to):
> """Yield numbers from 0 to *to* every *delay* seconds."""
> for i in range(to):
> yield i
> await asyncio.sleep(delay)
>
>
>
> It's came to my mind that it could could be simpler.
>
> We could use just
> async yield
>
> and all the other stuff could be done in the background.
>
> Like if we use the yield in function, that function becomes a generator
>
> example:
>
> def my_async_generator():
> for i in range(5):
>
> async yield  i
>
>
> What do you think about this? Would this be feasible?
>
> It doesn't appear to be any simpler.  You just moved async from one
place to another.

Therefore, change just for change sake, is pointless.  In fact, more harm
than pointless.

-1

>
>
> BR,
>
> __george__
>
>
> ___
> 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/SRWW6U3N3SHNJFLMTX3A4ZRFQGUNKQR6/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Gustavo J. A. M. Carneiro
Gambit Research
"The universe is always one step beyond logic." -- Frank Herbert
___
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/CJLL6OYTRQX5B5HX5LBGJ4JTTMXVICTA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Gustavo Carneiro]

On Wed, 17 Feb 2021 at 18:30, Ethan Furman  wrote:

> On 2/17/21 8:47 AM, Random832 wrote:
> > On Tue, Feb 16, 2021, at 23:24, Stephen J. Turnbull wrote:
>
> >> except a couple of characters.  So what currently looks like
> >>
> >>  some_list.sort(key=lambda e: e[3].priority)
> >>
> >> would then be
> >>
> >>  some_list.sort(key=(e)->e[3].priority)
> >
> > Let's not pretend the key argument being keyword-only isn't a wart.
> Surely this would be better if it could be some_list.sort(e->e[3].priority).
>
> No need to pretend, it isn't a wart.
>
> -1 on removing the lambda keyword.  Just because excessive punctuation
> works for other languages does not mean it's a good fit for Python.
>

Just my 2c, I don't find lambda verbose at all, quite like it.

But I wish Python allowed for multi-line lambda functions... somehow.

Why? If you need to have a callback function that takes 2 to 5 lines of
code, then
   (1) current lambda doesn't allow it,
   (2) inline named function, defined earlier, is too verbose IMHO (code
style dictates it needs two blank lines, one before, one after, plus need
to have a name),
 and also somewhat breaks the flow of reading code.

A multi-line lambda would be able to fill the gap, between too big for
single line lambda, but too small to justify its own def xxx().

Sorry, I don't have any concrete proposal, just a vague wish.
___
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/PSWFL5AQLWAQSDJA2M2IMZBUPQGCL5NB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Proposal: Python Native bindings for OpenAPI

[Gustavo Carneiro]

You may want to take a look at FastAPI[1], it already does more or less
what you ask for.

There is no need for it to be part of the Python core, it's fine as it is
as a package.

[1] https://fastapi.tiangolo.com/

On Fri, 6 Aug 2021 at 17:39, Vaideeswaran Ganesan  wrote:

> OpenAPI (https://spec.openapis.org/oas/latest.html) is an emerging
> standard for defining RESTful interfaces.
> OpenAPI is supported by swagger - which provides tools to convert an
> OpenAPI spec into python code (for both backend as well as client).
>
> The proposition I have is to make OpenAPI native to python.  Essentially,
> this involves some of the following:
> 1. OpenAPI provides definitions of objects, arrays, structures, primitive
> types, collections etc.
> 2. OpenAPI supports object creation (HTTPS POST), object modification
> (PUT), object deletion (DELETE) and object retrieval (GET).
> 3. OpenAPI also supports operations for collections (add to collection,
> remove from collection and modify collection)
> 4. OpenAPI also supports methods and allows parameters to be passed to
> these APIs.
>
> The Native Python implementation would load in OpenAPI specification and
> provide native Python experience as follows:
> 1. Primitive types are mapped to python primitive types
> 2. Objects and structures are treated as classes or dicts wrapped.  The
> field names in the Spec are accessible.
> 3. Arrays and Collections are mapped to python lists.
> 4. URLs are converted into object structure.
> 5.  Python inspection methods (__getattr__, __setattr__, __new__, __del__
> and others) of this model is changed to manipulate the fetched objects
> dynamically
>
> Parts of this implementations are found in various places : sushy
> (OpenStack) etc.
> However, having a more organized approach would make life easier.
>
> Swagger has a tool that can generate the code.  But this means that every
> time a specification changes you need to ship a new python library.
> The methodology presented not require any addition python libraries - the
> tool can download from the REST end point.
>
> By making OpenAPI native to python, we would avoid cumbersome handling of
> request codes etc. and make it as you we are accessing native objects.
> I can provide more details and a reference implementation I am working on.
>
> Wanted to know if this is worthy to be submitted as PEP!
> ___
> 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/5DBYKAEXM2Z3UQZGORXMBQTBN22RQPLT/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Gustavo J. A. M. Carneiro
Gambit Research
"The universe is always one step beyond logic." -- Frank Herbert
___
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/HFUX7E7DEF6M4VHQOUYYVIKKHUGK7HD5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add timeout parameter to Synchronization Primitives in asyncio

[Gustavo Carneiro]

Note that you can wrap any of those methods with an asyncio.wait_for().

try:
   try:
   await asyncio.wait_for(lock.acquire(), 1.0)
   except asyncio.TimeoutError:  # times out after 1 second
   print("deadlock!")
   return
   do_things_with_lock()
finally:
   lock.release()


Although I must admit, it would be convenient to have a timeout parameter
directly in the methods like acquire, especially because it would make
timeouts usable directly in the async context manager:

async with lock.acquire(timeout=1.0):
   do_things_with_lock()


On Mon, 20 Sept 2021 at 07:21, Andres Torres 
wrote:

> It would be very nice if the [Synchronization Primitives](
> https://docs.python.org/3/library/asyncio-sync.html) had a timeout
> parameter just like the [analogous classes](
> https://docs.python.org/3/library/threading.html#condition-objects) do in
> the threading module.
>
> Thank you for your consideration!
> ___
> 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/6CNWNDZHRVETDH5EFIRMWD42FGD6TTCP/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Gustavo J. A. M. Carneiro
Gambit Research
"The universe is always one step beyond logic." -- Frank Herbert
___
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/XGJSHB7KW6H4WYFDE73S5HOJC6KPYGVF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add timeout parameter to Synchronization Primitives in asyncio

[Gustavo Carneiro]

On Mon, 20 Sept 2021 at 13:15, Chris Angelico  wrote:

> On Mon, Sep 20, 2021 at 9:48 PM Gustavo Carneiro 
> wrote:
> >
> > Note that you can wrap any of those methods with an asyncio.wait_for().
> >
> > try:
> >try:
> >await asyncio.wait_for(lock.acquire(), 1.0)
> >except asyncio.TimeoutError:  # times out after 1 second
> >print("deadlock!")
> >return
> >do_things_with_lock()
> > finally:
> >lock.release()
> >
> >
> > Although I must admit, it would be convenient to have a timeout
> parameter directly in the methods like acquire, especially because it would
> make timeouts usable directly in the async context manager:
> >
> > async with lock.acquire(timeout=1.0):
> >do_things_with_lock()
> >
>
> How would this signal a timeout to your code? It looks lovely and
> clean, but there still need to be two branches, so you're not really
> going to avoid the try/except layer.
>

Right.  If you needed to handle the timeout, you would need a try except.
Else the TimeoutError exception that gets raised is unhandled and bubbles
up.

try:
async with lock.acquire(timeout=1.0):
do_things_with_lock()
except asyncio.TimeoutError:
print("deadlock!")
return

I mean, this is just slightly more convenient, probably slightly less scary
for some people, but that's all.

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


-- 
Gustavo J. A. M. Carneiro
Gambit Research
"The universe is always one step beyond logic." -- Frank Herbert
___
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/EIOECL4WGOA37SEXLBXYECZRQFIT7NQ7/
Code of Conduct: http://python.org/psf/codeofconduct/