On 02/08/2016 22:27, Terry Reedy wrote:
On 8/2/2016 7:05 AM, BartC wrote:

Your objection to a feature such as 'repeat N' doesn't really stack up.

My objection is that there is a real cost that MUST be stacked up
against the benefit.

...
Anyway, if that was a valid objection, it would apply throughout the
language. In list-comps for example (there is an index, but where do you
stick the print?).

In the expression.  Given 'f(i) for i in range(n)', a careful debug
version might be '(f(i), print(i))[0] for i in range(n)'.  If the loop
does not finish, the extra None component does not matter.  and the
subscripting could be omitted.

That's quite a big edit to the original code. I would duplicate the line, comment out the original, and add the print code to the copy. Then I can revert to the original without bugs creeping in. (Unless the rest of the line has to change anyway.)

Same method is used with repeats:

   for N:        # or whatever syntax is used

If a loop index /has/ to be printed, comment out the above and extend a copy of it to:

   for i in range(N):

But only /if/ that value is needed; most won't. (I suspect that loops repeated a set number of times might be simpler anyway.)

Or in a for-loop iterating over values:

 a=[10,20,30,40,50]
 for x in a:
    print (x)

This will print the element, but what's the index?

Irrelevant.  The end of the sequence of prints says where the loop stopped.

But it might go wrong before it gets to the end. You need the index to know how far along the list it's at.

I think the real reason is not willing to admit that the language lacks
something that could actually be useful,

I think it is you who is unwilling to admit that nearly everything that
would be useful also has a cost, and that the ultimate cost of adding
every useful feature, especially syntax features, would be to make
python less unusable.

[Did you mean 'less usable' here?]

I'm only concerned here with basic syntax. And most ideas already exist in other languages (not just mine). But here's one I idea I think I mentioned last year: having separators in numeric literals.

Now I look and see that PEP 515 describes it! (I think some versions of Python will already have it).

Do people think that makes Python top-heavy in features and less usable?

I *know* that actually implementing most of this stuff is trivial because I've done it a dozen times. And I appreciate that doing it in a very large, existing 'live' language with millions of users has administrative problems.

But the technical side of it is nothing compared to the 50Mloc tools that have been mentioned.


Some time around last August to October, I think, someone posted to
python-ideas that he had produced a children's Python environment that
accepted 'repeat n' statements and translated them to equivalent for
loops before running.  His idea was that 'repeat n' should be added to
python itself so translation would not be needed.  The main use of the
statement in this context is for logo/turtle code with many
side-effect-only calls.

Apparently 'repeat N' is a Logo statement so it makes sense to try and emulate that within Python (to simplify porting Logo algorithms for example).

Leaving IDLE aside, one could write a pyre.whatever script to translate
a .pyre file to a .py file and run the latter.  Any of these methods
could be applied to experimenting with other 'improvement' ideas.

Yes, I've experimented with that approach myself. Using a source-to-source translator with Python as output. But the input was an entirely different syntax (example: http://pastebin.com/Zj89YfTN).

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

Reply via email to