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

[David Mertz]

When did you last read the Dijkstra paper. It's short and he explains very
well why exactly all the constructs you mention are unlike Goto.

This isn't a proposal to subroutines, it's a proposal for subroutines in
which all lexically scoped variables are implicitly nonlocal. That's
basically Goto, certainly course enough to suffer all of Dijkstra's
complaints.

Yes, technically this could be called dynamic scope instead. But
notwithstanding the use in elisp, that's pretty widely regarded as a bad
ideas (even by the emacs developers who regret that early decision).

On Wed, Aug 15, 2018, 9:41 PM Steven D'Aprano  wrote:

> On Wed, Aug 15, 2018 at 08:35:35PM -0400, David Mertz wrote:
>
> > Goto considered harmful.
>
> Fortunately this proposal has nothing to do with goto.
>
> Elazar is correct that its a kind of subroutine call, just like an
> ordinary function call, except the scoping rules are different.
>
> And for the record, not everyone agrees that Dijkstra is correct about
> goto. Certainly unstructured code is harmful, but we use restricted
> forms of goto all the time, we just don't call it by that name:
>
> - loops
> - continue
> - break
> - if...else
> - function calls
> - exception handling
>
> Just like goto, these are all jumps which change the execution order of
> your code. And some people defend limited, careful use of explicit goto,
> including Donald Knuth.
>
>
> --
> Steve
> ___
> 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

[Steven D'Aprano]

On Wed, Aug 15, 2018 at 08:35:35PM -0400, David Mertz wrote:

> Goto considered harmful.

Fortunately this proposal has nothing to do with goto.

Elazar is correct that its a kind of subroutine call, just like an 
ordinary function call, except the scoping rules are different.

And for the record, not everyone agrees that Dijkstra is correct about 
goto. Certainly unstructured code is harmful, but we use restricted 
forms of goto all the time, we just don't call it by that name:

- loops
- continue
- break
- if...else
- function calls
- exception handling

Just like goto, these are all jumps which change the execution order of 
your code. And some people defend limited, careful use of explicit goto, 
including Donald Knuth.


-- 
Steve
___
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

[Abe Dillon]

[Jacob Solinsky]

> these local variables are used quite often in the mutate methods, of which
> there are several dozen, so storing them by default saves a lot of typing.


There are several things you can do to alleviate the typing problem:
1) Get an IDE that has auto-complete. I recommend PyCharm Community
Edition, but there are several.
2) Use better naming: there are many shorter synonyms for "preceding" and
"succeding" and the word "morpheme" is redundant.
3) define as much as you can in the higher scopes:

C = re.compile("^[bpgkdtszSZjCmnywh]").match
M = re.compile("^[mn]$").match

class Morpheme:
  @property
  def pf(self): return self.pre.form

  @property
  def sf(self): return self.suc.form

  @property
  def precm(self): return C(self.pf)

  @property
  def sucmm(self): return M(self.sf)

  ...

I think what would help most of all is reorganizing your code. As I
understand it, a morpheme is the "smallest grammatical unit in a language"
 so maybe it makes more sense to
make the morpheme class fairly simple and not have a morpheme have any
inherent awareness of its preceding or succeeding morphemes. That seems
like the job of a larger construct that would deal with sequences of
morphemes. The way you have it right now, the morpheme seems to play a
double role a linked-list and a gramatical unit.

[Jacob Solinsky]

> I found cluttering the Morpheme object instances with flags and such to be
> inelegant, since these flags are only used by the mutate method.
>

That may be an indicator that you're trying to do too much with the
morpheme class.

[Jacob Solinsky]

> Also, without using a hacky solution like making Morpheme a subclass of
> types.SimpleNamespace, every new flag I might want to inject has to have a
> default value set in the __init__ method to prevent an AttributeError from
> being raised.


Yes, you typically want to define all your object attributes in __init__
otherwise your objects become fragile and can break if you don't call the
right methods in the right order. It's generally considered a bad idea to
define instance attributes anywhere else unless it's something like a
"private" helper method that gets called inside __init__.

[Jacob Solinsky]

> Anyways, I will look around in the mail list for discussions of Code
> blocks, now that I know they are called.


Don't take this the wrong way, but it might be better to acquaint yourself
with the set of tools already available before looking for new ones.
___
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] Does jargon make learning more difficult?

[Greg Ewing]

Alexandre Brault wrote:

On 2018-08-15 03:32 PM, MRAB wrote:


On 2018-08-15 18:27, MRAB wrote:

>

While we're at it, what's the only creature that's known commonly and
only by its scientific name?


I would have guessed Tyrannosaurus Rex


I would have thought pretty much any dinosaur.

--
Greg
___
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

[Steven D'Aprano]

On Wed, Aug 15, 2018 at 01:52:27PM -0500, Jacob Solinsky wrote:

> -Jumping to a function as opposed to calling a function
> 
> When a function is jumped to, it inherits the variables in the 
> caller’s local namespace and is free to modify them or add new local 
> variables, unlike a normal function call, wherein the caller’s 
> namespace is inaccesible.

I think that the standard term for what you want is *dynamic scoping*.

http://wiki.c2.com/?DynamicScoping

http://leafo.net/guides/dynamic-scoping-in-lua.html

The most common language today that uses dynamic scoping is probably 
Emacs Lisp. Although dynamic scoping is very powerful, it is also harder 
to implement correctly (so I believe) and harder to reason about. It is 
generally considered that dynamic scoping is equivalent to the exclusive 
use of global variables (all functions see the same variables, no matter 
where they are defined), so the use of dynamic scoping gives up the 
benefits of local variables.

(See also "Global variables considered harmful".)


> At present, the only way I know of to 
> accomplish this is to bundle all variables in the caller method’s 
> namespace as properties of the method’s instance and have the callee 
> method modify those properties.

This would generally be considered a severe violation of the Law of 
Demeter, one of the most important principles for reducing coupling 
between software components:

https://www2.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/LawOfDemeter.htm

http://www.ccs.neu.edu/home/lieber/LoD.html

but also one of the most misunderstood. (Anyone who tells you that the 
LoD is "never use more than one dot" is wrong.)

As far as I am concerned, reducing coupling between software components 
is the single most important design principle there is. But what do we 
do when the problem you are trying to solve inherently has a lot of 
coupling between data components? I think that computer science doesn't 
have a lot to say about such hard problems, apart from "avoid them".


> Though it is easier to read code 
> written this way, it resulted in a great deal of redundancy in the 
> code I was writing. The task I was attempting to accomplish was 
> approximately this:

What you quoted was not a description of the task, but a concrete 
implementation of one possible solution to the task. You are describing 
*how* you want to do it, but you haven't described what *it* is.

This is not the place for it, but generally you should describe the 
functional requirements, not the implementation. You have Nouns, and 
Verbs, but what do you want to do with them? What is the high-level 
behaviour? If you focus on implementation too early, you may blind 
yourself to simpler solutions that accomplish the same end using a 
completely different means.

A light-hearted example:

"How do I turn the temperature of my refridgerator up? I need to boil 
some water, but the temperature control of the fridge only goes up to 
about 10°C (50°F)."

"Why don't you use the stove or microwave oven?"

"Because... that is to say... I... okay."


Since I don't understand your functional requirements, I don't know 
whether you are dealing with a situation which inherently requires high 
coupling, or if you are missing a solution which would avoid the need 
for global variables or dynamic scoping.


[...]
> Each subclass of Morpheme has its own slightly different mutate 
> method. Some subclasses of Morpheme needed to access and manipulate a 
> great deal of information about the verb and their surroundings,

This suggests to me that a solution might be to generate and pass around 
some sort of *context object* for each word you operate on. The obvious 
problems with this include:

- you have to generate that context object for every word, whether
  it will use it or not;

- in principle, the amount of context needed could be unbounded; 
  one word may only need information from the previous word, 
  while another word in a long run-on sentence may need information
  from half a page back.


> while 
> other subclasses’ mutate methods differed little from the default. 
> Most of the variables manipulated by the mutate method are not used by 
> any other methods of class Morpheme and thus should not be made 
> properties of the attached instance. What I wish I were able to do is 
> write many little methods that modify the same set of local variables 
> and compose them together into a complete mutate method. 

Closures are the exact equivalent of classes. If you have a solution 
(however clumsy) that works with classes, you should be able to re-write 
it in terms of closures. Whether that solution is less clumsy remains to 
be seen!

So you can have something like this:

def environment():
a = 1
b = 2
# define some closures
def change1():
nonlocal a
a += 1
def change2():
nonlocal a, b
a += 2
b += 3
   def 

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

[Elazar]

I have no opinion on the proposal, but the equation with goto is dead
wrong. Yes, technically this is a goto. But so is a regular function call.
Jumping to a function makes thd code _easier_ to reason about, statically,
not harder. When you call an arbitrary function, you have no idea whether
it will return or not. When you jump to a function, you _know_ it will not
return. That's strictly more information, based solely on the syntax of the
statement.

Yes, if you have local functions mutating the state then jumpung to them
makes the code difficult to read. *but so is calling them*, with the
addition of the returning that you have to track.

Jumping to functions is procedural programming. There is no reasonfor it to
be "considered harmful" any more than calling funcions; indeed even less
so.

Elazar

On Wed, Aug 15, 2018, 17:42 Eric Fahlgren  wrote:

> How about just
> https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf
>
> On Wed, Aug 15, 2018 at 5:38 PM David Mertz  wrote:
>
>> Hmm.. link broke. Is this right?
>>
>>
>> https://www.google.com/url?sa=t=web=j=https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf=2ahUKEwi8lqHYqfDcAhXImOAKHeAzDmsQFjAEegQIBhAB=AOvVaw1CZug_36-PbevItYXTb7SR
>>
>> On Wed, Aug 15, 2018, 8:35 PM David Mertz  wrote:
>>
>>> Goto considered harmful.
>>>
>>>
>>> https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf=2ahUKEwi8lqHYqfDcAhXImOAKHeAzDmsQFjAEegQIBhAB=AOvVaw1CZug_36-PbevItYXTb7SR
>>>
>>> On Wed, Aug 15, 2018, 3:52 PM Jacob Solinsky 
>>> wrote:
>>>
 -Jumping to a function as opposed to calling a function

 When a function is jumped to, it inherits the variables in the caller’s
 local namespace and is free to modify them or add new local variables,
 unlike a normal function call, wherein the caller’s namespace is
 inaccesible. At present, the only way I know of to accomplish this is to
 bundle all variables in the caller method’s namespace as properties of the
 method’s instance and have the callee method modify those properties.
 Though it is easier to read code written this way, it resulted in a great
 deal of redundancy in the code I was writing. The task I was attempting to
 accomplish was approximately this:

 class Verb:
 def __init__(self, parameters):
 self.parameters = parameters
 def conjugate(self):
 #Using the parameters, chose an appropriate list of
 morphemes to prefix and suffix to the verb
 self.morphemelist = morphemelist
 for morpheme in self.morphemelist:
 morpheme.mutate()
 returnstring = ‘'
 for morpheme in self.morphemelist:
 returnstring = returnstring + morpheme.form
 returnstring = returnstring

 class Morpheme:
 def __init__(self, verb, form, precedingmorpheme,
 succeedingmorpheme):
 self.verb = verb
 self.form = form
 self.precedingmorpheme = precedingmorpheme
 self.succeedingmorpheme = succeedingmorpheme
 def mutate(self):
 #Using the verb’s parameters and the type and form of
 the preceding and succeeding morpheme, mutate this morpheme’s form so that
   #a correct verb form is produced
 self.form = newform

 class Ban(Morpheme):
 def __init__(self, verb, form):
 super().__init__(verb, ‘ban’)
 def mutate(self):
 #This morpheme has mutation logic unique to itself but
 with many similarities to the default morpheme’s mutation logic
 self.form = newform

 Each subclass of Morpheme has its own slightly different mutate method.
 Some subclasses of Morpheme needed to access and manipulate a great deal of
 information about the verb and their surroundings, while other subclasses’
 mutate methods differed little from the default. Most of the variables
 manipulated by the mutate method are not used by any other methods of class
 Morpheme and thus should not be made properties of the attached instance.
 What I wish I were able to do is write many little methods that modify the
 same set of local variables and compose them together into a complete
 mutate method. This would be effectively equivalent to having the “jump to
 function” calls be replaced with the text in the function’s body, like a C
 language macrosubstitution, but without using anything like preprocessor
 directives.

 Let foo(a, b) be the syntax to call foo(a, b), and foo(a, b)% be the
 syntax to jump to foo(a, b)

 def foo(a):
 return a + c

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

 def bazz(a, c):
 return foo(a)%

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

[Eric Fahlgren]

How about just
https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf

On Wed, Aug 15, 2018 at 5:38 PM David Mertz  wrote:

> Hmm.. link broke. Is this right?
>
>
> https://www.google.com/url?sa=t=web=j=https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf=2ahUKEwi8lqHYqfDcAhXImOAKHeAzDmsQFjAEegQIBhAB=AOvVaw1CZug_36-PbevItYXTb7SR
>
> On Wed, Aug 15, 2018, 8:35 PM David Mertz  wrote:
>
>> Goto considered harmful.
>>
>>
>> https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf=2ahUKEwi8lqHYqfDcAhXImOAKHeAzDmsQFjAEegQIBhAB=AOvVaw1CZug_36-PbevItYXTb7SR
>>
>> On Wed, Aug 15, 2018, 3:52 PM Jacob Solinsky 
>> wrote:
>>
>>> -Jumping to a function as opposed to calling a function
>>>
>>> When a function is jumped to, it inherits the variables in the caller’s
>>> local namespace and is free to modify them or add new local variables,
>>> unlike a normal function call, wherein the caller’s namespace is
>>> inaccesible. At present, the only way I know of to accomplish this is to
>>> bundle all variables in the caller method’s namespace as properties of the
>>> method’s instance and have the callee method modify those properties.
>>> Though it is easier to read code written this way, it resulted in a great
>>> deal of redundancy in the code I was writing. The task I was attempting to
>>> accomplish was approximately this:
>>>
>>> class Verb:
>>> def __init__(self, parameters):
>>> self.parameters = parameters
>>> def conjugate(self):
>>> #Using the parameters, chose an appropriate list of
>>> morphemes to prefix and suffix to the verb
>>> self.morphemelist = morphemelist
>>> for morpheme in self.morphemelist:
>>> morpheme.mutate()
>>> returnstring = ‘'
>>> for morpheme in self.morphemelist:
>>> returnstring = returnstring + morpheme.form
>>> returnstring = returnstring
>>>
>>> class Morpheme:
>>> def __init__(self, verb, form, precedingmorpheme,
>>> succeedingmorpheme):
>>> self.verb = verb
>>> self.form = form
>>> self.precedingmorpheme = precedingmorpheme
>>> self.succeedingmorpheme = succeedingmorpheme
>>> def mutate(self):
>>> #Using the verb’s parameters and the type and form of
>>> the preceding and succeeding morpheme, mutate this morpheme’s form so that
>>>   #a correct verb form is produced
>>> self.form = newform
>>>
>>> class Ban(Morpheme):
>>> def __init__(self, verb, form):
>>> super().__init__(verb, ‘ban’)
>>> def mutate(self):
>>> #This morpheme has mutation logic unique to itself but
>>> with many similarities to the default morpheme’s mutation logic
>>> self.form = newform
>>>
>>> Each subclass of Morpheme has its own slightly different mutate method.
>>> Some subclasses of Morpheme needed to access and manipulate a great deal of
>>> information about the verb and their surroundings, while other subclasses’
>>> mutate methods differed little from the default. Most of the variables
>>> manipulated by the mutate method are not used by any other methods of class
>>> Morpheme and thus should not be made properties of the attached instance.
>>> What I wish I were able to do is write many little methods that modify the
>>> same set of local variables and compose them together into a complete
>>> mutate method. This would be effectively equivalent to having the “jump to
>>> function” calls be replaced with the text in the function’s body, like a C
>>> language macrosubstitution, but without using anything like preprocessor
>>> directives.
>>>
>>> Let foo(a, b) be the syntax to call foo(a, b), and foo(a, b)% be the
>>> syntax to jump to foo(a, b)
>>>
>>> def foo(a):
>>> return a + c
>>>
>>> def bar(a, c):
>>> return foo(a)
>>>
>>> def bazz(a, c):
>>> return foo(a)%
>>>
>>> c = 5
>>>
>>> call = bar(1, 3)
>>>
>>> jump = bazz(1, 3)
>>>
>>>
>>> After execution, call in the above code would be 6 and jump in the above
>>> code would be 4.
>>>
>>>
>>> ___
>>> 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/
>
___
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

[David Mertz]

Hmm.. link broke. Is this right?

https://www.google.com/url?sa=t=web=j=https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf=2ahUKEwi8lqHYqfDcAhXImOAKHeAzDmsQFjAEegQIBhAB=AOvVaw1CZug_36-PbevItYXTb7SR

On Wed, Aug 15, 2018, 8:35 PM David Mertz  wrote:

> Goto considered harmful.
>
>
> https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf=2ahUKEwi8lqHYqfDcAhXImOAKHeAzDmsQFjAEegQIBhAB=AOvVaw1CZug_36-PbevItYXTb7SR
>
> On Wed, Aug 15, 2018, 3:52 PM Jacob Solinsky 
> wrote:
>
>> -Jumping to a function as opposed to calling a function
>>
>> When a function is jumped to, it inherits the variables in the caller’s
>> local namespace and is free to modify them or add new local variables,
>> unlike a normal function call, wherein the caller’s namespace is
>> inaccesible. At present, the only way I know of to accomplish this is to
>> bundle all variables in the caller method’s namespace as properties of the
>> method’s instance and have the callee method modify those properties.
>> Though it is easier to read code written this way, it resulted in a great
>> deal of redundancy in the code I was writing. The task I was attempting to
>> accomplish was approximately this:
>>
>> class Verb:
>> def __init__(self, parameters):
>> self.parameters = parameters
>> def conjugate(self):
>> #Using the parameters, chose an appropriate list of
>> morphemes to prefix and suffix to the verb
>> self.morphemelist = morphemelist
>> for morpheme in self.morphemelist:
>> morpheme.mutate()
>> returnstring = ‘'
>> for morpheme in self.morphemelist:
>> returnstring = returnstring + morpheme.form
>> returnstring = returnstring
>>
>> class Morpheme:
>> def __init__(self, verb, form, precedingmorpheme,
>> succeedingmorpheme):
>> self.verb = verb
>> self.form = form
>> self.precedingmorpheme = precedingmorpheme
>> self.succeedingmorpheme = succeedingmorpheme
>> def mutate(self):
>> #Using the verb’s parameters and the type and form of the
>> preceding and succeeding morpheme, mutate this morpheme’s form so that
>>   #a correct verb form is produced
>> self.form = newform
>>
>> class Ban(Morpheme):
>> def __init__(self, verb, form):
>> super().__init__(verb, ‘ban’)
>> def mutate(self):
>> #This morpheme has mutation logic unique to itself but
>> with many similarities to the default morpheme’s mutation logic
>> self.form = newform
>>
>> Each subclass of Morpheme has its own slightly different mutate method.
>> Some subclasses of Morpheme needed to access and manipulate a great deal of
>> information about the verb and their surroundings, while other subclasses’
>> mutate methods differed little from the default. Most of the variables
>> manipulated by the mutate method are not used by any other methods of class
>> Morpheme and thus should not be made properties of the attached instance.
>> What I wish I were able to do is write many little methods that modify the
>> same set of local variables and compose them together into a complete
>> mutate method. This would be effectively equivalent to having the “jump to
>> function” calls be replaced with the text in the function’s body, like a C
>> language macrosubstitution, but without using anything like preprocessor
>> directives.
>>
>> Let foo(a, b) be the syntax to call foo(a, b), and foo(a, b)% be the
>> syntax to jump to foo(a, b)
>>
>> def foo(a):
>> return a + c
>>
>> def bar(a, c):
>> return foo(a)
>>
>> def bazz(a, c):
>> return foo(a)%
>>
>> c = 5
>>
>> call = bar(1, 3)
>>
>> jump = bazz(1, 3)
>>
>>
>> After execution, call in the above code would be 6 and jump in the above
>> code would be 4.
>>
>>
>> ___
>> 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

[David Mertz]

Goto considered harmful.

https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf=2ahUKEwi8lqHYqfDcAhXImOAKHeAzDmsQFjAEegQIBhAB=AOvVaw1CZug_36-PbevItYXTb7SR

On Wed, Aug 15, 2018, 3:52 PM Jacob Solinsky 
wrote:

> -Jumping to a function as opposed to calling a function
>
> When a function is jumped to, it inherits the variables in the caller’s
> local namespace and is free to modify them or add new local variables,
> unlike a normal function call, wherein the caller’s namespace is
> inaccesible. At present, the only way I know of to accomplish this is to
> bundle all variables in the caller method’s namespace as properties of the
> method’s instance and have the callee method modify those properties.
> Though it is easier to read code written this way, it resulted in a great
> deal of redundancy in the code I was writing. The task I was attempting to
> accomplish was approximately this:
>
> class Verb:
> def __init__(self, parameters):
> self.parameters = parameters
> def conjugate(self):
> #Using the parameters, chose an appropriate list of
> morphemes to prefix and suffix to the verb
> self.morphemelist = morphemelist
> for morpheme in self.morphemelist:
> morpheme.mutate()
> returnstring = ‘'
> for morpheme in self.morphemelist:
> returnstring = returnstring + morpheme.form
> returnstring = returnstring
>
> class Morpheme:
> def __init__(self, verb, form, precedingmorpheme,
> succeedingmorpheme):
> self.verb = verb
> self.form = form
> self.precedingmorpheme = precedingmorpheme
> self.succeedingmorpheme = succeedingmorpheme
> def mutate(self):
> #Using the verb’s parameters and the type and form of the
> preceding and succeeding morpheme, mutate this morpheme’s form so that
>   #a correct verb form is produced
> self.form = newform
>
> class Ban(Morpheme):
> def __init__(self, verb, form):
> super().__init__(verb, ‘ban’)
> def mutate(self):
> #This morpheme has mutation logic unique to itself but
> with many similarities to the default morpheme’s mutation logic
> self.form = newform
>
> Each subclass of Morpheme has its own slightly different mutate method.
> Some subclasses of Morpheme needed to access and manipulate a great deal of
> information about the verb and their surroundings, while other subclasses’
> mutate methods differed little from the default. Most of the variables
> manipulated by the mutate method are not used by any other methods of class
> Morpheme and thus should not be made properties of the attached instance.
> What I wish I were able to do is write many little methods that modify the
> same set of local variables and compose them together into a complete
> mutate method. This would be effectively equivalent to having the “jump to
> function” calls be replaced with the text in the function’s body, like a C
> language macrosubstitution, but without using anything like preprocessor
> directives.
>
> Let foo(a, b) be the syntax to call foo(a, b), and foo(a, b)% be the
> syntax to jump to foo(a, b)
>
> def foo(a):
> return a + c
>
> def bar(a, c):
> return foo(a)
>
> def bazz(a, c):
> return foo(a)%
>
> c = 5
>
> call = bar(1, 3)
>
> jump = bazz(1, 3)
>
>
> After execution, call in the above code would be 6 and jump in the above
> code would be 4.
>
>
> ___
> 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 Angelico]

On Thu, Aug 16, 2018 at 8:53 AM, Jacob Solinsky  wrote:
> What I had hoped to do was use a preamble code block to collect all of the
> most common queries called by the mutate function in the local namespace,
> for example
>
> C = 'bpgkdtszSZjCmnywh'
> M = 'mn'
>
>
> class Morpheme:
> #stuff
>
> def preamble(self):
>
> ps = self.precedingmorpheme.form
> ss = self.succeedingmorpheme.form
> ssc = re.match(f'^[{C}]', self.succedingmorpheme.form) #Whether or not
> the following morpheme is consonant initial
> ssm = re.match(f'[{M}]$', self.precedingmorpheme.form) #Whether or not
> the preceding morpheme is nasal final
>
> these local variables are used quite often in the mutate methods, of which
> there are several dozen, so storing them by default saves a lot of typing.
>

Ahh, I see what you mean. I was thinking the other way - a single
mutate function that has a part in there saying "now run the code
block for this particular subclass".

What would be really nice would be something like:

from preamble() import *

I'm fairly sure that (per se) isn't going to fly, but it would be
interesting as a concept. Would need a new spelling.

The quirky part of my brain is trying to figure if class namespace can
be abused for this.

ChrisA
___
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]

What I had hoped to do was use a preamble code block to collect all of the
most common queries called by the mutate function in the local namespace,
for example

C = 'bpgkdtszSZjCmnywh'
M = 'mn'


class Morpheme:
#stuff

def preamble(self):

ps = self.precedingmorpheme.form
ss = self.succeedingmorpheme.form
ssc = re.match(f'^[{C}]', self.succedingmorpheme.form) #Whether or not
the following morpheme is consonant initial
ssm = re.match(f'[{M}]$', self.precedingmorpheme.form) #Whether or not
the preceding morpheme is nasal final

these local variables are used quite often in the mutate methods, of which
there are several dozen, so storing them by default saves a lot of typing.



class Ban(Morpheme):
def __init__(self):
  super().__init__(verb, precedingmorpheme, succeedingmorpheme,
form = 'ban')
def mutate(self):
  self.preamble()%
  if ps[-1] == 'd':
 self.form = 'p' + self.form[1:]
 self.preceding.form = ''
  if ssc:
 self.form = self.form + 'E'
  if ssm:
 self.form = re.sub('an', 'An', self.form)

What I actually ended up doing is placing these queries in the Morpheme
__init__ method
def __init__(self, ...):
self.ps = self.precedingmorpheme.form
self.ss = self.succeedingmorpheme.form
self.ssc = re.match(f'^[{C}]', self.succedingmorpheme.form)
#Whether or not the following morpheme is consonant initial
self.ssm = re.match(f'[{M}]$', self.precedingmorpheme.form)
#Whether or not the preceding morpheme is nasal final

This works perfectly fine, but I found cluttering the Morpheme object
instances with flags and such to be inelegant, since these flags are only
used by the mutate method. Also, without using a hacky solution like making
Morpheme a subclass of types.SimpleNamespace, every new flag I might want
to inject has to have a default value set in the __init__ method to prevent
an AttributeError from being raised. Anyways, I will look around in the
mail list for discussions of Code blocks, now that I know they are called.


On Wed, 15 Aug 2018, 16:41 Abe Dillon,  wrote:

> Jumping into functions that mutate variables in the calling scope sounds a
> lot like "GoTo"  which
> is notorious for leading to code that's very hard to reason about. Your
> functions would implicitly require that you assign variables in the calling
> scope before calling the function instead of explicitly requiring them in
> the function's signature. That can be very confusing.
>
> A lot of times, when I find that my function call signatures have become
> unwieldy, it's a sign that I need to bundle a lot of related variables into
> an object and either define methods on that object or pass that object to
> functions instead of the large number of variables that it encapsulates.
> You just use 'self' as a sort-of back-pack that carries around what you
> need.
>
> It's difficult to see what you're after from your Verb and Morpheme
> example. They don't seem to call any functions that use variables from the
> caller's scope. Can you flesh that out a bit better?
>
>
> On Wed, Aug 15, 2018 at 3:24 PM, Chris Angelico  wrote:
>
>> On Thu, Aug 16, 2018 at 4:52 AM, Jacob Solinsky 
>> wrote:
>> > -Jumping to a function as opposed to calling a function
>> >
>> > When a function is jumped to, it inherits the variables in the caller’s
>> local namespace and is free to modify them or add new local variables,
>> unlike a normal function call, wherein the caller’s namespace is
>> inaccesible. At present, the only way I know of to accomplish this is to
>> bundle all variables in the caller method’s namespace as properties of the
>> method’s instance and have the callee method modify those properties.
>> Though it is easier to read code written this way, it resulted in a great
>> deal of redundancy in the code I was writing.
>> >
>>
>> > Let foo(a, b) be the syntax to call foo(a, b), and foo(a, b)% be the
>> syntax to jump to foo(a, b)
>> >
>> > def foo(a):
>> > return a + c
>> >
>> > def bar(a, c):
>> > return foo(a)
>> >
>> > def bazz(a, c):
>> > return foo(a)%
>> >
>> > c = 5
>> >
>> > call = bar(1, 3)
>> >
>> > jump = bazz(1, 3)
>> >
>> >
>> > After execution, call in the above code would be 6 and jump in the
>> above code would be 4.
>>
>> You're trying to shed encapsulation (by having the jumped-to function
>> operate in the "caller's" namespace), but also pass parameters to it.
>> That's going to cause a lot of confusion.
>>
>> I'm sympathetic to the problem, but I don't think functions are the
>> solution here. You want some form of code block. There've been a
>> number of proposals along those lines, and so far, not one of them has
>> been really implementable. Check out some of the prior theories and
>> see if one of them will work for you.
>>
>> ChrisA
>> ___
>> Python-ideas 

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

[Abe Dillon]

Sorry for the double post, but I wanted to make sure you saw my original
misplaced post:

Jumping into functions that mutate variables in the calling scope sounds a
lot like "GoTo"  which is
notorious for leading to code that's very hard to reason about. Your
functions would implicitly require that you assign variables in the calling
scope before calling the function instead of explicitly requiring them in
the function's signature. That can be very confusing.

A lot of times, when I find that my function call signatures have become
unwieldy, it's a sign that I need to bundle a lot of related variables into
an object and either define methods on that object or pass that object to
functions instead of the large number of variables that it encapsulates.
You just use 'self' as a sort-of back-pack that carries around what you
need.

It's difficult to see what you're after from your Verb and Morpheme
example. They don't seem to call any functions that use variables from the
caller's scope. Can you flesh that out a bit more to show where the problem
arrises?
___
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

[Abe Dillon]

[Chris Angelico]

> Drop the word "function" and it's no longer about a goto - it's about
> a block of code that can be deposited into another context.


The only context I've used goto is in a TI-83 scientific calculator, but in
that, it was just about jumping around to different labels in code and had
nothing to do with functions. Though this may not have been the "canonical"
goto that Dijkstra considered harmful.

[Chris Angelico]

> By the way:


> > It's difficult to see what you're after from your Verb and Morpheme
> example.


> You're responding to MY post, which is a response to Jacob's. Please
> watch your use of pronouns; it would help a lot if you weren't top
> posting, and were directly responding to specific people's specific
> comments.


Sorry, I ran into a lot of problems trying to use the Google Groups
interface to post, so I've resorted to strictly using email. Unfortunately,
that makes the structure of the conversation less obvious to me. I'll try
to be more mindful of this in the future.

On Wed, Aug 15, 2018 at 4:58 PM, Chris Angelico  wrote:

> On Thu, Aug 16, 2018 at 7:40 AM, Abe Dillon  wrote:
> > Jumping into functions that mutate variables in the calling scope sounds
> a
> > lot like "GoTo" which is notorious for leading to code that's very hard
> to
> > reason about. Your functions would implicitly require that you assign
> > variables in the calling scope before calling the function instead of
> > explicitly requiring them in the function's signature. That can be very
> > confusing.
>
> Drop the word "function" and it's no longer about a goto - it's about
> a block of code that can be deposited into another context. If you
> were to copy and paste that code, its meaning would be defined by
> where it is used; the idea of a "code block" is that you can do that
> with something that can be passed around like a function, but isn't a
> function.
>
> We could borrow a term from the Python grammar and call it a "suite",
> perhaps, but "code block" is probably the best term. As mentioned,
> there have been previous proposals along these lines.
>
> By the way:
>
> > It's difficult to see what you're after from your Verb and Morpheme
> example.
>
> You're responding to MY post, which is a response to Jacob's. Please
> watch your use of pronouns; it would help a lot if you weren't top
> posting, and were directly responding to specific people's specific
> comments.
>
> ChrisA
> ___
> 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 Angelico]

On Thu, Aug 16, 2018 at 7:40 AM, Abe Dillon  wrote:
> Jumping into functions that mutate variables in the calling scope sounds a
> lot like "GoTo" which is notorious for leading to code that's very hard to
> reason about. Your functions would implicitly require that you assign
> variables in the calling scope before calling the function instead of
> explicitly requiring them in the function's signature. That can be very
> confusing.

Drop the word "function" and it's no longer about a goto - it's about
a block of code that can be deposited into another context. If you
were to copy and paste that code, its meaning would be defined by
where it is used; the idea of a "code block" is that you can do that
with something that can be passed around like a function, but isn't a
function.

We could borrow a term from the Python grammar and call it a "suite",
perhaps, but "code block" is probably the best term. As mentioned,
there have been previous proposals along these lines.

By the way:

> It's difficult to see what you're after from your Verb and Morpheme example.

You're responding to MY post, which is a response to Jacob's. Please
watch your use of pronouns; it would help a lot if you weren't top
posting, and were directly responding to specific people's specific
comments.

ChrisA
___
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

[Abe Dillon]

Jumping into functions that mutate variables in the calling scope sounds a
lot like "GoTo"  which is
notorious for leading to code that's very hard to reason about. Your
functions would implicitly require that you assign variables in the calling
scope before calling the function instead of explicitly requiring them in
the function's signature. That can be very confusing.

A lot of times, when I find that my function call signatures have become
unwieldy, it's a sign that I need to bundle a lot of related variables into
an object and either define methods on that object or pass that object to
functions instead of the large number of variables that it encapsulates.
You just use 'self' as a sort-of back-pack that carries around what you
need.

It's difficult to see what you're after from your Verb and Morpheme
example. They don't seem to call any functions that use variables from the
caller's scope. Can you flesh that out a bit better?


On Wed, Aug 15, 2018 at 3:24 PM, Chris Angelico  wrote:

> On Thu, Aug 16, 2018 at 4:52 AM, Jacob Solinsky 
> wrote:
> > -Jumping to a function as opposed to calling a function
> >
> > When a function is jumped to, it inherits the variables in the caller’s
> local namespace and is free to modify them or add new local variables,
> unlike a normal function call, wherein the caller’s namespace is
> inaccesible. At present, the only way I know of to accomplish this is to
> bundle all variables in the caller method’s namespace as properties of the
> method’s instance and have the callee method modify those properties.
> Though it is easier to read code written this way, it resulted in a great
> deal of redundancy in the code I was writing.
> >
>
> > Let foo(a, b) be the syntax to call foo(a, b), and foo(a, b)% be the
> syntax to jump to foo(a, b)
> >
> > def foo(a):
> > return a + c
> >
> > def bar(a, c):
> > return foo(a)
> >
> > def bazz(a, c):
> > return foo(a)%
> >
> > c = 5
> >
> > call = bar(1, 3)
> >
> > jump = bazz(1, 3)
> >
> >
> > After execution, call in the above code would be 6 and jump in the above
> code would be 4.
>
> You're trying to shed encapsulation (by having the jumped-to function
> operate in the "caller's" namespace), but also pass parameters to it.
> That's going to cause a lot of confusion.
>
> I'm sympathetic to the problem, but I don't think functions are the
> solution here. You want some form of code block. There've been a
> number of proposals along those lines, and so far, not one of them has
> been really implementable. Check out some of the prior theories and
> see if one of them will work for you.
>
> ChrisA
> ___
> 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 Angelico]

On Thu, Aug 16, 2018 at 4:52 AM, Jacob Solinsky  wrote:
> -Jumping to a function as opposed to calling a function
>
> When a function is jumped to, it inherits the variables in the caller’s local 
> namespace and is free to modify them or add new local variables, unlike a 
> normal function call, wherein the caller’s namespace is inaccesible. At 
> present, the only way I know of to accomplish this is to bundle all variables 
> in the caller method’s namespace as properties of the method’s instance and 
> have the callee method modify those properties. Though it is easier to read 
> code written this way, it resulted in a great deal of redundancy in the code 
> I was writing.
>

> Let foo(a, b) be the syntax to call foo(a, b), and foo(a, b)% be the syntax 
> to jump to foo(a, b)
>
> def foo(a):
> return a + c
>
> def bar(a, c):
> return foo(a)
>
> def bazz(a, c):
> return foo(a)%
>
> c = 5
>
> call = bar(1, 3)
>
> jump = bazz(1, 3)
>
>
> After execution, call in the above code would be 6 and jump in the above code 
> would be 4.

You're trying to shed encapsulation (by having the jumped-to function
operate in the "caller's" namespace), but also pass parameters to it.
That's going to cause a lot of confusion.

I'm sympathetic to the problem, but I don't think functions are the
solution here. You want some form of code block. There've been a
number of proposals along those lines, and so far, not one of them has
been really implementable. Check out some of the prior theories and
see if one of them will work for you.

ChrisA
___
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]

Hi Jacob

Thank you for your problem. I'll focus on your simple example (lightly
edited for clarity)

> Let foo(a, b) be the syntax to call foo(a, b), and foo(a, b)% be the syntax 
> to jump to foo(a, b)
>
> c = 5
>
> def foo(a):
> return a + c
>
> def bar(a, c):
> return foo(a)
>
> def bazz(a, c):
> return foo(a)%
>
> call = bar(1, 3) # 6, being 1 + 5
> bazz(1, 3) # 4, being 1 + 3

This may allow you to solve your verb and morpheme problem. But I hope
there's an easier way. One that can be done using Python as it is now.

My understanding is that you want a stack. Similar to the Python's
function call stack, but with something extra. So that functions
execute in an richer context.

Here's an idea. Start by giving us a toy example of a calculation
you'd like to do. Then the problem is: how to do this in Python.

By the way, are there any existing Python libraries for this sort of thing?

I hope this helps.

-- 
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] Does jargon make learning more difficult?

[Alexandre Brault]

On 2018-08-15 03:32 PM, MRAB wrote:
> On 2018-08-15 18:27, MRAB wrote:
>> On 2018-08-15 09:17, Jonathan Fine wrote:
>>> Steve Barnes and Greg Ewing wrote:
>>>
>   * A dinosaur is specifically an extinct terrible (formerly
> considered)
> lizard


 Which technically is not a lizard.
>>>
>>> I can't resist. Puffinus puffinus is the scientific name for
>>>
>>> (drum roll)
>>>
>>> no, not the Atlantic (or common) Puffin but
>>>
>>> (off-pitch fanfare)
>>>
>>> https://en.wikipedia.org/wiki/Manx_shearwater
>>>
>> While we're at it, what's the only creature that's known commonly and
>> only by its scientific name?
>>
> The answer is boa constrictor.
>
I would have guessed Tyrannosaurus Rex

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

[Jacob Solinsky]

-Jumping to a function as opposed to calling a function

When a function is jumped to, it inherits the variables in the caller’s local 
namespace and is free to modify them or add new local variables, unlike a 
normal function call, wherein the caller’s namespace is inaccesible. At 
present, the only way I know of to accomplish this is to bundle all variables 
in the caller method’s namespace as properties of the method’s instance and 
have the callee method modify those properties. Though it is easier to read 
code written this way, it resulted in a great deal of redundancy in the code I 
was writing. The task I was attempting to accomplish was approximately this:

class Verb:
def __init__(self, parameters):
self.parameters = parameters
def conjugate(self):
#Using the parameters, chose an appropriate list of morphemes 
to prefix and suffix to the verb
self.morphemelist = morphemelist
for morpheme in self.morphemelist:
morpheme.mutate()
returnstring = ‘'
for morpheme in self.morphemelist:
returnstring = returnstring + morpheme.form
returnstring = returnstring

class Morpheme:
def __init__(self, verb, form, precedingmorpheme, succeedingmorpheme):
self.verb = verb
self.form = form
self.precedingmorpheme = precedingmorpheme
self.succeedingmorpheme = succeedingmorpheme
def mutate(self): 
#Using the verb’s parameters and the type and form of the 
preceding and succeeding morpheme, mutate this morpheme’s form so that  
  #a correct verb form is produced
self.form = newform

class Ban(Morpheme):
def __init__(self, verb, form):
super().__init__(verb, ‘ban’)
def mutate(self):
#This morpheme has mutation logic unique to itself but with 
many similarities to the default morpheme’s mutation logic
self.form = newform

Each subclass of Morpheme has its own slightly different mutate method. Some 
subclasses of Morpheme needed to access and manipulate a great deal of 
information about the verb and their surroundings, while other subclasses’ 
mutate methods differed little from the default. Most of the variables 
manipulated by the mutate method are not used by any other methods of class 
Morpheme and thus should not be made properties of the attached instance. What 
I wish I were able to do is write many little methods that modify the same set 
of local variables and compose them together into a complete mutate method. 
This would be effectively equivalent to having the “jump to function” calls be 
replaced with the text in the function’s body, like a C language 
macrosubstitution, but without using anything like preprocessor directives.

Let foo(a, b) be the syntax to call foo(a, b), and foo(a, b)% be the syntax to 
jump to foo(a, b)

def foo(a):
return a + c

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

def bazz(a, c):
return foo(a)%

c = 5

call = bar(1, 3)

jump = bazz(1, 3)


After execution, call in the above code would be 6 and jump in the above code 
would be 4.


___
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] Does jargon make learning more difficult?

[MRAB]

On 2018-08-15 18:27, MRAB wrote:

On 2018-08-15 09:17, Jonathan Fine wrote:

Steve Barnes and Greg Ewing wrote:


  * A dinosaur is specifically an extinct terrible (formerly considered)
lizard



Which technically is not a lizard.


I can't resist. Puffinus puffinus is the scientific name for

(drum roll)

no, not the Atlantic (or common) Puffin but

(off-pitch fanfare)

https://en.wikipedia.org/wiki/Manx_shearwater


While we're at it, what's the only creature that's known commonly and
only by its scientific name?


The answer is boa constrictor.
___
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] Does jargon make learning more difficult?

[Danilo J. S. Bellini]

On 14 August 2018 at 16:42, Michael Selik  wrote:

> In my own experience teaching, I find that many concepts are easier to
> introduce if I avoid the Python jargon until after I've explained what it
> does. [...]
>

"until after" != "forever".

A jargon might be just an acronym, a word or few words, meaningless for
someone who doesn't know what it means [sic], but even for this person the
jargon is useful: he/she can look for information about it. Teaching the
other way around to let the student grasp the "mechanical procedure" before
its name doesn't change anything regarding the names.

You can make everyone memorize the algorithm for adding base-10 whole
numbers by hand without teaching the students words like "adding" or "sum",
not even the "+" symbol. But it would be a confusion if you use any other
symbol or word to replace these "maths jargon" ones, and you shouldn't
avoid the socially used names/symbols just because you're teaching that
stuff for kids who still doesn't know them. And I'm aware of students
complaining they can't remember something they've learned (or simply they
didn't know someone was talking about what they know, a communication
issue) because they didn't know the name (not even for searching in the
web, a dictionary, whatever...).

I really regret that I complained when expressions like "modus ponens" and
"disjunctive syllogism" were teached to me during a class in 2004, that day
I thought these stuff were so obvious that they shouldn't have a name.
Until I found, later, that I needed to know these names in order to
understand some stuff I was reading. These names might had been hard to
memorize, but they were better than arbitrary names that no one else
happens to use.

Some of my worst teachers avoided the proper jargon forever, not just
"until after" definitions/examples. Several classes here in Brazil tries to
teach some concepts by forcing everything to be in Portuguese, like an
"ideology of full translation", and sometimes the translated names are
meaningless (no social context external to the class uses them). I got
somewhat angry when I found that a lot of stuff I knew had other names in
every useful social context, and I know who/what I should blame for that.

Terminology is the first step when going into a new domain... an example,
marked as "Important unit", can be found at https://www.statistics-made-
easy.com/introduction-to-statistics/


*This introduction will teach you all the basic terms of statistics. It is
important to understand them well before studying the unit about organizing
data. The lessons are organized in a way to make the learning process as
smooth as possible. Follow the logical order given here to study the
lessons.*


[...] It's tempting to use terms based on the origin of the concept,
> historical odds and ends, or even jokes. [...]
>

Usually, you're not naming something new and unnamed... but sometimes the
concept might have more than a single name. I think that's like irregular
verbs: they're so common that they "break the patterns"; concepts that are
spread/scattered everywhere might have a distinct name in each domain.

Names should be useful to precisely express the concept in social contexts,
but there's a context that should never be considered for that: the
"teaching" one. If the concept itself isn't known by some people, why care
about an alternative "non-jargon" name? A name doesn't belong to a person
or a class, but to the people who can use/understand it, and I believe
using proper jargon instead of alternative "simplified" names should
maximize that.

It's the social expressiveness towards people who already know the concepts
that should be emphasized, not some other arbitrary "simplification" goal
(e.g. minimize the number of characters, only use English, ...).

IMHO, avoiding jargon sounds like avoiding teaching. In the case of new
Python stuff, avoiding the socially standardized terminology is an act of
isolation/seclusion.

-- 
Danilo J. S. Bellini
---
"*It is not our business to set up prohibitions, but to arrive at
conventions.*" (R. Carnap)
___
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] Python docs page: In what ways is None special

[Jonathan Fine]

Hi

Thank you all, for the kind words and appreciation, and the comments
and suggestions. I have time now to respond to one comment. Please
note that is just my opinion, and your opinion may be different.

Rhodri James prefers
(https://mail.python.org/pipermail/python-ideas/2018-August/052742.html)
> Sometimes a value is required but we're not able to provide one.
to my
> Sometimes a value is required. But we're not able to provide one.

The next sentence is
> In Python, we can use None to solve this problem.

I chose the punctuation I did, because I wanted to state clearly the
problem. Which is, roughly speaking, damned if you do, and damned if
you don't. (In the US, between a rock and a hard place.)

In other words, a dilemma.
https://www.dictionary.com/browse/dilemma
a choice between [...] undesirable alternatives.

This paragraph
> Sometimes a value is required. But we're not able to
> provide one. In Python, we can use None to solve
> this problem.
is in my mind None in a nutshell.

Rhodri says my version, exaggerated for effect, reads like
> Sometimes a value is required.  But (pay careful attention
> to this, it's important and there will be a quiz later)
> we're not able to provide one.

Yes, Rhodri, you've understood what I'm doing. I do want the reader to
pay careful attention. If they only remember one thing, this is what I
want them to remember.

Rhodri say that his version reads more easily. I agree. And that that
is why I prefer my version!

Sometimes you have to slow the reader down, so that there's time for
understanding to catch up. Short sentences catch attention. Long
sentences, with many clauses and a variation of ideas, go by like the
scenery on a long and monotonous care journey. And little is
remembered.

The lesson I take from this is not that I am right and Rhodri is
wrong. Or the other way round. That depends on context, taste and
house style. And often, there are good reasons on both sides of the
decision. So the starting point for persuading someone to change their
mind might be this: Understand the forces that led them to the
position they hold.

Sometime before the end of the month, I'll process the remaining
contributions and comments. I hope it doesn't take me more than an
hour or two. I'll start by looking at github issues, then pull
requests, and then python-ideas.

Once again, thank you for all the comments and suggestions. And the
kind words and appreciation.
-- 
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] Does jargon make learning more difficult?

[MRAB]

On 2018-08-15 09:17, Jonathan Fine wrote:

Steve Barnes and Greg Ewing wrote:


  * A dinosaur is specifically an extinct terrible (formerly considered)
lizard



Which technically is not a lizard.


I can't resist. Puffinus puffinus is the scientific name for

(drum roll)

no, not the Atlantic (or common) Puffin but

(off-pitch fanfare)

https://en.wikipedia.org/wiki/Manx_shearwater

While we're at it, what's the only creature that's known commonly and 
only by its scientific name?

___
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] Python docs: page: In what ways in None special

[Chris Barker via Python-ideas]

Since I already spent a bunch of time on this, I did a PR:

https://github.com/jfine2358/py-jfine2358/pull/2

further discussion should probably be in that PR / repo

-CHB


On Wed, Aug 15, 2018 at 9:02 AM, Chris Barker - NOAA Federal <
chris.bar...@noaa.gov> wrote:

> > None is keyword, and just like any other keyword, it can't be re-bound.
>
>
> >> it's only a keyword because Python doesn't otherwise have a way of
> creating non-rebindable names.  It's purpose is to represent the singular
> object of NoneType, and in that sense it's a literal as much as [] or "".
>
> We’re getting kind of pedantic here, but no, it’s not “as much as” — []
> and “” create new instances of a list or string.
>
> For the purposes of this document, however, these are pretty esoteric
> distinctions.
>
> What the docs should make clear is that None ( and True and False ) is a
> singleton— None will always refer to the SAME None object.
>
> And that can be demonstrated by showing that you can’t rebind the name
> None.
>
> But I think it’s misleading to say that that is the same as:
>
> 42 = “something else”
>
> None is syntactical a name like any other — what’s special about is that
> it can’t be rebound.
>
> -CHB
>
> >
> > --
> > Rhodri James *-* Kynesim Ltd
>



-- 

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] Python docs: page: In what ways in None special

[Chris Barker - NOAA Federal via Python-ideas]

> None is keyword, and just like any other keyword, it can't be re-bound.


>> it's only a keyword because Python doesn't otherwise have a way of creating 
>> non-rebindable names.  It's purpose is to represent the singular object of 
>> NoneType, and in that sense it's a literal as much as [] or "".

We’re getting kind of pedantic here, but no, it’s not “as much as” —
[] and “” create new instances of a list or string.

For the purposes of this document, however, these are pretty esoteric
distinctions.

What the docs should make clear is that None ( and True and False ) is
a singleton— None will always refer to the SAME None object.

And that can be demonstrated by showing that you can’t rebind the name None.

But I think it’s misleading to say that that is the same as:

42 = “something else”

None is syntactical a name like any other — what’s special about is
that it can’t be rebound.

-CHB

>
> --
> Rhodri James *-* Kynesim Ltd
___
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] Does jargon make learning more difficult?

[Greg Ewing]

Jonathan Fine wrote:

Puffinus puffinus is the scientific name for


Puff the Magic Dragon?

--
Greg
___
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] Python docs: page: In what ways in None special

[Rhodri James]

On 15/08/18 00:09, Chris Barker wrote:

On Tue, Aug 14, 2018 at 10:45 AM, Rhodri James  wrote:


On 'None is a constant':

Erm.  I think you've got carried away with simplifying this and gone down
a blind alley.  None is a literal, and like any other literal can't be
rebound.


no, it's not -- None is keyword, and just like any other keyword, it can't
be re-bound. However, every other keyword I tried to rebind results in a
generic:


It's both, really.  In many ways it's only a keyword because Python 
doesn't otherwise have a way of creating non-rebindable names.  It's 
purpose is to represent the singular object of NoneType, and in that 
sense it's a literal as much as [] or "".


--
Rhodri James *-* Kynesim Ltd
___
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] Does jargon make learning more difficult?

[Rhodri James]

On 15/08/18 06:21, Steve Barnes wrote:

The English language has, historically, always borrowed, co-opted and
sometimes perverted words from other languages to allow distinct
concepts to be expressed concisely - which I personally, (admittedly as
a native speaker), find rather useful.


I think you and Michael are arguing to the same end.  He was suggesting 
that it's easier to teach a concept by introducing the idea and then a 
name for it, rather like the way Python creates objects before binding them.


--
Rhodri James *-* Kynesim Ltd
___
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] Does jargon make learning more difficult?

[Jonathan Fine]

Steve Barnes and Greg Ewing wrote:

>>   * A dinosaur is specifically an extinct terrible (formerly considered)
>> lizard
>
>
> Which technically is not a lizard.

I can't resist. Puffinus puffinus is the scientific name for

(drum roll)

no, not the Atlantic (or common) Puffin but

(off-pitch fanfare)

https://en.wikipedia.org/wiki/Manx_shearwater

-- 
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] Does jargon make learning more difficult?

[Greg Ewing]

Steve Barnes wrote:

  * Brakes are used to apply breaking,


I hope they actually apply braking, not breaking. :-)

  * A dinosaur is specifically an extinct terrible (formerly considered) 
lizard


Which technically is not a lizard.

--
Greg
___
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] Does jargon make learning more difficult?

[Michael Selik]

On Wed, Aug 15, 2018, 12:06 AM Stefan Behnel  wrote:

> Michael Selik schrieb am 14.08.2018 um 21:42:
> > This is supported by education research. Some light Googling found a
> > study on the topic [0] that is consistent with my own observations.
>
> OTx2, and no offence, but … this is supported by research as well. People
> tend to search just long enough to find the link that backs their …
> observations. :)
>

Of course! No offense taken. I did "light Googling", not a literature
review.

>
___
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] Does jargon make learning more difficult?

[Stefan Behnel]

Michael Selik schrieb am 14.08.2018 um 21:42:
> This is supported by education research. Some light Googling found a
> study on the topic [0] that is consistent with my own observations.

OTx2, and no offence, but … this is supported by research as well. People
tend to search just long enough to find the link that backs their …
observations. :)

Stefan

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/