Re: [Python-ideas] Does jargon make learning more difficult?

[Abe Dillon]

[Michael Selik]

> The conversation about syntactic sugar for ``functools.partial`` led to a
> question about whether jargon like "lambda" makes the concept of an
> anonymous function more difficult to learn.


To clarify: The original statement by Steven D'Aprano, "although possibly a
less jargon name would be nicer..." indicated to me that he thought there
might be situations where less jargon terms are preferable to jargon terms.

The argument I tried to make is, "yes I believe there are cases where a
less jargon identifier is preferable and that I believe 'lambda' is an
example of a missed opportunity to use a less jargon (maybe 'esoteric' is a
better word here?), more descriptive name."

Subjectively, I don't like lambda expressions. I find the word 'lambda' to
be an eye-sore in an otherwise very elegant language.

That being said: I believe subjective valuations are rarely devoid of
subtle, underlying motivators that are at least grounded in logic if not
objective. It's just hard to put your finger on it most of the time. I
often try to root out those motivators for why I feel the way I do and
articulate them as best I can. At the end of the day, though; I can't
always provide a completely objective, logical proof for why I feel the way
I do.

For instance: when the iPhone was introduced, a lot of people praised it's
subjectively "slick" user interface. I believe that perception of slickness
is partly because the iPhone emulated physical interfaces very well so it
leveraged people's intuition about the physical world. It was delightfully
intuitive.

I believe that part of my distaste for lambda is that it's an esoteric word
that doesn't convey any meaning to someone who's never heard of a 'lambda
expression' (which was the case for me when I first encountered it). Even
after I had heard of a lambda expression, the fact that the word had little
other connection to anything relevant in my brain meant that I had to
mentally translate it every time I read for a couple of years.

[Steven Barnes]

> While NOT wanting to start another fight I feel that I must put my
> pedant hat on & point out that the above highlights why domain specific
> words are used and their specificity actually highlights important
> concepts, i.e.:
>   * Brakes are used to apply breaking, (i.e. to slow the vehicle,
> possibly to a stop), while stoppers STOP something.


I don't think this is comparable to calling a car's brakes, "stoppers" for
several reasons.

1) What we call something usually relates to how humans communicate to
other humans about that thing, not how we actually use the tool.

I'm not against the idea of jargon. It clearly serves a useful purpose for
humans to communicate to other humans both concisely and with precision.
When I tell someone at work that a service went down and they say, "I'll
take a look at the logs", I know they're not talking about lengths of cut
or fallen tree. I'm glad humans are so good at deducing context that we
don't have to constantly disambiguate everything. I also understand that
this practice of overloading words sometimes leads to strange results like
"currying". Maybe calling it "signature reduction" would have been too
unwieldy and/or caused confusion with the word "reduce" which is often used
in the same context.

None of that has to do with how I interact with a car. Few brake pedals say
"brake" on them. I don't have to use the word "brake" to slow down my car.
Few of the interfaces in my car even have words. There's no lever that says
"high beams". There's no dashboard indicator that says "high beams". I
don't have to use the phrase "high beams" to turn on my high beams. At the
same time, I don't need to use or know the word "ternary" to read or write
a ternary expression in Python. I don't think that was a mistake or a
missed opportunity to force people to look up the word "ternary".

Sometimes in highly specific contexts, we deal with nuanced concepts like
the difference between a parameter and an argument. So we use jargon to
distinguish between them. That's not as much of problem in a programming
language. The constructs in Python have to have an exact meaning by
default. Clearly defining and separating name-spaces is an inescapable fact
of life in programming. There's no chance of Python accidentally
misinterpreting which "log" you're talking about. There's no potential for
a "who's on first" gag .

2) Cars tend to actually use pretty sensible naming schemes.

A windshield shields you from the wind. A windshield wiper wipes the
windshield. Windshield wiper fluid is fluid that helps the windshield wiper
wipe the windshield, etc.
If they called windshield wiper solution "epsilon", it wouldn't cause more
crashes or anything, it would just be more confusing than it needs to be.

3) It's not like calling 'brakes' 'stoppers'. It's more like calling an
expression that makes a function by some random greek letter. I don't see
much need 

Re: [Python-ideas] Jump to function as an an alternative to call function

[Abe Dillon]

Is "Ban" a class of morphemes or just a single morpheme? I would think
subclasses of Morpheme would be "Bound" and "Unbound" then there might be
subclasses of Bound and so on.

[Jacob Solinsky]

> now I understand that the best way to do that would just be to macro
> expand an often repeated segment of code.


This is also referred to as "functional decomposition" (if I understand you
correctly).

You can usually write a method as a sequence of steps you need to take,
then implement those steps in re-usable helper functions with descriptive
names.

My guess is that you'd want the morpheme class to be fairly simple and
leave a bunch of the joining logic to the Verb. I would make a morpheme
object's "morph" method take in some context (perhaps previous and next
morpheme and stress or something) and output a morphed version of the
morpheme without changing any internal state. That way, the "ban" morpheme
is always the "ban" morpheme no matter what.

It might also be easier to use dictionaries to look up morphemes based on
tense and other context. There are a lot of ways that data-structures and
coding practices can clean up code.



On Fri, Aug 17, 2018 at 4:13 PM, Jacob Solinsky 
wrote:

> The code does the following 2 things:
> A Verb class assembles the necessary morphemes in order in accordance with
> the verb's subject, object, mode, grmamatical order, tense and polarity.
>
> If all of the morphemes' default forms were mashed together at this point
> a valid Ojibwe verb form would not be produced
>
> The code in the mutate methods of each morphene transforms a sequence like
> gi-bizindaw-in-si-in-w-in-m-ban
> into
> gi-bizindoo--si-n-oo-n-inini-mwaa-ban
> gibizindoosinoonininimwaaban
>
> A third piece of code creates thousands of verb instances and populates a
> web form to show every conjugated form of a given verb, though that is not
> important here.
>
> The mutation of each morpheme is dependent on the type and form of the
> preceding and following morpheme, occasionally requiring even more
> information from the parent verb.
>  As most morphemes' mutation method are unique, the subclasses of Morpheme
> for the most part override the Morphems superclass's mutate implementation.
> However, it would reduce my code's current redundancy if I could place
> something like a macro expansion at the beginning of each mutate method's
> internal code, as there is a piece of code used to set up each mutate
> method's local variable space that I copied and pasted many times.
>
> The code I wrote already functions fine, it is just that while I was
> writing I was thinking to myself how convenient it would be if I could
> "jump to" functions, and now I understand that the best way to do that
> would just be to macro expand an often repeated segment of code.
>
> On Fri, 17 Aug 2018, 15:24 Abe Dillon,  wrote:
>
>> Jacob, can you please describe in greater detail *what* you're trying to
>> accomplish with your morpheme code? Not *how* you wish to accomplish it,
>> but *what* the code is supposed to do?
>>
>> I've looked into other projects that try to model morphemes and similar
>> language constructs to get a better idea of the problem space (NLTK
>> , TextBlob
>> , PyGlot
>> ,
>> etc.) and it looks like machine learning is often employed for
>> morpheme-related tasks. It may be that the rules for identifying and
>> manipulating morphemes are inherently so complex that they don't lend
>> themselves to elegant codification. That's usually the case for fields in
>> which people turn to machine learning.
>>
>> It may also be a case where functional decomposition would help. The
>> examples you've given aren't really sufficient to understand the problem.
>> It could be a legitimate deficiency in Python's feature set, or it may be
>> that Python already has features that could serve you better, or it may be
>> that the problem is inherently difficult to codify in an elegant way.
>>
>> Without a concrete use-case, it's nearly impossible to justify adding a
>> new feature to Python. This discussion is unlikely to lead to any
>> meaningful action otherwise.
>>
>> On Thu, Aug 16, 2018 at 4:37 PM, Jacob Solinsky 
>> wrote:
>>
>>> So when getx is executed inside a let form, if it tries to read/write
>>> the value of X it interacts with the X entry in the let form's symbol table
>>> before moving to find X in the global environment, right? That is similar
>>> to what I was trying to accomplish in python, but with the local symbol
>>> table of the calling function rather than a let form.
>>>
>>> I think the way a "jump to" function rather than a "call function" would
>>> be implemented would be by removing the prologue and epilogue of the
>>> function's compiled code. Something vaguely like this:
>>>
>>> def foo(a,b):
>>> c = bar(d =3)%
>>> return c+2
>>>
>>> def bar(d)
>>>  a += 2
>>> 

Re: [Python-ideas] Jump to function as an an alternative to call function

[Chris Barker - NOAA Federal via Python-ideas]

By the way— really kludgy, doesn’t exec() do what you want here:

Note


The default *locals* act as described for function locals()
 below:
modifications to the default *locals* dictionary should not be attempted.
Pass an explicit *locals*dictionary if you need to see effects of the code
on *locals* after function exec()
 returns.


Though great still may not effect the current local namespace.


But I’d be really surprised if there were no way to modify the local
namespace — you can mess with pretty much anything else in Python.


-CHB



Sent from my iPhone

On Aug 17, 2018, at 12:46 PM, Chris Barker  wrote:

On Thu, Aug 16, 2018 at 12:37 PM, Chris Angelico  wrote:

>
> I've no idea what interpreter you're using, but it doesn't work for me.
>

That was in iPython, with python3.6.2 -- I wouldn't have expected it to be
different in this case though -- really odd.

OK -- tired again, and it indeed it failed -- so I'm really confused. You
can see my console output -- it did indeed work at least once.



> You've changed a cached dictionary but haven't actually created a local
>

which still makes me wonder WHY locals() returns a writable dict...

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
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] Jump to function as an an alternative to call function

[Jacob Solinsky]

The code does the following 2 things:
A Verb class assembles the necessary morphemes in order in accordance with
the verb's subject, object, mode, grmamatical order, tense and polarity.

If all of the morphemes' default forms were mashed together at this point a
valid Ojibwe verb form would not be produced

The code in the mutate methods of each morphene transforms a sequence like
gi-bizindaw-in-si-in-w-in-m-ban
into
gi-bizindoo--si-n-oo-n-inini-mwaa-ban
gibizindoosinoonininimwaaban

A third piece of code creates thousands of verb instances and populates a
web form to show every conjugated form of a given verb, though that is not
important here.

The mutation of each morpheme is dependent on the type and form of the
preceding and following morpheme, occasionally requiring even more
information from the parent verb.
 As most morphemes' mutation method are unique, the subclasses of Morpheme
for the most part override the Morphems superclass's mutate implementation.
However, it would reduce my code's current redundancy if I could place
something like a macro expansion at the beginning of each mutate method's
internal code, as there is a piece of code used to set up each mutate
method's local variable space that I copied and pasted many times.

The code I wrote already functions fine, it is just that while I was
writing I was thinking to myself how convenient it would be if I could
"jump to" functions, and now I understand that the best way to do that
would just be to macro expand an often repeated segment of code.

On Fri, 17 Aug 2018, 15:24 Abe Dillon,  wrote:

> Jacob, can you please describe in greater detail *what* you're trying to
> accomplish with your morpheme code? Not *how* you wish to accomplish it,
> but *what* the code is supposed to do?
>
> I've looked into other projects that try to model morphemes and similar
> language constructs to get a better idea of the problem space (NLTK
> , TextBlob
> , PyGlot
> ,
> etc.) and it looks like machine learning is often employed for
> morpheme-related tasks. It may be that the rules for identifying and
> manipulating morphemes are inherently so complex that they don't lend
> themselves to elegant codification. That's usually the case for fields in
> which people turn to machine learning.
>
> It may also be a case where functional decomposition would help. The
> examples you've given aren't really sufficient to understand the problem.
> It could be a legitimate deficiency in Python's feature set, or it may be
> that Python already has features that could serve you better, or it may be
> that the problem is inherently difficult to codify in an elegant way.
>
> Without a concrete use-case, it's nearly impossible to justify adding a
> new feature to Python. This discussion is unlikely to lead to any
> meaningful action otherwise.
>
> On Thu, Aug 16, 2018 at 4:37 PM, Jacob Solinsky 
> wrote:
>
>> So when getx is executed inside a let form, if it tries to read/write the
>> value of X it interacts with the X entry in the let form's symbol table
>> before moving to find X in the global environment, right? That is similar
>> to what I was trying to accomplish in python, but with the local symbol
>> table of the calling function rather than a let form.
>>
>> I think the way a "jump to" function rather than a "call function" would
>> be implemented would be by removing the prologue and epilogue of the
>> function's compiled code. Something vaguely like this:
>>
>> def foo(a,b):
>> c = bar(d =3)%
>> return c+2
>>
>> def bar(d)
>>  a += 2
>>  e = 4
>>  return a + b + d +e
>>
>> foo(7, 2)
>>
>> Here would be the symbol table
>>
>> Scope Foo
>> __
>> a: fp - 1
>> b: fp - 2
>> d: fp - 3
>> e: fp - 5
>> c: fp - 4
>>
>> The interpreter would have to recognize that bar was being jumped to
>> rather than called and thus inject bar's arguments and variable
>> declarations and return value (if assigned to) into foo's stack frame.
>>
>> The translation of the above code would be this (I apologize for the
>> strange pseudoassembly, I don't know any of those languages on a more than
>> cursory level. The below code is obviously very slow, each variable read
>> from the memory and written to memory at every step, with no storage of
>> local variables in registers.) The "return c+2" statement is changed from a
>> return into a c += 2 assignment in the calling function.
>>
>> PUSH fp, returnregister # preserve old value in return register
>> PUSH -1(fp), 7 # load a
>> PUSH -2(fp),  2 # load b
>> PUSH -3(fp), 3 # load d
>> PUSH -4(fp), 0 # initialize c
>> ADDI -1(fp), -1(fp), 2 # a += 2
>> PUSH -5(fp), 4 # load e
>> ADD -4(fp), -1(fp), -2(fp) # c = a + b + d + e
>> ADD -4(fp), -4(fp), -5(fp) # c = a + d + d + e continued
>> ADDI returnregister, -4(fp), 2 # return c + 2
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, 16 Aug 2018, 

Re: [Python-ideas] Jump to function as an an alternative to call function

[Abe Dillon]

Jacob, can you please describe in greater detail *what* you're trying to
accomplish with your morpheme code? Not *how* you wish to accomplish it,
but *what* the code is supposed to do?

I've looked into other projects that try to model morphemes and similar
language constructs to get a better idea of the problem space (NLTK
, TextBlob ,
PyGlot
,
etc.) and it looks like machine learning is often employed for
morpheme-related tasks. It may be that the rules for identifying and
manipulating morphemes are inherently so complex that they don't lend
themselves to elegant codification. That's usually the case for fields in
which people turn to machine learning.

It may also be a case where functional decomposition would help. The
examples you've given aren't really sufficient to understand the problem.
It could be a legitimate deficiency in Python's feature set, or it may be
that Python already has features that could serve you better, or it may be
that the problem is inherently difficult to codify in an elegant way.

Without a concrete use-case, it's nearly impossible to justify adding a new
feature to Python. This discussion is unlikely to lead to any meaningful
action otherwise.

On Thu, Aug 16, 2018 at 4:37 PM, Jacob Solinsky 
wrote:

> So when getx is executed inside a let form, if it tries to read/write the
> value of X it interacts with the X entry in the let form's symbol table
> before moving to find X in the global environment, right? That is similar
> to what I was trying to accomplish in python, but with the local symbol
> table of the calling function rather than a let form.
>
> I think the way a "jump to" function rather than a "call function" would
> be implemented would be by removing the prologue and epilogue of the
> function's compiled code. Something vaguely like this:
>
> def foo(a,b):
> c = bar(d =3)%
> return c+2
>
> def bar(d)
>  a += 2
>  e = 4
>  return a + b + d +e
>
> foo(7, 2)
>
> Here would be the symbol table
>
> Scope Foo
> __
> a: fp - 1
> b: fp - 2
> d: fp - 3
> e: fp - 5
> c: fp - 4
>
> The interpreter would have to recognize that bar was being jumped to
> rather than called and thus inject bar's arguments and variable
> declarations and return value (if assigned to) into foo's stack frame.
>
> The translation of the above code would be this (I apologize for the
> strange pseudoassembly, I don't know any of those languages on a more than
> cursory level. The below code is obviously very slow, each variable read
> from the memory and written to memory at every step, with no storage of
> local variables in registers.) The "return c+2" statement is changed from a
> return into a c += 2 assignment in the calling function.
>
> PUSH fp, returnregister # preserve old value in return register
> PUSH -1(fp), 7 # load a
> PUSH -2(fp),  2 # load b
> PUSH -3(fp), 3 # load d
> PUSH -4(fp), 0 # initialize c
> ADDI -1(fp), -1(fp), 2 # a += 2
> PUSH -5(fp), 4 # load e
> ADD -4(fp), -1(fp), -2(fp) # c = a + b + d + e
> ADD -4(fp), -4(fp), -5(fp) # c = a + d + d + e continued
> ADDI returnregister, -4(fp), 2 # return c + 2
>
>
>
>
>
>
>
>
>
>
>
> On Thu, 16 Aug 2018, 14:44 Jonathan Fine,  wrote:
>
>> Hi Jacob
>>
>> I'm finding the python-ideas list a bit noisy, so I'm sending this
>> off-list.
>>
>> I've found
>>
>> https://www.gnu.org/software/emacs/manual/html_node/elisp/
>> Dynamic-Binding.html
>> https://www.gnu.org/software/emacs/manual/html_node/elisp/
>> Variable-Scoping.html
>>
>> Please confirm that this is at least close to what you want, to be
>> able to program your problem efficiently.
>>
>> Meanwhile, I'm thinking about how your algorithm might be expressed in
>> Python.
>>
>> --
>> Jonathan
>>
>
> ___
> 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 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] Jump to function as an an alternative to call function

[Chris Barker via Python-ideas]

On Thu, Aug 16, 2018 at 12:37 PM, Chris Angelico  wrote:

>
> I've no idea what interpreter you're using, but it doesn't work for me.
>

That was in iPython, with python3.6.2 -- I wouldn't have expected it to be
different in this case though -- really odd.

OK -- tired again, and it indeed it failed -- so I'm really confused. You
can see my console output -- it did indeed work at least once.



> You've changed a cached dictionary but haven't actually created a local
>

which still makes me wonder WHY locals() returns a writable dict...

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
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] Jump to function as an an alternative to call function

[Jonathan Fine]

Jacob Solinsky wrote:

> So when getx is executed inside a let form, if it tries to read/write the
> value of X it interacts with the X entry in the let form's symbol table
> before moving to find X in the global environment, right?

The context for this is two (very useful) URLs I sent him off list:

https://www.gnu.org/software/emacs/manual/html_node/elisp/Dynamic-Binding.html
https://www.gnu.org/software/emacs/manual/html_node/elisp/Variable-Scoping.html

-- 
Jonathan
___
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] Jump to function as an an alternative to call function

[Brice Parent]

Le 16/08/2018 à 20:34, Steven D'Aprano a écrit :

On Thu, Aug 16, 2018 at 10:31:28AM +0200, Brice Parent wrote:


If I understand well the need (I'm unsure I've had it myself), it would
be easier to be able to import the function in the active context, like
this:

def foo(a):
     return a + c

def bar(a, c):
     return foo(a)

def bazz(a, c):
     import __file__.foo
     return foo(a)

[...]

I'm not saying the syntax is the one that should be used (__file__
possibly not existing may be a problem), not even saying that we should
have this. I'm just showing a way to do the same thing with an easier
(to me) syntax.

The problem isn't that __file__ doesn't exist, it is that import DOES
exist and does something completely unsuitable:

[...]
That's what I was trying to say: I'm not proposing a syntax or any 
specific solution.
It was more about graphically explaining that I found more explicit 
(that word again...) to import (or copy, or insert) the target function 
inside the active scope than to have it done when you call the function 
itself.


___
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] Jump to function as an an alternative to call function

[Stephen J. Turnbull]

Jacob Solinsky writes:

 > I think the way a "jump to" function rather than a "call function" would be
 > implemented would be by removing the prologue and epilogue of the
 > function's compiled code. Something vaguely like this:

First, let me apologize for pointing you at Ruby blocks.  They don't
quite do what I thought they did; they're more like Python's
"nonlocal" than Lisp's "dynamic scope".  I'm pretty sure you would
need something else added to Python.  (But see below.)  If you're not
a Ruby programmer and don't necessarily want to be one, I'd say wait
for someone who is to say I'm wrong before pushing them.

Second, it seems to me that the kind of "DRY" you're looking for is
just as well implemented by a macro facility.  You might want to look
at MacroPy.

tl;dr here

I'm not very experienced with Ruby, so I'll post the snippets that
convinced me that Ruby's blocks don't DTRT.  Maybe somebody else can
correct my code to get the job done, in which case you might have a
reason to advocate blocks for Python.

Steve

Code:

The problem is that blocks have nonlocal access (as defined in Python
3) to the scope in which they are defined, not somehow imposing
dynamic access on that scope.

def preamble
# assign local variables
end

def mutate
preamble do
# do stuff with preamble's locals
end
end

doesn't work because the block can see mutate's locals but not
preamble's.

So I think

def mutate
def worker
yield
# do stuff with mutate's locals
end
worker do
# assign local variables
end
end

works (untested), but it's just a complicated way to write

def mutate
# assign local variables
# do stuff with mutate's locals
end

while

def worker
yield
# do stuff with mutate's locals
end

def mutate
worker do
# assign local variables
end
end

does not work: worker can't access the local variables of mutate
because they're a scope it can't see.


-- 
Associate Professor  Division of Policy and Planning Science
http://turnbull.sk.tsukuba.ac.jp/ Faculty of Systems and Information
Email: turnb...@sk.tsukuba.ac.jp   University of Tsukuba
Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/