Hi, the idea here is just to add the __larrow__ and __rarrow__ operators for <- and ->. E.g. of use on dicts :
Or on bools as Modus Ponens [1] Or your idea/imagination here :-) Regards, --francis [1] https://en.wikipedia.org/wiki/Modus_ponens
On Sun, Mar 03, 2019 at 03:46:24PM +0100, francismb <francismb@email.de> wrote:
You cannot create operator ``<-`` because it's currently valid syntax: 3 <- 2 is equivalent to 3 < -2
Regards, --francis
Oleg. -- Oleg Broytman https://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
Hi Oleg, On 3/3/19 4:06 PM, Oleg Broytman wrote:
Yes, its a good point, but for me it's not the same '<-' and '< -' due (n)blanks in between. It is may be how now it is, but means that it needs to be always like this? Isn't Python not already blank(s)/indentation aware? or it's just a grammar NO GO? Thanks in advance! --francis
francismb wrote:
It is may be how now it is, but means that it needs to be always like this?
Yes, as long as you care about not breaking existing code. While you may be in the habit of always leaving a space between '<' and '-', others may have different styles. Do you really want to tell them that all their code is now wrong? -- Greg
Hi Greg, On 3/9/19 1:42 AM, Greg Ewing wrote: problem if the update to a new version (let say from 3.X to next(3.X)) is done through some kind of updater/re-writer/evolver. In that case the evolver could just add the blanks. What do you think ? Could it work? Thanks in advance! --francis
In general, there is lots of code out in the wild that can't be updated for whatever reason, e.g. the person that knows Python left and it needs to continue to work. Weak argument, but cost-benefit I think it comes out ahead. In your example there isn't a reason I can tell why swapping the operands isn't what should be done as Calvin mentioned. The onus is on you to positively demonstrate you require both directions, not him to negatively demonstrate it's never required. I suggest you confine your proposal to `->` only, as it's currently illegal syntax. You would also want the reflected `__r*__` equivalent of `__arrow__` or `__rarrow__` (`__rrarrow__` if you also need the left-arrow...) Perhaps broadening the use of it, functions may be able to use it as a pipe operator, e.g. Elixir: https://elixir-lang.org/getting-started/enumerables-and-streams.html#the-pip... On Mon, Mar 11, 2019 at 2:58 PM francismb <francismb@email.de> wrote:
`->` would not be ambiguous in the proposed cases, but it does already mean something elsewhere in the language as of 3.5: def concat(a: str, b: str) -> str: return a + b This could potentially cause confusion (as with the % operator being used for modulo as well as string formatting). On Tue, Mar 12, 2019 at 10:58 AM Nick Timkovich <prometheus235@gmail.com> wrote:
On 3/13/19 1:44 PM, David Teresi wrote:
But by that logic, the colon is also ambiguous: the colon is used to indicate a dictionary entry, as in {a : str}. Given the radically difference contexts in which the tokens in question occur, I don't think that this is an issue (then again, I've never designed a language as widely consumed as Python).
Hi Nick, On 3/12/19 3:57 PM, Nick Timkovich wrote:
But I really just wanted to talk some *visual asymmetric form* that could be used as operator for potentially asymmetric operations and thought that the arrow could be one of this. So you're correct one should discuss with *form* could potentially be wider accepted/work. The debate on this is going on the thread: "Why operators are useful". Regards, --francis
I wonder if it is necessary to add two new operators, and for me, "arrow operator" is not clearer than `+`. Could you explain why do you prefer this operator than `+`? Also -> is a symbol of propositional logic, like ∧ and ∨ , do we also need these operators as well? At 2019-03-03 22:46:24, "francismb" <francismb@email.de> wrote:
I don't like the idea of arrows in both directions when you can just swap the operands instead On Sun, Mar 3, 2019 at 9:52 AM francismb <francismb@email.de> wrote:
-- CALVIN SPEALMAN SENIOR QUALITY ENGINEER cspealma@redhat.com M: +1.336.210.5107 <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
On Sun, Mar 03, 2019 at 03:46:24PM +0100, francismb <francismb@email.de> wrote:
You cannot create operator ``<-`` because it's currently valid syntax: 3 <- 2 is equivalent to 3 < -2
Regards, --francis
Oleg. -- Oleg Broytman https://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
Hi Oleg, On 3/3/19 4:06 PM, Oleg Broytman wrote:
Yes, its a good point, but for me it's not the same '<-' and '< -' due (n)blanks in between. It is may be how now it is, but means that it needs to be always like this? Isn't Python not already blank(s)/indentation aware? or it's just a grammar NO GO? Thanks in advance! --francis
francismb wrote:
It is may be how now it is, but means that it needs to be always like this?
Yes, as long as you care about not breaking existing code. While you may be in the habit of always leaving a space between '<' and '-', others may have different styles. Do you really want to tell them that all their code is now wrong? -- Greg
Hi Greg, On 3/9/19 1:42 AM, Greg Ewing wrote: problem if the update to a new version (let say from 3.X to next(3.X)) is done through some kind of updater/re-writer/evolver. In that case the evolver could just add the blanks. What do you think ? Could it work? Thanks in advance! --francis
In general, there is lots of code out in the wild that can't be updated for whatever reason, e.g. the person that knows Python left and it needs to continue to work. Weak argument, but cost-benefit I think it comes out ahead. In your example there isn't a reason I can tell why swapping the operands isn't what should be done as Calvin mentioned. The onus is on you to positively demonstrate you require both directions, not him to negatively demonstrate it's never required. I suggest you confine your proposal to `->` only, as it's currently illegal syntax. You would also want the reflected `__r*__` equivalent of `__arrow__` or `__rarrow__` (`__rrarrow__` if you also need the left-arrow...) Perhaps broadening the use of it, functions may be able to use it as a pipe operator, e.g. Elixir: https://elixir-lang.org/getting-started/enumerables-and-streams.html#the-pip... On Mon, Mar 11, 2019 at 2:58 PM francismb <francismb@email.de> wrote:
`->` would not be ambiguous in the proposed cases, but it does already mean something elsewhere in the language as of 3.5: def concat(a: str, b: str) -> str: return a + b This could potentially cause confusion (as with the % operator being used for modulo as well as string formatting). On Tue, Mar 12, 2019 at 10:58 AM Nick Timkovich <prometheus235@gmail.com> wrote:
On 3/13/19 1:44 PM, David Teresi wrote:
But by that logic, the colon is also ambiguous: the colon is used to indicate a dictionary entry, as in {a : str}. Given the radically difference contexts in which the tokens in question occur, I don't think that this is an issue (then again, I've never designed a language as widely consumed as Python).
Hi Nick, On 3/12/19 3:57 PM, Nick Timkovich wrote:
But I really just wanted to talk some *visual asymmetric form* that could be used as operator for potentially asymmetric operations and thought that the arrow could be one of this. So you're correct one should discuss with *form* could potentially be wider accepted/work. The debate on this is going on the thread: "Why operators are useful". Regards, --francis
I wonder if it is necessary to add two new operators, and for me, "arrow operator" is not clearer than `+`. Could you explain why do you prefer this operator than `+`? Also -> is a symbol of propositional logic, like ∧ and ∨ , do we also need these operators as well? At 2019-03-03 22:46:24, "francismb" <francismb@email.de> wrote:
I don't like the idea of arrows in both directions when you can just swap the operands instead On Sun, Mar 3, 2019 at 9:52 AM francismb <francismb@email.de> wrote:
-- CALVIN SPEALMAN SENIOR QUALITY ENGINEER cspealma@redhat.com M: +1.336.210.5107 <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
participants (10)
-
Calvin Spealman -
Chris Angelico -
Dan Sommers -
David Teresi -
fhsxfhsx -
francismb -
Greg Ewing -
Nick Timkovich -
Oleg Broytman -
Todd