[issue210656] IDLE goto file/line (PR#352)

[admin]

Change by admin :


___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue210656] IDLE goto file/line (PR#352)

[admin]

Change by admin :


--
github: None -> 32727

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44060] Define TARGET macro the same even when computed goto support is not enabled

[Skip Montanaro]

Change by Skip Montanaro :


--
keywords: +patch
pull_requests: +24612
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25949

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44060] Define TARGET macro the same even when computed goto support is not enabled

[Skip Montanaro]

New submission from Skip Montanaro :

When the interpreter is compiled with computed goto support, the TARGET macro 
is defined like this:

#define TARGET(op) op: TARGET_##op

If computed gotos are disabled, the implementation is simpler:

#define TARGET(op) op

I'm finding it useful to use those labels as gdb breakpoint targets. Is there 
some reason not to always define the TARGET_##op label?

--
components: Interpreter Core
messages: 393099
nosy: skip.montanaro
priority: normal
severity: normal
status: open
title: Define TARGET macro the same even when computed goto support is not 
enabled
type: enhancement
versions: Python 3.11

___
Python tracker 
<https://bugs.python.org/issue44060>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43199] FAQ about goto lacks answer

[Terry J. Reedy]

Change by Terry J. Reedy :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.6, Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43199] FAQ about goto lacks answer

[miss-islington]

miss-islington  added the comment:


New changeset 59f2741c4a1a53d4122d2cb512337f4b88619de9 by Miss Islington (bot) 
in branch '3.8':
bpo-43199: Briefly explain why no goto (GH-24852)
https://github.com/python/cpython/commit/59f2741c4a1a53d4122d2cb512337f4b88619de9


--

___
Python tracker 
<https://bugs.python.org/issue43199>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43199] FAQ about goto lacks answer

[miss-islington]

miss-islington  added the comment:


New changeset c3f0c3a9c7aa213a463c5928d33fd4049060 by Miss Islington (bot) 
in branch '3.9':
bpo-43199: Briefly explain why no goto (GH-24852)
https://github.com/python/cpython/commit/c3f0c3a9c7aa213a463c5928d33fd4049060


--

___
Python tracker 
<https://bugs.python.org/issue43199>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43199] FAQ about goto lacks answer

[miss-islington]

Change by miss-islington :


--
pull_requests: +23623
pull_request: https://github.com/python/cpython/pull/24863

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43199] FAQ about goto lacks answer

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +23622
pull_request: https://github.com/python/cpython/pull/24862

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43199] FAQ about goto lacks answer

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset 5e29021a5eb10baa9147fd977cab82fa3f652bf0 by Terry Jan Reedy in 
branch 'master':
bpo-43199: Briefly explain why no goto (GH-24852)
https://github.com/python/cpython/commit/5e29021a5eb10baa9147fd977cab82fa3f652bf0


--

___
Python tracker 
<https://bugs.python.org/issue43199>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43199] FAQ about goto lacks answer

[Terry J. Reedy]

Change by Terry J. Reedy :


--
keywords: +patch
nosy: +terry.reedy
nosy_count: 2.0 -> 3.0
pull_requests: +23613
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24852

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43199] FAQ about goto lacks answer

[Mikael Lövqvist]

New submission from Mikael Lövqvist :

In the FAQ there is a question "Why is there no goto?" but the answer addresses 
how to use exceptions to do something akin to goto. I think the documentation 
could benefit from the reasons why there is no goto or that the question is 
changed, perhaps "How to approximate goto?".

Reference: https://docs.python.org/3/faq/design.html#why-is-there-no-goto

--
assignee: docs@python
components: Documentation
messages: 386825
nosy: docs@python, mlovqvist
priority: normal
severity: normal
status: open
title: FAQ about goto lacks answer
type: enhancement
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue43199>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42144] A missing "goto" in the _ssl module!

[Christian Heimes]

Christian Heimes  added the comment:

Thanks, excellent finding.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42144] A missing "goto" in the _ssl module!

[miss-islington]

miss-islington  added the comment:


New changeset 83c86cf54b36a7325f615f5adf22b28e48f0e72d by Miss Skeleton (bot) 
in branch '3.9':
bpo-42144: Add a missing "goto error;" in the _ssl module (GH-22959)
https://github.com/python/cpython/commit/83c86cf54b36a7325f615f5adf22b28e48f0e72d


--

___
Python tracker 
<https://bugs.python.org/issue42144>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42144] A missing "goto" in the _ssl module!

[miss-islington]

miss-islington  added the comment:


New changeset 8e980ecfb7b42063ed41d665288aff69f0ed7fdc by Miss Skeleton (bot) 
in branch '3.8':
bpo-42144: Add a missing "goto error;" in the _ssl module (GH-22959)
https://github.com/python/cpython/commit/8e980ecfb7b42063ed41d665288aff69f0ed7fdc


--

___
Python tracker 
<https://bugs.python.org/issue42144>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42144] A missing "goto" in the _ssl module!

[miss-islington]

miss-islington  added the comment:


New changeset c32f2976b8f4034724c3270397aa16f38daf470f by Zackery Spytz in 
branch 'master':
bpo-42144: Add a missing "goto error;" in the _ssl module (GH-22959)
https://github.com/python/cpython/commit/c32f2976b8f4034724c3270397aa16f38daf470f


--
nosy: +miss-islington

___
Python tracker 
<https://bugs.python.org/issue42144>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42144] A missing "goto" in the _ssl module!

[miss-islington]

Change by miss-islington :


--
pull_requests: +21892
pull_request: https://github.com/python/cpython/pull/22975

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42144] A missing "goto" in the _ssl module!

[miss-islington]

Change by miss-islington :


--
pull_requests: +21891
pull_request: https://github.com/python/cpython/pull/22974

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42144] A missing "goto" in the _ssl module!

[Zackery Spytz]

Change by Zackery Spytz :


--
keywords: +patch
pull_requests: +21876
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/22959

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42144] A missing "goto" in the _ssl module!

[Zackery Spytz]

New submission from Zackery Spytz :

In the _ssl_configure_hostname() function, there's a missing "goto error;" if
SSL_set_tlsext_host_name() fails.

--
assignee: christian.heimes
components: Extension Modules, SSL
messages: 379562
nosy: ZackerySpytz, christian.heimes
priority: normal
severity: normal
status: open
title: A missing "goto" in the _ssl module!
versions: Python 3.10, Python 3.8, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue42144>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27115] IDLE goto should use query.Query subclass

[Terry J. Reedy]

Change by Terry J. Reedy :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27115] IDLE goto should use query.Query subclass

[miss-islington]

miss-islington  added the comment:


New changeset f8345358bcdd276eb470778daf05d343da9f1290 by Miss Islington (bot) 
in branch '3.7':
bpo-27115: Use Query subclass for IDLE editor Goto (GH-18871)
https://github.com/python/cpython/commit/f8345358bcdd276eb470778daf05d343da9f1290


--

___
Python tracker 
<https://bugs.python.org/issue27115>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27115] IDLE goto should use query.Query subclass

[miss-islington]

miss-islington  added the comment:


New changeset cadfe52a006abb46ea0948c6ae2e006064b4a091 by Miss Islington (bot) 
in branch '3.8':
bpo-27115: Use Query subclass for IDLE editor Goto (GH-18871)
https://github.com/python/cpython/commit/cadfe52a006abb46ea0948c6ae2e006064b4a091


--

___
Python tracker 
<https://bugs.python.org/issue27115>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27115] IDLE goto should use query.Query subclass

[miss-islington]

Change by miss-islington :


--
pull_requests: +18243
pull_request: https://github.com/python/cpython/pull/18886

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27115] IDLE goto should use query.Query subclass

[miss-islington]

Change by miss-islington :


--
pull_requests: +18244
pull_request: https://github.com/python/cpython/pull/18887

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27115] IDLE goto should use query.Query subclass

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset 363fab83b8a0e6d924c7a7c577feec6a2812bb8c by Terry Jan Reedy in 
branch 'master':
bpo-27115: Use Query subclass for IDLE editor Goto (GH-18871)
https://github.com/python/cpython/commit/363fab83b8a0e6d924c7a7c577feec6a2812bb8c


--

___
Python tracker 
<https://bugs.python.org/issue27115>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39852] IDLE: Goto should remove selection and update the status bar

[Terry J. Reedy]

Terry J. Reedy  added the comment:

https://github.com/python/devguide/issues/577

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39852] IDLE: Goto should remove selection and update the status bar

[Guido van Rossum]

Guido van Rossum  added the comment:

I guess it's similar to the 'return' vs. 'returns' issue, but I feel much
stronger about it here.

I would have written that as "make the spam module more spammy". Just read
a bunch of commits using e.g. `git log --oneline` to see what the
prevailing style is.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27115] IDLE goto should use query.Query subclass

[Terry J. Reedy]

Change by Terry J. Reedy :


--
pull_requests: +18229
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/18871

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27115] IDLE goto should use query.Query subclass

[Terry J. Reedy]

Change by Terry J. Reedy :


--
dependencies:  -Finish IDLE Query dialog appearance and behavior.
stage: patch review -> test needed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39852] IDLE: Goto should remove selection and update the status bar

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Is it the temporal ambiguity (fixed by adding 'now', which is in the blurbs) or 
the descriptive versus command style (as with 'Returns' versus 'Return') that 
you do not like?  If the latter, the devguide could use augmentation.

The only relevant 'guidance' I found is this descriptive example in 
https://devguide.python.org/pullrequest/#making-good-commits: "the spam module 
is now more spammy".  This seems similar to "IDLE context menu now clears 
selection".  I don't see anything about commit messages in 
https://devguide.python.org/committing/, which seems like another likely place 
for such.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27115] IDLE goto should use query.Query subclass

[miss-islington]

miss-islington  added the comment:


New changeset f3f0c7a108cd2a5071592e77e2f4b14ca35d4fcc by Miss Islington (bot) 
in branch '3.8':
bpo-27115: Move IDLE Query error blanking (GH-18868)
https://github.com/python/cpython/commit/f3f0c7a108cd2a5071592e77e2f4b14ca35d4fcc


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27115] IDLE goto should use query.Query subclass

[miss-islington]

miss-islington  added the comment:


New changeset 9d5ed8355d4cb73ab13fa6094c9ab57798dff3be by Miss Islington (bot) 
in branch '3.7':
bpo-27115: Move IDLE Query error blanking (GH-18868)
https://github.com/python/cpython/commit/9d5ed8355d4cb73ab13fa6094c9ab57798dff3be


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27115] IDLE goto should use query.Query subclass

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +18227
pull_request: https://github.com/python/cpython/pull/18869

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27115] IDLE goto should use query.Query subclass

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset e53a3932cb01683b0fa8a7448ca25a2e658c39e6 by Terry Jan Reedy in 
branch 'master':
bpo-27115: Move IDLE Query error blanking (GH-18868)
https://github.com/python/cpython/commit/e53a3932cb01683b0fa8a7448ca25a2e658c39e6


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27115] IDLE goto should use query.Query subclass

[miss-islington]

Change by miss-islington :


--
pull_requests: +18228
pull_request: https://github.com/python/cpython/pull/18870

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27115] IDLE goto should use query.Query subclass

[Terry J. Reedy]

Change by Terry J. Reedy :


--
keywords: +patch
pull_requests: +18226
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/18868

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39852] IDLE: Goto should remove selection and update the status bar

[Guido van Rossum]

Guido van Rossum  added the comment:

I have a nit on the commit message used here (and also in issue 39885). 
*Please* don't use this style of commit message "IDLE context menu clears 
selection". That phrasing sounds like it is the description of a bug. Please 
always use a phrasing that makes it clear what the commit/PR changes. In this 
case, for example, it could be "IDLE: make context menu clear selection".

I know there are projects that prefer this style. Python is not one of them. 
Please comply.

--
nosy: +gvanrossum

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27115] IDLE goto should use query.Query subclass

[Terry J. Reedy]

Terry J. Reedy  added the comment:

The related issue is #39852.  Since its PR-18801 fixed the status issue, I am 
returning this to the box replacement issue.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27115] IDLE goto should use query.Query subclass

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Since PR-18801 fixed the status issue, I am returning this to the box 
replacement issue.

--
title: IDLE goto should always update status bar line & column -> IDLE goto 
should use query.Query subclass

___
Python tracker 
<https://bugs.python.org/issue27115>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39852] IDLE: Goto should remove selection and update the status bar

[miss-islington]

miss-islington  added the comment:


New changeset ec61f53243a4455f41e37a5c645e668661952c28 by Miss Islington (bot) 
in branch '3.7':
bpo-39852: IDLE 'Go to line' deletes selection, updates status (GH-18801)
https://github.com/python/cpython/commit/ec61f53243a4455f41e37a5c645e668661952c28


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39852] IDLE: Goto should remove selection and update the status bar

[Terry J. Reedy]

Change by Terry J. Reedy :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39852] IDLE: Goto should remove selection and update the status bar

[miss-islington]

miss-islington  added the comment:


New changeset a5e821c7269ebed6e8b4b4eee3f2247ec41a9788 by Miss Islington (bot) 
in branch '3.8':
bpo-39852: IDLE 'Go to line' deletes selection, updates status (GH-18801)
https://github.com/python/cpython/commit/a5e821c7269ebed6e8b4b4eee3f2247ec41a9788


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39852] IDLE: Goto should remove selection and update the status bar

[miss-islington]

Change by miss-islington :


--
pull_requests: +18215
pull_request: https://github.com/python/cpython/pull/18858

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39852] IDLE: Goto should remove selection and update the status bar

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 2.0 -> 3.0
pull_requests: +18214
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/18857

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39852] IDLE: Goto should remove selection and update the status bar

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset 2522db11df102be3baf25ce9e816ebe8ffdb7fcc by Terry Jan Reedy in 
branch 'master':
bpo-39852: IDLE 'Go to line' deletes selection, updates status (GH-18801)
https://github.com/python/cpython/commit/2522db11df102be3baf25ce9e816ebe8ffdb7fcc


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39852] IDLE: Goto should remove selection and update the status bar

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Agreed about right clicks.  See new issue #39885.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39852] IDLE: Goto should remove selection and update the status bar

[Dave Liptack]

Dave Liptack  added the comment:

Like goto, right-click also exhibits this behavior.  Should selection_clear 
also be added to right-click code?

--

___
Python tracker 
<https://bugs.python.org/issue39852>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39852] IDLE: Goto should remove selection and update the status bar

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I am expanding this issue to include the part of #27115 that the PR will  fix. 
(I will also change the scope of the latter).

--
stage: patch review -> needs patch
title: IDLE: Goto should remove any selection -> IDLE: Goto should remove 
selection and update the status bar

___
Python tracker 
<https://bugs.python.org/issue39852>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39852] IDLE: Goto should remove any selection

[Terry J. Reedy]

Change by Terry J. Reedy :


--
keywords: +patch
pull_requests: +18157
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/18801

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39852] IDLE: Goto should remove any selection

[Terry J. Reedy]

Terry J. Reedy  added the comment:

selection_clear only partially clears a selection.  That it does something is 
proven by selection_clear.py.  It disables selection_get.  But run the file in 
IDLE and when it finishes, click the tk window, select a line, click Shell, and 
manually repeat the last 3 lines.  selection_get is disabled again, but upon 
clicking the title bar of the tk window (to not affect selection in the 
window), the selection is still highlighted.  Further experiments showed that 
the insertion-deletion bug of this issue remains when using selection_own and 
selection_clear in IDLE.

The alternative of simulating a click on the moved insert cursor is harder by 
works, at least on Windows.  This also triggers a status-bar update -- see 
#27115.

--
Added file: https://bugs.python.org/file48957/selection_clear.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27115] IDLE goto should always update status bar line & column

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I changed the title to reflect the intended user-visible behavior, which was 
always the real issue.  The original title proposed a solution that would not 
work.  The revised title gave an alternate solution that should not work.   

The discrepancy between clicking [Ok] and and pressing  arises because 
pressing Enter in the query box leaks  to the text, which 
happens to trigger a status bar update.  I regard this somewhat accidental 
side-effect to be a bug to be fixed.  Changing the text and status bar are the 
responsibility of the event handler.

The line number query box should just return a positive int or None, without 
side-effect.  So we should make sure that Query boxes do not leak key events 
and create a subclass to get a positive int.  But such a replacement is 
somewhat independent of triggering <>. 

A related issue is that goto does not clear selections. #39844.  I may fix that 
and this with one PR.

--
title: IDLE: replace uses of tkinter simpledialog with query.Query -> IDLE goto 
should always update status bar line & column

___
Python tracker 
<https://bugs.python.org/issue27115>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39852] IDLE: Goto should remove any selection

[Terry J. Reedy]

Terry J. Reedy  added the comment:

This is much clearer.  To expand on what I said before, inserting *anything*, 
such as by hitting a key, replaces a selection.  I verified that this is normal 
behavior, at least on Windows, with Notepad, Notepad++, and this Firefox entry 
box I am typing in.  So either of your steps 6 or 7 delete the still selected 
line, after the goto.  (And so a click is needed before 6 to stop the 
deletion.)  I see the continued selection as the problem.  Both Notepad and 
Notepad++ unselect any selection upon goto, the same as if one moved the cursor 
by clicking instead of goto.

I will try adding text.selection_clear() to the goto code.

--
stage:  -> needs patch
title: IDLE: Copy/Paste behaves like Cut/Paste -> IDLE: Goto should remove any 
selection
versions: +Python 3.7, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue39852>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Goto

[John Wong]

I think the point is there is not much to discuss. Goto is not going to be
added. Furthermore, for every program language you want to translate from
source, you have to find a workaround. Otherwise, your translation will
only work for languages that have goto. Even so the implementation may not
be exact what C goto is. Who knows. Much like in Go - the other day, slice
there has a different behavior to Python’s slice. I brought this up to show
that don’t expect everything to be equal.

John

On Tue, Jan 2, 2018 at 12:35 bartc <b...@freeuk.com> wrote:

> On 02/01/2018 15:20, Chris Angelico wrote:
> > On Wed, Jan 3, 2018 at 1:51 AM, bartc <b...@freeuk.com> wrote:
>
> >> I like to write code in a simple, clean, universal style that everyone
> can
> >> understand.
> >>
> >> That doesn't mean it has to look like Fortran.
> >
> > Why are you using a Python interpreter then? Why are you here on
> > python-list, talking about Python? There must be SOME reason for using
> > this language rather than another.
>
> I'm more familiar with Python than any other like languages.
>
> If I desperately needed a dynamic language and I couldn't use my own,
> then I would use Python.
>
> But I would need to use it on my own terms, regardless of whether the
> result is 'pythonic'. If the language had 'goto', then I would use it if
> I found it apt.
>
> However, the discussion here is academic, so it doesn't matter who uses
> what.
>
> Apart from anything else, Python is never going to officially adopt
> 'goto'. (Regardless of some version of it being available as an add-on
> library. Most things seem to be.)
>
>
> --
> bartc
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
Sent from Jeff Dean's printf() mobile console
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python goto

[Chris Angelico]

On Wed, Jan 3, 2018 at 5:16 AM, Rob Gaddi
<rgaddi@highlandtechnology.invalid> wrote:
> On 12/28/2017 04:35 AM, Skip Montanaro wrote:
>>
>> Jorge> I would like to know if there is a goto command or something
>> similar that
>> Jorge> I can use in Python.
>>
>> Ned> Python does not have a goto statement. You have to use structured
>> Ned> statements: for, while, try/except, yield, return, etc.
>>
>> Though it appears some wag has used function decorators to implement
>> goto statements:
>>
>> https://pypi.python.org/pypi/goto-statement/1.1
>>
>> Rather clever, it seems.
>>
>> Skip
>>
>
> If only all that power had been used for good instead of evil...
>

An evto statement?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python goto

[Rob Gaddi]

On 12/28/2017 04:35 AM, Skip Montanaro wrote:

Jorge> I would like to know if there is a goto command or something similar that
Jorge> I can use in Python.

Ned> Python does not have a goto statement. You have to use structured
Ned> statements: for, while, try/except, yield, return, etc.

Though it appears some wag has used function decorators to implement
goto statements:

https://pypi.python.org/pypi/goto-statement/1.1

Rather clever, it seems.

Skip



If only all that power had been used for good instead of evil...

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto

[bartc]

On 02/01/2018 15:20, Chris Angelico wrote:

On Wed, Jan 3, 2018 at 1:51 AM, bartc <b...@freeuk.com> wrote:



I like to write code in a simple, clean, universal style that everyone can
understand.

That doesn't mean it has to look like Fortran.


Why are you using a Python interpreter then? Why are you here on
python-list, talking about Python? There must be SOME reason for using
this language rather than another.


I'm more familiar with Python than any other like languages.

If I desperately needed a dynamic language and I couldn't use my own, 
then I would use Python.


But I would need to use it on my own terms, regardless of whether the 
result is 'pythonic'. If the language had 'goto', then I would use it if 
I found it apt.


However, the discussion here is academic, so it doesn't matter who uses 
what.


Apart from anything else, Python is never going to officially adopt 
'goto'. (Regardless of some version of it being available as an add-on 
library. Most things seem to be.)



--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto

[Chris Angelico]

On Wed, Jan 3, 2018 at 1:51 AM, bartc  wrote:
> On 29/12/2017 18:11, Chris Angelico wrote:
>>
>> On Sat, Dec 30, 2017 at 4:13 AM, bartc  wrote:
>>>
>>> If you want to translate code from one language to another, and the
>>> source
>>> language uses gotos, or uses control structures not available in the
>>> target
>>> language, then gotos would be very useful in the latter.
>>>
>>
>> As has already been said in this thread, a competent FORTRAN
>> programmer can write FORTRAN code in any language. But if you want to
>> actually write Python code, instead of writing FORTRAN code that gets
>> run through a Python interpreter, you have to grok the Python way of
>> doing things.
>
>
> That's not true. People should be able to write code as they like using the
> nearest available language and using the style they are most adept in and
> that they find comfortable. /Especially/ if they are coding for themselves
> rather as part of some organisation or within a team.
>
> The choice of language may enforce some changes, but that should be the
> extent of it.
>
> A lot of the so-called 'Pythonic' style I frankly don't care for.
>
> I like to write code in a simple, clean, universal style that everyone can
> understand.
>
> That doesn't mean it has to look like Fortran.

Why are you using a Python interpreter then? Why are you here on
python-list, talking about Python? There must be SOME reason for using
this language rather than another.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto

[bartc]

On 29/12/2017 18:11, Chris Angelico wrote:

On Sat, Dec 30, 2017 at 4:13 AM, bartc  wrote:

If you want to translate code from one language to another, and the source
language uses gotos, or uses control structures not available in the target
language, then gotos would be very useful in the latter.



As has already been said in this thread, a competent FORTRAN
programmer can write FORTRAN code in any language. But if you want to
actually write Python code, instead of writing FORTRAN code that gets
run through a Python interpreter, you have to grok the Python way of
doing things.


That's not true. People should be able to write code as they like using 
the nearest available language and using the style they are most adept 
in and that they find comfortable. /Especially/ if they are coding for 
themselves rather as part of some organisation or within a team.


The choice of language may enforce some changes, but that should be the 
extent of it.


A lot of the so-called 'Pythonic' style I frankly don't care for.

I like to write code in a simple, clean, universal style that everyone 
can understand.


That doesn't mean it has to look like Fortran.


You can't do that by mechanically transforming source
code into the syntax of a different language.


(Actually that's exactly what a project of mine from a few years ago was 
trying to do.


Example of 'binary trees' benchmark:

source syntax:https://pastebin.com/raw/bgfKw2pq

generated Python: https://pastebin.com/raw/XJWjWzpw)

Here, you normally had to be aware when writing in the source language, 
of what target language you were using. Although sometimes exactly the 
same source translated to several targets including Python and Lisp. 
Anyway, this was unsatisfactory as a universal syntax that could be 
translated to any language.)



People who try to tell you that all programming languages are
identical, just with different syntax, are doing you a disservice.
Lisp is not Python is not REXX is not C is not DeScribe Macro
Language. (Especially the latter. Do NOT try to write C code in DML.
It'll look ugly. Trust me.


My experiment showed that such people have a point.

--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Chris Angelico]

On Tue, Jan 2, 2018 at 9:11 AM,   wrote:
> On Monday, January 1, 2018 at 9:35:06 PM UTC, Chris Angelico wrote:
>> On Tue, Jan 2, 2018 at 7:16 AM, Chris Green wrote:
>> > Dennis Lee Bieber wrote:
>> >>
>> >> Well... "break" does bypass the rest of the block, but it still 
>> >> exits
>> >> via the end of the block. I have a tendency to try for one "return" per
>> >> procedure (so I'm more likely to have an "if ...: break" then "if ...:
>> >> return").
>> >
>> > I have always tried to enforce 'only one return per function'.  If
>> > there are multiple returns it makes maintenance very difficult as
>> > 'clear up' code can get bypassed.
>> >
>>
>> Isn't that why try/finally exists? No matter how many 'return'
>> statements you have, there's always exceptions to bypass any naive
>> cleanup code; and no matter how many returns you have, 'finally'
>> blocks still execute before return.
>>
>> ChrisA
>
> What happened to context managers?
>

They're a way of wrapping up repeatedly-used try/finally blocks. The
try/finally construct is the underlying functionality. In any case,
the same behaviour can be used by either, so yes, if you have cleanup
code and you're using 'with x:' rather than try/finally, it still fits
into the same concept that I'm describing, and still guarantees that
the cleanup code is executed before return.

(Yes, I know it's possible to bypass finally blocks. But the methods
for doing so (eg hard-aborting) also bypass the actual return, so the
"before return" part is still valid. If you're doing things that
depend on cleanup outside the process, like deleting temporary files,
you'll need something more than try/finally. But in that case, there's
no other code layout that would help you anyway.)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[breamoreboy]

On Monday, January 1, 2018 at 9:35:06 PM UTC, Chris Angelico wrote:
> On Tue, Jan 2, 2018 at 7:16 AM, Chris Green wrote:
> > Dennis Lee Bieber wrote:
> >>
> >> Well... "break" does bypass the rest of the block, but it still 
> >> exits
> >> via the end of the block. I have a tendency to try for one "return" per
> >> procedure (so I'm more likely to have an "if ...: break" then "if ...:
> >> return").
> >
> > I have always tried to enforce 'only one return per function'.  If
> > there are multiple returns it makes maintenance very difficult as
> > 'clear up' code can get bypassed.
> >
> 
> Isn't that why try/finally exists? No matter how many 'return'
> statements you have, there's always exceptions to bypass any naive
> cleanup code; and no matter how many returns you have, 'finally'
> blocks still execute before return.
> 
> ChrisA

What happened to context managers?

--
Kindest regards.

Mark Lawrence.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Chris Angelico]

On Tue, Jan 2, 2018 at 7:16 AM, Chris Green  wrote:
> Dennis Lee Bieber  wrote:
>>
>> Well... "break" does bypass the rest of the block, but it still exits
>> via the end of the block. I have a tendency to try for one "return" per
>> procedure (so I'm more likely to have an "if ...: break" then "if ...:
>> return").
>
> I have always tried to enforce 'only one return per function'.  If
> there are multiple returns it makes maintenance very difficult as
> 'clear up' code can get bypassed.
>

Isn't that why try/finally exists? No matter how many 'return'
statements you have, there's always exceptions to bypass any naive
cleanup code; and no matter how many returns you have, 'finally'
blocks still execute before return.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Chris Green]

Dennis Lee Bieber  wrote:
> 
> Well... "break" does bypass the rest of the block, but it still exits
> via the end of the block. I have a tendency to try for one "return" per
> procedure (so I'm more likely to have an "if ...: break" then "if ...:
> return"). 

I have always tried to enforce 'only one return per function'.  If
there are multiple returns it makes maintenance very difficult as
'clear up' code can get bypassed.

-- 
Chris Green
·
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[John Q Hacker]

Sorry, delete string "n't".  I mean that you would strcuture your code
with that architecture.

Hate that.

marxos

On 1/1/18, John Q Hacker <zonderv...@gmail.com> wrote:
>>> I don’t use gotos in C code. Why should it be “harder” in a higher-level
>>> language?
>>
>> Good for you.
>>
>> Looking at 14 million lines of Linux kernel sources, which are in C,
>> over 100,000 of them use 'goto'. About one every 120 lines.
>
> Most use of goto's implies a lack of understanding of the unseen
> architecture of the problem domain itself (otherwise, you wouldn't
> have structured your program with that architecture).  The only
> remaining use is optimization, and most of that is probably premature,
> as use of gotos *can* make things hard to understand, but using labels
> is a pretty happy medium.
>
> Marxos
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[John Q Hacker]

>> I don’t use gotos in C code. Why should it be “harder” in a higher-level
>> language?
>
> Good for you.
>
> Looking at 14 million lines of Linux kernel sources, which are in C,
> over 100,000 of them use 'goto'. About one every 120 lines.

Most use of goto's implies a lack of understanding of the unseen
architecture of the problem domain itself (otherwise, you wouldn't
have structured your program with that architecture).  The only
remaining use is optimization, and most of that is probably premature,
as use of gotos *can* make things hard to understand, but using labels
is a pretty happy medium.

Marxos
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[From]

  




   (Posting On Python-List Prohibited)



why ?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[bartc]

On 01/01/2018 15:06, From wrote:
   



 


(Posting On Python-List Prohibited)



 why ?



Huh?

I'm posting to the usenet group comp.lang.python (an off-topic reply to 
an off-topic remark, but it happens).


I've no idea what the prohibited part is about, if that's what you're 
posting about. But there have been dozens of other messages with the 
same subject.

--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[bartc]

On 01/01/2018 14:54, Peter J. Holzer wrote:

On 2017-12-30 11:07:56 -0500, Dennis Lee Bieber wrote:



Yes. I don't know any language which enforces "pure" structured
programming. They all have some constructs (goto, break, return,
exceptions, ...) to leave a block early. I don't think that invalidates
my point that the concept of structured programming predates Pascal.


Functional languages?

Some banish not only goto, but the concepts of assignments, and variables.

And even functions have to be pure with no side-effects, which makes I/O 
a problem.


They are really intent on making life difficult.

--
bartc

--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Peter J. Holzer]

On 2017-12-30 11:07:56 -0500, Dennis Lee Bieber wrote:
> On Sat, 30 Dec 2017 13:46:14 +0100, "Peter J. Holzer" <hjp-pyt...@hjp.at>
> declaimed the following:
> 
> >I don't think this is correct. Structured programming is much older:
> >ALGOL 60 was already a block structured language and Dijkstra wrote
> >"goto considered harmful" in the late 1960s. Pascal appeared in 1970, C
> >in 1974. To me (who learned to program in BASIC on a CP/M machine), C
> >is very much a structured programming language. If structured
> >programming gained traction around 1980, it might even have been because
> >structured languages like C with good performance became widely
> >available.
> >
>   There is a slight difference between just being block structured and
> full structured programming (at the time "one-entry/one-exit per
> construct".

I'd say there is a rather big difference: One is a programming paradigm,
the other a syntactic aid for the former. You can do structured
programming in assembler (I did in BASIC), but it is a lot easier and
natural in a block-structured language. I wasn't present when ALGOL was
invented (I wasn't even born then), but I am sure that the inventors
shared much of the mindset of "structured programming" (although the
name may not yet have been invented).

> Even Pascal still had a GOTO statement,

Yes. I don't know any language which enforces "pure" structured
programming. They all have some constructs (goto, break, return,
exceptions, ...) to leave a block early. I don't think that invalidates
my point that the concept of structured programming predates Pascal.

> and flow-charts were still part of documentation at school.

We learned about them in the 80's, too (along with Nassi-Shneiderman
diagrams). And in fact I still use them sometimes (although more
frequently to document processes for humans than for computers).
(I don't use NS diagrams at all anymore: They have no advantages over
pseudo code for me.)

>   The /teaching/ of structured programming as a discipline didn't really
> show up until my final year in college (79-80) and the first few years at
> Lockheed

I can't comment on how wide-spread teaching of structured programming
was, since I am too young. But since Pascal was explicitely intended as
a teaching language for structured programming, there must have been at
least a few professors to teach it in the late 1960's.

> -- which was also a time period when such abominations as TEXTFOR,
> MORTRAN, and RATFOR were created to allow for doing structured programming
> in FORTRAN-IV

And regardless of the quality (or lack thereof) of these preprocessors
I'd argue that they were created (and used) because at the time many
programmers thought that structured programming was a good idea. 

Is there any mainstream (procedural) computer language invented after
1970 which doesn't try to encourage structured programming?

hp

-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[breamoreboy]

On Sunday, December 31, 2017 at 6:56:16 PM UTC, bartc wrote:
> On 31/12/2017 17:01, breamoreboy wrote:
> 
> >Further I've never once in 17 years of using Python been tearing my hair out 
> >over the lack of goto
> 
> Neither have I over all the advanced features of Python I never use, and 
> for double that number of years.

I suggest that you steer well clear of all of Python's advanced features until 
you understand the Python philosophy as laid down in the Zen of Python.  
However I cannot see that happening as you seem to dispute everything about 
Python, flying in the face of any advice that you get from all the very 
experienced Pythonistas who frequent this place.  You must have access to the 
PSU's time machine if you've 34 years experience of Python as it hasn't been 
out that long.

> 
> Yet for some they will be as indispensable as they are incomprehensible 
> to others.

Let's all go back to machine code.

--
Kindest regards.

Mark Lawrence.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[bartc]

On 01/01/2018 00:40, MRAB wrote:

On 2017-12-31 23:21, bartc wrote:


[Block delimiting]


proc fn2(int a)=

...

end

(or possibly "inline f123=").

[snip]

OT: if "case ... esac" and "if ... fi", why not "proc ... corp"? :-)


(I don't think Algol-68 used corp otherwise it might have been copied 
too. But I also have 'function', and 'noitcnuf' would be a bit much.


Anyway in this variation of the syntax, there is a choice of block endings.

So 'case' can be closed with 'end', 'endcase', 'end case' or 'esac'.

With loops like while-do, either 'while' or 'do' can be the keyword.

For some kinds of blocks, (...) can be used.

But there can't be no block ending as in Python; there has to be 
something. Indentation here is not significant.)


--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[bartc]

On 31/12/2017 17:01, breamore...@gmail.com wrote:


Further I've never once in 17 years of using Python been tearing my hair out 
over the lack of goto


Neither have I over all the advanced features of Python I never use, and 
for double that number of years.


Yet for some they will be as indispensable as they are incomprehensible 
to others.


--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[mm0fmf]

On 31/12/2017 17:01, breamore...@gmail.com wrote:

I would use functions every time as a modern compiler can inline them


This


Further I've never once in 17 years of using Python been tearing my hair out 
over the lack of goto


And this. (In my case only 6 years.)


--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Ben Bacarisse]

bartc <b...@freeuk.com> writes:

> On 31/12/2017 22:09, Ben Bacarisse wrote:
>
>> No, you missed the point and did not address the question.  You said (now
>> cut)
>>
>> | If I thought introducing functions, whether local or not, as a way of
>> | avoiding goto was worth doing, I would do so.
>>
>> but I'm not sure you know if it's worth it or not.  So here's my
>> question again: what language (or languages) were you using when you
>> concluded that it was not worth using local functions to avoid gotos?
>> Maybe you had a bad experience from some language that did it badly.
>
> What makes you think I had a bad experience?

Nothing.  I was asking what experience you had that led to your
conclusion.  Knowing the language might explain the conclusion you came
to.

-- 
Ben.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[MRAB]

On 2017-12-31 23:21, bartc wrote:

On 31/12/2017 22:09, Ben Bacarisse wrote:


No, you missed the point and did not address the question.  You said (now
cut)

| If I thought introducing functions, whether local or not, as a way of
| avoiding goto was worth doing, I would do so.

but I'm not sure you know if it's worth it or not.  So here's my
question again: what language (or languages) were you using when you
concluded that it was not worth using local functions to avoid gotos?
Maybe you had a bad experience from some language that did it badly.


What makes you think I had a bad experience? I posted a version using
Python a few hours ago (which needs the local function to be moved to
work properly).

The same example works in my language (one of them anyway), but I still
find a quick goto the simplest thing to do especially when the code is
not complete so I don't know what will be added or changed or moved,
which will be harder as soon a specific sequence is extracted into a
function.

Also, what would be the duplicated code is seen to 'belong' to one of
the options, rather than be anonymous.

(Here is the same example in my static language:
https://pastebin.com/raw/dX2FNK7a

fn1 uses goto. fn2 uses a local function (not very demanding here so it
works). fn3 uses the special 'block-call' feature which I no longer use
(but I haven't yet got rid of it).

I prefer fn1 and fn3 because the code stays inline. If I had some
inspiration for a better feature then I'd have fn4 and maybe fn5 too.)


The compiler could inline automatically, or you could be explicit:

proc fn2(int a)=
inline proc f123=
println "One"
println "Two"
println "Three"
end

case a
when 1 then
f123()

when 2 then
println "Four"

else
println "Other"
f123()
esac
end

(or possibly "inline f123=").

[snip]

OT: if "case ... esac" and "if ... fi", why not "proc ... corp"? :-)
--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[bartc]

On 31/12/2017 22:09, Ben Bacarisse wrote:


No, you missed the point and did not address the question.  You said (now
cut)

| If I thought introducing functions, whether local or not, as a way of
| avoiding goto was worth doing, I would do so.

but I'm not sure you know if it's worth it or not.  So here's my
question again: what language (or languages) were you using when you
concluded that it was not worth using local functions to avoid gotos?
Maybe you had a bad experience from some language that did it badly.


What makes you think I had a bad experience? I posted a version using 
Python a few hours ago (which needs the local function to be moved to 
work properly).


The same example works in my language (one of them anyway), but I still 
find a quick goto the simplest thing to do especially when the code is 
not complete so I don't know what will be added or changed or moved, 
which will be harder as soon a specific sequence is extracted into a 
function.


Also, what would be the duplicated code is seen to 'belong' to one of 
the options, rather than be anonymous.


(Here is the same example in my static language: 
https://pastebin.com/raw/dX2FNK7a


fn1 uses goto. fn2 uses a local function (not very demanding here so it 
works). fn3 uses the special 'block-call' feature which I no longer use 
(but I haven't yet got rid of it).


I prefer fn1 and fn3 because the code stays inline. If I had some 
inspiration for a better feature then I'd have fn4 and maybe fn5 too.)


Within Python, I touched on performance issues in my earlier post. (A 
local function apparently involves an extra assignment - per function - 
each time the containing function is called.)



(Which is likely to cause problems if the code includes breaks, or
gotos if the language has them.)


Good grief!  That is exactly the sort of code you should not re-use by
jumping to it.  There are myriad potential problems and putting the code
into a function will allow the compiler to diagnose lots of them.


OK, forget the gotos then. But a block can still contain break or return 
(and in my syntax, several other loop controls). It loses context as 
soon as it's hoisted into a function.


--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Ben Bacarisse]

bartc <b...@freeuk.com> writes:

> On 31/12/2017 15:02, Ben Bacarisse wrote:
>> bartc <b...@freeuk.com> writes:
>
>> I think there's a problem with that.  Standard C does not have them, you
>> said your language does not implement them properly
>
> (The real problem is I don't remember local functions being used
> anywhere else. It's an idiom I'm not used to and that apparently few
> other people use. Except perhaps in Python where they do to use
> advanced features over simpler ones.)
>
>  and I think you are
>> new(ish) to Python.  What language did you try them in?  It may be that
>> it was overly complex in that language.  The idea is clean and simple.
>
> It's not simple to implement. Not if you want full access to the
> non-static variables of the containing function(s). It doesn't sound
> that efficient either.

No, you missed the point and did not address the question.  You said (now
cut)

| If I thought introducing functions, whether local or not, as a way of
| avoiding goto was worth doing, I would do so.

but I'm not sure you know if it's worth it or not.  So here's my
question again: what language (or languages) were you using when you
concluded that it was not worth using local functions to avoid gotos?
Maybe you had a bad experience from some language that did it badly.

>>> So in this case I disagree with dragging in named functions and
>>> introducing an extra level of control flow just to avoid duplicating
>>> half a dozen lines of code. I would just duplicate those lines (with a
>>> comment that they have to match the other set so that they are
>>> maintained in sync).
>>
>> The suggestion was to use them to avoid gotos.  If duplicating is a good
>> idea (and it's a hard line to draw) then we are not talking about the
>> same cases.  Given the choice of "dragging in named functions" and
>> dragging in named blocks and gotos, I would choose the functions every
>> time.
>
> The blocks don't need to be dragged; they are already in place!
>
> It's funny because in c.l.c you're always advocating keep declarations
> as close to the point of use as possible. Here you appear to be saying
> the opposite: taking code away from the primary point of use.

If a language allowed me to declare a local function at the point of
first use, I'd do that, but there are special reasons why that is not a
reasonable thing to do in most cases.  None the less, it's not
inconsistent to prefer one less than perfect option to another much less
than perfect option.

However, we're debating an entirely abstract notion.  What is a typical
use for this "re-use" goto idiom?  Maybe I'll prefer the goto version
over any of the alternatives when I see an actual use.

> (Which is likely to cause problems if the code includes breaks, or
> gotos if the language has them.)

Good grief!  That is exactly the sort of code you should not re-use by
jumping to it.  There are myriad potential problems and putting the code
into a function will allow the compiler to diagnose lots of them.

If you really are jumping to re-use code that includes gotos I suggest
the whole thing needs re-design.

-- 
Ben.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Chris Angelico]

On Mon, Jan 1, 2018 at 6:29 AM, bartc <b...@freeuk.com> wrote:
> You'll need to give an example I think. Suppose I start with this:
>
> def fn(a):
> if a==1:
> print ("One")
> print ("Two")
> print ("Three")
> elif a==2:
> print ("Four")
> else:
> print ("Other")
> print ("One")
> print ("Two")
> print ("Three")
>
> I want to share the lines that print One Two Three, so I create an inline
> function, defined as close as possible to the original code:
>
> def fn2(a):
> if a==1:
> def F123():
> print ("One")
> print ("Two")
> print ("Three")
> F123()
> elif a==2:
> print ("Four")
> else:
> print ("Other")
> F123()
>
> However, if I call this with fn2(3), it says that variable F123 has not been
> assigned.

Right, so you'd move it one line up (or move the 'if' down to below
the function definition), thus the larger block of code stays where it
is.

> Note also that a goto, and a function call, don't do the same thing. The
> function will return, the goto won't.

Not sure what you mean by "return", because what you effectively do is
create a name for a block of code, and then use (call) that block of
code more than once. That makes it easy to comprehend. With the goto,
you have to go look at the body below to figure out what happens.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[bartc]

On 31/12/2017 19:29, bartc wrote:

[Ignore the original, incomplete version of my post, which appears after 
the sig.


I decided to actually try it out for real instead of just guessing!

Good thing too.]
--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[bartc]

On 31/12/2017 17:06, Chris Angelico wrote:

On Mon, Jan 1, 2018 at 3:55 AM, bartc <b...@freeuk.com> wrote:

The suggestion was to use them to avoid gotos.  If duplicating is a good
idea (and it's a hard line to draw) then we are not talking about the
same cases.  Given the choice of "dragging in named functions" and
dragging in named blocks and gotos, I would choose the functions every
time.



The blocks don't need to be dragged; they are already in place!

It's funny because in c.l.c you're always advocating keep declarations as
close to the point of use as possible. Here you appear to be saying the
opposite: taking code away from the primary point of use.


I don't understand the issue here. All you need to do is add a "def"
statement header in front of the block of code. And maybe indent it
further, although if you're unifying "if/elif" subtrees, that'll
cancel out the indentation level change. The block of code stays at or
near its first use.


You'll need to give an example I think. Suppose I start with this:

def fn(a):
if a==1:
print ("One")
print ("Two")
print ("Three")
elif a==2:
print ("Four")
else:
print ("Other")
print ("One")
print ("Two")
print ("Three")

I want to share the lines that print One Two Three, so I create an 
inline function, defined as close as possible to the original code:


def fn2(a):
if a==1:
def F123():
print ("One")
print ("Two")
print ("Three")
F123()
elif a==2:
print ("Four")
else:
print ("Other")
F123()

However, if I call this with fn2(3), it says that variable F123 has not 
been assigned.


(I'm not sure what overheads are associated with nested functions. 
Presumably its byte-code is done once, but is there any other setup of 
F123 associated with each call of fn2()? Even when a==2 so that F123() 
is not called?


A brief test [not using print()] showed it was a little slower having 
F123 inside fn2() - and outside the if-statement to make it work - than 
having F123 outside. And having to call F123() anyway instead of just 
having the inline code makes it a little slower too.


Although this would need to be balanced by the cost of the alternative, 
whether a goto or whatever.)


Note also that a goto, and a function call, don't do the same thing. The 
function will return, the goto won't. In my example all paths will 
return, in others this will have to be taken care of.


--
bartc












 Don't forget that after turning a block into a def-function in-place, 
it will need to be followed by a call to it:


  if X:
 A
 B
 C
  elif ...
  else:
 A
 B
 C

This becomes:

   if X:
  def F():
 A
 B
 C
  F()
   elif...
   else
  F()

(Is the def statement executed once during byte-code compilation? Or can 
it give different result each time depending on what globals are visible 
within F? Will there at least be a set-up overhead for F each time



Note that calling a local function is not quite a drop-in replacement for



Once again, Bart, you're scorning something that you don't have much
(any?) experience with. Look at how the feature is used before you
hate on it.

ChrisA



--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[breamoreboy]

On Sunday, December 31, 2017 at 3:02:41 PM UTC, Ben Bacarisse wrote:
> bartc <b...@freeuk.com> writes:
> 
> > On 31/12/2017 12:41, Chris Angelico wrote:
> >> On Sun, Dec 31, 2017 at 11:33 PM, bartc <b...@freeuk.com> wrote:
> >>> On 30/12/2017 23:54, Chris Angelico wrote:
> >
> >>>> I've written code that uses dirty tricks like that to avoid
> >>>> duplication. It's at least as much of a problem as actual duplication
> >>>> is. Generally, the 'goto' solution results in subsequent programmers
> >>>> (such as my future selves) staring at the code for 30-60 seconds to
> >>>> figure out what it's doing. I don't like to do that to myself, much
> >>>> less to people I actually admire and respect.
> >>>
> >>> The problem is having to stare at the code for even longer to figure out 
> >>> the
> >>> even dirtier tricks you had to use to avoid gotos.
> >>
> >> Dirtier tricks like... named functions?
> >
> > I like to write clean and readable code. If I thought introducing
> > functions, whether local or not, as a way of avoiding goto was worth
> > doing, I would do so.
> 
> I think there's a problem with that.  Standard C does not have them, you
> said your language does not implement them properly and I think you are
> new(ish) to Python.  What language did you try them in?  It may be that
> it was overly complex in that language.  The idea is clean and simple.
> 
> > So in this case I disagree with dragging in named functions and
> > introducing an extra level of control flow just to avoid duplicating
> > half a dozen lines of code. I would just duplicate those lines (with a
> > comment that they have to match the other set so that they are
> > maintained in sync).
> 
> The suggestion was to use them to avoid gotos.  If duplicating is a good
> idea (and it's a hard line to draw) then we are not talking about the
> same cases.  Given the choice of "dragging in named functions" and
> dragging in named blocks and gotos, I would choose the functions every
> time.
> 
> 
> -- 
> Ben.

I would use functions every time as a modern compiler can inline them, 
something described here https://en.wikipedia.org/wiki/Inline_expansion for the 
benefit of newbies.  Further I've never once in 17 years of using Python been 
tearing my hair out over the lack of goto as there are numerous examples of how 
to avoid them.  This thread is yet another storm in a thimble.

--
Kindest regards.

Mark Lawrence.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Chris Angelico]

On Mon, Jan 1, 2018 at 3:55 AM, bartc  wrote:
>> The suggestion was to use them to avoid gotos.  If duplicating is a good
>> idea (and it's a hard line to draw) then we are not talking about the
>> same cases.  Given the choice of "dragging in named functions" and
>> dragging in named blocks and gotos, I would choose the functions every
>> time.
>
>
> The blocks don't need to be dragged; they are already in place!
>
> It's funny because in c.l.c you're always advocating keep declarations as
> close to the point of use as possible. Here you appear to be saying the
> opposite: taking code away from the primary point of use.

I don't understand the issue here. All you need to do is add a "def"
statement header in front of the block of code. And maybe indent it
further, although if you're unifying "if/elif" subtrees, that'll
cancel out the indentation level change. The block of code stays at or
near its first use.

Once again, Bart, you're scorning something that you don't have much
(any?) experience with. Look at how the feature is used before you
hate on it.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[bartc]

On 31/12/2017 15:02, Ben Bacarisse wrote:

bartc  writes:



I think there's a problem with that.  Standard C does not have them, you
said your language does not implement them properly


(The real problem is I don't remember local functions being used 
anywhere else. It's an idiom I'm not used to and that apparently few 
other people use. Except perhaps in Python where they do to use advanced 
features over simpler ones.)


 and I think you are

new(ish) to Python.  What language did you try them in?  It may be that
it was overly complex in that language.  The idea is clean and simple.


It's not simple to implement. Not if you want full access to the 
non-static variables of the containing function(s). It doesn't sound 
that efficient either.



So in this case I disagree with dragging in named functions and
introducing an extra level of control flow just to avoid duplicating
half a dozen lines of code. I would just duplicate those lines (with a
comment that they have to match the other set so that they are
maintained in sync).


The suggestion was to use them to avoid gotos.  If duplicating is a good
idea (and it's a hard line to draw) then we are not talking about the
same cases.  Given the choice of "dragging in named functions" and
dragging in named blocks and gotos, I would choose the functions every
time.


The blocks don't need to be dragged; they are already in place!

It's funny because in c.l.c you're always advocating keep declarations 
as close to the point of use as possible. Here you appear to be saying 
the opposite: taking code away from the primary point of use.


(Which is likely to cause problems if the code includes breaks, or gotos 
if the language has them.)


I think there is a way to solve this pattern via special language 
features, while writing the main code primarily inline and in a natural 
structure, but I haven't found a satisfactory method yet. I don't think 
local functions is it.


(And perhaps a solution lies outside the language such as within an 
editor, to allow sharing of the same block of code in multiple locations.)


--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Ben Bacarisse]

bartc <b...@freeuk.com> writes:

> On 31/12/2017 12:41, Chris Angelico wrote:
>> On Sun, Dec 31, 2017 at 11:33 PM, bartc <b...@freeuk.com> wrote:
>>> On 30/12/2017 23:54, Chris Angelico wrote:
>
>>>> I've written code that uses dirty tricks like that to avoid
>>>> duplication. It's at least as much of a problem as actual duplication
>>>> is. Generally, the 'goto' solution results in subsequent programmers
>>>> (such as my future selves) staring at the code for 30-60 seconds to
>>>> figure out what it's doing. I don't like to do that to myself, much
>>>> less to people I actually admire and respect.
>>>
>>> The problem is having to stare at the code for even longer to figure out the
>>> even dirtier tricks you had to use to avoid gotos.
>>
>> Dirtier tricks like... named functions?
>
> I like to write clean and readable code. If I thought introducing
> functions, whether local or not, as a way of avoiding goto was worth
> doing, I would do so.

I think there's a problem with that.  Standard C does not have them, you
said your language does not implement them properly and I think you are
new(ish) to Python.  What language did you try them in?  It may be that
it was overly complex in that language.  The idea is clean and simple.

> So in this case I disagree with dragging in named functions and
> introducing an extra level of control flow just to avoid duplicating
> half a dozen lines of code. I would just duplicate those lines (with a
> comment that they have to match the other set so that they are
> maintained in sync).

The suggestion was to use them to avoid gotos.  If duplicating is a good
idea (and it's a hard line to draw) then we are not talking about the
same cases.  Given the choice of "dragging in named functions" and
dragging in named blocks and gotos, I would choose the functions every
time.


-- 
Ben.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[bartc]

On 31/12/2017 12:41, Chris Angelico wrote:

On Sun, Dec 31, 2017 at 11:33 PM, bartc <b...@freeuk.com> wrote:

On 30/12/2017 23:54, Chris Angelico wrote:



I've written code that uses dirty tricks like that to avoid
duplication. It's at least as much of a problem as actual duplication
is. Generally, the 'goto' solution results in subsequent programmers
(such as my future selves) staring at the code for 30-60 seconds to
figure out what it's doing. I don't like to do that to myself, much
less to people I actually admire and respect.



The problem is having to stare at the code for even longer to figure out the
even dirtier tricks you had to use to avoid gotos.



Dirtier tricks like... named functions?


I like to write clean and readable code. If I thought introducing 
functions, whether local or not, as a way of avoiding goto was worth 
doing, I would do so.


So in this case I disagree with dragging in named functions and 
introducing an extra level of control flow just to avoid duplicating 
half a dozen lines of code. I would just duplicate those lines (with a 
comment that they have to match the other set so that they are 
maintained in sync).


For other uses of goto, I've introduced (not in Python or C but my own 
stuff) features to avoid the need some of those uses.


For example, extra loop controls, and loop controls that work with 
nested loops. I've also experimented with a feature intended purely to 
get to common clean-up code, but that had little advantage over using 
goto other than not writing 'goto', and thus avoiding some of the stigma 
(but you will also know it will do a one-off forward jump to a common 
point).


(Actually, none of my code ever needs to use 'goto' anyway, as I can 
also write it as 'go to'. That's effective if anyone does a 'grep' on my 
code looking for 'goto' instances...)


--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Chris Angelico]

On Sun, Dec 31, 2017 at 11:33 PM, bartc <b...@freeuk.com> wrote:
> On 30/12/2017 23:54, Chris Angelico wrote:
>>
>> On Sun, Dec 31, 2017 at 10:45 AM, bartc <b...@freeuk.com> wrote:
>>>
>>> On 30/12/2017 23:26, Gregory Ewing wrote:
>>>>
>>>>
>>>> bartc wrote:
>>>>>
>>>>>
>>>>> B and C occur twice, so a goto is a quick way to reuse B and C without
>>>>> needing to duplicate code,
>>>>
>>>>
>>>>
>>>> This only works if the repeated part happens to be at the
>>>> tail of each case.
>>>
>>>
>>>
>>> IME that seems to be the most common situation.
>>>
>>
>> I've written code that uses dirty tricks like that to avoid
>> duplication. It's at least as much of a problem as actual duplication
>> is. Generally, the 'goto' solution results in subsequent programmers
>> (such as my future selves) staring at the code for 30-60 seconds to
>> figure out what it's doing. I don't like to do that to myself, much
>> less to people I actually admire and respect.
>
>
> The problem is having to stare at the code for even longer to figure out the
> even dirtier tricks you had to use to avoid gotos.
>

Dirtier tricks like... named functions?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[bartc]

On 30/12/2017 23:54, Chris Angelico wrote:

On Sun, Dec 31, 2017 at 10:45 AM, bartc <b...@freeuk.com> wrote:

On 30/12/2017 23:26, Gregory Ewing wrote:


bartc wrote:


B and C occur twice, so a goto is a quick way to reuse B and C without
needing to duplicate code,



This only works if the repeated part happens to be at the
tail of each case.



IME that seems to be the most common situation.



I've written code that uses dirty tricks like that to avoid
duplication. It's at least as much of a problem as actual duplication
is. Generally, the 'goto' solution results in subsequent programmers
(such as my future selves) staring at the code for 30-60 seconds to
figure out what it's doing. I don't like to do that to myself, much
less to people I actually admire and respect.


The problem is having to stare at the code for even longer to figure out 
the even dirtier tricks you had to use to avoid gotos.



--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Ben Bacarisse]

bartc <b...@freeuk.com> writes:

> On 30/12/2017 20:36, Ben Bacarisse wrote:
>> bartc <b...@freeuk.com> writes:
>>
>>> On 30/12/2017 16:53, mm0fmf wrote:
>>>> On 30/12/2017 14:41, bartc wrote:
>>>>> it looks a bit naff
>>>>
>>>> Understatement of 2017.
>>>
>>> I'm honest about my own ideas, but my remarks were about the use of
>>> special symbols such as "::" and "@".
>>>
>>> Before completely dismissing it however, you should look at how
>>> another language such as Python can achieve the same thing.
>>>
>>> Namely, take any block of code within a function, and allow it to be
>>> executed or shared from anywhere else in the function, with the
>>> minimum of disruption.
>>
>> That's what a local function does and it does it with the clean
>> semantics of a function call.
>>
>> When this idea came up in comp.lang.c you could not see the point, yet
>> you appear to have a use-case common enough that you have a solution
>> worked out using gotos.
>
> C doesn't in general have local functions. My own languages don't
> implement them properly. So I tend not to use them.

But now you have good reason to change that.  Properly implemented they
do exactly what you want very neatly.  You can stick with gotos, of
course, but at least I hope you won't pour scorn on the idea of local
function if it comes up again.

>>> If it looks better than what I'd come up with, then I'll use that instead.
>>
>> What looks better is always going to be an unreliable and subjective
>> measure, but calling a named function almost certainly scales better and
>> will allow for better structuring (such as when one block needs to use
>> another one).
>
> Using a local (or even non-local) function is what I'm trying to
> avoid, as I prefer to keep the code inline, and not disrupt it too
> much.

That's what used to be called hacking.  You write it one way and then
spot that that block over there can be used here, but you don't tidy up
the code, you just jump to it!  In general, it is exactly the sort of
goto use that gave gotos a bad name.  Anyway, by their very nature, the
blocks you are talking about should not be inline since they don't
belong to any one execution path.


(I hope you don't mind this annotation -- over at comp.lang.c I just
remove text from my replies to you as is your preference, but people
here will not have seen that exchange and I prefer to mark edits.)

-- 
Ben.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[MRAB]

On 2017-12-30 23:22, Gregory Ewing wrote:

Stefan Ram wrote:

  BASIC has

DEF FN...

  which /can/ define actual subroutines, limited to expressions.

  Now, what does this limitation remind me of?


The equivalent limitation in Python is nowhere near as bad,
since if you outgrow what lambda can do you can always
use a def instead. BASIC didn't have that option (unless
you were using one of the more advanced dialects, such
as BBC BASIC, which had a PROC statement).

PROC wasn't really a statement, but a prefix for a procedure name. There 
was also another prefix, FN, for functions.


DEF PROChello
print "Hello world!"
ENDPROC

DEF FNsquare(x)
= x * x

They even had LOCAL variables and parameter lists. The Acorn Archimedes 
range had an improved version of BBC BASIC.

--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Chris Angelico]

On Sun, Dec 31, 2017 at 10:45 AM, bartc <b...@freeuk.com> wrote:
> On 30/12/2017 23:26, Gregory Ewing wrote:
>>
>> bartc wrote:
>>>
>>> B and C occur twice, so a goto is a quick way to reuse B and C without
>>> needing to duplicate code,
>>
>>
>> This only works if the repeated part happens to be at the
>> tail of each case.
>
>
> IME that seems to be the most common situation.
>

I've written code that uses dirty tricks like that to avoid
duplication. It's at least as much of a problem as actual duplication
is. Generally, the 'goto' solution results in subsequent programmers
(such as my future selves) staring at the code for 30-60 seconds to
figure out what it's doing. I don't like to do that to myself, much
less to people I actually admire and respect.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[bartc]

On 30/12/2017 23:26, Gregory Ewing wrote:

bartc wrote:
B and C occur twice, so a goto is a quick way to reuse B and C without 
needing to duplicate code,


This only works if the repeated part happens to be at the
tail of each case.


IME that seems to be the most common situation.

 Any other situation and you're back to

local functions.



--
Bartc

--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Gregory Ewing]

bartc wrote:
B and C occur twice, so a goto is a quick way to reuse B and C without 
needing to duplicate code,


This only works if the repeated part happens to be at the
tail of each case. Any other situation and you're back to
local functions.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Gregory Ewing]

bartc wrote:
C doesn't in general have local functions. My own languages don't 
implement them properly. So I tend not to use them.


Looks like there's something circular going on here. You don't
have much experience of using local functions, so you don't
see a lot of value in them, so you haven't made the effort to
implement them in your own languages, so you don't get much
experience in using them.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Gregory Ewing]

Stefan Ram wrote:

  BASIC has

DEF FN...

  which /can/ define actual subroutines, limited to expressions.

  Now, what does this limitation remind me of?


The equivalent limitation in Python is nowhere near as bad,
since if you outgrow what lambda can do you can always
use a def instead. BASIC didn't have that option (unless
you were using one of the more advanced dialects, such
as BBC BASIC, which had a PROC statement).

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Chris Angelico]

On Sun, Dec 31, 2017 at 9:43 AM, bartc <b...@freeuk.com> wrote:
> On 30/12/2017 20:36, Ben Bacarisse wrote:
>>
>> bartc <b...@freeuk.com> writes:
>>
>>> On 30/12/2017 16:53, mm0fmf wrote:
>>>>
>>>> On 30/12/2017 14:41, bartc wrote:
>>>>>
>>>>> it looks a bit naff
>>>>
>>>>
>>>> Understatement of 2017.
>>>
>>>
>>> I'm honest about my own ideas, but my remarks were about the use of
>>> special symbols such as "::" and "@".
>>>
>>> Before completely dismissing it however, you should look at how
>>> another language such as Python can achieve the same thing.
>>>
>>> Namely, take any block of code within a function, and allow it to be
>>> executed or shared from anywhere else in the function, with the
>>> minimum of disruption.
>>
>>
>> That's what a local function does and it does it with the clean
>> semantics of a function call.
>>
>> When this idea came up in comp.lang.c you could not see the point, yet
>> you appear to have a use-case common enough that you have a solution
>> worked out using gotos.
>
>
> C doesn't in general have local functions. My own languages don't implement
> them properly. So I tend not to use them.
>
>>> If it looks better than what I'd come up with, then I'll use that
>>> instead.
>>
>>
>> What looks better is always going to be an unreliable and subjective
>> measure, but calling a named function almost certainly scales better and
>> will allow for better structuring (such as when one block needs to use
>> another one).
>
>
> Using a local (or even non-local) function is what I'm trying to avoid, as I
> prefer to keep the code inline, and not disrupt it too much.
>
> You may also want to execute a block only temporarily, or as part of a short
> test. So you don't want to go to the trouble of hoisting a block of code
> into a local function.
>
> (And in C, which has local block scopes, there would be trouble with
> visibility of all the variables the block uses, unless the local function is
> untidily placed right where the original block was.)
>

Okay, so a low level language lacks certain facilities. Great. What
has this to do with Python and goto? You *can* use nested functions.
And they can do everything you need of these sub-blocks (albeit with
some overhead).

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[bartc]

On 30/12/2017 20:36, Ben Bacarisse wrote:

bartc  writes:


On 30/12/2017 16:53, mm0fmf wrote:

On 30/12/2017 14:41, bartc wrote:

it looks a bit naff


Understatement of 2017.


I'm honest about my own ideas, but my remarks were about the use of
special symbols such as "::" and "@".

Before completely dismissing it however, you should look at how
another language such as Python can achieve the same thing.

Namely, take any block of code within a function, and allow it to be
executed or shared from anywhere else in the function, with the
minimum of disruption.


That's what a local function does and it does it with the clean
semantics of a function call.

When this idea came up in comp.lang.c you could not see the point, yet
you appear to have a use-case common enough that you have a solution
worked out using gotos.


C doesn't in general have local functions. My own languages don't 
implement them properly. So I tend not to use them.



If it looks better than what I'd come up with, then I'll use that instead.


What looks better is always going to be an unreliable and subjective
measure, but calling a named function almost certainly scales better and
will allow for better structuring (such as when one block needs to use
another one).


Using a local (or even non-local) function is what I'm trying to avoid, 
as I prefer to keep the code inline, and not disrupt it too much.


You may also want to execute a block only temporarily, or as part of a 
short test. So you don't want to go to the trouble of hoisting a block 
of code into a local function.


(And in C, which has local block scopes, there would be trouble with 
visibility of all the variables the block uses, unless the local 
function is untidily placed right where the original block was.)


--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[William Ray Wing]

> On Dec 30, 2017, at 7:46 AM, Peter J. Holzer <hjp-pyt...@hjp.at> wrote:
> 
> On 2017-12-29 19:09:35 -0500, Dennis Lee Bieber wrote:
>> On Fri, 29 Dec 2017 23:12:22 +, bartc <b...@freeuk.com> declaimed the
>> following:
>>> Looking at 14 million lines of Linux kernel sources, which are in C, 
>>> over 100,000 of them use 'goto'. About one every 120 lines.
>>> 
>> 
>>  C is a language that predates the "structured programming" concepts of
>> the late 70/early 80.
> 
> I don't think this is correct. Structured programming is much older:
> ALGOL 60 was already a block structured language and Dijkstra wrote
> "goto considered harmful" in the late 1960s. Pascal appeared in 1970, C
> in 1974. To me (who learned to program in BASIC on a CP/M machine), C
> is very much a structured programming language. If structured
> programming gained traction around 1980, it might even have been because
> structured languages like C with good performance became widely
> available.
> 
> That said, C lacks exception handling (well, there is setjmp/longjmp,
> but ...) and multi-level break/continue, so goto is often the cleanest
> way to abort what you are doing and start to clean up. Python has
> exception handling, and that removes most of the cases where you would
> use goto in C (the rest is probably mostly in micro-optimizations: If
> you care about the run-time difference between a goto and a subroutine
> call, you probably shouldn't use Python in the first place).
> 
>hp
> 

I’ve been watching this discussion ebb and flow - and finally can’t resist 
pointing folks here at the famous essay: “Real Programmers Don’t Use Pascal”.  
It has its own Wikipedia article at this point:

 https://en.wikipedia.org/wiki/Real_Programmers_Don't_Use_Pascal

A copy of the original essay appears here: 
https://www.ee.ryerson.ca/~elf/hack/realmen.html

Hopefully fun reading over a beer.

Bill


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Chris Angelico]

On Sun, Dec 31, 2017 at 7:36 AM, Ben Bacarisse  wrote:
> bartc  writes:
>
>> On 30/12/2017 16:53, mm0fmf wrote:
>>> On 30/12/2017 14:41, bartc wrote:
 it looks a bit naff
>>>
>>> Understatement of 2017.
>>
>> I'm honest about my own ideas, but my remarks were about the use of
>> special symbols such as "::" and "@".
>>
>> Before completely dismissing it however, you should look at how
>> another language such as Python can achieve the same thing.
>>
>> Namely, take any block of code within a function, and allow it to be
>> executed or shared from anywhere else in the function, with the
>> minimum of disruption.
>
> That's what a local function does and it does it with the clean
> semantics of a function call.
>

The only downside that I can think of is performance - function calls
can be a bit heavy-weight. I'd be curious to see what a "lightweight
local function" would look like - it could have restrictive semantics
like "can only be called from the function that constructed it" and
then could behave like Bart's proposed "block of code". But I suspect
it wouldn't have all that many uses, compared to a *real* closure,
which can be passed around as its own entity.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Ben Bacarisse]

bartc  writes:

> On 30/12/2017 16:53, mm0fmf wrote:
>> On 30/12/2017 14:41, bartc wrote:
>>> it looks a bit naff
>>
>> Understatement of 2017.
>
> I'm honest about my own ideas, but my remarks were about the use of
> special symbols such as "::" and "@".
>
> Before completely dismissing it however, you should look at how
> another language such as Python can achieve the same thing.
>
> Namely, take any block of code within a function, and allow it to be
> executed or shared from anywhere else in the function, with the
> minimum of disruption.

That's what a local function does and it does it with the clean
semantics of a function call.

When this idea came up in comp.lang.c you could not see the point, yet
you appear to have a use-case common enough that you have a solution
worked out using gotos.

> If it looks better than what I'd come up with, then I'll use that instead.

What looks better is always going to be an unreliable and subjective
measure, but calling a named function almost certainly scales better and
will allow for better structuring (such as when one block needs to use
another one).

-- 
Ben.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Ian Kelly]

On Sat, Dec 30, 2017 at 8:41 AM, bartc <b...@freeuk.com> wrote:
> (I had introduced a special language feature just for this kind of thing,
> but it was unsatisfactory. Goto was simpler and understood by everyone. And
> portable to any other language - that hasn't done away with goto. But it
> worked like this (not Python):
>
> a:=20
>
> case a
> when 10 then
> fred::
> println "one"
>
> when 20 then
> @fred
> println "two"
>
> end
>
> Output is "one" "two" when a is 20.
>
> fred:: names a block, and @fred 'calls' that block, without having to move
> it out of context. Actually this goes beyond what 'goto' can do, as it can
> also 'come back'. But as you can see, it looks a bit naff. A bit 1970s.)

BASIC had this feature in the form of the GOSUB statement. Although it
used an explicit rather than implicit RETURN.

BASIC was an awful language for developing programs of any size,
though. Without actual subroutines and with only one variable scope,
most people developed the practice of using GOSUB and designating
specific global variables as pseudo-arguments in order to have some
limited form of parameter passing. That was the kind of environment
where GOTO really, really sucks and produces the monstrous spaghetti
code that gives it its bad reputation. With the restrictions of
languages like C (i.e. only allowing GOTO within a function) and with
a reasonable level of restraint, I don't think that the use of GOTO is
really that big of a deal.
-- 
https://mail.python.org/mailman/listinfo/python-list