[Python-ideas] Re: Adding PathLiteral class and existing object instance to pathlib

[mwmajewsk]

You are right, it would not, I incorrectly assumed that since 
Path() actually evaluates to PosixPath('.') then Path()/'tmp' evaluates to 
PosixPath('./tmp') but it does not.
___
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/HYGRZF366TNYRACTJEKALKIQA6J7W7B2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding PathLiteral class and existing object instance to pathlib

[Christopher Barker]

On Mon, Feb 15, 2021 at 5:21 PM Paul Bryan  wrote:

> I wonder how that is substantially different than:
>


> or perhaps more verbosely, but arguably more readable:
>
> from pathlib import Path
>
> Path() / "foo"
>
> or

from pathlib import Path
Path("foo")

I guess I don't find the proposal or variation worth it to me -- though I
guess it's easier when you are translating code that uses string paths
already -- but not much easier.

-CHB

-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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/QY72VXTDW7CIEBPYN6HO6EBNR7XFA72U/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Conditional with statements

[Christopher Barker]

Still OT ...

> But I do think you need to consider not just your editor -- if anyone else
> is going to read your code.
>
> They're not (in any universe I can imagine).
>

Exactly -- the most important thing about style is that it be consistent
within a project's development team -- if that's just you, then you're all
set.

> you also have other checks in there, so those would have to be moved into
> the functions in the dict, maybe with wrappers (or not -- depends on where
> you store some of that state data.
>
> Exactly.  Some wasted effort to turn a simple, contiguous, transparent
> chunk of code into something more complicated, spread out and harder to
> understand.
>

As i said -- depends on the rest of your code. It could make it less spread
out and easier to understand :-)

For the most part using a dict to switch makes the most sense if the same
pattern will be used with multiple "switch dicts".


> Again, turning simple straightforward into more complicated code.  (I'm
> quite capable of writing tricks like that *when I think they're
> appropriate*; I've done it many times.)
>

I'm not sure I'd call it "tricks" -- but anyway, I've found that big nested
ifelses are rarely the cleanest solution -- but not never.

- Chris B.

-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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/X3CATFE42OMTYZU63XWYVB2SPGNSAW7A/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding PathLiteral class and existing object instance to pathlib

[Paul Bryan]

I wonder how that is substantially different than:

from pathlib import Path as p
p() / "foo"

or perhaps more verbosely, but arguably more readable:

from pathlib import Path
Path() / "foo"

Paul


On Tue, 2021-02-16 at 01:07 +, mwmajewsk wrote:
> P.S. the code snippet I mentioned is not rendering with mailman
> archives, here it is again;
> 
> from pathlib import path_literal as p
> p/"foo"
> 
> the result is:
> PosixPath('foo')
> ___
> 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/ARV4RO2YVDWGT4JQLPYJIIDYCYILLKQY/
> 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/BAFAGNN3PNHR6BK37XHWBCMSZPHL6NZX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding PathLiteral class and existing object instance to pathlib

[mwmajewsk]

P.S. the code snippet I mentioned is not rendering with mailman archives, here 
it is again;

from pathlib import path_literal as p
p/"foo"

the result is:
PosixPath('foo')
___
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/ARV4RO2YVDWGT4JQLPYJIIDYCYILLKQY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Arrow functions polyfill

[Rob Cliffe via Python-ideas]

On 15/02/2021 16:32, David Mertz wrote:
On Mon, Feb 15, 2021 at 4:19 PM Guido van Rossum > wrote:


Okay, here’s my dilemma. It looks like this thread wants to devise
a new syntax for lambda, using e.g. (x, y) -> x+y, or the same
with =>. That’s great, but doesn’t open new vistas. OTOH, for
people using type annotations, a much more pressing issue is an
alternative for typing.Callable that is more readable, and
supports extra features that Callable doesn’t, like keyword args,
varargs, and pos-only.


FWIW, I *do not* want an alternate spelling for lambda.

+1



If your time machine were still working, and you could go back to 1991 
to change the spelling, yes I might like that. For that matter, if 
someone had a good spelling for multi-line lambdas, I might like 
that.  Or *maybe* some other difference in behavior, but nothing comes 
immediately to mind.

+1


But allowing a few cryptic punctuation symbols to express an anonymous 
function while still retaining "the name of a cryptic greek letter" to 
do exactly the same thing seems like a strong non-goal.

+1.


That said, if I had to look at one, I'd like '->' much better than '=>'.

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

[Python-ideas] Adding PathLiteral class and existing object instance to pathlib

[mwmajewsk]

Hi All,

The pathlib library is really helpful when working with paths, but creating an 
instance of Path class could be easier.

There was a discussion about solving this with p-strings here 
https://mail.python.org/archives/list/python-ideas@python.org/thread/MNKRQF3ZM77A224EO5OZLLAUFGB5MTVA/#OH4ANXJTTTKONQ4FRWDTEW2FEZVSKLZV
But that would alter python syntax.
Easier, but just as nice solution could be adding the following snippet to 
pathlib:

class PathLiteral(): 
  def __truediv__(self, other): 
return Path(other)
path_literal = PathLiteral()   

This would allow 
the following snippet to work:

>>> from pathlib import path_literal as p
>>> p/"foo"
PosixPath('foo')

This idea is inspired by this tweet 
https://twitter.com/bitecode_dev/status/1217429169396731906

The core of the idea is that it does not require syntax changes, only need a 
small instance of an object, that can simplify and encourage use of pathlib.
When someone needs to rewrite a lots of string-paths to pathlib's Path you only 
need to add that import line, and prepend strings with "p/".

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

[Python-ideas] Re: Arrow functions polyfill

[Greg Ewing]

On 16/02/21 6:29 am, Guido van Rossum wrote:
I can sympathize with trying to get a replacement for lambda, because 
many other languages have jumped on the arrow bandwagon, and few Python 
first-time programmers have enough of a CS background to recognize the 
significance of the word lambda.


I think there's also just a desire for brevity. In the situations
where it's appropriate to use a lambda, you want something very
compact, and "lambda" is a rather long and unwieldy thing to have
stuck in there.

Another thing that comes to mind is that the way Python uses
"lambda" is somewhat arbitrary. In Lisp, the first programming
language where it was used, it's the *fundamental* way of
creating a function. All the other function-defining constructs
are macros that expand into something containing a lambda.
But Python uses it *only* for in-line anonymous functions, so
it feels sort of tacked on.

I'm not arguing for or against anything here, just exploring
possible reasons why the idea of lambda-replacement comes up
so often.

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

[Python-ideas] Re: Alternate lambda syntax

[Mike Miller]

On 2021-02-13 14:33, Christopher Barker wrote:
On Fri, Feb 12, 2021 at 1:00 AM Brendan Barnwell > wrote:

         The only thing that would be better than lambda is a less confusing
keyword. 

There seems to be a frequent objection to the word "lambda" -- personally, I 
found it cryptic, but it's not hard to remember, and it IS easy to look up. But 
if you don't like that word, why not "def"? Every place I've tried to use "def" 
where "lambda" is legal, it's a syntax error. So we could use the same word. 
Would that be less confusing?



Agreed.  It isn't too important at this point, but I'd also skip the punctuation 
and add an expression version of def:



def named_function(x, y):
return x * y

anonymous_function = def x, y: x * y


Parentheses on the parameter list could be allowed as well.

Javascript has (too much) flexibility in this area, but I wouldn't mind Python 
loosening slightly to use the keyword it probably should have in the beginning.


-Mike

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

[Python-ideas] Re: Arrow functions polyfill

[Abdulla Al Kathiri]

> On 15 Feb 2021, at 9:48 PM, Ricky Teachey  wrote:
> 
> hypotenuse(x,y): (x**2+y**2)**0.5

Can I use a named function (proposed here) as an argument to a function?
e.g., 

def example(func, x, y):
return func(x, y)

example(hypotenuse(x,y): (x**2+y**2)**0.5, 3, 4) 
Or should it be an anonymous function like this?
example((x,y): (x**2+y**2)**0.5, 3, 4)

Maybe with named function, it would be something like this? 
hypotenuse(x,y): (x**2+y**2)**0.5
example(hypotenuse, 3, 4) 

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

[Python-ideas] Re: Arrow functions polyfill

[Paul Sokolovsky]

Hello,

On Mon, 15 Feb 2021 13:00:50 -0500
Ricky Teachey  wrote:

> On Mon, Feb 15, 2021 at 12:55 PM David Mertz  wrote:
> 
> > On Mon, Feb 15, 2021, 12:26 PM Ricky Teachey
> >  
> >> f(x,y)=>x,y->str
> >>>  
> >>  
> > I read this as "my cat walked across my keyboard, and I'm very
> > proud she wants to be a programmer."
> >  
> 
> Our cat died last fall so if that's what happened, I should be pretty
> spooked right now!

Apparently, desire to be a *functional* programmer and write
functions in short notation prevails. 

> 
> ---
> Ricky.


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

[Python-ideas] Re: Arrow functions polyfill

[Ricky Teachey]

On Mon, Feb 15, 2021 at 12:55 PM David Mertz  wrote:

> On Mon, Feb 15, 2021, 12:26 PM Ricky Teachey
>
>> f(x,y)=>x,y->str
>>>
>>
> I read this as "my cat walked across my keyboard, and I'm very proud she
> wants to be a programmer."
>

Our cat died last fall so if that's what happened, I should be pretty
spooked right now!

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/JG2RRJSSKPFKGMF2X525T2VJJMBX7JDI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Arrow functions polyfill

[David Mertz]

On Mon, Feb 15, 2021, 12:26 PM Ricky Teachey

> f(x,y)=>x,y->str
>>
>
I read this as "my cat walked across my keyboard, and I'm very proud she
wants to be a programmer."

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

[Python-ideas] Re: Arrow functions polyfill

[Ricky Teachey]

On Mon, Feb 15, 2021 at 12:30 PM Guido van Rossum  wrote:

> On Mon, Feb 15, 2021 at 9:02 AM Ricky Teachey  wrote:
>
>> [...]
>> But if we could expand the  proposal to allow both anonymous and named
>> functions, that would seem like a fantastic idea to me.
>>
>> Anonymous function syntax:
>>
>> (x,y)->x+y
>>
>> Named function syntax:
>>
>> f(x,y)->x+y
>>
>
> Proposals like this always baffle me. Python already has both anonymous
> and named functions. They are spelled with 'lambda' and 'def',
> respectively. What good would it do us to create an alternate spelling for
> 'def'?
>

Thanks for responding. I don't want to derail this discussion especially
since I've brought it up in the last several months and didn't get anywhere
on it.

To answer the question though: I think it would really open up python to a
whole group of people are find the idea of "programming" too intimidating
but could benefit from it immensely. This could happen if writing a
function was made more similar to what they already KNOW how to write
(handwritten math).

A common thing I hear from colleagues is "I'm not a developer, I'm not a
programmer, I'm an engineer", and seeing this just intimidates people:

lambda x,y: (x**2+y**2)**0.5

def  hypotenuse(x,y):
(x**2+y**2)**0.5

Allowing short one-line functions to be spelled something like this would
be more friendly because it looks so familiar, nearly identical to a
handwritten mathematical equation:

hypotenuse(x,y) => (x**2+y**2)**0.5

Anyway I've offered up this desire to this list before and for the most
part people haven't been very receptive, so I won't belabor it. But I
thought I'd bring it up again in this context since this:

f(x,y) => x+y

...and this:

(x,y) => x+y

...would be SO CLOSE to each other.

You could also write this, I suppose:

hypotenuse = (x,y) => (x**2+y**2)**0.5

But that isn't any better for the casually programming engineer than lambda
or def, to be honest.

On Mon, Feb 15, 2021 at 12:40 PM Jonathan Goble  wrote:

> On Mon, Feb 15, 2021 at 12:29 PM Ricky Teachey  wrote:
>
>> f(x,y)=>x+y->str
>>
>
> I can't -1 this enough. How do I read this?
>
> Imagine you have never seen this discussion and you come across this code
> in the wild. You are familiar with type hints, including return type
> annotations, but aren't familiar with this syntax. From that perspective,
> what does this code mean?
>
> ...
>
> My preferred spelling of the above (with the addition of sample parameter
> type hints) would be:
>
> f(x: int, y: int) -> str: x, y
>
> ...
>
> Even with that spelling, I'm -0.5 on the named function version (for the
> reasons described by Guido), and only +0.5 on the anonymous version
> (because I'm not convinced that it's needed).
>

I see your point and I would be fine with that spelling. With no type hints
it would look like:

hypotenuse(x,y): (x**2+y**2)**0.5

That would seem fine to me.

Anyway as I said above, I know this is an uphill battle. I'll leave it
alone unless other people come out liking the anonymous and non-anonymous
function syntax idea.

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/UGBETLVFKZKYXKN3OP75A2ECEYI6Y6HP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Arrow functions polyfill

[Jonathan Goble]

On Mon, Feb 15, 2021 at 12:29 PM Ricky Teachey  wrote:

> f(x,y)=>x+y->str
>

I can't -1 this enough. How do I read this?

Imagine you have never seen this discussion and you come across this code
in the wild. You are familiar with type hints, including return type
annotations, but aren't familiar with this syntax. From that perspective,
what does this code mean?

1) Define a function that returns x plus an instance of
typing.Callable[[y], str] (assuming that the discussed Callable shorthand
has been adopted)
2) Define a function that returns the sum of x and y, but with the return
type annotated as a str
3) Call the function f with arguments x and y, and attempt to compare the
return value to... something (except the user made a typo and you'll
actually get a syntax error)
4) Absolutely nothing and it's just random electronic scribbling by the
author that won't compile and they forgot to comment out (yes, that's
always an option)

Frankly, it's not obvious to me. Some mental gymnastics might eventually
land me at 2), but now my head hurts.

My preferred spelling of the above (with the addition of sample parameter
type hints) would be:

f(x: int, y: int) -> str: x, y

(No, the type hints don't make sense. They're just an example of syntax.)

Benefits over your proposal:
1) No ugly => that looks like a greater-or-equal operator if you haven't
had your morning coffee
2) Looks a lot more like existing syntax (the smaller the delta between old
and new, the easier it is to learn and adopt the new). In fact, it
basically IS existing syntax, except for the lack of a "def" in front and
an explicit "return" keyword (seriously, insert those two keywords and it
compiles already).
3) Works just as well with anonymous functions: `(x: int, y: int) -> str:
x, y` is clear and and easy to deduce the meaning of to anyone familiar
with basic Python syntax
4) Much more Pythonic than the => syntax -- because it already looks like
Python code.

Even with that spelling, I'm -0.5 on the named function version (for the
reasons described by Guido), and only +0.5 on the anonymous version
(because I'm not convinced that it's needed).
___
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/T7QSWRCP6VRC5NA3CNJPXS7QJRIXFYRN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Arrow functions polyfill

[Guido van Rossum]

On Mon, Feb 15, 2021 at 9:02 AM Ricky Teachey  wrote:

> [...]
> But if we could expand the  proposal to allow both anonymous and named
> functions, that would seem like a fantastic idea to me.
>
> Anonymous function syntax:
>
> (x,y)->x+y
>
> Named function syntax:
>
> f(x,y)->x+y
>

Proposals like this always baffle me. Python already has both anonymous and
named functions. They are spelled with 'lambda' and 'def', respectively.
What good would it do us to create an alternate spelling for 'def'?

I know that in JavaScript there are different ways to define functions
('function' and '=>'), and they have subtly different semantics. (For
example, regarding 'this'. Such an incredible mess!) We don't need
different semantics in Python.

I can sympathize with trying to get a replacement for lambda, because many
other languages have jumped on the arrow bandwagon, and few Python
first-time programmers have enough of a CS background to recognize the
significance of the word lambda. But named functions? Why??


> But since Guido wants to save the right shaft operator for type hinting,
> and named functions do need a way to write type hints, maybe the best thing
> to do is use an equal sign shaft for the function definition and the right
> shaft for the type hint:
>
> f(x,y)=>x,y->str
>
> >>> f('a','b')
> 'ab'
> >>> f(1,2)  # type hint error
>

Another thing. Type hints are not interpreted at runtime, and I don't
expect this to change in the near to middle future.

Plus, that syntax really has nothing to recommend it.

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

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

[Python-ideas] Re: Arrow functions polyfill

[Ricky Teachey]

On Mon, Feb 15, 2021 at 12:02 PM Ricky Teachey  wrote:

> On Mon, Feb 15, 2021, 11:34 AM David Mertz  wrote:
>
>> On Mon, Feb 15, 2021 at 4:19 PM Guido van Rossum 
>> wrote:
>>
>>> Okay, here’s my dilemma. It looks like this thread wants to devise a new
>>> syntax for lambda, using e.g. (x, y) -> x+y, or the same with =>. That’s
>>> great, but doesn’t open new vistas. OTOH, for people using type
>>> annotations, a much more pressing issue is an alternative for
>>> typing.Callable that is more readable, and supports extra features that
>>> Callable doesn’t, like keyword args, varargs, and pos-only.
>>>
>>
>> FWIW, I *do not* want an alternate spelling for lambda.
>>
>> If your time machine were still working, and you could go back to 1991 to
>> change the spelling, yes I might like that.  For that matter, if someone
>> had a good spelling for multi-line lambdas, I might like that.  Or *maybe*
>> some other difference in behavior, but nothing comes immediately to mind.
>>
>> But allowing a few cryptic punctuation symbols to express an anonymous
>> function while still retaining "the name of a cryptic greek letter" to do
>> exactly the same thing seems like a strong non-goal.
>>
>> That said, if I had to look at one, I'd like '->' much better than '=>'.
>>
>
> I also don't see this as a very worthwhile goal.
>
> But if we could expand the  proposal to allow both anonymous and named
> functions, that would seem like a fantastic idea to me.
>
> Anonymous function syntax:
>
> (x,y)->x+y
>
> Named function syntax:
>
> f(x,y)->x+y
>
> But since Guido wants to save the right shaft operator for type hinting,
> and named functions do need a way to write type hints, maybe the best thing
> to do is use an equal sign shaft for the function definition and the right
> shaft for the type hint:
>
> f(x,y)=>x,y->str
>
> >>> f('a','b')
> 'ab'
> >>> f(1,2)  # type hint error
>
> Rick.
>

Sorry I was typing that last one on my phone and typed a mistake. Should
have been a plus sign in the expression and not a comma:

f(x,y)=>x+y->str

>>> f('a','b')
'ab'
>>> f(1,2)  # type hint error

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/MYNTQSLTFOIHA44KU6Q4UIZ3OD42JRLM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Arrow functions polyfill

[Ricky Teachey]

On Mon, Feb 15, 2021, 11:34 AM David Mertz  wrote:

> On Mon, Feb 15, 2021 at 4:19 PM Guido van Rossum  wrote:
>
>> Okay, here’s my dilemma. It looks like this thread wants to devise a new
>> syntax for lambda, using e.g. (x, y) -> x+y, or the same with =>. That’s
>> great, but doesn’t open new vistas. OTOH, for people using type
>> annotations, a much more pressing issue is an alternative for
>> typing.Callable that is more readable, and supports extra features that
>> Callable doesn’t, like keyword args, varargs, and pos-only.
>>
>
> FWIW, I *do not* want an alternate spelling for lambda.
>
> If your time machine were still working, and you could go back to 1991 to
> change the spelling, yes I might like that.  For that matter, if someone
> had a good spelling for multi-line lambdas, I might like that.  Or *maybe*
> some other difference in behavior, but nothing comes immediately to mind.
>
> But allowing a few cryptic punctuation symbols to express an anonymous
> function while still retaining "the name of a cryptic greek letter" to do
> exactly the same thing seems like a strong non-goal.
>
> That said, if I had to look at one, I'd like '->' much better than '=>'.
>

I also don't see this as a very worthwhile goal.

But if we could expand the  proposal to allow both anonymous and named
functions, that would seem like a fantastic idea to me.

Anonymous function syntax:

(x,y)->x+y

Named function syntax:

f(x,y)->x+y

But since Guido wants to save the right shaft operator for type hinting,
and named functions do need a way to write type hints, maybe the best thing
to do is use an equal sign shaft for the function definition and the right
shaft for the type hint:

f(x,y)=>x,y->str

>>> f('a','b')
'ab'
>>> f(1,2)  # type hint error

Rick.

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

[Python-ideas] Re: Arrow functions polyfill

[David Mertz]

On Mon, Feb 15, 2021 at 4:19 PM Guido van Rossum  wrote:

> Okay, here’s my dilemma. It looks like this thread wants to devise a new
> syntax for lambda, using e.g. (x, y) -> x+y, or the same with =>. That’s
> great, but doesn’t open new vistas. OTOH, for people using type
> annotations, a much more pressing issue is an alternative for
> typing.Callable that is more readable, and supports extra features that
> Callable doesn’t, like keyword args, varargs, and pos-only.
>

FWIW, I *do not* want an alternate spelling for lambda.

If your time machine were still working, and you could go back to 1991 to
change the spelling, yes I might like that.  For that matter, if someone
had a good spelling for multi-line lambdas, I might like that.  Or *maybe*
some other difference in behavior, but nothing comes immediately to mind.

But allowing a few cryptic punctuation symbols to express an anonymous
function while still retaining "the name of a cryptic greek letter" to do
exactly the same thing seems like a strong non-goal.

That said, if I had to look at one, I'd like '->' much better than '=>'.
___
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/6MWEHXH6RSEDPMHIVGBHQ7O2K3IQ25L2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Arrow functions polyfill

[Guido van Rossum]

Okay, here’s my dilemma. It looks like this thread wants to devise a new
syntax for lambda, using e.g. (x, y) -> x+y, or the same with =>. That’s
great, but doesn’t open new vistas.

OTOH, for people using type annotations, a much more pressing issue is an
alternative for typing.Callable that is more readable, and supports extra
features that Callable doesn’t, like keyword args, varargs, and pos-only.

If you can do both with the same arrow, great, but if the arrows must
differ (for some technical reason, e.g. types in cast()), I want -> for
Callable, and you can have => for lambda.

—Guido

On Mon, Feb 15, 2021 at 02:51 Steven D'Aprano  wrote:

> On Mon, Feb 15, 2021 at 02:12:03AM +1100, Chris Angelico wrote:
> > On Sun, Feb 14, 2021 at 8:42 PM Steven D'Aprano 
> wrote:
> > > We should not choose the more confusing, error-prone solution out of
> > > fear of being different. Python is already different from Javascript in
> > > every regard:
> > >
> >
> > Is it really?
>
> Well, they're both Turing Complete, so I guess not different in *every*
> regard :-)
>
> By the way, I'm not judging the differences.
>
>
> > > - the basic execution model is different;
> > Don't know what you mean here, but I thought they were the same.
>
> Python has a purely dynamic execution model; Javascript has a hybrid
> two-pass model that combines elements of static and dynamic execution,
> and which allows code like this to run:
>
> print(f(3));
>
> function f(a) {
>   return a*2;
> }
>
>
> (not in an interactive REPL of course).
>
> Although both Python and Javascript have dynamic typing, Python's
> type model is stronger (i.e. stricter) than Javascript's.
>
> 1 + '2'  # an error in Python, 12 in Javascript.
>
> In Python, every thing is an object; in Javascript, some things are
> objects, and some things are primitive values.
>
>
> > > - the object model is different;
> > Same object model.
>
> Absolutely not. Javascript is based on the prototype object model, and
> Python is based on the class object model.
>
>
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inheritance_and_the_prototype_chain
>
>
> > > - the numeric model is different;
> > Python has more data types, but that's not as fundamental a difference
> > as you might think
>
> Python has a numeric tower; Javascript has a single floating point type.
> It's hard to build a tower with a single brick :-)
>
>
> > >  -the truthy/falsey model is different;
> > There are different rules about WHAT is truthy/falsy, but, again, the
> > differences aren't fundamental
>
> The differences are precisely my point.
>
>
> > > - the syntax is different;
> > > - the list of keywords is different;
> > > - the standard library is different;
> > > - the list of operators is different;
> > Well, of course. If these four were the same, they'd be the same
> > language. These four differ between Py2 and Py3 too.
>
> Yes, the fact that they are different languages is my point.
>
>
> > > - even basic equality is different;
> > Yes, although that's more historic than anything else - most people
> > use "===" which has mostly the same semantics as Python's equality
>
> "Mostly the same", apart from being completely different :-(
>
> Javascript's === tests for "same type and equal" for primitive values,
> and is equivalent to Python's `is` for objects. It cannot be overloaded.
>
>
> > > - the culture of the community is different.
> > TBH neither community has a single culture.
>
> Of course neither group of people is a monoculture of identical
> clones. That would be the Haskell community *wink*
>
> But in general, the JS/Node.js community embraces practices which are
> rejected by the Python community, such as the use of micro-packages.
> Remember left-pad?
>
> This four-line package got nearly fifty million downloads last week:
>
> https://www.npmjs.com/package/isarray
>
> That's about 78 times per second.
>
> If I published that on PyPI, I would be amazed if I got 78 downloads in
> a year.
>
>
> --
> 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/7RDIPZDPOZUU7AD5JFE2BNQH75OAAGS7/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
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/UJ32U33U4FL4GAOERD77CMB5QFJNHF63/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Conditional with statements

[Rob Cliffe via Python-ideas]

On 15/02/2021 01:58, Christopher Barker wrote:

Getting OT here -- you've been warned.

On Sun, Feb 14, 2021 at 2:10 AM Rob Cliffe > wrote:



You've broken a number of "rules" code code formatting there ;-)

Thanks for the quotation marks.  Indeed, PEP 8 provides
guidelines, not diktats.

A big one is aligning things vertically, which, as a rule, I
like. but this example does really push things out away from each
other, so I'm not so sure.


It's written to suit my editor.  I'm with Brendan: restricting the
whole world to 80 chars per line is like insisting the whole world
program in COBOL.


I agree about the 80 char limit -- personally using usually 90 or 95.

But I do think you need to consider not just your editor -- if anyone 
else is going to read your code.

They're not (in any universe I can imagine).


But in your example, it not only has long lines, but by lining up the 
stuff after the colon -- there is a LOT of info way over on the right, 
which I'm not so sure about.



Just for fun, here it is after being run through Black (which I
don't usually use ) -- but I think it looks better that way.

Also -- my first thought looking at that was that it could really
benefit from the pattern matching :-)

Yes IMHO it would be a slight improvement.  But AFAIU pattern
matching is not available yet.


no, it's not. That was a note for me in a way -- I'm a bit of a 
skeptic about pattern matching, so this is a good example use case.



And my second thought was that there could be a whole other
pattern used here -- I usually find long chained elifs can be
better expressed as a dict selection, or subclassing, or ...

I cannot imagine how a dictionary, much less a subclass (of
what)?  could have any relevance here.  I'd be interested if you
could elucidate.


Again, I don't know what the rest of your code looks like, so maybe 
none of these would work well, but:


for using a dict, you could set it up something like:

ch_proc_dict = {"B": self.ToggleBackgroundColour,
                "C": self.ChangeCommonChars,
                "D": self.DeleteArea,
                ...
                }
then:

if process_dict[ch](event):
    return

you also have other checks in there, so those would have to be moved 
into the functions in the dict, maybe with wrappers (or not -- depends 
on where you store some of that state data.
Exactly.  Some wasted effort to turn a simple, contiguous, transparent 
chunk of code into something more complicated, spread out and harder to 
understand.


as for subclassing, that's a very different pattern that probably 
doesn't apply here now that I think about it:


This looks to me like wxPython code (or the like).

It is.  It's part of a wx.EVT_CHAR handler.
  for wx.lib.floatcanvas, I don't have keyboard accelerators, but I do 
have "GUI Modes"  classes: Depending on what Mode is set at the 
moment, each event gets mapped to different actions, so you might have 
different handling of the character hit depending on what object is 
selected:


object_selected.process_keystroke(ch)

Of course, you'd need this kind of "switch" construct in the object 
class anyway. Unless you wanted to get really wordy, and have:


def process_A(self..)
    ...
def process_B(self...)
    ...

you could be a bit saved in Python:

getattr(selected_object, "process" + ch)(event)
Again, turning simple straightforward into more complicated code.  (I'm 
quite capable of writing tricks like that *when I think they're 
appropriate*; I've done it many times.)


Anyway, as I say -- pretty darn off topic, but those are two of the 
three ways that I think "switch -- case" can be spelled in Python.


-Chris B


   if ch == "B":


self.ToggleBackgroundColour(event)
elif ch == "C":
    self.ChangeCommonChars(event)
    return
elif ch == "D" and len(Areas) > 1:
    self.DeleteArea(event)
    return
elif ch == "F" and __debug__:
    self.Info(event)
    return
elif ch == "I":
    self.ChangeImagesToScroll(event)
    return
elif ch == "J" and self.NUMBER_OF_IMAGES == 1:
    self.ChangeJustification(event)
    return
elif ch == "L":
    self.ToggleShowLabels(event)
elif ch == "M" and MaxNumberOfImages > 1:
    self.ChangeNumberOfImages(event)
elif ch == "N" and CanZapImage:
    self.Rename(event)
elif ch == "R" and not (area.Dynamic | area.IsTour):
    self.ToggleRandom(event, 1)
elif ch == "S":
    self.ToggleSets(event, 1)
elif ch == "T":
    self.ChangeTimer(event)
    return
elif ch == "U" and not (area.Dynamic | area.Random):
    self.ToggleIsTour(event, 1)
elif ch == "V" and OnAnImage:
    self.WindowsPhotoViewer(event)
    return
elif ch == "W":
    self.ToggleWrap(event, 1)
elif ch == "Y" and not (area.Random | area.IsTour):
    

[Python-ideas] Re: Arrow functions polyfill

[Steven D'Aprano]

On Mon, Feb 15, 2021 at 02:12:03AM +1100, Chris Angelico wrote:
> On Sun, Feb 14, 2021 at 8:42 PM Steven D'Aprano  wrote:
> > We should not choose the more confusing, error-prone solution out of
> > fear of being different. Python is already different from Javascript in
> > every regard:
> >
> 
> Is it really?

Well, they're both Turing Complete, so I guess not different in *every* 
regard :-)

By the way, I'm not judging the differences.


> > - the basic execution model is different;
> Don't know what you mean here, but I thought they were the same.

Python has a purely dynamic execution model; Javascript has a hybrid 
two-pass model that combines elements of static and dynamic execution, 
and which allows code like this to run:

print(f(3));

function f(a) {
  return a*2;
}


(not in an interactive REPL of course).

Although both Python and Javascript have dynamic typing, Python's 
type model is stronger (i.e. stricter) than Javascript's.

1 + '2'  # an error in Python, 12 in Javascript.

In Python, every thing is an object; in Javascript, some things are 
objects, and some things are primitive values.


> > - the object model is different;
> Same object model.

Absolutely not. Javascript is based on the prototype object model, and 
Python is based on the class object model.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inheritance_and_the_prototype_chain


> > - the numeric model is different;
> Python has more data types, but that's not as fundamental a difference
> as you might think

Python has a numeric tower; Javascript has a single floating point type. 
It's hard to build a tower with a single brick :-)


> >  -the truthy/falsey model is different;
> There are different rules about WHAT is truthy/falsy, but, again, the
> differences aren't fundamental

The differences are precisely my point.


> > - the syntax is different;
> > - the list of keywords is different;
> > - the standard library is different;
> > - the list of operators is different;
> Well, of course. If these four were the same, they'd be the same
> language. These four differ between Py2 and Py3 too.

Yes, the fact that they are different languages is my point.


> > - even basic equality is different;
> Yes, although that's more historic than anything else - most people
> use "===" which has mostly the same semantics as Python's equality

"Mostly the same", apart from being completely different :-(

Javascript's === tests for "same type and equal" for primitive values, 
and is equivalent to Python's `is` for objects. It cannot be overloaded.


> > - the culture of the community is different.
> TBH neither community has a single culture.

Of course neither group of people is a monoculture of identical 
clones. That would be the Haskell community *wink*

But in general, the JS/Node.js community embraces practices which are 
rejected by the Python community, such as the use of micro-packages. 
Remember left-pad?

This four-line package got nearly fifty million downloads last week:

https://www.npmjs.com/package/isarray

That's about 78 times per second.

If I published that on PyPI, I would be amazed if I got 78 downloads in 
a year.


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