Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. Python>
  3. Python
New Python implementation
flibble at i42
Feb 11, 2021, 4:30 AM
Post #1 of 93 (567 views)
Permalink
Hi!

I am starting work on creating a new Python implementation from scratch using "neos" my universal compiler that can compile any programming language. I envision this implementation to be significantly faster than the currently extant Python implementations (which isn't a stretch given how poorly they perform).

Sample neos session (parsing a fibonacci program, neoscript rather than Python in this case):

neos 1.0.0.0 ED-209
] help
h(elp)
s(chema) <path to language schema> Load language schema
l(oad) <path to program> Load program
list List program
c(ompile) Compile program
r(un) Run program
![<expression>] Evaluate expression (enter interactive mode if expression omitted)
:<input> Input (as stdin)
q(uit) Quit neos
lc List loaded concept libraries
t(race) <0|1|2|3|4|5> [<filter>] Compiler trace
m(etrics) Display metrics for running programs
] lc
[neos.core] (file:///D:\code\neos\build\win32\vs2019\x64\Release\core.ncl)
[neos.boolean]
[neos.language]
[neos.logic]
[neos.math]
[neos.module]
[neos.object]
[neos.string]
[neos.math.universal] (file:///D:\code\neos\build\win32\vs2019\x64\Release\core.math.universal.ncl)
] s neoscript
Loading schema 'neoscript'...
Language: Default neoGFX scripting language
Version: 1.0.0
Copyright (C) 2019 Leigh Johnston
neoscript] l examples/neoscript/fibonacci.neo
neoscript] list
File 'examples/neoscript/fibonacci.neo':
-- neoscript example: Fibonacci

using neos.string;
using neos.stream;

import fn to_string(x : i32) -> string;
import fn to_integer(s : string) -> i32;
import proc input(s : out string);
import proc print(s : in string);

-- functions are pure
def fn add(x, y : i32) -> i32
{
return x + y;
}
def fn fib(x : i32) -> i32
{
if (x < 2)
return 1;
else
return add(fib(x-1), fib(x-2));
}

-- procedures are impure
def proc main()
s : string;
{
print("Enter a positive "
"integer: ");
input(s);
print("Fibonacci(" + s + ") = " + to_string(fib(to_integer(s))) + "\n");
}
neoscript] t 1
neoscript] c
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(g)
folding: string.utf8(g) <- string.utf8.character.alpha()
folded: string.utf8(g) <- string.utf8.character.alpha() = string.utf8(gn)
folding: string.utf8(gn) <- string.utf8.character.alpha()
folded: string.utf8(gn) <- string.utf8.character.alpha() = string.utf8(gni)
folding: string.utf8(gni) <- string.utf8.character.alpha()
folded: string.utf8(gni) <- string.utf8.character.alpha() = string.utf8(gnir)
folding: string.utf8(gnir) <- string.utf8.character.alpha()
folded: string.utf8(gnir) <- string.utf8.character.alpha() = string.utf8(gnirt)
folding: string.utf8(gnirt) <- string.utf8.character.alpha()
folded: string.utf8(gnirt) <- string.utf8.character.alpha() = string.utf8(gnirts)
folding: string.utf8(gnirts) <- string.utf8.character.period()
folded: string.utf8(gnirts) <- string.utf8.character.period() = string.utf8(gnirts.)
folding: string.utf8(gnirts.) <- string.utf8.character.alpha()
folded: string.utf8(gnirts.) <- string.utf8.character.alpha() = string.utf8(gnirts.s)
folding: string.utf8(gnirts.s) <- string.utf8.character.alpha()
folded: string.utf8(gnirts.s) <- string.utf8.character.alpha() = string.utf8(gnirts.so)
folding: string.utf8(gnirts.so) <- string.utf8.character.alpha()
folded: string.utf8(gnirts.so) <- string.utf8.character.alpha() = string.utf8(gnirts.soe)
folding: string.utf8(gnirts.soe) <- string.utf8.character.alpha()
folded: string.utf8(gnirts.soe) <- string.utf8.character.alpha() = string.utf8(gnirts.soen)
folding: source.package.name() <- string.utf8(gnirts.soen)
folded: source.package.name() <- string.utf8(gnirts.soen) = source.package.name(neos.string)
folding: source.package.import() <- source.package.name(neos.string)
folded: source.package.import() <- source.package.name(neos.string) = source.package.import(neos.string)
folding: source.package.import(neos.string) <- source.package.import(neos.string)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(g)
folding: string.utf8(g) <- string.utf8.character.alpha()
folded: string.utf8(g) <- string.utf8.character.alpha() = string.utf8(gn)
folding: string.utf8(gn) <- string.utf8.character.alpha()
folded: string.utf8(gn) <- string.utf8.character.alpha() = string.utf8(gni)
folding: string.utf8(gni) <- string.utf8.character.alpha()
folded: string.utf8(gni) <- string.utf8.character.alpha() = string.utf8(gnir)
folding: string.utf8(gnir) <- string.utf8.character.alpha()
folded: string.utf8(gnir) <- string.utf8.character.alpha() = string.utf8(gnirt)
folding: string.utf8(gnirt) <- string.utf8.character.alpha()
folded: string.utf8(gnirt) <- string.utf8.character.alpha() = string.utf8(gnirts)
folding: string.utf8(gnirts) <- string.utf8.character.underscore()
folded: string.utf8(gnirts) <- string.utf8.character.underscore() = string.utf8(gnirts_)
folding: string.utf8(gnirts_) <- string.utf8.character.alpha()
folded: string.utf8(gnirts_) <- string.utf8.character.alpha() = string.utf8(gnirts_o)
folding: string.utf8(gnirts_o) <- string.utf8.character.alpha()
folded: string.utf8(gnirts_o) <- string.utf8.character.alpha() = string.utf8(gnirts_ot)
folding: language.identifier() <- string.utf8(gnirts_ot)
folded: language.identifier() <- string.utf8(gnirts_ot) = language.identifier(to_string)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(x)
folding: language.identifier() <- string.utf8(x)
folded: language.identifier() <- string.utf8(x) = language.identifier(x)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(r)
folding: string.utf8(r) <- string.utf8.character.alpha()
folded: string.utf8(r) <- string.utf8.character.alpha() = string.utf8(re)
folding: string.utf8(re) <- string.utf8.character.alpha()
folded: string.utf8(re) <- string.utf8.character.alpha() = string.utf8(reg)
folding: string.utf8(reg) <- string.utf8.character.alpha()
folded: string.utf8(reg) <- string.utf8.character.alpha() = string.utf8(rege)
folding: string.utf8(rege) <- string.utf8.character.alpha()
folded: string.utf8(rege) <- string.utf8.character.alpha() = string.utf8(reget)
folding: string.utf8(reget) <- string.utf8.character.alpha()
folded: string.utf8(reget) <- string.utf8.character.alpha() = string.utf8(regetn)
folding: string.utf8(regetn) <- string.utf8.character.alpha()
folded: string.utf8(regetn) <- string.utf8.character.alpha() = string.utf8(regetni)
folding: string.utf8(regetni) <- string.utf8.character.underscore()
folded: string.utf8(regetni) <- string.utf8.character.underscore() = string.utf8(regetni_)
folding: string.utf8(regetni_) <- string.utf8.character.alpha()
folded: string.utf8(regetni_) <- string.utf8.character.alpha() = string.utf8(regetni_o)
folding: string.utf8(regetni_o) <- string.utf8.character.alpha()
folded: string.utf8(regetni_o) <- string.utf8.character.alpha() = string.utf8(regetni_ot)
folding: language.identifier() <- string.utf8(regetni_ot)
folded: language.identifier() <- string.utf8(regetni_ot) = language.identifier(to_integer)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(s)
folding: language.identifier() <- string.utf8(s)
folded: language.identifier() <- string.utf8(s) = language.identifier(s)
folded: source.package.import(neos.string) <- source.package.import(neos.string) = ()
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(m)
folding: string.utf8(m) <- string.utf8.character.alpha()
folded: string.utf8(m) <- string.utf8.character.alpha() = string.utf8(ma)
folding: string.utf8(ma) <- string.utf8.character.alpha()
folded: string.utf8(ma) <- string.utf8.character.alpha() = string.utf8(mae)
folding: string.utf8(mae) <- string.utf8.character.alpha()
folded: string.utf8(mae) <- string.utf8.character.alpha() = string.utf8(maer)
folding: string.utf8(maer) <- string.utf8.character.alpha()
folded: string.utf8(maer) <- string.utf8.character.alpha() = string.utf8(maert)
folding: string.utf8(maert) <- string.utf8.character.alpha()
folded: string.utf8(maert) <- string.utf8.character.alpha() = string.utf8(maerts)
folding: string.utf8(maerts) <- string.utf8.character.period()
folded: string.utf8(maerts) <- string.utf8.character.period() = string.utf8(maerts.)
folding: string.utf8(maerts.) <- string.utf8.character.alpha()
folded: string.utf8(maerts.) <- string.utf8.character.alpha() = string.utf8(maerts.s)
folding: string.utf8(maerts.s) <- string.utf8.character.alpha()
folded: string.utf8(maerts.s) <- string.utf8.character.alpha() = string.utf8(maerts.so)
folding: string.utf8(maerts.so) <- string.utf8.character.alpha()
folded: string.utf8(maerts.so) <- string.utf8.character.alpha() = string.utf8(maerts.soe)
folding: string.utf8(maerts.soe) <- string.utf8.character.alpha()
folded: string.utf8(maerts.soe) <- string.utf8.character.alpha() = string.utf8(maerts.soen)
folding: source.package.name() <- string.utf8(maerts.soen)
folded: source.package.name() <- string.utf8(maerts.soen) = source.package.name(neos.stream)
folding: source.package.import() <- source.package.name(neos.stream)
folded: source.package.import() <- source.package.name(neos.stream) = source.package.import(neos.stream)
folding: source.package.import(neos.stream) <- source.package.import(neos.stream)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(t)
folding: string.utf8(t) <- string.utf8.character.alpha()
folded: string.utf8(t) <- string.utf8.character.alpha() = string.utf8(tu)
folding: string.utf8(tu) <- string.utf8.character.alpha()
folded: string.utf8(tu) <- string.utf8.character.alpha() = string.utf8(tup)
folding: string.utf8(tup) <- string.utf8.character.alpha()
folded: string.utf8(tup) <- string.utf8.character.alpha() = string.utf8(tupn)
folding: string.utf8(tupn) <- string.utf8.character.alpha()
folded: string.utf8(tupn) <- string.utf8.character.alpha() = string.utf8(tupni)
folding: language.identifier() <- string.utf8(tupni)
folded: language.identifier() <- string.utf8(tupni) = language.identifier(input)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(s)
folding: language.identifier() <- string.utf8(s)
folded: language.identifier() <- string.utf8(s) = language.identifier(s)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(t)
folding: string.utf8(t) <- string.utf8.character.alpha()
folded: string.utf8(t) <- string.utf8.character.alpha() = string.utf8(tn)
folding: string.utf8(tn) <- string.utf8.character.alpha()
folded: string.utf8(tn) <- string.utf8.character.alpha() = string.utf8(tni)
folding: string.utf8(tni) <- string.utf8.character.alpha()
folded: string.utf8(tni) <- string.utf8.character.alpha() = string.utf8(tnir)
folding: string.utf8(tnir) <- string.utf8.character.alpha()
folded: string.utf8(tnir) <- string.utf8.character.alpha() = string.utf8(tnirp)
folding: language.identifier() <- string.utf8(tnirp)
folded: language.identifier() <- string.utf8(tnirp) = language.identifier(print)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(s)
folding: language.identifier() <- string.utf8(s)
folded: language.identifier() <- string.utf8(s) = language.identifier(s)
folded: source.package.import(neos.stream) <- source.package.import(neos.stream) = ()
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(g)
folding: string.utf8(g) <- string.utf8.character.alpha()
folded: string.utf8(g) <- string.utf8.character.alpha() = string.utf8(gn)
folding: string.utf8(gn) <- string.utf8.character.alpha()
folded: string.utf8(gn) <- string.utf8.character.alpha() = string.utf8(gni)
folding: string.utf8(gni) <- string.utf8.character.alpha()
folded: string.utf8(gni) <- string.utf8.character.alpha() = string.utf8(gnir)
folding: string.utf8(gnir) <- string.utf8.character.alpha()
folded: string.utf8(gnir) <- string.utf8.character.alpha() = string.utf8(gnirt)
folding: string.utf8(gnirt) <- string.utf8.character.alpha()
folded: string.utf8(gnirt) <- string.utf8.character.alpha() = string.utf8(gnirts)
folding: string.utf8(gnirts) <- string.utf8.character.underscore()
folded: string.utf8(gnirts) <- string.utf8.character.underscore() = string.utf8(gnirts_)
folding: string.utf8(gnirts_) <- string.utf8.character.alpha()
folded: string.utf8(gnirts_) <- string.utf8.character.alpha() = string.utf8(gnirts_o)
folding: string.utf8(gnirts_o) <- string.utf8.character.alpha()
folded: string.utf8(gnirts_o) <- string.utf8.character.alpha() = string.utf8(gnirts_ot)
folding: language.identifier() <- string.utf8(gnirts_ot)
folded: language.identifier() <- string.utf8(gnirts_ot) = language.identifier(to_string)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(x)
folding: language.identifier() <- string.utf8(x)
folded: language.identifier() <- string.utf8(x) = language.identifier(x)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(r)
folding: string.utf8(r) <- string.utf8.character.alpha()
folded: string.utf8(r) <- string.utf8.character.alpha() = string.utf8(re)
folding: string.utf8(re) <- string.utf8.character.alpha()
folded: string.utf8(re) <- string.utf8.character.alpha() = string.utf8(reg)
folding: string.utf8(reg) <- string.utf8.character.alpha()
folded: string.utf8(reg) <- string.utf8.character.alpha() = string.utf8(rege)
folding: string.utf8(rege) <- string.utf8.character.alpha()
folded: string.utf8(rege) <- string.utf8.character.alpha() = string.utf8(reget)
folding: string.utf8(reget) <- string.utf8.character.alpha()
folded: string.utf8(reget) <- string.utf8.character.alpha() = string.utf8(regetn)
folding: string.utf8(regetn) <- string.utf8.character.alpha()
folded: string.utf8(regetn) <- string.utf8.character.alpha() = string.utf8(regetni)
folding: string.utf8(regetni) <- string.utf8.character.underscore()
folded: string.utf8(regetni) <- string.utf8.character.underscore() = string.utf8(regetni_)
folding: string.utf8(regetni_) <- string.utf8.character.alpha()
folded: string.utf8(regetni_) <- string.utf8.character.alpha() = string.utf8(regetni_o)
folding: string.utf8(regetni_o) <- string.utf8.character.alpha()
folded: string.utf8(regetni_o) <- string.utf8.character.alpha() = string.utf8(regetni_ot)
folding: language.identifier() <- string.utf8(regetni_ot)
folded: language.identifier() <- string.utf8(regetni_ot) = language.identifier(to_integer)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(s)
folding: language.identifier() <- string.utf8(s)
folded: language.identifier() <- string.utf8(s) = language.identifier(s)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(t)
folding: string.utf8(t) <- string.utf8.character.alpha()
folded: string.utf8(t) <- string.utf8.character.alpha() = string.utf8(tu)
folding: string.utf8(tu) <- string.utf8.character.alpha()
folded: string.utf8(tu) <- string.utf8.character.alpha() = string.utf8(tup)
folding: string.utf8(tup) <- string.utf8.character.alpha()
folded: string.utf8(tup) <- string.utf8.character.alpha() = string.utf8(tupn)
folding: string.utf8(tupn) <- string.utf8.character.alpha()
folded: string.utf8(tupn) <- string.utf8.character.alpha() = string.utf8(tupni)
folding: language.identifier() <- string.utf8(tupni)
folded: language.identifier() <- string.utf8(tupni) = language.identifier(input)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(s)
folding: language.identifier() <- string.utf8(s)
folded: language.identifier() <- string.utf8(s) = language.identifier(s)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(t)
folding: string.utf8(t) <- string.utf8.character.alpha()
folded: string.utf8(t) <- string.utf8.character.alpha() = string.utf8(tn)
folding: string.utf8(tn) <- string.utf8.character.alpha()
folded: string.utf8(tn) <- string.utf8.character.alpha() = string.utf8(tni)
folding: string.utf8(tni) <- string.utf8.character.alpha()
folded: string.utf8(tni) <- string.utf8.character.alpha() = string.utf8(tnir)
folding: string.utf8(tnir) <- string.utf8.character.alpha()
folded: string.utf8(tnir) <- string.utf8.character.alpha() = string.utf8(tnirp)
folding: language.identifier() <- string.utf8(tnirp)
folded: language.identifier() <- string.utf8(tnirp) = language.identifier(print)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(s)
folding: language.identifier() <- string.utf8(s)
folded: language.identifier() <- string.utf8(s) = language.identifier(s)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(d)
folding: string.utf8(d) <- string.utf8.character.alpha()
folded: string.utf8(d) <- string.utf8.character.alpha() = string.utf8(dd)
folding: string.utf8(dd) <- string.utf8.character.alpha()
folded: string.utf8(dd) <- string.utf8.character.alpha() = string.utf8(dda)
folding: language.identifier() <- string.utf8(dda)
folded: language.identifier() <- string.utf8(dda) = language.identifier(add)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(x)
folding: language.identifier() <- string.utf8(x)
folded: language.identifier() <- string.utf8(x) = language.identifier(x)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(y)
folding: language.identifier() <- string.utf8(y)
folded: language.identifier() <- string.utf8(y) = language.identifier(y)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(x)
folding: language.identifier() <- string.utf8(x)
folded: language.identifier() <- string.utf8(x) = language.identifier(x)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(y)
folding: language.identifier() <- string.utf8(y)
folded: language.identifier() <- string.utf8(y) = language.identifier(y)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(b)
folding: string.utf8(b) <- string.utf8.character.alpha()
folded: string.utf8(b) <- string.utf8.character.alpha() = string.utf8(bi)
folding: string.utf8(bi) <- string.utf8.character.alpha()
folded: string.utf8(bi) <- string.utf8.character.alpha() = string.utf8(bif)
folding: language.identifier() <- string.utf8(bif)
folded: language.identifier() <- string.utf8(bif) = language.identifier(fib)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(x)
folding: language.identifier() <- string.utf8(x)
folded: language.identifier() <- string.utf8(x) = language.identifier(x)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(x)
folding: language.identifier() <- string.utf8(x)
folded: language.identifier() <- string.utf8(x) = language.identifier(x)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(d)
folding: string.utf8(d) <- string.utf8.character.alpha()
folded: string.utf8(d) <- string.utf8.character.alpha() = string.utf8(dd)
folding: string.utf8(dd) <- string.utf8.character.alpha()
folded: string.utf8(dd) <- string.utf8.character.alpha() = string.utf8(dda)
folding: language.identifier() <- string.utf8(dda)
folded: language.identifier() <- string.utf8(dda) = language.identifier(add)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(b)
folding: string.utf8(b) <- string.utf8.character.alpha()
folded: string.utf8(b) <- string.utf8.character.alpha() = string.utf8(bi)
folding: string.utf8(bi) <- string.utf8.character.alpha()
folded: string.utf8(bi) <- string.utf8.character.alpha() = string.utf8(bif)
folding: language.identifier() <- string.utf8(bif)
folded: language.identifier() <- string.utf8(bif) = language.identifier(fib)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(x)
folding: language.identifier() <- string.utf8(x)
folded: language.identifier() <- string.utf8(x) = language.identifier(x)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(b)
folding: string.utf8(b) <- string.utf8.character.alpha()
folded: string.utf8(b) <- string.utf8.character.alpha() = string.utf8(bi)
folding: string.utf8(bi) <- string.utf8.character.alpha()
folded: string.utf8(bi) <- string.utf8.character.alpha() = string.utf8(bif)
folding: language.identifier() <- string.utf8(bif)
folded: language.identifier() <- string.utf8(bif) = language.identifier(fib)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(x)
folding: language.identifier() <- string.utf8(x)
folded: language.identifier() <- string.utf8(x) = language.identifier(x)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(n)
folding: string.utf8(n) <- string.utf8.character.alpha()
folded: string.utf8(n) <- string.utf8.character.alpha() = string.utf8(ni)
folding: string.utf8(ni) <- string.utf8.character.alpha()
folded: string.utf8(ni) <- string.utf8.character.alpha() = string.utf8(nia)
folding: string.utf8(nia) <- string.utf8.character.alpha()
folded: string.utf8(nia) <- string.utf8.character.alpha() = string.utf8(niam)
folding: language.identifier() <- string.utf8(niam)
folded: language.identifier() <- string.utf8(niam) = language.identifier(main)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(s)
folding: language.identifier() <- string.utf8(s)
folded: language.identifier() <- string.utf8(s) = language.identifier(s)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(t)
folding: string.utf8(t) <- string.utf8.character.alpha()
folded: string.utf8(t) <- string.utf8.character.alpha() = string.utf8(tn)
folding: string.utf8(tn) <- string.utf8.character.alpha()
folded: string.utf8(tn) <- string.utf8.character.alpha() = string.utf8(tni)
folding: string.utf8(tni) <- string.utf8.character.alpha()
folded: string.utf8(tni) <- string.utf8.character.alpha() = string.utf8(tnir)
folding: string.utf8(tnir) <- string.utf8.character.alpha()
folded: string.utf8(tnir) <- string.utf8.character.alpha() = string.utf8(tnirp)
folding: language.identifier() <- string.utf8(tnirp)
folded: language.identifier() <- string.utf8(tnirp) = language.identifier(print)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8( )
folding: string.utf8( ) <- string.utf8.character.alpha()
folded: string.utf8( ) <- string.utf8.character.alpha() = string.utf8(
folding: string.utf8( <- string.utf8.character.alpha()
folded: string.utf8( <- string.utf8.character.alpha() = string.utf8( :r)
folding: string.utf8( :r) <- string.utf8.character.alpha()
folded: string.utf8( :r) <- string.utf8.character.alpha() = string.utf8( :re)
folding: string.utf8( :re) <- string.utf8.character.alpha()
folded: string.utf8( :re) <- string.utf8.character.alpha() = string.utf8( :reg)
folding: string.utf8( :reg) <- string.utf8.character.alpha()
folded: string.utf8( :reg) <- string.utf8.character.alpha() = string.utf8( :rege)
folding: string.utf8( :rege) <- string.utf8.character.alpha()
folded: string.utf8( :rege) <- string.utf8.character.alpha() = string.utf8( :reget)
folding: string.utf8( :reget) <- string.utf8.character.alpha()
folded: string.utf8( :reget) <- string.utf8.character.alpha() = string.utf8( :regetn)
folding: string.utf8( :regetn) <- string.utf8.character.alpha()
folded: string.utf8( :regetn) <- string.utf8.character.alpha() = string.utf8( :regetni)
folding: string.utf8( :regetni) <- string.utf8.character.alpha()
folded: string.utf8( :regetni) <- string.utf8.character.alpha() = string.utf8( :regetni )
folding: string.utf8( :regetni ) <- string.utf8.character.alpha()
folded: string.utf8( :regetni ) <- string.utf8.character.alpha() = string.utf8( :regetni e)
folding: string.utf8( :regetni e) <- string.utf8.character.alpha()
folded: string.utf8( :regetni e) <- string.utf8.character.alpha() = string.utf8( :regetni ev)
folding: string.utf8( :regetni ev) <- string.utf8.character.alpha()
folded: string.utf8( :regetni ev) <- string.utf8.character.alpha() = string.utf8( :regetni evi)
folding: string.utf8( :regetni evi) <- string.utf8.character.alpha()
folded: string.utf8( :regetni evi) <- string.utf8.character.alpha() = string.utf8( :regetni evit)
folding: string.utf8( :regetni evit) <- string.utf8.character.alpha()
folded: string.utf8( :regetni evit) <- string.utf8.character.alpha() = string.utf8( :regetni eviti)
folding: string.utf8( :regetni eviti) <- string.utf8.character.alpha()
folded: string.utf8( :regetni eviti) <- string.utf8.character.alpha() = string.utf8( :regetni evitis)
folding: string.utf8( :regetni evitis) <- string.utf8.character.alpha()
folded: string.utf8( :regetni evitis) <- string.utf8.character.alpha() = string.utf8( :regetni evitiso)
folding: string.utf8( :regetni evitiso) <- string.utf8.character.alpha()
folded: string.utf8( :regetni evitiso) <- string.utf8.character.alpha() = string.utf8( :regetni evitisop)
folding: string.utf8( :regetni evitisop) <- string.utf8.character.alpha()
folded: string.utf8( :regetni evitisop) <- string.utf8.character.alpha() = string.utf8( :regetni evitisop )
folding: string.utf8( :regetni evitisop ) <- string.utf8.character.alpha()
folded: string.utf8( :regetni evitisop ) <- string.utf8.character.alpha() = string.utf8( :regetni evitisop a)
folding: string.utf8( :regetni evitisop a) <- string.utf8.character.alpha()
folded: string.utf8( :regetni evitisop a) <- string.utf8.character.alpha() = string.utf8( :regetni evitisop a )
folding: string.utf8( :regetni evitisop a ) <- string.utf8.character.alpha()
folded: string.utf8( :regetni evitisop a ) <- string.utf8.character.alpha() = string.utf8( :regetni evitisop a r)
folding: string.utf8( :regetni evitisop a r) <- string.utf8.character.alpha()
folded: string.utf8( :regetni evitisop a r) <- string.utf8.character.alpha() = string.utf8( :regetni evitisop a re)
folding: string.utf8( :regetni evitisop a re) <- string.utf8.character.alpha()
folded: string.utf8( :regetni evitisop a re) <- string.utf8.character.alpha() = string.utf8( :regetni evitisop a ret)
folding: string.utf8( :regetni evitisop a ret) <- string.utf8.character.alpha()
folded: string.utf8( :regetni evitisop a ret) <- string.utf8.character.alpha() = string.utf8( :regetni evitisop a retn)
folding: string.utf8( :regetni evitisop a retn) <- string.utf8.character.alpha()
folded: string.utf8( :regetni evitisop a retn) <- string.utf8.character.alpha() = string.utf8( :regetni evitisop a retnE)
folding: string.utf8( :regetni evitisop a retnE) <- string.utf8( :regetni evitisop a retnE)
folded: string.utf8( :regetni evitisop a retnE) <- string.utf8( :regetni evitisop a retnE) = string.utf8(Enter a positive integer: )
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(t)
folding: string.utf8(t) <- string.utf8.character.alpha()
folded: string.utf8(t) <- string.utf8.character.alpha() = string.utf8(tu)
folding: string.utf8(tu) <- string.utf8.character.alpha()
folded: string.utf8(tu) <- string.utf8.character.alpha() = string.utf8(tup)
folding: string.utf8(tup) <- string.utf8.character.alpha()
folded: string.utf8(tup) <- string.utf8.character.alpha() = string.utf8(tupn)
folding: string.utf8(tupn) <- string.utf8.character.alpha()
folded: string.utf8(tupn) <- string.utf8.character.alpha() = string.utf8(tupni)
folding: language.identifier() <- string.utf8(tupni)
folded: language.identifier() <- string.utf8(tupni) = language.identifier(input)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(s)
folding: language.identifier() <- string.utf8(s)
folded: language.identifier() <- string.utf8(s) = language.identifier(s)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(t)
folding: string.utf8(t) <- string.utf8.character.alpha()
folded: string.utf8(t) <- string.utf8.character.alpha() = string.utf8(tn)
folding: string.utf8(tn) <- string.utf8.character.alpha()
folded: string.utf8(tn) <- string.utf8.character.alpha() = string.utf8(tni)
folding: string.utf8(tni) <- string.utf8.character.alpha()
folded: string.utf8(tni) <- string.utf8.character.alpha() = string.utf8(tnir)
folding: string.utf8(tnir) <- string.utf8.character.alpha()
folded: string.utf8(tnir) <- string.utf8.character.alpha() = string.utf8(tnirp)
folding: language.identifier() <- string.utf8(tnirp)
folded: language.identifier() <- string.utf8(tnirp) = language.identifier(print)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(()
folding: string.utf8(() <- string.utf8.character.alpha()
folded: string.utf8(() <- string.utf8.character.alpha() = string.utf8((i)
folding: string.utf8((i) <- string.utf8.character.alpha()
folded: string.utf8((i) <- string.utf8.character.alpha() = string.utf8((ic)
folding: string.utf8((ic) <- string.utf8.character.alpha()
folded: string.utf8((ic) <- string.utf8.character.alpha() = string.utf8((icc)
folding: string.utf8((icc) <- string.utf8.character.alpha()
folded: string.utf8((icc) <- string.utf8.character.alpha() = string.utf8((icca)
folding: string.utf8((icca) <- string.utf8.character.alpha()
folded: string.utf8((icca) <- string.utf8.character.alpha() = string.utf8((iccan)
folding: string.utf8((iccan) <- string.utf8.character.alpha()
folded: string.utf8((iccan) <- string.utf8.character.alpha() = string.utf8((iccano)
folding: string.utf8((iccano) <- string.utf8.character.alpha()
folded: string.utf8((iccano) <- string.utf8.character.alpha() = string.utf8((iccanob)
folding: string.utf8((iccanob) <- string.utf8.character.alpha()
folded: string.utf8((iccanob) <- string.utf8.character.alpha() = string.utf8((iccanobi)
folding: string.utf8((iccanobi) <- string.utf8.character.alpha()
folded: string.utf8((iccanobi) <- string.utf8.character.alpha() = string.utf8((iccanobiF)
folding: string.utf8((iccanobiF) <- string.utf8((iccanobiF)
folded: string.utf8((iccanobiF) <- string.utf8((iccanobiF) = string.utf8(Fibonacci()
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(s)
folding: language.identifier() <- string.utf8(s)
folded: language.identifier() <- string.utf8(s) = language.identifier(s)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8( )
folding: string.utf8( ) <- string.utf8.character.alpha()
folded: string.utf8( ) <- string.utf8.character.alpha() = string.utf8( =)
folding: string.utf8( =) <- string.utf8.character.alpha()
folded: string.utf8( =) <- string.utf8.character.alpha() = string.utf8( = )
folding: string.utf8( = ) <- string.utf8.character.alpha()
folded: string.utf8( = ) <- string.utf8.character.alpha() = string.utf8( = ))
folding: string.utf8( = )) <- string.utf8( = ))
folded: string.utf8( = )) <- string.utf8( = )) = string.utf8() = )
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(g)
folding: string.utf8(g) <- string.utf8.character.alpha()
folded: string.utf8(g) <- string.utf8.character.alpha() = string.utf8(gn)
folding: string.utf8(gn) <- string.utf8.character.alpha()
folded: string.utf8(gn) <- string.utf8.character.alpha() = string.utf8(gni)
folding: string.utf8(gni) <- string.utf8.character.alpha()
folded: string.utf8(gni) <- string.utf8.character.alpha() = string.utf8(gnir)
folding: string.utf8(gnir) <- string.utf8.character.alpha()
folded: string.utf8(gnir) <- string.utf8.character.alpha() = string.utf8(gnirt)
folding: string.utf8(gnirt) <- string.utf8.character.alpha()
folded: string.utf8(gnirt) <- string.utf8.character.alpha() = string.utf8(gnirts)
folding: string.utf8(gnirts) <- string.utf8.character.underscore()
folded: string.utf8(gnirts) <- string.utf8.character.underscore() = string.utf8(gnirts_)
folding: string.utf8(gnirts_) <- string.utf8.character.alpha()
folded: string.utf8(gnirts_) <- string.utf8.character.alpha() = string.utf8(gnirts_o)
folding: string.utf8(gnirts_o) <- string.utf8.character.alpha()
folded: string.utf8(gnirts_o) <- string.utf8.character.alpha() = string.utf8(gnirts_ot)
folding: language.identifier() <- string.utf8(gnirts_ot)
folded: language.identifier() <- string.utf8(gnirts_ot) = language.identifier(to_string)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(b)
folding: string.utf8(b) <- string.utf8.character.alpha()
folded: string.utf8(b) <- string.utf8.character.alpha() = string.utf8(bi)
folding: string.utf8(bi) <- string.utf8.character.alpha()
folded: string.utf8(bi) <- string.utf8.character.alpha() = string.utf8(bif)
folding: language.identifier() <- string.utf8(bif)
folded: language.identifier() <- string.utf8(bif) = language.identifier(fib)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(r)
folding: string.utf8(r) <- string.utf8.character.alpha()
folded: string.utf8(r) <- string.utf8.character.alpha() = string.utf8(re)
folding: string.utf8(re) <- string.utf8.character.alpha()
folded: string.utf8(re) <- string.utf8.character.alpha() = string.utf8(reg)
folding: string.utf8(reg) <- string.utf8.character.alpha()
folded: string.utf8(reg) <- string.utf8.character.alpha() = string.utf8(rege)
folding: string.utf8(rege) <- string.utf8.character.alpha()
folded: string.utf8(rege) <- string.utf8.character.alpha() = string.utf8(reget)
folding: string.utf8(reget) <- string.utf8.character.alpha()
folded: string.utf8(reget) <- string.utf8.character.alpha() = string.utf8(regetn)
folding: string.utf8(regetn) <- string.utf8.character.alpha()
folded: string.utf8(regetn) <- string.utf8.character.alpha() = string.utf8(regetni)
folding: string.utf8(regetni) <- string.utf8.character.underscore()
folded: string.utf8(regetni) <- string.utf8.character.underscore() = string.utf8(regetni_)
folding: string.utf8(regetni_) <- string.utf8.character.alpha()
folded: string.utf8(regetni_) <- string.utf8.character.alpha() = string.utf8(regetni_o)
folding: string.utf8(regetni_o) <- string.utf8.character.alpha()
folded: string.utf8(regetni_o) <- string.utf8.character.alpha() = string.utf8(regetni_ot)
folding: language.identifier() <- string.utf8(regetni_ot)
folded: language.identifier() <- string.utf8(regetni_ot) = language.identifier(to_integer)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(s)
folding: language.identifier() <- string.utf8(s)
folded: language.identifier() <- string.utf8(s) = language.identifier(s)
folding: string.utf8() <- string.utf8.character.LF()
folded: string.utf8() <- string.utf8.character.LF() = string.utf8( )
folding: string.utf8( ) <- string.utf8( )
folded: string.utf8( ) <- string.utf8( ) = string.utf8( )
Compilation time: 336.892ms
neoscript]

Message ends.

/Flibble

--
????
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
rosuav at gmail
Feb 11, 2021, 7:13 AM
Post #2 of 93 (567 views)
Permalink
On Thu, Feb 11, 2021 at 11:36 PM Mr Flibble
<flibble@i42.removethisbit.co.uk> wrote:
>
>
> Hi!
>
> I am starting work on creating a new Python implementation from scratch using "neos" my universal compiler that can compile any programming language.

Is it your intention to support all of Python's syntax and semantics,
or is this an unrelated language with mandatory strict type tags and a
severely restricted set of data types? For instance, can your neos
compile this code?

def power():
return (2**3**4**2) % 1000000000

from time import time
start = time()
print(power())
time = time() - start
print("Took %s seconds" % time)

On my system, I get this from CPython 3.10:
176561152
Took 0.1589798927307129 seconds

And this from PyPy:
176561152
Took 0.0233387947083 seconds

> I envision this implementation to be significantly faster than the currently extant Python implementations (which isn't a stretch given how poorly they perform).

Riiiiiight, yep, all existing Python implementations are terribly
slow. Go ahead then; run the code above, show me a better time, and of
course compare to what a recent off-the-shelf CPython can do on the
same hardware. Then see how PyPy performs at the same job.

> Sample neos session (parsing a fibonacci program, neoscript rather than Python in this case):

Is neoscript an intermediate language like RPython, used only to
implement the compiler, or are you actually transforming Python code
into neoscript?

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
drsalists at gmail
Feb 11, 2021, 8:31 AM
Post #3 of 93 (567 views)
Permalink
On Thu, Feb 11, 2021 at 4:35 AM Mr Flibble <flibble@i42.removethisbit.co.uk>
wrote:

>
> Hi!
>
> I am starting work on creating a new Python implementation from scratch
> using "neos" my universal compiler that can compile any programming
> language. I envision this implementation to be significantly faster than
> the currently extant Python implementations (which isn't a stretch given
> how poorly they perform).
>

I'd like to encourage you to give this a go. It's a huge task, but it's
needed.

You may be interested in the approaches of Pypy, Cython, Shedskin and
Nuitka.

Pypy is a Python written in RPython, where RPython is a restricted subset
of Python 2. It can translate RPython to C, or JIT compile pretty full
Python code - 2.x or 3.x. It has trouble with C extension modules, as the
CPython API for extension modules is pretty leaky. CFFI appears to be the
big hope of fixing this problem, but most C extension modules still use the
CPython C extension Module API.

Cython transpiles a Python-like language to C. It allows you to intermix
Python datatypes and C datatypes; the more you use C datatypes, the faster
the result is. It can be slower if you aren't careful with your type
conversions, but it can be faster if used well. It has a really nice
--annotate option that shows how close to C your program is, line by line.

Shedskin transpiles an implicitly static subset of Python 2 to C++. It's a
great tool, but sadly it is unlikely to make the jump from Python 2 to
Python 3, and Python 3 is definitely the future of Python.

Nuitka is a Python -> C/C++ transpiler. I know little about it, but it
sounds kind of like what you're proposing. It's been focusing on
compatibility first, followed by performance.

Good luck!
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
flibble at i42
Feb 11, 2021, 9:45 AM
Post #4 of 93 (567 views)
Permalink
On 11/02/2021 15:13, Chris Angelico wrote:
> On Thu, Feb 11, 2021 at 11:36 PM Mr Flibble
> <flibble@i42.removethisbit.co.uk> wrote:
>>
>>
>> Hi!
>>
>> I am starting work on creating a new Python implementation from scratch using "neos" my universal compiler that can compile any programming language.
>
> Is it your intention to support all of Python's syntax and semantics,

Yes.

> or is this an unrelated language with mandatory strict type tags and a
> severely restricted set of data types? For instance, can your neos
> compile this code?

No. The neos universal compiler itself is language agnostic: a pre-requisite for the requirement to be able to compile any programming language.

>
> def power():
> return (2**3**4**2) % 1000000000
>
> from time import time
> start = time()
> print(power())
> time = time() - start
> print("Took %s seconds" % time)
>
> On my system, I get this from CPython 3.10:
> 176561152
> Took 0.1589798927307129 seconds
>
> And this from PyPy:
> 176561152
> Took 0.0233387947083 seconds
>
>> I envision this implementation to be significantly faster than the currently extant Python implementations (which isn't a stretch given how poorly they perform).
>
> Riiiiiight, yep, all existing Python implementations are terribly
> slow. Go ahead then; run the code above, show me a better time, and of
> course compare to what a recent off-the-shelf CPython can do on the
> same hardware. Then see how PyPy performs at the same job.

You are timing the arithmetic library rather than the interpreter.

>
>> Sample neos session (parsing a fibonacci program, neoscript rather than Python in this case):
>
> Is neoscript an intermediate language like RPython, used only to
> implement the compiler, or are you actually transforming Python code
> into neoscript?

neoscript is the neos reference language (i.e. not an intermediate language) and will be unrelated to the Python implementation.

/Flibble

--
????
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
flibble at i42
Feb 11, 2021, 9:56 AM
Post #5 of 93 (567 views)
Permalink
On 11/02/2021 16:31, Dan Stromberg wrote:
> On Thu, Feb 11, 2021 at 4:35 AM Mr Flibble <flibble@i42.removethisbit.co.uk>
> wrote:
>
>>
>> Hi!
>>
>> I am starting work on creating a new Python implementation from scratch
>> using "neos" my universal compiler that can compile any programming
>> language. I envision this implementation to be significantly faster than
>> the currently extant Python implementations (which isn't a stretch given
>> how poorly they perform).
>>
>
> I'd like to encourage you to give this a go. It's a huge task, but it's
> needed.

Actually it is a relatively small task due to the neos universal compiler's architectural design. If it was a large task I wouldn't be doing it.

>
> You may be interested in the approaches of Pypy, Cython, Shedskin and
> Nuitka.

I am not particularly interested in any of the existing implementations as they bear no relation to the design of my language agnostic universal compiler, runtime, VM and JIT; the only use they will have will be to disambiguate certain Python language constructs that I cannot disambiguate from documentation alone: this is a natural consequence of Python not being standardized; those steering the language need to grow a pair and get Python standardized preferably as an ISO Standard.

>
> Pypy is a Python written in RPython, where RPython is a restricted subset
> of Python 2. It can translate RPython to C, or JIT compile pretty full
> Python code - 2.x or 3.x. It has trouble with C extension modules, as the
> CPython API for extension modules is pretty leaky. CFFI appears to be the
> big hope of fixing this problem, but most C extension modules still use the
> CPython C extension Module API.

RPython doesn't interest me. neos will be using libffi for FFI.

>
> Cython transpiles a Python-like language to C. It allows you to intermix
> Python datatypes and C datatypes; the more you use C datatypes, the faster
> the result is. It can be slower if you aren't careful with your type
> conversions, but it can be faster if used well. It has a really nice
> --annotate option that shows how close to C your program is, line by line.

I don't agree with the concept of delivering C compilers to end users. The only compilers I think end users should be running are GPU shader compilers and byecode/JIT compilers such as neos.

>
> Shedskin transpiles an implicitly static subset of Python 2 to C++. It's a
> great tool, but sadly it is unlikely to make the jump from Python 2 to
> Python 3, and Python 3 is definitely the future of Python.

Not interested in that (see previous answer replacing "C" with "C++").

>
> Nuitka is a Python -> C/C++ transpiler. I know little about it, but it
> sounds kind of like what you're proposing. It's been focusing on
> compatibility first, followed by performance.

Bears no relation to neos architecture.

>
> Good luck!

Thanks for the sentiment but I am not relying on luck.

/Flibble

--
????
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
rosuav at gmail
Feb 11, 2021, 10:03 AM
Post #6 of 93 (567 views)
Permalink
On Fri, Feb 12, 2021 at 4:52 AM Mr Flibble
<flibble@i42.removethisbit.co.uk> wrote:
>
> On 11/02/2021 15:13, Chris Angelico wrote:
> > On Thu, Feb 11, 2021 at 11:36 PM Mr Flibble
> > <flibble@i42.removethisbit.co.uk> wrote:
> >>
> >>
> >> Hi!
> >>
> >> I am starting work on creating a new Python implementation from scratch using "neos" my universal compiler that can compile any programming language.
> >
> > Is it your intention to support all of Python's syntax and semantics,
>
> Yes.
>
> > or is this an unrelated language with mandatory strict type tags and a
> > severely restricted set of data types? For instance, can your neos
> > compile this code?
>
> No. The neos universal compiler itself is language agnostic: a pre-requisite for the requirement to be able to compile any programming language.
>

Okay, cool, then I misunderstood the point of neoscript (I thought you
would compile Python to neoscript and then neoscript to binary).

As Dan says, go for it, give it a go. I think it'll give you a very
good demonstration of how CPython, and especially PyPy, are actually
highly performant languages :)

> You are timing the arithmetic library rather than the interpreter.

Hmm, I didn't call on any library functions. The crucial and
time-consuming operations were entirely implemented using operators on
constants.

(I also deliberately reused the name "time" in multiple ways, just to
stress-test anything that tries to restrict data types.)

In any case, it's not Python if it can't handle arbitrarily large
numbers. Python is an excellent language for mathematics.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
rosuav at gmail
Feb 11, 2021, 10:06 AM
Post #7 of 93 (567 views)
Permalink
On Fri, Feb 12, 2021 at 5:01 AM Mr Flibble
<flibble@i42.removethisbit.co.uk> wrote:
>
> On 11/02/2021 16:31, Dan Stromberg wrote:
> > On Thu, Feb 11, 2021 at 4:35 AM Mr Flibble <flibble@i42.removethisbit.co.uk>
> > wrote:
> >
> >>
> >> Hi!
> >>
> >> I am starting work on creating a new Python implementation from scratch
> >> using "neos" my universal compiler that can compile any programming
> >> language. I envision this implementation to be significantly faster than
> >> the currently extant Python implementations (which isn't a stretch given
> >> how poorly they perform).
> >>
> >
> > I'd like to encourage you to give this a go. It's a huge task, but it's
> > needed.
>
> Actually it is a relatively small task due to the neos universal compiler's architectural design. If it was a large task I wouldn't be doing it.
>
> >
> > You may be interested in the approaches of Pypy, Cython, Shedskin and
> > Nuitka.
>
> I am not particularly interested in any of the existing implementations as they bear no relation to the design of my language agnostic universal compiler, runtime, VM and JIT; the only use they will have will be to disambiguate certain Python language constructs that I cannot disambiguate from documentation alone: this is a natural consequence of Python not being standardized; those steering the language need to grow a pair and get Python standardized preferably as an ISO Standard.
>

You keep insulting Python and the Python devs. Put up or shut up -
show some actual code before you make too many boasts.

Python DOES have a strong language specification. Its semantics are
documented. If you find places where the documentation is lacking,
point them out specifically, don't FUD your way through.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
flibble at i42
Feb 11, 2021, 10:10 AM
Post #8 of 93 (567 views)
Permalink
On 11/02/2021 18:03, Chris Angelico wrote:

> In any case, it's not Python if it can't handle arbitrarily large
> numbers. Python is an excellent language for mathematics.

I am also creating Ada and Haskell implementations which have a similar requirement.

/Flibble

--
????
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
flibble at i42
Feb 11, 2021, 10:14 AM
Post #9 of 93 (567 views)
Permalink
On 11/02/2021 18:06, Chris Angelico wrote:
> On Fri, Feb 12, 2021 at 5:01 AM Mr Flibble
> <flibble@i42.removethisbit.co.uk> wrote:
>>
>> On 11/02/2021 16:31, Dan Stromberg wrote:
>>> On Thu, Feb 11, 2021 at 4:35 AM Mr Flibble <flibble@i42.removethisbit.co.uk>
>>> wrote:
>>>
>>>>
>>>> Hi!
>>>>
>>>> I am starting work on creating a new Python implementation from scratch
>>>> using "neos" my universal compiler that can compile any programming
>>>> language. I envision this implementation to be significantly faster than
>>>> the currently extant Python implementations (which isn't a stretch given
>>>> how poorly they perform).
>>>>
>>>
>>> I'd like to encourage you to give this a go. It's a huge task, but it's
>>> needed.
>>
>> Actually it is a relatively small task due to the neos universal compiler's architectural design. If it was a large task I wouldn't be doing it.
>>
>>>
>>> You may be interested in the approaches of Pypy, Cython, Shedskin and
>>> Nuitka.
>>
>> I am not particularly interested in any of the existing implementations as they bear no relation to the design of my language agnostic universal compiler, runtime, VM and JIT; the only use they will have will be to disambiguate certain Python language constructs that I cannot disambiguate from documentation alone: this is a natural consequence of Python not being standardized; those steering the language need to grow a pair and get Python standardized preferably as an ISO Standard.
>>
>
> You keep insulting Python and the Python devs. Put up or shut up -
> show some actual code before you make too many boasts.
>
> Python DOES have a strong language specification. Its semantics are
> documented. If you find places where the documentation is lacking,
> point them out specifically, don't FUD your way through.

For a language to transition from "toy" status it has to be formally standardized. It is unacceptable to define a language in terms of a particular implementation. A git repo of Source code and associated observable dynamic behaviour when that code is compiled and ran is a poor substitute for an official ISO Standard.

/Flibble

--
????
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
pbryan at anode
Feb 11, 2021, 10:24 AM
Post #10 of 93 (567 views)
Permalink
On Thu, 2021-02-11 at 17:56 +0000, Mr Flibble wrote:

> Actually it is a relatively small task due to the neos universal
> compiler's architectural design.  If it was a large task I wouldn't
> be doing it.

When do you estimate this task will be completed?

> I am not particularly interested in any of the existing
> implementations as they bear no relation to the design of my language
> agnostic universal compiler, runtime, VM and JIT; the only use they
> will have will be to disambiguate certain Python language constructs
> that I cannot disambiguate from documentation alone: this is a
> natural consequence of Python not being standardized; those steering
> the language need to grow a pair and get Python standardized
> preferably as an ISO Standard.

I take it you don't hope to receive any support from those you're
insulting by such a statement?

> Thanks for the sentiment but I am not relying on luck.

By your conduct so far, I think you will also not be relying on the
goodwill of this community.

Paul

--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
flibble at i42
Feb 11, 2021, 10:29 AM
Post #11 of 93 (567 views)
Permalink
On 11/02/2021 18:24, Paul Bryan wrote:
> On Thu, 2021-02-11 at 17:56 +0000, Mr Flibble wrote:
>
>> Actually it is a relatively small task due to the neos universal
>> compiler's architectural design.  If it was a large task I wouldn't
>> be doing it.
>
> When do you estimate this task will be completed?
>
>> I am not particularly interested in any of the existing
>> implementations as they bear no relation to the design of my language
>> agnostic universal compiler, runtime, VM and JIT; the only use they
>> will have will be to disambiguate certain Python language constructs
>> that I cannot disambiguate from documentation alone: this is a
>> natural consequence of Python not being standardized; those steering
>> the language need to grow a pair and get Python standardized
>> preferably as an ISO Standard.
>
> I take it you don't hope to receive any support from those you're
> insulting by such a statement?
>
>> Thanks for the sentiment but I am not relying on luck.
>
> By your conduct so far, I think you will also not be relying on the
> goodwill of this community.

Personally I prefer telling it like it is (i.e. the truth) rather than walking on eggshells.

/Flibble

--
????
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
python-list at python
Feb 11, 2021, 11:45 AM
Post #12 of 93 (567 views)
Permalink
On 12/02/2021 07.14, Mr Flibble wrote:
> On 11/02/2021 18:06, Chris Angelico wrote:
>> On Fri, Feb 12, 2021 at 5:01 AM Mr Flibble
>> <flibble@i42.removethisbit.co.uk> wrote:
>>>
>>> On 11/02/2021 16:31, Dan Stromberg wrote:
>>>> On Thu, Feb 11, 2021 at 4:35 AM Mr Flibble
>>>> <flibble@i42.removethisbit.co.uk>
>>>> wrote:
>>>>
>>>>> I am starting work on creating a new Python implementation from
>>>>> scratch
... (which isn't a stretch given how poorly they perform).

>>>> I'd like to encourage you to give this a go.  It's a huge task, but
>>>> it's needed.
>>>
>>> Actually it is a relatively small task due to the neos universal
>>> compiler's architectural design.  If it was a large task I wouldn't
>>> be doing it.
>>>
>>>> You may be interested in...
>>>
>>> I am not particularly interested in any of the existing
>>> implementations as they bear no relation to the design of my language

...not being standardized; those steering
>>> the language need to grow a pair and get Python standardized
>>> preferably as an ISO Standard.
...
> For a language to transition from "toy" status it has to be formally
> standardized.  It is unacceptable to define a language in terms of a
> particular implementation. A git repo of Source code and associated
> observable dynamic behaviour when that code is compiled and ran is a
> poor substitute for an official ISO Standard.
>
> /Flibble


When I first met it, one of the concepts I found difficult to 'wrap my
head around' was the idea that "open software" allowed folk to fork the
original work and 'do their own thing'. My thinking was (probably)
"surely, the original is the authoritative version". Having other
versions seemed an invitation to confusion and dilution.

However, as soon as (open) software is made available, other people
start making it 'better' - whatever their own definition of "better".

Yes, it is both a joy and a complication.


Such is contrary to the principle of "standards". At its extreme, a
standard says there is only one way to do the-whatever. This is why many
'standard programming languages' then offer the 'out' of having various
levels of 'standard'. For example, despite being one of the longest
standardised languages, many COBOL implementations achieve only part of
"the standard" - and one has to dive (deep) into the 'small print' to
establish which 'bits' are in their particular 'pick and mix'. Yet, they
still (quite legally) refer to their product as 'standard'!

The second issue with standards is the time and effort it takes to
achieve an agreement and thus reach the point of publishing.

A third issue, and possibly the reason why attempting a standard is a
"losing battle", is that programming and languages are in a constant
state of flux - we call it "ongoing development". Even though Python
v3.10 is reaching a state of anticipation, there are organisations and
libraries that still work using Python 2. Thus, and HTML/"the browser
wars" is an example of this, as fast as a standard is discussed, someone
(even those contributing to said standards) is doing his/her best to
build 'more advanced features' beyond the standard... "Standards" and
'driving development forward' are at least in tension, at worst,
complete-opposites.

Standards, like "waterfall" project specifications, cannot be 'cast in
stone' because the world keeps changing. Standards are insufficiently
agile and Agile!


Whereas the likes of COBOL had "owners", if not as a point-of-fact, at
least in terms of (commercial) 'might' and 'power', Python has its
"Python Software Foundation" (https://www.python.org/psf/). Please feel
free to approach that group to talk about 'what is Python' and
'standardisation'.

Rather than a process of "imposing" a standard, Python has a more 'grass
roots' democratic process which involves PEPs (Python Enhancement
Proposal). These are 'great ideas', even intentions-to-build or
proofs-of-concept, documented, and presented for the community to
consider. The better ones make it through and become part of the
language and its eco-system.

Has the above proposal started on that 'standards path'? Is it
'documented', or merely an idea?


Another aspect of open source is its 'meritocracy' - respect for those
who have demonstrated their abilities (and commitment). Certain names
'crop-up' on PEPs, and more tellingly, on "accepted" PEPs.

Of the three names appearing in this thread, which two have been seen
before, and have contributed to PEPs or to this list, in the past?

Is there a choice to 'stand on the shoulders of giants', or to 'walk all
over ... in hob-nailed boots'? Has this conversation illustrated
respect, or (perhaps unintentionally) torn-down others' sweat-and-tears
without offering something (better) for consideration/approval/use? Is
there any proof that you/I/someone-else can actually "do" better? An
applicable saying is "the proof is in the pudding". So, rather than
claims, shouldn't we be dealing with facts, eg system-A does better than
system-B under the following conditions?


A community comprises people who are prepared to work towards some
commonality. Positivity and friendliness, ie 'honey', tend to work
better than 'vinegar'. Would you say that anything approaching "troll"
behavior is less-likely to achieve cohesion?

Few (successful) projects are managed by a single person. This list is a
great meeting-place to find others who might share your particular
interest - and further, who might be prepared to collaborate - as the
saying goes "scratch your own itch". Is this what you seek? Has the
choice of language/approach in this conversation been best-calculated to
'gather around' like-minded folk? Is there a difference between speaking
with determination and making a case, and being disrespectful of others?


Wishing you well. It seems (to (neos-ignorant) me at least) an ambitious
project. There are certainly times when 'execution speed' becomes a
major criteria. Many of us will look forward to (your development of) a
solution. Please let us know when it's ready for use/trials...




Personal comments:

1
Am admitting to a sense of wariness towards 'new' people who use a
made-up name - despite mine being somewhat obfuscated (NB calling
"David?" in any given community is likely to elicit multiple replies,
thus the "dn"/inviting colleagues to call me by my initials).

2
Noting a false (non-standard/RFC) email address, and consequently every
message's (non-standard) impact on the email-reflector.

3
My mind is whirling in an attempt to understand "show me a better time".
Does this perhaps indicate that @Chris' social life leaves something to
be desired? Are Python-nerds really the ones to turn-to for dating
advice, or is that not what @Chris means by "(having) a good time"?
--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
rosuav at gmail
Feb 11, 2021, 11:53 AM
Post #13 of 93 (567 views)
Permalink
On Fri, Feb 12, 2021 at 6:47 AM dn via Python-list
<python-list@python.org> wrote:
> 3
> My mind is whirling in an attempt to understand "show me a better time".
> Does this perhaps indicate that @Chris' social life leaves something to
> be desired? Are Python-nerds really the ones to turn-to for dating
> advice, or is that not what @Chris means by "(having) a good time"?

LOL! I was referring to the fact that my demonstration snippet
included a rudimentary timing bracket, and that, if existing Python
implementations are indeed abysmally slow, it should be possible to
run the same code on a different interpreter and get a lower number -
a "better" time being shorter.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
python-list at python
Feb 11, 2021, 12:42 PM
Post #14 of 93 (567 views)
Permalink
On 12/02/2021 08.53, Chris Angelico wrote:
> On Fri, Feb 12, 2021 at 6:47 AM dn via Python-list
> <python-list@python.org> wrote:
>> 3
>> My mind is whirling in an attempt to understand "show me a better time".
>> Does this perhaps indicate that @Chris' social life leaves something to
>> be desired? Are Python-nerds really the ones to turn-to for dating
>> advice, or is that not what @Chris means by "(having) a good time"?
>
> LOL! I was referring to the fact that my demonstration snippet
> included a rudimentary timing bracket, and that, if existing Python
> implementations are indeed abysmally slow, it should be possible to
> run the same code on a different interpreter and get a lower number -
> a "better" time being shorter.


Agreed.

I've been 'bitten' by running 'the same' interpreter on different
hardware/configs and finding that one part of the program[me] ran faster
on the dev-machine, and another part faster on the prod-box. Felt a bit
like a no-win situation! Timing was an important contribution. However,
needing to perform same in-situ was a surprise. 'Gotcha'!

There are a lot of variables in the efficiency-game. It's not completely
cut-and-dried to say this, but as a general rule-of-thumb one does not
select Python for applications/components which have significant
execution-time constraints/requirements. However, Python is rarely
bettered when it comes to developer-time! Horses for courses...


As to being outrageously cheeky: even if COVID travel-restrictions have
been lifted, knowing the Tasman Sea remains between us,
allowed/emboldened me to go for the prize(?) for finding at least some
word-play to laugh-about in this whole conversation.

PS my version of bravery is that if you come after me carrying a big
stick, I shall run in the opposite direction - very quickly!

PPS speaking of travel: have you taken advantage of any of the
"vouchers" offered by your (Fed?State) government as an economic
stimulus/recovery for the hospitality industry?
--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
drsalists at gmail
Feb 11, 2021, 1:13 PM
Post #15 of 93 (567 views)
Permalink
On Thu, Feb 11, 2021 at 10:21 AM Mr Flibble <flibble@i42.removethisbit.co.uk>
wrote:

> For a language to transition from "toy" status it has to be formally
> standardized. It is unacceptable to define a language in terms of a
> particular implementation. A git repo of Source code and associated
> observable dynamic behaviour when that code is compiled and ran is a poor
> substitute for an official ISO Standard.
>
I'm inclined to agree, though Python has done surprisingly well at
fostering multiple implementations despite having a reference
implementation for so long.

The thing it'd probably help the most with, is slowly down the rate of
change in the language. The Core Devs seem to want to improve CPython
rapidly, which is not great for the many other implementations - EG Jython
and IronPython. Also, "improvements" in CPython are frequently tending
toward featuritis, since the complexity of a language tends to grow with
the square of its feature count.

Does your project have a name yet? I'd like to follow it through google
alerts or an announcement mailing list.
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
flibble at i42
Feb 11, 2021, 1:58 PM
Post #16 of 93 (567 views)
Permalink
On 11/02/2021 21:13, Dan Stromberg wrote:
> Does your project have a name yet? I'd like to follow it through google
> alerts or an announcement mailing list.

"neos" - https://neos.dev/ https://github.com/i42output/neos

/Flibble

--
????
--
https://mail.python.org/mailman/listinfo/python-list
RE: New Python implementation [ In reply to ]
python-list at python
Feb 11, 2021, 2:22 PM
Post #17 of 93 (566 views)
Permalink
I may be the only one who does not deal well with a condescending attitude.

I have to wonder what international standards body ever completes a task in finite time, only to find the real world has moved on. Having standards can be a great idea. When the standard does not properly describe any implementations either because some leave out things and others have partial or enhanced implementations, then it is just a goal.

May I ask if the proposed product itself needs standardization? Since it claims to support many (or amusingly ANY) language fully, perhaps they can share their Ada or other version before they do Python, or are they working on all of them at once?

Realistically, many languages have chosen various paths and a model that captures them all will have to be fairly complex and perhaps needlessly complex. Does it need multiple ways to deal with issues like scope and perhaps keep track of that if a program crosses several boundaries? Will it be able to handle something like an R program running a package that allows a parallel running of a Python program as they work jointly on the same or copied data structures? I have been writing those lately and in the future may incorporate additional languages to take advantage of the strengths and features of each while avoiding the weaknesses or missing aspects of another.

Anyone who considers the task specified to be a small problem is either brilliant or perhaps not well informed.

If they can do what they say well, great. But I have seen other such attempts such as finding a way to translate between word processor formats that try to deal with overlapping but different concepts and do imperfect translations. That may of course not be relevant here if what is produced is code that runs and yet follows the expected rules as if it was being interpreted.
But a more pleasant attitude may make the same points, not that I am sure what those are and what is being asked. It sounds more like being told.

-----Original Message-----
From: Python-list <python-list-bounces+avigross=verizon.net@python.org> On Behalf Of Mr Flibble
Sent: Thursday, February 11, 2021 1:15 PM
To: python-list@python.org
Subject: Re: New Python implementation

On 11/02/2021 18:06, Chris Angelico wrote:
> On Fri, Feb 12, 2021 at 5:01 AM Mr Flibble
> <flibble@i42.removethisbit.co.uk> wrote:
>>
>> On 11/02/2021 16:31, Dan Stromberg wrote:
>>> On Thu, Feb 11, 2021 at 4:35 AM Mr Flibble
>>> <flibble@i42.removethisbit.co.uk>
>>> wrote:
>>>
>>>>
>>>> Hi!
>>>>
>>>> I am starting work on creating a new Python implementation from
>>>> scratch using "neos" my universal compiler that can compile any
>>>> programming language. I envision this implementation to be
>>>> significantly faster than the currently extant Python
>>>> implementations (which isn't a stretch given how poorly they perform).
>>>>
>>>
>>> I'd like to encourage you to give this a go. It's a huge task, but
>>> it's needed.
>>
>> Actually it is a relatively small task due to the neos universal compiler's architectural design. If it was a large task I wouldn't be doing it.
>>
>>>
>>> You may be interested in the approaches of Pypy, Cython, Shedskin
>>> and Nuitka.
>>
>> I am not particularly interested in any of the existing implementations as they bear no relation to the design of my language agnostic universal compiler, runtime, VM and JIT; the only use they will have will be to disambiguate certain Python language constructs that I cannot disambiguate from documentation alone: this is a natural consequence of Python not being standardized; those steering the language need to grow a pair and get Python standardized preferably as an ISO Standard.
>>
>
> You keep insulting Python and the Python devs. Put up or shut up -
> show some actual code before you make too many boasts.
>
> Python DOES have a strong language specification. Its semantics are
> documented. If you find places where the documentation is lacking,
> point them out specifically, don't FUD your way through.

For a language to transition from "toy" status it has to be formally standardized. It is unacceptable to define a language in terms of a particular implementation. A git repo of Source code and associated observable dynamic behaviour when that code is compiled and ran is a poor substitute for an official ISO Standard.

/Flibble

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

--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
drsalists at gmail
Feb 11, 2021, 2:25 PM
Post #18 of 93 (566 views)
Permalink
On Thu, Feb 11, 2021 at 2:00 PM Mr Flibble <flibble@i42.removethisbit.co.uk>
wrote:

> On 11/02/2021 21:13, Dan Stromberg wrote:
> > Does your project have a name yet? I'd like to follow it through google
> > alerts or an announcement mailing list.
>
> "neos" - https://neos.dev/ https://github.com/i42output/neos
>

Pypi already appears to have another project named neos:
https://pypi.org/project/neos/
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
flibble at i42
Feb 11, 2021, 2:33 PM
Post #19 of 93 (566 views)
Permalink
On 11/02/2021 22:25, Dan Stromberg wrote:
> On Thu, Feb 11, 2021 at 2:00 PM Mr Flibble <flibble@i42.removethisbit.co.uk>
> wrote:
>
>> On 11/02/2021 21:13, Dan Stromberg wrote:
>>> Does your project have a name yet? I'd like to follow it through google
>>> alerts or an announcement mailing list.
>>
>> "neos" - https://neos.dev/ https://github.com/i42output/neos
>>
>
> Pypi already appears to have another project named neos:
> https://pypi.org/project/neos/

neos isn't a Python package so that isn't a problem.

/Flibble

--
????
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
greg.ewing at canterbury
Feb 11, 2021, 3:12 PM
Post #20 of 93 (566 views)
Permalink
On 12/02/21 11:33 am, Mr Flibble wrote:
> neos isn't a Python package so that isn't a problem.

It might be a bit confusing if it ever becomes part of the
wider Python ecosystem, though.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
flibble at i42
Feb 11, 2021, 4:05 PM
Post #21 of 93 (566 views)
Permalink
On 11/02/2021 23:12, Greg Ewing wrote:
> On 12/02/21 11:33 am, Mr Flibble wrote:
>> neos isn't a Python package so that isn't a problem.
>
> It might be a bit confusing if it ever becomes part of the
> wider Python ecosystem, though.
Python is but one language that neos will implement.

/Flibble

--
????
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
flibble at i42
Feb 11, 2021, 4:06 PM
Post #22 of 93 (566 views)
Permalink
On 11/02/2021 23:05, Paul Rubin wrote:
> Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk> writes:
>> "neos" - https://neos.dev/ https://github.com/i42output/neos
>
> Good luck, let us know when it is done. What is there doesn't look like
> a credible start so far, but maybe you will surprise us. Have you
> actually written any code in the languages you say you are going to
> support? E.g. Ada, Haskell, Rust. I'd agree that Python is fairly
> simple compared to those.

Not credible? On what do you base that analysis?

/Flibble

--
????
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
python-list at python
Feb 11, 2021, 4:15 PM
Post #23 of 93 (554 views)
Permalink
On 11/02/2021 12:30, Mr Flibble wrote:

> I am starting work on creating a new Python implementation
> from scratch using "neos" my universal compiler that can
> compile any programming language.

Can i clarify that?
Are you saying that you are going to recompile the existing
C code for pyhton using yoour universal compiler and the
resulting binary file will be a new implementation of
the interpreter that you expect to be faster?

That's what it sounds like to me.
In which case the question is not whether you can write a
better interpreter than CPython but whether you can write
a better compiler than GNU/MING/VC etc

While a universal compiler is certainly an interesting
and challenging project I'm not sure how much it tells us
about existing Python implementations.

On the other hand, if you are planning on rewriting the
existing interpreter in something other than C, what
is that something?

> Sample neos session (parsing a fibonacci program,
> neoscript rather than Python in this case):

I'm not sure what relevance this has unless you want
to rewrite Python in neoscript? Or are you translating
the C into neoscript and then compiling it? But in a
later response you seem to say neoscript was not involved?

Slightly confused...

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
tjreedy at udel
Feb 11, 2021, 6:45 PM
Post #24 of 93 (554 views)
Permalink
On 2/11/2021 5:33 PM, Mr Flibble wrote:
> On 11/02/2021 22:25, Dan Stromberg wrote:
>> On Thu, Feb 11, 2021 at 2:00 PM Mr Flibble
>> <flibble@i42.removethisbit.co.uk>
>> wrote:
>>
>>> On 11/02/2021 21:13, Dan Stromberg wrote:
>>>> Does your project have a name yet?  I'd like to follow it through
>>>> google
>>>> alerts or an announcement mailing list.
>>>
>>> "neos" - https://neos.dev/ https://github.com/i42output/neos
>>>
>>
>> Pypi already appears to have another project named neos:
>> https://pypi.org/project/neos/
>
> neos isn't a Python package so that isn't a problem.

Since it obviously is a Python package, as in importable into a Python
program, why do you deny it?

--
Terry Jan Reedy


--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
flibble at i42
Feb 12, 2021, 1:42 PM
Post #25 of 93 (554 views)
Permalink
On 12/02/2021 02:45, Terry Reedy wrote:
> On 2/11/2021 5:33 PM, Mr Flibble wrote:
>> On 11/02/2021 22:25, Dan Stromberg wrote:
>>> On Thu, Feb 11, 2021 at 2:00 PM Mr Flibble <flibble@i42.removethisbit.co.uk>
>>> wrote:
>>>
>>>> On 11/02/2021 21:13, Dan Stromberg wrote:
>>>>> Does your project have a name yet?  I'd like to follow it through google
>>>>> alerts or an announcement mailing list.
>>>>
>>>> "neos" - https://neos.dev/ https://github.com/i42output/neos
>>>>
>>>
>>> Pypi already appears to have another project named neos:
>>> https://pypi.org/project/neos/
>>
>> neos isn't a Python package so that isn't a problem.
>
> Since it obviously is a Python package, as in importable into a Python program, why do you deny it?

You are mistaken: it isn't a Python package and it isn't importable into a Python program.

/Flibble

--
????
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
flibble at i42
Feb 12, 2021, 1:46 PM
Post #26 of 93 (380 views)
Permalink
On 12/02/2021 00:15, Alan Gauld wrote:
> On 11/02/2021 12:30, Mr Flibble wrote:
>
>> I am starting work on creating a new Python implementation
>> from scratch using "neos" my universal compiler that can
>> compile any programming language.
>
> Can i clarify that?
> Are you saying that you are going to recompile the existing
> C code for pyhton using yoour universal compiler and the
> resulting binary file will be a new implementation of
> the interpreter that you expect to be faster?

Nope.

>
> That's what it sounds like to me.
> In which case the question is not whether you can write a
> better interpreter than CPython but whether you can write
> a better compiler than GNU/MING/VC etc

See previous answer.

>
> While a universal compiler is certainly an interesting
> and challenging project I'm not sure how much it tells us
> about existing Python implementations.

The two things are unrelated; however it is well known that Python is slow.

>
> On the other hand, if you are planning on rewriting the
> existing interpreter in something other than C, what
> is that something?

Nope.

>
>> Sample neos session (parsing a fibonacci program,
>> neoscript rather than Python in this case):
>
> I'm not sure what relevance this has unless you want
> to rewrite Python in neoscript? Or are you translating
> the C into neoscript and then compiling it? But in a
> later response you seem to say neoscript was not involved?
>
> Slightly confused...
>

The neos Python implementation will consist of a schema file which describes the language plus any Python-specific semantic concepts that don't generalize to more than one language.

/Flibble

--
????
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
python-list at python
Feb 12, 2021, 4:01 PM
Post #27 of 93 (379 views)
Permalink
On 12/02/2021 21:46, Mr Flibble wrote:

> The neos Python implementation will consist of a schema file
> which describes the language plus any Python-specific semantic concepts

So the schema file is some kind of formal grammar definition of
the language?

And you "compile" this directly into machine code?
Is that the idea?

So when you say you have a universal compiler for any language
what you mean is that you can produce a compiler/interpreter
for any language from a language definition/schema. Is that it?

I'm still not sure I understand what exactly you are proposing
to do. What the final output looks like?

I'm assuming it's a new executable interpreter that can run any
valid python code. Is that correct?

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
tjreedy at udel
Feb 12, 2021, 10:56 PM
Post #28 of 93 (378 views)
Permalink
On 2/12/2021 4:42 PM, Mr Flibble wrote:
> On 12/02/2021 02:45, Terry Reedy wrote:
>> On 2/11/2021 5:33 PM, Mr Flibble wrote:
>>> On 11/02/2021 22:25, Dan Stromberg wrote:
>>>> On Thu, Feb 11, 2021 at 2:00 PM Mr Flibble
>>>> <flibble@i42.removethisbit.co.uk>
>>>> wrote:
>>>>
>>>>> On 11/02/2021 21:13, Dan Stromberg wrote:
>>>>>> Does your project have a name yet?  I'd like to follow it through
>>>>>> google
>>>>>> alerts or an announcement mailing list.
>>>>>
>>>>> "neos" - https://neos.dev/ https://github.com/i42output/neos
>>>>>
>>>>
>>>> Pypi already appears to have another project named neos:
>>>> https://pypi.org/project/neos/
>>>
>>> neos isn't a Python package so that isn't a problem.
>>
>> Since it obviously is a Python package, as in importable into a Python
>> program, why do you deny it?
>
> You are mistaken: it isn't a Python package and it isn't importable into
> a Python program.

https://pypi.org/project/neos/ shows
import neos.makers as makers
import neos.cls as cls

When you wrote 'neos' without qualification right after the neos package
url, I though you were referring to the package, not your neos. My
mistake and your unclear writing.

--
Terry Jan Reedy


--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
flibble at i42
Feb 13, 2021, 8:09 AM
Post #29 of 93 (378 views)
Permalink
On 13/02/2021 00:01, Alan Gauld wrote:
> On 12/02/2021 21:46, Mr Flibble wrote:
>
>> The neos Python implementation will consist of a schema file
>> which describes the language plus any Python-specific semantic concepts
>
> So the schema file is some kind of formal grammar definition of
> the language?
>
> And you "compile" this directly into machine code?
> Is that the idea?
>
> So when you say you have a universal compiler for any language
> what you mean is that you can produce a compiler/interpreter
> for any language from a language definition/schema. Is that it?
>
> I'm still not sure I understand what exactly you are proposing
> to do. What the final output looks like?
>
> I'm assuming it's a new executable interpreter that can run any
> valid python code. Is that correct?

It is a universal *compiler* so it compiles the python code to byte code and then optionally to machine code via a JIT which is then executed.

/Flibble

--
????
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
python-list at python
Feb 13, 2021, 10:11 AM
Post #30 of 93 (374 views)
Permalink
On 13/02/2021 16:09, Mr Flibble wrote:
> On 13/02/2021 00:01, Alan Gauld wrote:
>> I'm assuming it's a new executable interpreter that can run any
>> valid python code. Is that correct?
>
> It is a universal *compiler* so it compiles the python code to byte code
> and then optionally to machine code via a JIT which is then executed.

OK, sorry for being dense, but just to be absolutely clear.

You are going to create a Python compiler that will take existing
Python code and output a byte code file. (I assume the byte code
is not standard Python byte code?) And I assume the execution
environment for the bytecode is part of your neos system?

If that's correct, then how do you propose to deal with
regular Python byte code? And what would the Python disassembler
produce - Python assembler instructions or neos?

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
ikorot01 at gmail
Feb 13, 2021, 3:30 PM
Post #31 of 93 (374 views)
Permalink
Hi,
But most importantly - what is the reason for this ?
I mean - what problems the actual python compiler produce?

Thank you.


On Sat, Feb 13, 2021, 3:26 PM Alan Gauld via Python-list <
python-list@python.org> wrote:

> On 13/02/2021 16:09, Mr Flibble wrote:
> > On 13/02/2021 00:01, Alan Gauld wrote:
> >> I'm assuming it's a new executable interpreter that can run any
> >> valid python code. Is that correct?
> >
> > It is a universal *compiler* so it compiles the python code to byte code
> > and then optionally to machine code via a JIT which is then executed.
>
> OK, sorry for being dense, but just to be absolutely clear.
>
> You are going to create a Python compiler that will take existing
> Python code and output a byte code file. (I assume the byte code
> is not standard Python byte code?) And I assume the execution
> environment for the bytecode is part of your neos system?
>
> If that's correct, then how do you propose to deal with
> regular Python byte code? And what would the Python disassembler
> produce - Python assembler instructions or neos?
>
> --
> Alan G
> Author of the Learn to Program web site
> http://www.alan-g.me.uk/
> http://www.amazon.com/author/alan_gauld
> Follow my photo-blog on Flickr at:
> http://www.flickr.com/photos/alangauldphotos
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
flibble at i42
Feb 13, 2021, 4:07 PM
Post #32 of 93 (374 views)
Permalink
On 13/02/2021 18:11, Alan Gauld wrote:
> On 13/02/2021 16:09, Mr Flibble wrote:
>> On 13/02/2021 00:01, Alan Gauld wrote:
>>> I'm assuming it's a new executable interpreter that can run any
>>> valid python code. Is that correct?
>>
>> It is a universal *compiler* so it compiles the python code to byte code
>> and then optionally to machine code via a JIT which is then executed.
>
> OK, sorry for being dense, but just to be absolutely clear.
>
> You are going to create a Python compiler that will take existing
> Python code and output a byte code file. (I assume the byte code
> is not standard Python byte code?) And I assume the execution
> environment for the bytecode is part of your neos system?

No neos is not a Python compiler: it is a *universal* compiler that can compile any programming language describable by a schema file and any language-specific semantic concepts. The byte code will be proprietary, yes, and will be executed by neos and/or JITed.

>
> If that's correct, then how do you propose to deal with
> regular Python byte code? And what would the Python disassembler
> produce - Python assembler instructions or neos?

The neos Python implementation will not be dealing with Python byte code in any form whatsoever.

/Flibble

--
????
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
flibble at i42
Feb 13, 2021, 4:09 PM
Post #33 of 93 (372 views)
Permalink
On 13/02/2021 23:30, Igor Korot wrote:
> Hi,
> But most importantly - what is the reason for this ?
> I mean - what problems the actual python compiler produce?
>
> Thank you.

I am creating neos as I need a performant scripting engine for my other major project "neoGFX" and I want to be able to support multiple popular scripting languages including Python.

/Flibble

--
????
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
rosuav at gmail
Feb 13, 2021, 4:19 PM
Post #34 of 93 (372 views)
Permalink
On Sun, Feb 14, 2021 at 11:14 AM Mr Flibble
<flibble@i42.removethisbit.co.uk> wrote:
>
> On 13/02/2021 23:30, Igor Korot wrote:
> > Hi,
> > But most importantly - what is the reason for this ?
> > I mean - what problems the actual python compiler produce?
> >
> > Thank you.
>
> I am creating neos as I need a performant scripting engine for my other major project "neoGFX" and I want to be able to support multiple popular scripting languages including Python.
>

Until you have actually produced a (mostly) compatible Python
implementation, can you please stop making these repeated and baseless
jabs at CPython's performance? You keep stating or hinting that
CPython is somehow unnecessarily slow, but unless you have some code
to back your claims, this is nothing but mudslinging.

CPython is not as slow as you might think. And PyPy is highly
efficient at what it does well. Show us that you can do better than
these before you call them slow.

At the absolute least, show that you have something that can run Python code.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
RE: New Python implementation [ In reply to ]
python-list at python
Feb 13, 2021, 4:47 PM
Post #35 of 93 (372 views)
Permalink
It is likely that people would understand better if spoken to properly so I have been listening and hopefully gaining a picture that I can share, and be corrected helpfully when wrong.

My personal guess is that the project at hand is to do something very vaguely like what was done to the CURSES functionality ages ago in prehistory where lots of different terminals (and terminal emulators) used an assortment of control and escape sequences to make a text-based terminal do things like delete to the end of a line. The idea was to extract out all kinds of functionality used by pretty much all the terminals and save the info for say the hp2621 terminal either in a file with that name, or as entries in a file specifying many terminals or even in your environment. Then you made sure you had some variable like TERM set to hp2621 or whatever. If later you logged in on another kind of terminal, it would adjust dynamically for that without changing your program.

When a program like vi(m) or emacs ran, it used the curses library which would dynamically reconfigure based on the terminal used and try to figure out the cheapest way (in terms of characters and I/O usually) to send extra escape sequences to update your screen as changes were made. Sometimes it would clear the screen and re-enter the new stuff and sometimes delete three lines then put in the replacement and so on.

End of example. There are other examples like a format for documents that might take one of many ones like Word and make a common storage format that can easily be printed on any device that supports the features. The important aspect for me, is abstraction.

My impression is the proposed project would abstract out the details of what any language can do and then examine one language after another (such as Ada or Python) and create some kind of description that can be stored, such as in a file. I have no idea what that might look like. I assume it would include what keywords there are or what variable names might look like or if some construct has an ending like "FI" or "endif" or "}" and it is only once this is completed, that the next phase can be used.

It sounds like they would have what he considers a universal compiler that determines what language (perhaps even version) a file or group of files are using and then loads in info that metamorphizes it into an effective compiler for that language. It may not be that simple and I have no idea how it does that or how it outputs the result but it sounds like they have yet another language we might loosely compare to the byte stream used by JAVA and SCALA and some others that is half-digested and can be run by the JVM, or the Python version of something along those lines.

In any case, I get the impression that this output will then look about the same no matter what language it came from. It will not require specific run-time environments but one overarching runtime that can run anything, again, using whatever abstraction or rules they come up with. And, in some cases, you may choose to go a step further and take this portable file format and compile it further down to an executable that runs on a specific machine and so on. I shudder at how well it will output error messages!

Assuming this is feasible and well done, it might open quite a few doors in terms of designing both mini-languages and variants on existing ones and brand new ones with new ideas. You would have to find a way to describe your language as described above and as long as it is consistent in some ways, no need to ever build your own interpreter or compiler. It might be a bit like designing a new terminal (or just emulator) that has features you want. Mind you, some of the new features might require changes in the "Neo" something/data before it can be handled, but once added, any other language, within reason, might be able to add a similar feature and it should work.

I hope I got this at least partially right and it is more informative that repeatedly telling people things like "Nope" as if this is a quiz and not an informative discussion.

-----Original Message-----
From: Python-list <python-list-bounces+avigross=verizon.net@python.org> On Behalf Of Mr Flibble
Sent: Saturday, February 13, 2021 7:07 PM
To: python-list@python.org
Subject: Re: New Python implementation

On 13/02/2021 18:11, Alan Gauld wrote:
> On 13/02/2021 16:09, Mr Flibble wrote:
>> On 13/02/2021 00:01, Alan Gauld wrote:
>>> I'm assuming it's a new executable interpreter that can run any
>>> valid python code. Is that correct?
>>
>> It is a universal *compiler* so it compiles the python code to byte
>> code and then optionally to machine code via a JIT which is then executed.
>
> OK, sorry for being dense, but just to be absolutely clear.
>
> You are going to create a Python compiler that will take existing
> Python code and output a byte code file. (I assume the byte code is
> not standard Python byte code?) And I assume the execution environment
> for the bytecode is part of your neos system?

No neos is not a Python compiler: it is a *universal* compiler that can compile any programming language describable by a schema file and any language-specific semantic concepts. The byte code will be proprietary, yes, and will be executed by neos and/or JITed.

>
> If that's correct, then how do you propose to deal with regular Python
> byte code? And what would the Python disassembler produce - Python
> assembler instructions or neos?

The neos Python implementation will not be dealing with Python byte code in any form whatsoever.

/Flibble

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

--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
ned at nedbatchelder
Feb 13, 2021, 4:51 PM
Post #36 of 93 (372 views)
Permalink
On Saturday, February 13, 2021 at 7:19:58 PM UTC-5, Chris Angelico wrote:
> On Sun, Feb 14, 2021 at 11:14 AM Mr Flibble
> <fli...@i42.removethisbit.co.uk> wrote:
> >
> > On 13/02/2021 23:30, Igor Korot wrote:
> > > Hi,
> > > But most importantly - what is the reason for this ?
> > > I mean - what problems the actual python compiler produce?
> > >
> > > Thank you.
> >
> > I am creating neos as I need a performant scripting engine for my other major project "neoGFX" and I want to be able to support multiple popular scripting languages including Python.
> >
> Until you have actually produced a (mostly) compatible Python
> implementation, can you please stop making these repeated and baseless
> jabs at CPython's performance? You keep stating or hinting that
> CPython is somehow unnecessarily slow, but unless you have some code
> to back your claims, this is nothing but mudslinging.
>
> CPython is not as slow as you might think. And PyPy is highly
> efficient at what it does well. Show us that you can do better than
> these before you call them slow.
>
> At the absolute least, show that you have something that can run Python code.
>
> ChrisA

The OP has been making these claims on IRC for a while (at least two years). He has never cared to substantiate them, or even participate in a civil and detailed discussion. He is either 1) smarter than all of us, or 2) woefully under-informed, or 3) trolling. Our best course is to ignore him until he has code we can try.

--Ned.
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
python-list at python
Feb 13, 2021, 4:52 PM
Post #37 of 93 (372 views)
Permalink
On 14/02/2021 00:07, Mr Flibble wrote:
> On 13/02/2021 18:11, Alan Gauld wrote:

>> You are going to create a Python compiler that will take existing
>> Python code and output a byte code file.
>
> No neos is not a Python compiler: it is a *universal* compiler that
> can compile any programming language describable by a schema file

Yes, I understand that, but from the perspective of this list
what you are doing is providing a tool (a combination of neos
and a schema) that will take in Python source code and spit out
neos byte code. So, to all intents and purposes it is a Python
compiler (albeit capable of more when needed).

>> If that's correct, then how do you propose to deal with
>> regular Python byte code? And what would the Python disassembler
>> produce - Python assembler instructions or neos?
>
> The neos Python implementation will not be dealing
> with Python byte code in any form whatsoever.

Ok but what do you do with the disassembler module?
Will it read neos byte code instead of the Python codes?
Also what about tools that work at the byte code level,
I assume they will not work with neos either?
That might include the profiler and debugger for example?

Also what would happen with the interactive prompt (>>>)
I'm assuming you'd expect users to continue using the CPython
interpreter and only compile the source after it was working
there? Like turning on the optimiser in a traditional
compiled language like C.

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
flibble at i42
Feb 13, 2021, 6:13 PM
Post #38 of 93 (372 views)
Permalink
On 14/02/2021 00:19, Chris Angelico wrote:
> On Sun, Feb 14, 2021 at 11:14 AM Mr Flibble
> <flibble@i42.removethisbit.co.uk> wrote:
>>
>> On 13/02/2021 23:30, Igor Korot wrote:
>>> Hi,
>>> But most importantly - what is the reason for this ?
>>> I mean - what problems the actual python compiler produce?
>>>
>>> Thank you.
>>
>> I am creating neos as I need a performant scripting engine for my other major project "neoGFX" and I want to be able to support multiple popular scripting languages including Python.
>>
>
> Until you have actually produced a (mostly) compatible Python
> implementation, can you please stop making these repeated and baseless
> jabs at CPython's performance? You keep stating or hinting that
> CPython is somehow unnecessarily slow, but unless you have some code
> to back your claims, this is nothing but mudslinging.
>
> CPython is not as slow as you might think. And PyPy is highly
> efficient at what it does well. Show us that you can do better than
> these before you call them slow.
>
> At the absolute least, show that you have something that can run Python code.

It isn't just me that is saying CPython is egregiously slow: it is at the bottom of the list as far as performance is concerned. Python is undoubtedly the biggest contributor to climate change of all the programming languages in mainstream use today.

See: https://thenewstack.io/which-programming-languages-use-the-least-electricity/

/Flibble

--
????
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
flibble at i42
Feb 13, 2021, 6:17 PM
Post #39 of 93 (372 views)
Permalink
On 14/02/2021 00:51, Ned Batchelder wrote:
> On Saturday, February 13, 2021 at 7:19:58 PM UTC-5, Chris Angelico wrote:
>> On Sun, Feb 14, 2021 at 11:14 AM Mr Flibble
>> <fli...@i42.removethisbit.co.uk> wrote:
>>>
>>> On 13/02/2021 23:30, Igor Korot wrote:
>>>> Hi,
>>>> But most importantly - what is the reason for this ?
>>>> I mean - what problems the actual python compiler produce?
>>>>
>>>> Thank you.
>>>
>>> I am creating neos as I need a performant scripting engine for my other major project "neoGFX" and I want to be able to support multiple popular scripting languages including Python.
>>>
>> Until you have actually produced a (mostly) compatible Python
>> implementation, can you please stop making these repeated and baseless
>> jabs at CPython's performance? You keep stating or hinting that
>> CPython is somehow unnecessarily slow, but unless you have some code
>> to back your claims, this is nothing but mudslinging.
>>
>> CPython is not as slow as you might think. And PyPy is highly
>> efficient at what it does well. Show us that you can do better than
>> these before you call them slow.
>>
>> At the absolute least, show that you have something that can run Python code.
>>
>> ChrisA
>
> The OP has been making these claims on IRC for a while (at least two years). He has never cared to substantiate them, or even participate in a civil and detailed discussion. He is either 1) smarter than all of us, or 2) woefully under-informed, or 3) trolling. Our best course is to ignore him until he has code we can try.

I am sure you are most annoyed that you can't ban me from Usenet, dear, like you banned me from IRC. You need to grow the fuck up.

Your use of the words "all of us" is disingenuous, try "me" instead. "All of us" includes people as smart as me but can't be arsed fixing the Python space because they can just about live with the status quo.

/Flibble

--
????
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
grant.b.edwards at gmail
Feb 13, 2021, 7:26 PM
Post #40 of 93 (372 views)
Permalink
On 2021-02-14, Ned Batchelder <ned@nedbatchelder.com> wrote:
> On Saturday, February 13, 2021 at 7:19:58 PM UTC-5, Chris Angelico wrote:
>
>> At the absolute least, show that you have something that can run Python code.
>
> The OP has been making these claims on IRC for a (at least two
> years). He has never cared to substantiate them, or even participate
> in a civil and detailed discussion. He is either 1) smarter than
> all of us, or 2) woefully under-informed, or 3) trolling.

He posts using the name of a hand-puppet. I think that provides a bit
of a clue as to which of the 3 is most likely. And it's not even a
_real_ hand-puppet: it's a computer-generated hologram of a hand
hand-puppet.





--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
flibble at i42
Feb 13, 2021, 7:59 PM
Post #41 of 93 (372 views)
Permalink
On 14/02/2021 03:35, Paul Rubin wrote:
> Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk> writes:
>> I am creating neos as I need a performant scripting engine for my
>> other major project "neoGFX" and I want to be able to support multiple
>> popular scripting languages including Python.
>
> Is something wrong with Guile for that purpose? If yes, maybe you are
> setting yourself up for the exact same obstacles ;-).

NIH.

/Flibble

--
????
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
flibble at i42
Feb 13, 2021, 8:08 PM
Post #42 of 93 (372 views)
Permalink
On 14/02/2021 02:54, Mark Lawrence wrote:
> On Sunday, February 14, 2021 at 2:18:03 AM UTC, Mr Flibble wrote:
>> On 14/02/2021 00:51, Ned Batchelder wrote:
>
>>> The OP has been making these claims on IRC for a while (at least two years). He has never cared to substantiate them, or even participate in a civil and detailed discussion. He is either 1) smarter than all of us, or 2) woefully under-informed, or 3) trolling. Our best course is to ignore him until he has code we can try.
>> I am sure you are most annoyed that you can't ban me from Usenet, dear, like you banned me from IRC. You need to grow the fuck up.
>
> I take it that you didn't write "How to win friends and influence people"? I don't suppose that the moderators will actually wake up and remove you from the mailing lists asap.

I see you are just as prickly as Ned, Mark. May I suggest that you too grow a pair? I am not on the mailing list BTW; e-mail lists are an outmoded concept much like CPython.

/Flibble

--
????
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
flibble at i42
Feb 13, 2021, 8:48 PM
Post #43 of 93 (372 views)
Permalink
On 14/02/2021 00:52, Alan Gauld wrote:
> On 14/02/2021 00:07, Mr Flibble wrote:
>> On 13/02/2021 18:11, Alan Gauld wrote:
>
>>> You are going to create a Python compiler that will take existing
>>> Python code and output a byte code file.
>>
>> No neos is not a Python compiler: it is a *universal* compiler that
>> can compile any programming language describable by a schema file
>
> Yes, I understand that, but from the perspective of this list
> what you are doing is providing a tool (a combination of neos
> and a schema) that will take in Python source code and spit out
> neos byte code. So, to all intents and purposes it is a Python
> compiler (albeit capable of more when needed).
>
>>> If that's correct, then how do you propose to deal with
>>> regular Python byte code? And what would the Python disassembler
>>> produce - Python assembler instructions or neos?
>>
>> The neos Python implementation will not be dealing
>> with Python byte code in any form whatsoever.
>
> Ok but what do you do with the disassembler module?
> Will it read neos byte code instead of the Python codes?
> Also what about tools that work at the byte code level,
> I assume they will not work with neos either?
> That might include the profiler and debugger for example?

neos will include a language agnostic disassembler and debugger.

>
> Also what would happen with the interactive prompt (>>>)
> I'm assuming you'd expect users to continue using the CPython
> interpreter and only compile the source after it was working
> there? Like turning on the optimiser in a traditional
> compiled language like C.

neos will include support for interactive sessions; no reason to use CPython at all.

/Flibble

--
????
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
flibble at i42
Feb 13, 2021, 8:50 PM
Post #44 of 93 (372 views)
Permalink
On 14/02/2021 03:26, Grant Edwards wrote:
> On 2021-02-14, Ned Batchelder <ned@nedbatchelder.com> wrote:
>> On Saturday, February 13, 2021 at 7:19:58 PM UTC-5, Chris Angelico wrote:
>>
>>> At the absolute least, show that you have something that can run Python code.
>>
>> The OP has been making these claims on IRC for a (at least two
>> years). He has never cared to substantiate them, or even participate
>> in a civil and detailed discussion. He is either 1) smarter than
>> all of us, or 2) woefully under-informed, or 3) trolling.
>
> He posts using the name of a hand-puppet. I think that provides a bit
> of a clue as to which of the 3 is most likely. And it's not even a
> _real_ hand-puppet: it's a computer-generated hologram of a hand
> hand-puppet.

lulz. If I am a troll then Elon Musk is also a troll.

/Flibble

--
????
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
arj.python at gmail
Feb 13, 2021, 9:31 PM
Post #45 of 93 (369 views)
Permalink
After reading the thread i'm like: where can i try it out ...

On Thu, 11 Feb 2021, 16:38 Mr Flibble, <flibble@i42.removethisbit.co.uk>
wrote:

>
> Hi!
>
> I am starting work on creating a new Python implementation from scratch
> using "neos" my universal compiler that can compile any programming
> language. I envision this implementation to be significantly faster than
> the currently extant Python implementations (which isn't a stretch given
> how poorly they perform).
>
> Sample neos session (parsing a fibonacci program, neoscript rather than
> Python in this case):
>
> neos 1.0.0.0 ED-209
> ] help
> h(elp)
> s(chema) <path to language schema> Load language schema
> l(oad) <path to program> Load program
> list List program
> c(ompile) Compile program
> r(un) Run program
> ![<expression>] Evaluate expression (enter
> interactive mode if expression omitted)
> :<input> Input (as stdin)
> q(uit) Quit neos
> lc List loaded concept libraries
> t(race) <0|1|2|3|4|5> [<filter>] Compiler trace
> m(etrics) Display metrics for running
> programs
> ] lc
> [neos.core] (file:///D:\code\neos\build\win32\vs2019\x64\Release\core.ncl)
> [neos.boolean]
> [neos.language]
> [neos.logic]
> [neos.math]
> [neos.module]
> [neos.object]
> [neos.string]
> [neos.math.universal]
> (file:///D:\code\neos\build\win32\vs2019\x64\Release\core.math.universal.ncl)
> ] s neoscript
> Loading schema 'neoscript'...
> Language: Default neoGFX scripting language
> Version: 1.0.0
> Copyright (C) 2019 Leigh Johnston
> neoscript] l examples/neoscript/fibonacci.neo
> neoscript] list
> File 'examples/neoscript/fibonacci.neo':
> -- neoscript example: Fibonacci
>
> using neos.string;
> using neos.stream;
>
> import fn to_string(x : i32) -> string;
> import fn to_integer(s : string) -> i32;
> import proc input(s : out string);
> import proc print(s : in string);
>
> -- functions are pure
> def fn add(x, y : i32) -> i32
> {
> return x + y;
> }
> def fn fib(x : i32) -> i32
> {
> if (x < 2)
> return 1;
> else
> return add(fib(x-1), fib(x-2));
> }
>
> -- procedures are impure
> def proc main()
> s : string;
> {
> print("Enter a positive "
> "integer: ");
> input(s);
> print("Fibonacci(" + s + ") = " + to_string(fib(to_integer(s))) +
> "\n");
> }
> neoscript] t 1
> neoscript] c
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(g)
> folding: string.utf8(g) <- string.utf8.character.alpha()
> folded: string.utf8(g) <- string.utf8.character.alpha() = string.utf8(gn)
> folding: string.utf8(gn) <- string.utf8.character.alpha()
> folded: string.utf8(gn) <- string.utf8.character.alpha() = string.utf8(gni)
> folding: string.utf8(gni) <- string.utf8.character.alpha()
> folded: string.utf8(gni) <- string.utf8.character.alpha() =
> string.utf8(gnir)
> folding: string.utf8(gnir) <- string.utf8.character.alpha()
> folded: string.utf8(gnir) <- string.utf8.character.alpha() =
> string.utf8(gnirt)
> folding: string.utf8(gnirt) <- string.utf8.character.alpha()
> folded: string.utf8(gnirt) <- string.utf8.character.alpha() =
> string.utf8(gnirts)
> folding: string.utf8(gnirts) <- string.utf8.character.period()
> folded: string.utf8(gnirts) <- string.utf8.character.period() =
> string.utf8(gnirts.)
> folding: string.utf8(gnirts.) <- string.utf8.character.alpha()
> folded: string.utf8(gnirts.) <- string.utf8.character.alpha() =
> string.utf8(gnirts.s)
> folding: string.utf8(gnirts.s) <- string.utf8.character.alpha()
> folded: string.utf8(gnirts.s) <- string.utf8.character.alpha() =
> string.utf8(gnirts.so)
> folding: string.utf8(gnirts.so) <- string.utf8.character.alpha()
> folded: string.utf8(gnirts.so) <- string.utf8.character.alpha() =
> string.utf8(gnirts.soe)
> folding: string.utf8(gnirts.soe) <- string.utf8.character.alpha()
> folded: string.utf8(gnirts.soe) <- string.utf8.character.alpha() =
> string.utf8(gnirts.soen)
> folding: source.package.name() <- string.utf8(gnirts.soen)
> folded: source.package.name() <- string.utf8(gnirts.soen) =
> source.package.name(neos.string)
> folding: source.package.import() <- source.package.name(neos.string)
> folded: source.package.import() <- source.package.name(neos.string) =
> source.package.import(neos.string)
> folding: source.package.import(neos.string) <-
> source.package.import(neos.string)
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(g)
> folding: string.utf8(g) <- string.utf8.character.alpha()
> folded: string.utf8(g) <- string.utf8.character.alpha() = string.utf8(gn)
> folding: string.utf8(gn) <- string.utf8.character.alpha()
> folded: string.utf8(gn) <- string.utf8.character.alpha() = string.utf8(gni)
> folding: string.utf8(gni) <- string.utf8.character.alpha()
> folded: string.utf8(gni) <- string.utf8.character.alpha() =
> string.utf8(gnir)
> folding: string.utf8(gnir) <- string.utf8.character.alpha()
> folded: string.utf8(gnir) <- string.utf8.character.alpha() =
> string.utf8(gnirt)
> folding: string.utf8(gnirt) <- string.utf8.character.alpha()
> folded: string.utf8(gnirt) <- string.utf8.character.alpha() =
> string.utf8(gnirts)
> folding: string.utf8(gnirts) <- string.utf8.character.underscore()
> folded: string.utf8(gnirts) <- string.utf8.character.underscore() =
> string.utf8(gnirts_)
> folding: string.utf8(gnirts_) <- string.utf8.character.alpha()
> folded: string.utf8(gnirts_) <- string.utf8.character.alpha() =
> string.utf8(gnirts_o)
> folding: string.utf8(gnirts_o) <- string.utf8.character.alpha()
> folded: string.utf8(gnirts_o) <- string.utf8.character.alpha() =
> string.utf8(gnirts_ot)
> folding: language.identifier() <- string.utf8(gnirts_ot)
> folded: language.identifier() <- string.utf8(gnirts_ot) =
> language.identifier(to_string)
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(x)
> folding: language.identifier() <- string.utf8(x)
> folded: language.identifier() <- string.utf8(x) = language.identifier(x)
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(r)
> folding: string.utf8(r) <- string.utf8.character.alpha()
> folded: string.utf8(r) <- string.utf8.character.alpha() = string.utf8(re)
> folding: string.utf8(re) <- string.utf8.character.alpha()
> folded: string.utf8(re) <- string.utf8.character.alpha() = string.utf8(reg)
> folding: string.utf8(reg) <- string.utf8.character.alpha()
> folded: string.utf8(reg) <- string.utf8.character.alpha() =
> string.utf8(rege)
> folding: string.utf8(rege) <- string.utf8.character.alpha()
> folded: string.utf8(rege) <- string.utf8.character.alpha() =
> string.utf8(reget)
> folding: string.utf8(reget) <- string.utf8.character.alpha()
> folded: string.utf8(reget) <- string.utf8.character.alpha() =
> string.utf8(regetn)
> folding: string.utf8(regetn) <- string.utf8.character.alpha()
> folded: string.utf8(regetn) <- string.utf8.character.alpha() =
> string.utf8(regetni)
> folding: string.utf8(regetni) <- string.utf8.character.underscore()
> folded: string.utf8(regetni) <- string.utf8.character.underscore() =
> string.utf8(regetni_)
> folding: string.utf8(regetni_) <- string.utf8.character.alpha()
> folded: string.utf8(regetni_) <- string.utf8.character.alpha() =
> string.utf8(regetni_o)
> folding: string.utf8(regetni_o) <- string.utf8.character.alpha()
> folded: string.utf8(regetni_o) <- string.utf8.character.alpha() =
> string.utf8(regetni_ot)
> folding: language.identifier() <- string.utf8(regetni_ot)
> folded: language.identifier() <- string.utf8(regetni_ot) =
> language.identifier(to_integer)
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(s)
> folding: language.identifier() <- string.utf8(s)
> folded: language.identifier() <- string.utf8(s) = language.identifier(s)
> folded: source.package.import(neos.string) <-
> source.package.import(neos.string) = ()
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(m)
> folding: string.utf8(m) <- string.utf8.character.alpha()
> folded: string.utf8(m) <- string.utf8.character.alpha() = string.utf8(ma)
> folding: string.utf8(ma) <- string.utf8.character.alpha()
> folded: string.utf8(ma) <- string.utf8.character.alpha() = string.utf8(mae)
> folding: string.utf8(mae) <- string.utf8.character.alpha()
> folded: string.utf8(mae) <- string.utf8.character.alpha() =
> string.utf8(maer)
> folding: string.utf8(maer) <- string.utf8.character.alpha()
> folded: string.utf8(maer) <- string.utf8.character.alpha() =
> string.utf8(maert)
> folding: string.utf8(maert) <- string.utf8.character.alpha()
> folded: string.utf8(maert) <- string.utf8.character.alpha() =
> string.utf8(maerts)
> folding: string.utf8(maerts) <- string.utf8.character.period()
> folded: string.utf8(maerts) <- string.utf8.character.period() =
> string.utf8(maerts.)
> folding: string.utf8(maerts.) <- string.utf8.character.alpha()
> folded: string.utf8(maerts.) <- string.utf8.character.alpha() =
> string.utf8(maerts.s)
> folding: string.utf8(maerts.s) <- string.utf8.character.alpha()
> folded: string.utf8(maerts.s) <- string.utf8.character.alpha() =
> string.utf8(maerts.so)
> folding: string.utf8(maerts.so) <- string.utf8.character.alpha()
> folded: string.utf8(maerts.so) <- string.utf8.character.alpha() =
> string.utf8(maerts.soe)
> folding: string.utf8(maerts.soe) <- string.utf8.character.alpha()
> folded: string.utf8(maerts.soe) <- string.utf8.character.alpha() =
> string.utf8(maerts.soen)
> folding: source.package.name() <- string.utf8(maerts.soen)
> folded: source.package.name() <- string.utf8(maerts.soen) =
> source.package.name(neos.stream)
> folding: source.package.import() <- source.package.name(neos.stream)
> folded: source.package.import() <- source.package.name(neos.stream) =
> source.package.import(neos.stream)
> folding: source.package.import(neos.stream) <-
> source.package.import(neos.stream)
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(t)
> folding: string.utf8(t) <- string.utf8.character.alpha()
> folded: string.utf8(t) <- string.utf8.character.alpha() = string.utf8(tu)
> folding: string.utf8(tu) <- string.utf8.character.alpha()
> folded: string.utf8(tu) <- string.utf8.character.alpha() = string.utf8(tup)
> folding: string.utf8(tup) <- string.utf8.character.alpha()
> folded: string.utf8(tup) <- string.utf8.character.alpha() =
> string.utf8(tupn)
> folding: string.utf8(tupn) <- string.utf8.character.alpha()
> folded: string.utf8(tupn) <- string.utf8.character.alpha() =
> string.utf8(tupni)
> folding: language.identifier() <- string.utf8(tupni)
> folded: language.identifier() <- string.utf8(tupni) =
> language.identifier(input)
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(s)
> folding: language.identifier() <- string.utf8(s)
> folded: language.identifier() <- string.utf8(s) = language.identifier(s)
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(t)
> folding: string.utf8(t) <- string.utf8.character.alpha()
> folded: string.utf8(t) <- string.utf8.character.alpha() = string.utf8(tn)
> folding: string.utf8(tn) <- string.utf8.character.alpha()
> folded: string.utf8(tn) <- string.utf8.character.alpha() = string.utf8(tni)
> folding: string.utf8(tni) <- string.utf8.character.alpha()
> folded: string.utf8(tni) <- string.utf8.character.alpha() =
> string.utf8(tnir)
> folding: string.utf8(tnir) <- string.utf8.character.alpha()
> folded: string.utf8(tnir) <- string.utf8.character.alpha() =
> string.utf8(tnirp)
> folding: language.identifier() <- string.utf8(tnirp)
> folded: language.identifier() <- string.utf8(tnirp) =
> language.identifier(print)
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(s)
> folding: language.identifier() <- string.utf8(s)
> folded: language.identifier() <- string.utf8(s) = language.identifier(s)
> folded: source.package.import(neos.stream) <-
> source.package.import(neos.stream) = ()
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(g)
> folding: string.utf8(g) <- string.utf8.character.alpha()
> folded: string.utf8(g) <- string.utf8.character.alpha() = string.utf8(gn)
> folding: string.utf8(gn) <- string.utf8.character.alpha()
> folded: string.utf8(gn) <- string.utf8.character.alpha() = string.utf8(gni)
> folding: string.utf8(gni) <- string.utf8.character.alpha()
> folded: string.utf8(gni) <- string.utf8.character.alpha() =
> string.utf8(gnir)
> folding: string.utf8(gnir) <- string.utf8.character.alpha()
> folded: string.utf8(gnir) <- string.utf8.character.alpha() =
> string.utf8(gnirt)
> folding: string.utf8(gnirt) <- string.utf8.character.alpha()
> folded: string.utf8(gnirt) <- string.utf8.character.alpha() =
> string.utf8(gnirts)
> folding: string.utf8(gnirts) <- string.utf8.character.underscore()
> folded: string.utf8(gnirts) <- string.utf8.character.underscore() =
> string.utf8(gnirts_)
> folding: string.utf8(gnirts_) <- string.utf8.character.alpha()
> folded: string.utf8(gnirts_) <- string.utf8.character.alpha() =
> string.utf8(gnirts_o)
> folding: string.utf8(gnirts_o) <- string.utf8.character.alpha()
> folded: string.utf8(gnirts_o) <- string.utf8.character.alpha() =
> string.utf8(gnirts_ot)
> folding: language.identifier() <- string.utf8(gnirts_ot)
> folded: language.identifier() <- string.utf8(gnirts_ot) =
> language.identifier(to_string)
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(x)
> folding: language.identifier() <- string.utf8(x)
> folded: language.identifier() <- string.utf8(x) = language.identifier(x)
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(r)
> folding: string.utf8(r) <- string.utf8.character.alpha()
> folded: string.utf8(r) <- string.utf8.character.alpha() = string.utf8(re)
> folding: string.utf8(re) <- string.utf8.character.alpha()
> folded: string.utf8(re) <- string.utf8.character.alpha() = string.utf8(reg)
> folding: string.utf8(reg) <- string.utf8.character.alpha()
> folded: string.utf8(reg) <- string.utf8.character.alpha() =
> string.utf8(rege)
> folding: string.utf8(rege) <- string.utf8.character.alpha()
> folded: string.utf8(rege) <- string.utf8.character.alpha() =
> string.utf8(reget)
> folding: string.utf8(reget) <- string.utf8.character.alpha()
> folded: string.utf8(reget) <- string.utf8.character.alpha() =
> string.utf8(regetn)
> folding: string.utf8(regetn) <- string.utf8.character.alpha()
> folded: string.utf8(regetn) <- string.utf8.character.alpha() =
> string.utf8(regetni)
> folding: string.utf8(regetni) <- string.utf8.character.underscore()
> folded: string.utf8(regetni) <- string.utf8.character.underscore() =
> string.utf8(regetni_)
> folding: string.utf8(regetni_) <- string.utf8.character.alpha()
> folded: string.utf8(regetni_) <- string.utf8.character.alpha() =
> string.utf8(regetni_o)
> folding: string.utf8(regetni_o) <- string.utf8.character.alpha()
> folded: string.utf8(regetni_o) <- string.utf8.character.alpha() =
> string.utf8(regetni_ot)
> folding: language.identifier() <- string.utf8(regetni_ot)
> folded: language.identifier() <- string.utf8(regetni_ot) =
> language.identifier(to_integer)
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(s)
> folding: language.identifier() <- string.utf8(s)
> folded: language.identifier() <- string.utf8(s) = language.identifier(s)
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(t)
> folding: string.utf8(t) <- string.utf8.character.alpha()
> folded: string.utf8(t) <- string.utf8.character.alpha() = string.utf8(tu)
> folding: string.utf8(tu) <- string.utf8.character.alpha()
> folded: string.utf8(tu) <- string.utf8.character.alpha() = string.utf8(tup)
> folding: string.utf8(tup) <- string.utf8.character.alpha()
> folded: string.utf8(tup) <- string.utf8.character.alpha() =
> string.utf8(tupn)
> folding: string.utf8(tupn) <- string.utf8.character.alpha()
> folded: string.utf8(tupn) <- string.utf8.character.alpha() =
> string.utf8(tupni)
> folding: language.identifier() <- string.utf8(tupni)
> folded: language.identifier() <- string.utf8(tupni) =
> language.identifier(input)
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(s)
> folding: language.identifier() <- string.utf8(s)
> folded: language.identifier() <- string.utf8(s) = language.identifier(s)
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(t)
> folding: string.utf8(t) <- string.utf8.character.alpha()
> folded: string.utf8(t) <- string.utf8.character.alpha() = string.utf8(tn)
> folding: string.utf8(tn) <- string.utf8.character.alpha()
> folded: string.utf8(tn) <- string.utf8.character.alpha() = string.utf8(tni)
> folding: string.utf8(tni) <- string.utf8.character.alpha()
> folded: string.utf8(tni) <- string.utf8.character.alpha() =
> string.utf8(tnir)
> folding: string.utf8(tnir) <- string.utf8.character.alpha()
> folded: string.utf8(tnir) <- string.utf8.character.alpha() =
> string.utf8(tnirp)
> folding: language.identifier() <- string.utf8(tnirp)
> folded: language.identifier() <- string.utf8(tnirp) =
> language.identifier(print)
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(s)
> folding: language.identifier() <- string.utf8(s)
> folded: language.identifier() <- string.utf8(s) = language.identifier(s)
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(d)
> folding: string.utf8(d) <- string.utf8.character.alpha()
> folded: string.utf8(d) <- string.utf8.character.alpha() = string.utf8(dd)
> folding: string.utf8(dd) <- string.utf8.character.alpha()
> folded: string.utf8(dd) <- string.utf8.character.alpha() = string.utf8(dda)
> folding: language.identifier() <- string.utf8(dda)
> folded: language.identifier() <- string.utf8(dda) =
> language.identifier(add)
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(x)
> folding: language.identifier() <- string.utf8(x)
> folded: language.identifier() <- string.utf8(x) = language.identifier(x)
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(y)
> folding: language.identifier() <- string.utf8(y)
> folded: language.identifier() <- string.utf8(y) = language.identifier(y)
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(x)
> folding: language.identifier() <- string.utf8(x)
> folded: language.identifier() <- string.utf8(x) = language.identifier(x)
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(y)
> folding: language.identifier() <- string.utf8(y)
> folded: language.identifier() <- string.utf8(y) = language.identifier(y)
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(b)
> folding: string.utf8(b) <- string.utf8.character.alpha()
> folded: string.utf8(b) <- string.utf8.character.alpha() = string.utf8(bi)
> folding: string.utf8(bi) <- string.utf8.character.alpha()
> folded: string.utf8(bi) <- string.utf8.character.alpha() = string.utf8(bif)
> folding: language.identifier() <- string.utf8(bif)
> folded: language.identifier() <- string.utf8(bif) =
> language.identifier(fib)
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(x)
> folding: language.identifier() <- string.utf8(x)
> folded: language.identifier() <- string.utf8(x) = language.identifier(x)
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(x)
> folding: language.identifier() <- string.utf8(x)
> folded: language.identifier() <- string.utf8(x) = language.identifier(x)
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(d)
> folding: string.utf8(d) <- string.utf8.character.alpha()
> folded: string.utf8(d) <- string.utf8.character.alpha() = string.utf8(dd)
> folding: string.utf8(dd) <- string.utf8.character.alpha()
> folded: string.utf8(dd) <- string.utf8.character.alpha() = string.utf8(dda)
> folding: language.identifier() <- string.utf8(dda)
> folded: language.identifier() <- string.utf8(dda) =
> language.identifier(add)
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(b)
> folding: string.utf8(b) <- string.utf8.character.alpha()
> folded: string.utf8(b) <- string.utf8.character.alpha() = string.utf8(bi)
> folding: string.utf8(bi) <- string.utf8.character.alpha()
> folded: string.utf8(bi) <- string.utf8.character.alpha() = string.utf8(bif)
> folding: language.identifier() <- string.utf8(bif)
> folded: language.identifier() <- string.utf8(bif) =
> language.identifier(fib)
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(x)
> folding: language.identifier() <- string.utf8(x)
> folded: language.identifier() <- string.utf8(x) = language.identifier(x)
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(b)
> folding: string.utf8(b) <- string.utf8.character.alpha()
> folded: string.utf8(b) <- string.utf8.character.alpha() = string.utf8(bi)
> folding: string.utf8(bi) <- string.utf8.character.alpha()
> folded: string.utf8(bi) <- string.utf8.character.alpha() = string.utf8(bif)
> folding: language.identifier() <- string.utf8(bif)
> folded: language.identifier() <- string.utf8(bif) =
> language.identifier(fib)
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(x)
> folding: language.identifier() <- string.utf8(x)
> folded: language.identifier() <- string.utf8(x) = language.identifier(x)
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(n)
> folding: string.utf8(n) <- string.utf8.character.alpha()
> folded: string.utf8(n) <- string.utf8.character.alpha() = string.utf8(ni)
> folding: string.utf8(ni) <- string.utf8.character.alpha()
> folded: string.utf8(ni) <- string.utf8.character.alpha() = string.utf8(nia)
> folding: string.utf8(nia) <- string.utf8.character.alpha()
> folded: string.utf8(nia) <- string.utf8.character.alpha() =
> string.utf8(niam)
> folding: language.identifier() <- string.utf8(niam)
> folded: language.identifier() <- string.utf8(niam) =
> language.identifier(main)
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(s)
> folding: language.identifier() <- string.utf8(s)
> folded: language.identifier() <- string.utf8(s) = language.identifier(s)
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(t)
> folding: string.utf8(t) <- string.utf8.character.alpha()
> folded: string.utf8(t) <- string.utf8.character.alpha() = string.utf8(tn)
> folding: string.utf8(tn) <- string.utf8.character.alpha()
> folded: string.utf8(tn) <- string.utf8.character.alpha() = string.utf8(tni)
> folding: string.utf8(tni) <- string.utf8.character.alpha()
> folded: string.utf8(tni) <- string.utf8.character.alpha() =
> string.utf8(tnir)
> folding: string.utf8(tnir) <- string.utf8.character.alpha()
> folded: string.utf8(tnir) <- string.utf8.character.alpha() =
> string.utf8(tnirp)
> folding: language.identifier() <- string.utf8(tnirp)
> folded: language.identifier() <- string.utf8(tnirp) =
> language.identifier(print)
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8( )
> folding: string.utf8( ) <- string.utf8.character.alpha()
> folded: string.utf8( ) <- string.utf8.character.alpha() = string.utf8(
> folding: string.utf8( <- string.utf8.character.alpha()
> folded: string.utf8( <- string.utf8.character.alpha() = string.utf8( :r)
> folding: string.utf8( :r) <- string.utf8.character.alpha()
> folded: string.utf8( :r) <- string.utf8.character.alpha() = string.utf8(
> :re)
> folding: string.utf8( :re) <- string.utf8.character.alpha()
> folded: string.utf8( :re) <- string.utf8.character.alpha() = string.utf8(
> :reg)
> folding: string.utf8( :reg) <- string.utf8.character.alpha()
> folded: string.utf8( :reg) <- string.utf8.character.alpha() = string.utf8(
> :rege)
> folding: string.utf8( :rege) <- string.utf8.character.alpha()
> folded: string.utf8( :rege) <- string.utf8.character.alpha() =
> string.utf8( :reget)
> folding: string.utf8( :reget) <- string.utf8.character.alpha()
> folded: string.utf8( :reget) <- string.utf8.character.alpha() =
> string.utf8( :regetn)
> folding: string.utf8( :regetn) <- string.utf8.character.alpha()
> folded: string.utf8( :regetn) <- string.utf8.character.alpha() =
> string.utf8( :regetni)
> folding: string.utf8( :regetni) <- string.utf8.character.alpha()
> folded: string.utf8( :regetni) <- string.utf8.character.alpha() =
> string.utf8( :regetni )
> folding: string.utf8( :regetni ) <- string.utf8.character.alpha()
> folded: string.utf8( :regetni ) <- string.utf8.character.alpha() =
> string.utf8( :regetni e)
> folding: string.utf8( :regetni e) <- string.utf8.character.alpha()
> folded: string.utf8( :regetni e) <- string.utf8.character.alpha() =
> string.utf8( :regetni ev)
> folding: string.utf8( :regetni ev) <- string.utf8.character.alpha()
> folded: string.utf8( :regetni ev) <- string.utf8.character.alpha() =
> string.utf8( :regetni evi)
> folding: string.utf8( :regetni evi) <- string.utf8.character.alpha()
> folded: string.utf8( :regetni evi) <- string.utf8.character.alpha() =
> string.utf8( :regetni evit)
> folding: string.utf8( :regetni evit) <- string.utf8.character.alpha()
> folded: string.utf8( :regetni evit) <- string.utf8.character.alpha() =
> string.utf8( :regetni eviti)
> folding: string.utf8( :regetni eviti) <- string.utf8.character.alpha()
> folded: string.utf8( :regetni eviti) <- string.utf8.character.alpha() =
> string.utf8( :regetni evitis)
> folding: string.utf8( :regetni evitis) <- string.utf8.character.alpha()
> folded: string.utf8( :regetni evitis) <- string.utf8.character.alpha() =
> string.utf8( :regetni evitiso)
> folding: string.utf8( :regetni evitiso) <- string.utf8.character.alpha()
> folded: string.utf8( :regetni evitiso) <- string.utf8.character.alpha() =
> string.utf8( :regetni evitisop)
> folding: string.utf8( :regetni evitisop) <- string.utf8.character.alpha()
> folded: string.utf8( :regetni evitisop) <- string.utf8.character.alpha() =
> string.utf8( :regetni evitisop )
> folding: string.utf8( :regetni evitisop ) <- string.utf8.character.alpha()
> folded: string.utf8( :regetni evitisop ) <- string.utf8.character.alpha()
> = string.utf8( :regetni evitisop a)
> folding: string.utf8( :regetni evitisop a) <- string.utf8.character.alpha()
> folded: string.utf8( :regetni evitisop a) <- string.utf8.character.alpha()
> = string.utf8( :regetni evitisop a )
> folding: string.utf8( :regetni evitisop a ) <-
> string.utf8.character.alpha()
> folded: string.utf8( :regetni evitisop a ) <-
> string.utf8.character.alpha() = string.utf8( :regetni evitisop a r)
> folding: string.utf8( :regetni evitisop a r) <-
> string.utf8.character.alpha()
> folded: string.utf8( :regetni evitisop a r) <-
> string.utf8.character.alpha() = string.utf8( :regetni evitisop a re)
> folding: string.utf8( :regetni evitisop a re) <-
> string.utf8.character.alpha()
> folded: string.utf8( :regetni evitisop a re) <-
> string.utf8.character.alpha() = string.utf8( :regetni evitisop a ret)
> folding: string.utf8( :regetni evitisop a ret) <-
> string.utf8.character.alpha()
> folded: string.utf8( :regetni evitisop a ret) <-
> string.utf8.character.alpha() = string.utf8( :regetni evitisop a retn)
> folding: string.utf8( :regetni evitisop a retn) <-
> string.utf8.character.alpha()
> folded: string.utf8( :regetni evitisop a retn) <-
> string.utf8.character.alpha() = string.utf8( :regetni evitisop a retnE)
> folding: string.utf8( :regetni evitisop a retnE) <- string.utf8( :regetni
> evitisop a retnE)
> folded: string.utf8( :regetni evitisop a retnE) <- string.utf8( :regetni
> evitisop a retnE) = string.utf8(Enter a positive integer: )
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(t)
> folding: string.utf8(t) <- string.utf8.character.alpha()
> folded: string.utf8(t) <- string.utf8.character.alpha() = string.utf8(tu)
> folding: string.utf8(tu) <- string.utf8.character.alpha()
> folded: string.utf8(tu) <- string.utf8.character.alpha() = string.utf8(tup)
> folding: string.utf8(tup) <- string.utf8.character.alpha()
> folded: string.utf8(tup) <- string.utf8.character.alpha() =
> string.utf8(tupn)
> folding: string.utf8(tupn) <- string.utf8.character.alpha()
> folded: string.utf8(tupn) <- string.utf8.character.alpha() =
> string.utf8(tupni)
> folding: language.identifier() <- string.utf8(tupni)
> folded: language.identifier() <- string.utf8(tupni) =
> language.identifier(input)
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(s)
> folding: language.identifier() <- string.utf8(s)
> folded: language.identifier() <- string.utf8(s) = language.identifier(s)
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(t)
> folding: string.utf8(t) <- string.utf8.character.alpha()
> folded: string.utf8(t) <- string.utf8.character.alpha() = string.utf8(tn)
> folding: string.utf8(tn) <- string.utf8.character.alpha()
> folded: string.utf8(tn) <- string.utf8.character.alpha() = string.utf8(tni)
> folding: string.utf8(tni) <- string.utf8.character.alpha()
> folded: string.utf8(tni) <- string.utf8.character.alpha() =
> string.utf8(tnir)
> folding: string.utf8(tnir) <- string.utf8.character.alpha()
> folded: string.utf8(tnir) <- string.utf8.character.alpha() =
> string.utf8(tnirp)
> folding: language.identifier() <- string.utf8(tnirp)
> folded: language.identifier() <- string.utf8(tnirp) =
> language.identifier(print)
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(()
> folding: string.utf8(() <- string.utf8.character.alpha()
> folded: string.utf8(() <- string.utf8.character.alpha() = string.utf8((i)
> folding: string.utf8((i) <- string.utf8.character.alpha()
> folded: string.utf8((i) <- string.utf8.character.alpha() = string.utf8((ic)
> folding: string.utf8((ic) <- string.utf8.character.alpha()
> folded: string.utf8((ic) <- string.utf8.character.alpha() =
> string.utf8((icc)
> folding: string.utf8((icc) <- string.utf8.character.alpha()
> folded: string.utf8((icc) <- string.utf8.character.alpha() =
> string.utf8((icca)
> folding: string.utf8((icca) <- string.utf8.character.alpha()
> folded: string.utf8((icca) <- string.utf8.character.alpha() =
> string.utf8((iccan)
> folding: string.utf8((iccan) <- string.utf8.character.alpha()
> folded: string.utf8((iccan) <- string.utf8.character.alpha() =
> string.utf8((iccano)
> folding: string.utf8((iccano) <- string.utf8.character.alpha()
> folded: string.utf8((iccano) <- string.utf8.character.alpha() =
> string.utf8((iccanob)
> folding: string.utf8((iccanob) <- string.utf8.character.alpha()
> folded: string.utf8((iccanob) <- string.utf8.character.alpha() =
> string.utf8((iccanobi)
> folding: string.utf8((iccanobi) <- string.utf8.character.alpha()
> folded: string.utf8((iccanobi) <- string.utf8.character.alpha() =
> string.utf8((iccanobiF)
> folding: string.utf8((iccanobiF) <- string.utf8((iccanobiF)
> folded: string.utf8((iccanobiF) <- string.utf8((iccanobiF) =
> string.utf8(Fibonacci()
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(s)
> folding: language.identifier() <- string.utf8(s)
> folded: language.identifier() <- string.utf8(s) = language.identifier(s)
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8( )
> folding: string.utf8( ) <- string.utf8.character.alpha()
> folded: string.utf8( ) <- string.utf8.character.alpha() = string.utf8( =)
> folding: string.utf8( =) <- string.utf8.character.alpha()
> folded: string.utf8( =) <- string.utf8.character.alpha() = string.utf8( = )
> folding: string.utf8( = ) <- string.utf8.character.alpha()
> folded: string.utf8( = ) <- string.utf8.character.alpha() = string.utf8( =
> ))
> folding: string.utf8( = )) <- string.utf8( = ))
> folded: string.utf8( = )) <- string.utf8( = )) = string.utf8() = )
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(g)
> folding: string.utf8(g) <- string.utf8.character.alpha()
> folded: string.utf8(g) <- string.utf8.character.alpha() = string.utf8(gn)
> folding: string.utf8(gn) <- string.utf8.character.alpha()
> folded: string.utf8(gn) <- string.utf8.character.alpha() = string.utf8(gni)
> folding: string.utf8(gni) <- string.utf8.character.alpha()
> folded: string.utf8(gni) <- string.utf8.character.alpha() =
> string.utf8(gnir)
> folding: string.utf8(gnir) <- string.utf8.character.alpha()
> folded: string.utf8(gnir) <- string.utf8.character.alpha() =
> string.utf8(gnirt)
> folding: string.utf8(gnirt) <- string.utf8.character.alpha()
> folded: string.utf8(gnirt) <- string.utf8.character.alpha() =
> string.utf8(gnirts)
> folding: string.utf8(gnirts) <- string.utf8.character.underscore()
> folded: string.utf8(gnirts) <- string.utf8.character.underscore() =
> string.utf8(gnirts_)
> folding: string.utf8(gnirts_) <- string.utf8.character.alpha()
> folded: string.utf8(gnirts_) <- string.utf8.character.alpha() =
> string.utf8(gnirts_o)
> folding: string.utf8(gnirts_o) <- string.utf8.character.alpha()
> folded: string.utf8(gnirts_o) <- string.utf8.character.alpha() =
> string.utf8(gnirts_ot)
> folding: language.identifier() <- string.utf8(gnirts_ot)
> folded: language.identifier() <- string.utf8(gnirts_ot) =
> language.identifier(to_string)
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(b)
> folding: string.utf8(b) <- string.utf8.character.alpha()
> folded: string.utf8(b) <- string.utf8.character.alpha() = string.utf8(bi)
> folding: string.utf8(bi) <- string.utf8.character.alpha()
> folded: string.utf8(bi) <- string.utf8.character.alpha() = string.utf8(bif)
> folding: language.identifier() <- string.utf8(bif)
> folded: language.identifier() <- string.utf8(bif) =
> language.identifier(fib)
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(r)
> folding: string.utf8(r) <- string.utf8.character.alpha()
> folded: string.utf8(r) <- string.utf8.character.alpha() = string.utf8(re)
> folding: string.utf8(re) <- string.utf8.character.alpha()
> folded: string.utf8(re) <- string.utf8.character.alpha() = string.utf8(reg)
> folding: string.utf8(reg) <- string.utf8.character.alpha()
> folded: string.utf8(reg) <- string.utf8.character.alpha() =
> string.utf8(rege)
> folding: string.utf8(rege) <- string.utf8.character.alpha()
> folded: string.utf8(rege) <- string.utf8.character.alpha() =
> string.utf8(reget)
> folding: string.utf8(reget) <- string.utf8.character.alpha()
> folded: string.utf8(reget) <- string.utf8.character.alpha() =
> string.utf8(regetn)
> folding: string.utf8(regetn) <- string.utf8.character.alpha()
> folded: string.utf8(regetn) <- string.utf8.character.alpha() =
> string.utf8(regetni)
> folding: string.utf8(regetni) <- string.utf8.character.underscore()
> folded: string.utf8(regetni) <- string.utf8.character.underscore() =
> string.utf8(regetni_)
> folding: string.utf8(regetni_) <- string.utf8.character.alpha()
> folded: string.utf8(regetni_) <- string.utf8.character.alpha() =
> string.utf8(regetni_o)
> folding: string.utf8(regetni_o) <- string.utf8.character.alpha()
> folded: string.utf8(regetni_o) <- string.utf8.character.alpha() =
> string.utf8(regetni_ot)
> folding: language.identifier() <- string.utf8(regetni_ot)
> folded: language.identifier() <- string.utf8(regetni_ot) =
> language.identifier(to_integer)
> folding: string.utf8() <- string.utf8.character.alpha()
> folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(s)
> folding: language.identifier() <- string.utf8(s)
> folded: language.identifier() <- string.utf8(s) = language.identifier(s)
> folding: string.utf8() <- string.utf8.character.LF()
> folded: string.utf8() <- string.utf8.character.LF() = string.utf8( )
> folding: string.utf8( ) <- string.utf8( )
> folded: string.utf8( ) <- string.utf8( ) = string.utf8( )
> Compilation time: 336.892ms
> neoscript]
>
> Message ends.
>
> /Flibble
>
> --
> ????
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
auriocus at gmx
Feb 14, 2021, 1:15 AM
Post #46 of 93 (371 views)
Permalink
Am 14.02.21 um 01:19 schrieb Chris Angelico:
> On Sun, Feb 14, 2021 at 11:14 AM Mr Flibble
> <flibble@i42.removethisbit.co.uk> wrote:
>>
>> On 13/02/2021 23:30, Igor Korot wrote:
>>> Hi,
>>> But most importantly - what is the reason for this ?
>>> I mean - what problems the actual python compiler produce?
>>>
>>> Thank you.
>>
>> I am creating neos as I need a performant scripting engine for my other major project "neoGFX" and I want to be able to support multiple popular scripting languages including Python.
>>
>
> Until you have actually produced a (mostly) compatible Python
> implementation, can you please stop making these repeated and baseless
> jabs at CPython's performance? You keep stating or hinting that
> CPython is somehow unnecessarily slow, but unless you have some code
> to back your claims, this is nothing but mudslinging.

This is a message to all commentators on this list: Mr Flibble is known
on comp.lang.c++ for making very confident claims and announcements of
the greatest software product since the invention of the wheel.

He is indeed a capable C++ programmer, but he frequently underestimates
the work needed for such big projects so that you can easily count them
as vaporware for now. For example, he created his own "cross-platform,
modern" GUI toolkit neoGFX[*] just because he thinks that QT is bad (it
uses non-standard C++). Of course, cross-platform for now means it runs
on Windows and anything else is far into the future, also the optical
design looks modern / OK right now, but will look outdated soon. There
is no evidence that any other designer will join the project to keep the
look up to date.

He wants that neoGFX is scriptable in Python, but instead of linking
with CPython, he will write his own Python implementation instead,
because CPython is slow/not clean/ whatever. He doesn't seem to
understand that this is an enormous task on its own, because the
interesting part of a scripting language is the standard library with
many decade-years of work.

So my advice is to waste your time in this discussion if you find it
entertaining, but don't expect to have a usable product soon.

Best regards,

Christian

[*] https://github.com/i42output/neoGFX
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
ikorot01 at gmail
Feb 14, 2021, 7:33 AM
Post #47 of 93 (371 views)
Permalink
Of course not.
Its like saying "JAVA sucks" without any citation or proof.

And I'm just curious - why not use C directly, since he is so great
developer for whatever task he needs to do?

Fun time reading... Hope it will continue.

Thank you.


On Sun, Feb 14, 2021, 1:22 AM Christian Gollwitzer <auriocus@gmx.de> wrote:

> Am 14.02.21 um 01:19 schrieb Chris Angelico:
> > On Sun, Feb 14, 2021 at 11:14 AM Mr Flibble
> > <flibble@i42.removethisbit.co.uk> wrote:
> >>
> >> On 13/02/2021 23:30, Igor Korot wrote:
> >>> Hi,
> >>> But most importantly - what is the reason for this ?
> >>> I mean - what problems the actual python compiler produce?
> >>>
> >>> Thank you.
> >>
> >> I am creating neos as I need a performant scripting engine for my other
> major project "neoGFX" and I want to be able to support multiple popular
> scripting languages including Python.
> >>
> >
> > Until you have actually produced a (mostly) compatible Python
> > implementation, can you please stop making these repeated and baseless
> > jabs at CPython's performance? You keep stating or hinting that
> > CPython is somehow unnecessarily slow, but unless you have some code
> > to back your claims, this is nothing but mudslinging.
>
> This is a message to all commentators on this list: Mr Flibble is known
> on comp.lang.c++ for making very confident claims and announcements of
> the greatest software product since the invention of the wheel.
>
> He is indeed a capable C++ programmer, but he frequently underestimates
> the work needed for such big projects so that you can easily count them
> as vaporware for now. For example, he created his own "cross-platform,
> modern" GUI toolkit neoGFX[*] just because he thinks that QT is bad (it
> uses non-standard C++). Of course, cross-platform for now means it runs
> on Windows and anything else is far into the future, also the optical
> design looks modern / OK right now, but will look outdated soon. There
> is no evidence that any other designer will join the project to keep the
> look up to date.
>
> He wants that neoGFX is scriptable in Python, but instead of linking
> with CPython, he will write his own Python implementation instead,
> because CPython is slow/not clean/ whatever. He doesn't seem to
> understand that this is an enormous task on its own, because the
> interesting part of a scripting language is the standard library with
> many decade-years of work.
>
> So my advice is to waste your time in this discussion if you find it
> entertaining, but don't expect to have a usable product soon.
>
> Best regards,
>
> Christian
>
> [*] https://github.com/i42output/neoGFX
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
auriocus at gmx
Feb 14, 2021, 3:00 PM
Post #48 of 93 (371 views)
Permalink
Am 14.02.21 um 11:12 schrieb Paul Rubin:
> Christian Gollwitzer <auriocus@gmx.de> writes:
>> He wants that neoGFX is scriptable in Python, but instead of linking
>> with CPython, he will write his own Python implementation instead,
>> because CPython is slow/not clean/ whatever. He doesn't seem to
>> understand that this is an enormous task on its own, because the
>> interesting part of a scripting language is the standard library with
>> many decade-years of work.
>
> I wonder how big an issue the stdlib really is. Lots of it is written
> in Python and can port to another interpreter. Lots more is CPython C
> API bindings to external C libraries (e.g. OpenSSL) so porting those
> would be a matter of rebinding those libraries to libffi in the cases
> where that hasn't been done already.

I'm not saying that it is unfeasible or very difficult. I'm saying that
it is a lot of work, and for a single developer who has this as a side
project / support for his graphics engine and who wants to beat existing
implementations wrt. speed, I'm saying it is going to take a lot of
time. It'definitely impossible by "defining a few JSON schema files", as
Leigh claims with his "universal compiler". There definitely IS a lot of
stuff in a baseline CPython interpreter - a (seemingly) simple thing
like "print" will have an implementation of 1000 lines in C with all the
formatting library, file I/O etc. Arbitrary precision integers - another
library, networking - yet another and so on.

> CPython really is pretty slow, maybe because it uses so much boxed data,
> derps around with refcounts all the time, suffers memory fragmentation
> from not having a relocating GC, etc. And that is before we even
> mention the GIL.

I don't argue with that. CPython is slow. But I'm arguing that you can't
make it faster by multiple orders of magnitude unless you change the
language. For numerical code, straight-forward C is usually 100x to
1000x faster than Python, and you can reach the same performance by
giving up dynamic typing - Cython demonstrates this quite convincingly.
If you don't want static typing (with types close to the machine like
fixed-width integers) than you'll have to resort to a LOT of black magic
to even come close (PyPy, modern JS engines, ....)

Christian

--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
flibble at i42
Feb 14, 2021, 3:32 PM
Post #49 of 93 (371 views)
Permalink
On 14/02/2021 23:00, Christian Gollwitzer wrote:
> Am 14.02.21 um 11:12 schrieb Paul Rubin:
>> Christian Gollwitzer <auriocus@gmx.de> writes:
>>> He wants that neoGFX is scriptable in Python, but instead of linking
>>> with CPython, he will write his own Python implementation instead,
>>> because CPython is slow/not clean/ whatever. He doesn't seem to
>>> understand that this is an enormous task on its own, because the
>>> interesting part of a scripting language is the standard library with
>>> many decade-years of work.
>>
>> I wonder how big an issue the stdlib really is.  Lots of it is written
>> in Python and can port to another interpreter.  Lots more is CPython C
>> API bindings to external C libraries (e.g. OpenSSL) so porting those
>> would be a matter of rebinding those libraries to libffi in the cases
>> where that hasn't been done already.
>
> I'm not saying that it is unfeasible or very difficult. I'm saying that it is a lot of work, and for a single developer who has this as a side project / support for his graphics engine and who wants to beat existing implementations wrt. speed, I'm saying it is going to take a lot of time. It'definitely impossible by "defining a few JSON schema files", as Leigh claims with his "universal compiler". There definitely IS a lot of stuff in a baseline CPython interpreter - a (seemingly) simple thing like "print" will have an implementation of 1000 lines in C with all the formatting library, file I/O etc. Arbitrary precision integers - another library, networking - yet another and so on.

There will only be one schema file and it is will be a relatively small task which certainly isn't "impossible": I should have a working implementation by the summer. As far as arbitrary precision integers are concerned I am well on the way to completing the "neonumeral" library (which also has arbitrary precision floats).

As far as the standard library is concerned: that is already in Python so I should be able to support it with little effort; the only thing requiring more work would be the built-ins.

>
>> CPython really is pretty slow, maybe because it uses so much boxed data,
>> derps around with refcounts all the time, suffers memory fragmentation
>> from not having a relocating GC, etc.  And that is before we even
>> mention the GIL.
>
> I don't argue with that. CPython is slow. But I'm arguing that you can't make it faster by multiple orders of magnitude unless you change the language. For numerical code, straight-forward C is usually 100x to 1000x faster than Python, and you can reach the same performance by giving up dynamic typing - Cython demonstrates this quite convincingly. If you don't want static typing (with types close to the machine like fixed-width integers) than you'll have to resort to a LOT of black magic to even come close (PyPy, modern JS engines, ....)

I believe PyPy is only 4x faster than CPython on average and comes nowhere near close to JS JIT engines performance-wise.

/Flibble

--
????
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
drsalists at gmail
Feb 14, 2021, 4:30 PM
Post #50 of 93 (369 views)
Permalink
On Sun, Feb 14, 2021 at 3:05 PM Christian Gollwitzer <auriocus@gmx.de>
wrote:

> Am 14.02.21 um 11:12 schrieb Paul Rubin:
> > Christian Gollwitzer <auriocus@gmx.de> writes:
> >> He wants that neoGFX is scriptable in Python, but instead of linking
> >> with CPython, he will write his own Python implementation instead,
> >> because CPython is slow/not clean/ whatever. He doesn't seem to
> >> understand that this is an enormous task on its own, because the
> >> interesting part of a scripting language is the standard library with
> >> many decade-years of work.
> >
> > I wonder how big an issue the stdlib really is. Lots of it is written
> > in Python and can port to another interpreter. Lots more is CPython C
> > API bindings to external C libraries (e.g. OpenSSL) so porting those
> > would be a matter of rebinding those libraries to libffi in the cases
> > where that hasn't been done already.
>
Hopefully CFFI, not libffi: https://cffi.readthedocs.io/en/latest/

I'm not saying that it is unfeasible or very difficult. I'm saying that
> it is a lot of work


It is.

However, IronPython and Shedskin do not have a full Python standard
library. I'd still call them "Python".
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
roel at roelschroeven
Feb 15, 2021, 12:37 PM
Post #51 of 93 (440 views)
Permalink
Mr Flibble schreef op 15/02/2021 om 0:32:
> On 14/02/2021 23:00, Christian Gollwitzer wrote:
> I'm not saying that it is unfeasible or very difficult. I'm saying that it is a lot of work, and for a single developer who has this as a side project / support for his graphics engine and who wants to beat existing implementations wrt. speed, I'm saying it is going to take a lot of time. It'definitely impossible by "defining a few JSON schema files", as Leigh claims with his "universal compiler". There definitely IS a lot of stuff in a baseline CPython interpreter - a (seemingly) simple thing like "print" will have an implementation of 1000 lines in C with all the formatting library, file I/O etc. Arbitrary precision integers - another library, networking - yet another and so on.
>
> There will only be one schema file and it is will be a relatively small task which certainly isn't "impossible": I should have a working implementation by the summer.

So your claim is that your compiler is able to, or will be able to,
compile any language just by specifying a small schema file. Great!

Do you maybe have a proof-of-concept? A simple language with a simple
schema file to test the basic workings of your compiler, like your
neoscript or perhaps something like a minimal variant of Python? I'm
curious what such a schema file would like look, and especially how you
use it to not only specify the syntax but also the semantics of the
various languages.

Is it your intention to not only compile procedural and object-oriented
languages, or also functional languages such as Haskell, Ocaml, Scheme?

--
"Honest criticism is hard to take, particularly from a relative, a
friend, an acquaintance, or a stranger."
-- Franklin P. Jones

Roel Schroeven

--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
grant.b.edwards at gmail
Feb 15, 2021, 12:59 PM
Post #52 of 93 (440 views)
Permalink
On 2021-02-15, Roel Schroeven <roel@roelschroeven.net> wrote:

> Is it your intention to not only compile procedural and object-oriented
> languages, or also functional languages such as Haskell, Ocaml, Scheme?

And Prolog!

--
Grant



--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
roel at roelschroeven
Feb 15, 2021, 2:24 PM
Post #53 of 93 (440 views)
Permalink
Grant Edwards schreef op 15/02/2021 om 21:59:
> On 2021-02-15, Roel Schroeven <roel@roelschroeven.net> wrote:
>
>> Is it your intention to not only compile procedural and object-oriented
>> languages, or also functional languages such as Haskell, Ocaml, Scheme?
>
> And Prolog!

Ha, yes, that one was the next one I thought about, but in the I decided
to leave it out.

--
"Honest criticism is hard to take, particularly from a relative, a
friend, an acquaintance, or a stranger."
-- Franklin P. Jones

Roel Schroeven

--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
ikorot01 at gmail
Feb 15, 2021, 2:25 PM
Post #54 of 93 (440 views)
Permalink
And C.

Thank you.


On Mon, Feb 15, 2021, 3:56 PM Grant Edwards <grant.b.edwards@gmail.com>
wrote:

> On 2021-02-15, Roel Schroeven <roel@roelschroeven.net> wrote:
>
> > Is it your intention to not only compile procedural and object-oriented
> > languages, or also functional languages such as Haskell, Ocaml, Scheme?
>
> And Prolog!
>
> --
> Grant
>
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
RE: New Python implementation [ In reply to ]
python-list at python
Feb 15, 2021, 2:43 PM
Post #55 of 93 (440 views)
Permalink
Grant,

Haven't thought about Prolog in a LOOONG time but it had some wild twists on
how to specify a problem that might not be trivial to integrate with other
languages as our now seemingly censored person with much delusion of
grandeur suggests. It is a language that does not specify what to do but
more what rules an answer must abide by.

Perhaps he should go to work for the Star Trek Federation and improving
their Universal Translator that can learn any alien language in about two
sentences. I am sure he will tell us it would be trivial for him or her
along with other Fibbles he/she tells.

Am I the only one who found it amusing, back to Python, that a recent attack
on Python was about a fairly trivial problem to solve in most languages, let
alone Python. Toy language does not normally apply to a fairly mature
language, regularly extended to do many things in many ways, unless anything
not fully standardized is a toy. I consider many such to become toys as they
end up near the end of their lives and hard to extend further.

I think the question was as simple as how to find the first period in a
string (assuming it exists?) and replace it with an @ and not subsequent
ones. Not very challenging even using very basic commands in a computer
language. Computing 101?

Can you name any language where that is hard to do from scratch? Sure, many
will provide a ready-made function that does it in one line of code (or a
partial line) but most languages let you use something like a loop that lets
you look at one letter of a "string" variable at a time and perhaps copy it
to a new one. A logical variable can be set so you conditionally replace
just the first instance. Whether changed in place or in a copy, it seems
trivial.

So why snide comments that you need more than a toy language when this is
precisely what is doable even in a toy language, but so commonly done that
many better languages (and Python definitely is included) give you an
assortment of built-in functionality to make it easy, and then dozens of
other ways in modules you can load ...

Now there are fairly complex things that a user cannot easily build from
scratch or find a ready-made solution. There may well be say a PROLOG
program that is simple and elegant and very hard to solve using Python, let
alone a toy language.

To me, all languages are toys, albeit for different age/experience groups.

-----Original Message-----
From: Python-list <python-list-bounces+avigross=verizon.net@python.org> On
Behalf Of Grant Edwards
Sent: Monday, February 15, 2021 4:00 PM
To: python-list@python.org
Subject: Re: New Python implementation

On 2021-02-15, Roel Schroeven <roel@roelschroeven.net> wrote:

> Is it your intention to not only compile procedural and
> object-oriented languages, or also functional languages such as Haskell,
Ocaml, Scheme?

And Prolog!

--
Grant



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

--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
buck.2019 at gmail
Feb 15, 2021, 2:46 PM
Post #56 of 93 (440 views)
Permalink
On Thu, Feb 11, 2021 at 1:49 PM dn via Python-list <python-list@python.org>
wrote:

> When I first met it, one of the concepts I found difficult to 'wrap my
> head around' was the idea that "open software" allowed folk to fork the
> original work and 'do their own thing'. My thinking was (probably)
> "surely, the original is the authoritative version". Having other
> versions seemed an invitation to confusion and dilution.
>
> However, as soon as (open) software is made available, other people
> start making it 'better' - whatever their own definition of "better".
>
> Yes, it is both a joy and a complication.
>
> ...
>
> Wishing you well. It seems (to (neos-ignorant) me at least) an ambitious
> project. There are certainly times when 'execution speed' becomes a
> major criteria. Many of us will look forward to (your development of) a
> solution. Please let us know when it's ready for use/trials...
>

Well put! Thank you for this thoughtful and informative message. You
obviously put substantial work into it.
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
grant.b.edwards at gmail
Feb 15, 2021, 3:12 PM
Post #57 of 93 (440 views)
Permalink
On 2021-02-15, Avi Gross via Python-list <python-list@python.org> wrote:

> Haven't thought about Prolog in a LOOONG time but it had some wild
> twists on how to specify a problem that might not be trivial to
> integrate with other languages as our now seemingly censored person
> with much delusion of grandeur suggests. It is a language that does
> not specify what to do but more what rules an answer must abide by.

Of all the languages I've used, Prolog was by far the hardest to get
my head around. The dialect I used the most (which still wasn't much)
was part of Digitalk's Smalltalk system. I don't recall if Digitalk
Prolog was written entirely in Smalltalk, or if it was just integrated
into the Smalltalk system as an opaque object.

--
Grant

--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
python-list at python
Feb 15, 2021, 4:29 PM
Post #58 of 93 (440 views)
Permalink
On 15/02/2021 22:24, Roel Schroeven wrote:
> Grant Edwards schreef op 15/02/2021 om 21:59:
>> On 2021-02-15, Roel Schroeven <roel@roelschroeven.net> wrote:
>>
>>> Is it your intention to not only compile procedural and object-oriented
>>> languages, or also functional languages such as Haskell, Ocaml, Scheme?
>>
>> And Prolog!
>
> Ha, yes, that one was the next one I thought about, but in the I decided
> to leave it out.

Yes, Prolog is definitely different. When I was at Uni' in the mid 80s
we all got taught Prolog because the Japanese had promised to produce
a 5th generation computer by 1990 and it would be based on Prolog.
We're still waiting, but in the meantime we got the internet and GUIs.

Looks like Sun got it right - "the network is the computer"...

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
drsalists at gmail
Feb 15, 2021, 5:09 PM
Post #59 of 93 (440 views)
Permalink
On Mon, Feb 15, 2021 at 3:25 PM Grant Edwards <grant.b.edwards@gmail.com>
wrote:

> On 2021-02-15, Avi Gross via Python-list <python-list@python.org> wrote:
> Of all the languages I've used, Prolog was by far the hardest to get
> my head around. The dialect I used the most (which still wasn't much)
> was part of Digitalk's Smalltalk system. I don't recall if Digitalk
> Prolog was written entirely in Smalltalk, or if it was just integrated
> into the Smalltalk system as an opaque object.
>
I actually found Prolog to be a lot like /usr/bin/make.

It's an OK language if everything you need to do can be solved well using a
depth first search. Otherwise, it kind of gets in the way.
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
ikorot01 at gmail
Feb 15, 2021, 8:51 PM
Post #60 of 93 (439 views)
Permalink
Hi, guys,
Let me try to throw in another one - PL/1.
This guys used to be very popular with the accounting community...

Thank you.

On Mon, Feb 15, 2021 at 9:51 PM Alan Gauld via Python-list
<python-list@python.org> wrote:
>
> On 15/02/2021 22:24, Roel Schroeven wrote:
> > Grant Edwards schreef op 15/02/2021 om 21:59:
> >> On 2021-02-15, Roel Schroeven <roel@roelschroeven.net> wrote:
> >>
> >>> Is it your intention to not only compile procedural and object-oriented
> >>> languages, or also functional languages such as Haskell, Ocaml, Scheme?
> >>
> >> And Prolog!
> >
> > Ha, yes, that one was the next one I thought about, but in the I decided
> > to leave it out.
>
> Yes, Prolog is definitely different. When I was at Uni' in the mid 80s
> we all got taught Prolog because the Japanese had promised to produce
> a 5th generation computer by 1990 and it would be based on Prolog.
> We're still waiting, but in the meantime we got the internet and GUIs.
>
> Looks like Sun got it right - "the network is the computer"...
>
> --
> Alan G
> Author of the Learn to Program web site
> http://www.alan-g.me.uk/
> http://www.amazon.com/author/alan_gauld
> Follow my photo-blog on Flickr at:
> http://www.flickr.com/photos/alangauldphotos
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
drsalists at gmail
Feb 15, 2021, 8:57 PM
Post #61 of 93 (439 views)
Permalink
On Mon, Feb 15, 2021 at 8:52 PM Igor Korot <ikorot01@gmail.com> wrote:

> Hi, guys,
> Let me try to throw in another one - PL/1.
> This guys used to be very popular with the accounting community...
>

Actually PL/I is basically proprietary Pascal - from IBM. My Intro Comp
Sci classes at the University of Cincinnati were in PL/I, because IBM had
an office not far from the University, and they liked to hire interns from
UCinci. I was told that otherwise the classes would've been in Pascal.
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
python-list at python
Feb 15, 2021, 9:36 PM
Post #62 of 93 (439 views)
Permalink
On 16/02/2021 17.57, Dan Stromberg wrote:
> On Mon, Feb 15, 2021 at 8:52 PM Igor Korot <ikorot01@gmail.com> wrote:
>
>> Hi, guys,
>> Let me try to throw in another one - PL/1.
>> This guys used to be very popular with the accounting community...
>>
>
> Actually PL/I is basically proprietary Pascal - from IBM. My Intro Comp
> Sci classes at the University of Cincinnati were in PL/I, because IBM had
> an office not far from the University, and they liked to hire interns from
> UCinci. I was told that otherwise the classes would've been in Pascal.


Might a coincidence of location have been conflated with language
development?


PL/I (note the Roman "one") was developed out of the IBM System/360
effort, ie one computer architecture for all types of users (cf
different computers for 'commercial' and 'scientific' clients - which
you can see again today in AWS' range of compute options, for example).
It was to be 'one language to rule them all'.

Initially, it was based on FORTRAN. We joked that it took all of the bad
parts of FORTRAN and COBOL and mashed them into a single ... language.
However, like many such efforts, it attempted to take 'the best' from
many sources (including ALGOL).

Sadly, (maybe) it, like Ada (another attempt to be 'all things to all
men') only ever really existed in a niche market.


Pascal, named after the mathematician and philosopher the French credit
with 'inventing the computer', was developed in the European world -
which even back-then had marked differences in thinking to the American
approach/domination of computing.

Prof Niklaus Wirth published a seminal book "Algorithms + Data
Structures = Programs" (which I seem to have lost, somewhere in the
mists of time). I don't think it gave examples in Pascal, but it did use
a pseudo-code/-language which illuminated various ideas and ways of
developing programmatic solutions. As I recall, it (and Pascal) was very
ALGOL like, and thus heavily influenced by "stack architecture" (cf
IBM's collections of "registers" in an ALU). Certainly the language was
clearly based upon ALGOL-60. Clearly it led to the refinement and/or
development of Pascal.

Pascal's value as a teaching language was that it embodied many aspects
of structured programming, and like Python, consisted of a limited range
of items which could be learned very quickly (in contrast to PL/I's many
'bells and whistles'). Thus, once absorbed, learning attention could be
directed to ComSc/algorithms + data!

Pascal was also very efficient, to compile and to execute, which made it
a competent fore-runner of Micro-Python (etc) in the micro and
single-board computer arenae/arenas.

Without Python, I think I'd prefer to use (an updated) UCSD-Pascal or
Borland Turbo-Pascal to this very day! PL/I, not so much - even on a
mainframe project!
--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
drsalists at gmail
Feb 15, 2021, 10:05 PM
Post #63 of 93 (439 views)
Permalink
On Mon, Feb 15, 2021 at 9:37 PM dn via Python-list <python-list@python.org>
wrote:

> On 16/02/2021 17.57, Dan Stromberg wrote:
> > On Mon, Feb 15, 2021 at 8:52 PM Igor Korot <ikorot01@gmail.com> wrote:
> >
> >> Hi, guys,
> >> Let me try to throw in another one - PL/1.
> >> This guys used to be very popular with the accounting community...
> >>
> >
> > Actually PL/I is basically proprietary Pascal - from IBM. My Intro Comp
> > Sci classes at the University of Cincinnati were in PL/I, because IBM had
> > an office not far from the University, and they liked to hire interns
> from
> > UCinci. I was told that otherwise the classes would've been in Pascal.
>
>
> Might a coincidence of location have been conflated with language
> development?
>
Nah. All 3 are in the Algol family: Algol, Pascal, PL/I.

I'll grant you that PL/I is a "big language" though. It didn't rely on
external libraries as much as it should have.
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
auriocus at gmx
Feb 15, 2021, 11:25 PM
Post #64 of 93 (439 views)
Permalink
Am 15.02.21 um 21:37 schrieb Roel Schroeven:
>
> So your claim is that your compiler is able to, or will be able to,
> compile any language just by specifying a small schema file. Great!
>
> Do you maybe have a proof-of-concept? A simple language with a simple
> schema file to test the basic workings of your compiler,

Here is the git repo:

https://github.com/i42output/neos

under languages/ you'll find different schema files.

Christian
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
auriocus at gmx
Feb 15, 2021, 11:35 PM
Post #65 of 93 (439 views)
Permalink
Am 16.02.21 um 06:36 schrieb dn:
> Pascal's value as a teaching language was that it embodied many aspects
> of structured programming, and like Python, consisted of a limited range
> of items which could be learned very quickly (in contrast to PL/I's many
> 'bells and whistles').

ROFL. Maybe that was true for Python when it was first invented. Today
it is not "a few simple things". Even just the core language, anything
that's built into the interpreter if you leave out any standard
function, is enormous. To name a few: List comprehension, format
strings, iterator protocol, asynchronous programming, everything called
__dunderland. A minimal language with only very few basic rules, that
would be Scheme e.g. Of course, it doesn't mean that Scheme is easier to
program, but it is easier to write a compiler for it than for Python.

That is a misundestanding often presented - a language that is simple in
the sense of having a few simple rules, is usually hard to use. (e.g.
Brainfuck). A language which is easy to use, often comes with a large
variety of building blocks, to give you the right tool to choose for the
job at hands (e.g. Python), and therefore is "complex".

Christian

--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
python-list at python
Feb 16, 2021, 12:57 AM
Post #66 of 93 (439 views)
Permalink
Christian Gollwitzer writes:

> Am 16.02.21 um 06:36 schrieb dn:
>> Pascal's value as a teaching language was that it embodied many aspects
>> of structured programming, and like Python, consisted of a limited range
>> of items which could be learned very quickly (in contrast to PL/I's many
>> 'bells and whistles').
>
> ROFL. Maybe that was true for Python when it was first invented. Today
> it is not "a few simple things". Even just the core language, anything
> that's built into the interpreter if you leave out any standard
> function, is enormous. To name a few: List comprehension, format
> strings, iterator protocol, asynchronous programming, everything called
> __dunderland. A minimal language with only very few basic rules, that
> would be Scheme e.g. Of course, it doesn't mean that Scheme is easier to
> program, but it is easier to write a compiler for it than for Python.
>
> That is a misundestanding often presented - a language that is simple in
> the sense of having a few simple rules, is usually hard to use. (e.g.
> Brainfuck). A language which is easy to use, often comes with a large
> variety of building blocks, to give you the right tool to choose for the
> job at hands (e.g. Python), and therefore is "complex".
>
> Christian

In Norway, where I try to teach mathematics to highschoolers, programming has
recently entered the teaching of stem subjects.

Even if Python is my choice language for personal projects, I am not certain it
is the right language to use in a classroom context. My feeling is that Python
comes with way too much packed in, making it very hard for the students to get
to a level where they can sit down and be creative with their own
programming. You either guide them very, very deliberately, exposing piece by
piece of the language ... or you let them loose, having to explain the
difference in scoping between list comprehensions and for loops after three
weeks.

I am exaggerating ... a little.

I am not sure I agree that a language like Scheme or Logo or Brainfuck, with
their small number of building blocks, would be harder to learn.

To me, Python is the lego boxes from the early 2000s, where there were so many
specialized pieces that you felt that the original design might as well be the
only design.

Regards,
Tarjei
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
python-list at python
Feb 16, 2021, 3:03 AM
Post #67 of 93 (438 views)
Permalink
On 16/02/2021 07:35, Christian Gollwitzer wrote:
> Am 16.02.21 um 06:36 schrieb dn:
>> Pascal's value as a teaching language was that it embodied many aspects
>> of structured programming, and like Python, consisted of a limited range
>> of items which could be learned very quickly
>
> ROFL. Maybe that was true for Python when it was first invented. Today
> it is not "a few simple things". Even just the core language,

Python v1 was a good teaching language. v2 complicated it a bit
but it was still usable. v3 is no longer a good teaching language
(unless maybe you are teaching CompSci at university.)

In fact in v3 things are so complex that I seriously considered
dropping Python as the core language for my programming tutorial.
Until I started looking for an alternative, and there really isn't
anything much better. At least not that can also be used for real
projects once you've learned it.

But the sort of change that has made it complicated for beginners
is range(). range() used to be simple - it returned a list of numbers
in the range specified. The hardest thing to explain was why it
stopped one short of the upper limit. Now range returns a
"range object". Say what? How do explain a range object to a beginner?
And you can't avoid it because the name pops up in the interpreter.

And that's just one example, the language is now full of meta goodness
that makes it incomprehensible to beginners. In a teaching environment,
with a teacher present to answer questions, it's probably usable,
but for a self guided course it's increasingly inscrutable.

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
david at lowryduda
Feb 16, 2021, 7:12 AM
Post #68 of 93 (438 views)
Permalink
> In Norway, where I try to teach mathematics to highschoolers,
> programming has recently entered the teaching of stem subjects.
>
> Even if Python is my choice language for personal projects, I am not
> certain it is the right language to use in a classroom context.
> ...
> I am not sure I agree that a language like Scheme or Logo or
> Brainfuck, with their small number of building blocks, would be harder
> to learn.

Does this mean that you also try to teach programming to highschoolers,
or is there a different (maybe dedicated) teacher to that? What language
do they use? And does it influence math education at all? (Coming from
someone who sometimes tries to teach undergraduates about math).

- David Lowry-Duda
--
https://mail.python.org/mailman/listinfo/python-list
RE: New Python implementation [ In reply to ]
python-list at python
Feb 16, 2021, 8:51 AM
Post #69 of 93 (438 views)
Permalink
Christian,

Thanks for sharing. I took a look and he does have a few schemas for Ada and
C from TWO YEARS ago. Nothing about the infinite number of other languages
he plans on supporting, let alone Python. And what he has is likely not
enough to do what he claims he can do easily and rapidly.

What gets me is that many languages severely overload the use of some
characters and tokens so they can mean many things based on the context and
capturing that is much harder than declaring what is a keyword. Worse, some
languages like PERL make so many things optional, that you can write very
brief programs that keep implicitly assuming the previous part stored
results in $_ and seem at first to be magical as the actual code does not
seem connected to anything. I am not so sure there is a reasonable way to
program ALL existing language his way & to have one ring-like compiler to
rule them all, albeit you might be able to consolidate several somewhat
similar languages.

I also wonder how efficient such a universal compiler (maybe technically not
a compiler) would be but if it was only used once, maybe not. But didn't he
also say this thing would work in an interactive mode line by line?

It reminds me of when I was studying concepts about various takes on a
Turing Machine for my thesis. It has been proven that a Turing Machine can
theoretically solve any problem you can solve with a non-quantum computer. I
emphasize it is theoretical because we are talking about an infinite tape
with squares containing symbols that are read by a head that moves over it
either to the left or right based on the current state and so on. Fairly
simple programs like copying a million instances of "1" in a row can take
quite a while and really complex programs need near-infinite times or
infinitesimal time per step. What is POSSIBLE is far from useful.

I feel the same way about NEOS. Given a sufficiently advanced and convoluted
schema you can write a sufficiently convoluted computer program that might
halt with an answer -- meaning it will compile a valid program written in a
language that is completely defined by that schema and perhaps additional
info. We know it can be done because each language has existing compilers
and/or interpreters that do so, without an explicit schema.

But to have a program that can take any schema whatsoever and do what is
needed is a bit much. Existing languages were simply not designed with this
in mind and new/old languages might feel constrained about designing new
features that will not be able to fit within an existing schema.

In particular, how do you handle multiple versions of a language like Python
2.X and the incompatible Python 3.X and the eventual re-re-designed Python
4.Y? They all may be placed in files ending in .py!

There is nothing wrong with thinking out of the box or making grand plans.
But I have known people ranging from overly optimistic to manic who think
nothing of making extraordinary claims and may actually believe it. I would
not be shocked if a subset of what is being suggested for NEOS might be done
by a large team in a few decades but by then, we may all be using quantum
computers and a whole new set of languages to take advantage of new
paradigms like superposition ...

-----Original Message-----
From: Python-list <python-list-bounces+avigross=verizon.net@python.org> On
Behalf Of Christian Gollwitzer
Sent: Tuesday, February 16, 2021 2:25 AM
To: python-list@python.org
Subject: Re: New Python implementation

Am 15.02.21 um 21:37 schrieb Roel Schroeven:
>
> So your claim is that your compiler is able to, or will be able to,
> compile any language just by specifying a small schema file. Great!
>
> Do you maybe have a proof-of-concept? A simple language with a simple
> schema file to test the basic workings of your compiler,

Here is the git repo:

https://github.com/i42output/neos

under languages/ you'll find different schema files.

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

--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
ben.usenet at bsb
Feb 16, 2021, 9:58 AM
Post #70 of 93 (438 views)
Permalink
"Avi Gross" <avigross@verizon.net> writes:

> Thanks for sharing. I took a look and he does have a few schemas for Ada and
> C from TWO YEARS ago. Nothing about the infinite number of other languages
> he plans on supporting, let alone Python. And what he has is likely not
> enough to do what he claims he can do easily and rapidly.

The C schema says almost nothing about C. It lists one kind of comment
and a few type names. Significantly, it says almost nothing about the
semantics of even the tiny fragment of C presented.

Attempts at a universal compiler stalled in the 1980s (though there may
have been some new developments since I stopped looking) because
expressing the semantics of different languages is so very hard. In
fact, much of the interest in pursuing the idea came from benefits that
would be derived simply from having a language's semantics formally
described.

I don't think there is anything to see here. If the author had come up
with some new ways to tackle any of the problems, he would be telling
people about these, not saying "be patient" (and bad-mouthing CPython).

--
Ben.
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
auriocus at gmx
Feb 16, 2021, 10:31 AM
Post #71 of 93 (424 views)
Permalink
I agree to all the rest of your post, but this:

Am 16.02.21 um 09:57 schrieb Tarjei Bærland:
> I am not sure I agree that a language like Scheme or Logo or Brainfuck, with
> their small number of building blocks, would be harder to learn.


is strange. I'm not sure, have you actually looked at Brainfuck? Maybe
there is also confusion what means "learning" a programming language.
For me, learning a language does not mean to remember the rules and
keywords, but to be able to write useful programs. Indeed, Brainfuck
with its 8 commands is easy to remember, but it comes at a very high
price: you can't do anything useful with it with reasonable effort. It
is unusable even for pure computer science stuff. It is easy to see that
BF is Turing complete, so please write a BF program to compute the
ackermann function. Should be easy, just three rules ;) I'd definitely
choose Python to do it here.

In that sense, Scheme also appears to be the Brainfuck of functional
programming to me. It is not much more than the pure untyped lambda
calculus, and by definition this allows you to compute anything, just
like Brainfuck is a Turing machine. Actually it is impressive that you
can write actual useful code with such a minimalist language (infix
math? Pure bloat!). OTOH it feels like "assembly" compared to more
evolved functional languages like, e.g. Haskell.

Christian
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
torriem at gmail
Feb 16, 2021, 11:51 AM
Post #72 of 93 (424 views)
Permalink
On 2/16/21 10:58 AM, Ben Bacarisse wrote:
> Attempts at a universal compiler stalled in the 1980s (though there may
> have been some new developments since I stopped looking) because
> expressing the semantics of different languages is so very hard. In
> fact, much of the interest in pursuing the idea came from benefits that
> would be derived simply from having a language's semantics formally
> described.
>
> I don't think there is anything to see here. If the author had come up
> with some new ways to tackle any of the problems, he would be telling> people about these, not saying "be patient" (and bad-mouthing CPython).

Indeed, in all seriousness if he is successful, I look forward to
reading his PhD dissertation, because it would be worthy of a PhD,
especially if he made some breakthroughs in metacompiler design. His
comments don't give me hope, though.

Seems a bit paradoxical to me to, on the one hand, express a desire to
build a Python implementation, but on the other hand, mock Python as a
toy language. Why bother with Python at all?

I wish him luck and maybe he'll eventually come back to the community
with something to show and impress with.

--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
python-list at python
Feb 16, 2021, 1:08 PM
Post #73 of 93 (424 views)
Permalink
David Lowry-Duda writes:

>> In Norway, where I try to teach mathematics to highschoolers,
>> programming has recently entered the teaching of stem subjects.
>>
>> Even if Python is my choice language for personal projects, I am not
>> certain it is the right language to use in a classroom context.
>> ...
>> I am not sure I agree that a language like Scheme or Logo or
>> Brainfuck, with their small number of building blocks, would be harder
>> to learn.
>
> Does this mean that you also try to teach programming to highschoolers,
> or is there a different (maybe dedicated) teacher to that? What language
> do they use? And does it influence math education at all? (Coming from
> someone who sometimes tries to teach undergraduates about math).
>
> - David Lowry-Duda

Yes, that also means that mathematics teachers are teaching programming
as well. For my part, it's a welcome change, and I've already been
teaching another programming course for a couple of years, but a lot of
teachers are having to start programming alongside their students.

I don't have any numbers for this, but I'd be surprised if less than 95%
of all teachers used Python for this. (I know of no exception.)

I think it's too soon to tell whether it affects the education. However,
I would have liked to better know the motivation for including
it. Python seems like one of several good choices if you want to
manipulate mathematical objects, perhaps mixing in som symbolic algebra
via Sympy, and other "high level concepts". However, if the aim is for
the students to quickly experience what it's like to design their own
simple algorithm without excessive guidance, Python might not then be the
optimal choice.

- Tarjei Bærland

PS: I can't remember in what context I visited it, but thanks for an
inspiring site.
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
python-list at python
Feb 16, 2021, 1:22 PM
Post #74 of 93 (424 views)
Permalink
Christian Gollwitzer writes:

> I agree to all the rest of your post, but this:
>
> Am 16.02.21 um 09:57 schrieb Tarjei Bærland:
>> I am not sure I agree that a language like Scheme or Logo or Brainfuck, with
>> their small number of building blocks, would be harder to learn.
>
>
> is strange. I'm not sure, have you actually looked at Brainfuck? Maybe
> there is also confusion what means "learning" a programming language.
> For me, learning a language does not mean to remember the rules and
> keywords, but to be able to write useful programs. Indeed, Brainfuck
> with its 8 commands is easy to remember, but it comes at a very high
> price: you can't do anything useful with it with reasonable effort. It
> is unusable even for pure computer science stuff. It is easy to see that
> BF is Turing complete, so please write a BF program to compute the
> ackermann function. Should be easy, just three rules ;) I'd definitely
> choose Python to do it here.
>
> In that sense, Scheme also appears to be the Brainfuck of functional
> programming to me. It is not much more than the pure untyped lambda
> calculus, and by definition this allows you to compute anything, just
> like Brainfuck is a Turing machine. Actually it is impressive that you
> can write actual useful code with such a minimalist language (infix
> math? Pure bloat!). OTOH it feels like "assembly" compared to more
> evolved functional languages like, e.g. Haskell.
>
> Christian

To me, it depends on what you want out of including programming in
mathematics education.

Sure, Brainfuck is two steps too far, but Scheme or Logo I'd wager be
excellent languages to get the students into computational
thinking. Haskell might be a good choice as well, I do not have enough
experience with it to say.

If the aim is to quickly get the students to "be creative" with
programming by themselves, my feeling is that Python is too unwieldy for
a beginner.

In a programming course I am teaching, one of the goals is for the
students to distinguish "high level" and "low level" languages. I've
used Brainfuck as an example of a programming language at a low level of
abstraction. That session is often the most engaging throughout the
year. The students are sitting writing their own code after a few
minutes. They get the feeling of designing their own computational
procedure much quicker than in Python. (Yes, of course, the introductory
excercises in Python are a bit more advanced than "add two numbers".)

I am honestly not sure what quite what my feelings are regarding this,
perhaps Python is the best of all possible options.

- Tarjei

Note, I am emphatically saying this in the context of a maths class.
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
drsalists at gmail
Feb 16, 2021, 1:42 PM
Post #75 of 93 (424 views)
Permalink
On Tue, Feb 16, 2021 at 1:23 PM Tarjei Bærland via Python-list <
python-list@python.org> wrote:

> Sure, Brainfuck is two steps too far, but Scheme or Logo I'd wager be
> excellent languages to get the students into computational
> thinking. Haskell might be a good choice as well, I do not have enough
> experience with it to say.
>
I am not a Haskell expert by any stretch. But I did play with it a bit.

It's a fascinating language. But I think the language is hobbled by poor
error messages from the main compiler, GHC. I've been told GHC has a
rather elegant implementation, but that came at the cost of the quality of
error messages.
https://www.reddit.com/r/haskell/comments/54l3ug/readable_error_messages_like_in_elm/

There was a project to produce a somewhat restricted Haskell implementation
with better error messages, but sadly that project is no longer maintained.
https://wiki.haskell.org/Hugs
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
roel at roelschroeven
Feb 16, 2021, 1:42 PM
Post #76 of 93 (358 views)
Permalink
Christian Gollwitzer schreef op 16/02/2021 om 8:25:
> Am 15.02.21 um 21:37 schrieb Roel Schroeven:
>>
>> So your claim is that your compiler is able to, or will be able to,
>> compile any language just by specifying a small schema file. Great!
>>
>> Do you maybe have a proof-of-concept? A simple language with a simple
>> schema file to test the basic workings of your compiler,
>
> Here is the git repo:
>
> https://github.com/i42output/neos
>
> under languages/ you'll find different schema files.

I saw that, and I saw the schema files. I had a look at the one for C,
because I don't know the first thing about Ada, and it's not nearly
enough to describe even the tiniest subset of C. And I saw the example
session he posted here, where he supposedly compiles something, but
doesn't even run it. It looked like that compilation did nothing but
folding and folding and folding. And he didn't run it!

So it looks like that's the status of the project now: a compilation
step that does /something/, but apparently doesn't result in anything
runnable. And some work-in-progress (seemingly) schema files, but
nothing concrete yet.

But I wanted to give Mr Flibble to benefit of the doubt, and asked more
explicitly about the status of the project. Apparently I was too late,
Mr Flibble was already banned, but I didn't know that yet.

I've thougt about downloading the whole thing and trying to build it.
But I'd have to install Visual Studio 2019 first and probably some
dependencies. It didn't seem worth the effort.


Regards,
Roel

--
"Honest criticism is hard to take, particularly from a relative, a
friend, an acquaintance, or a stranger."
-- Franklin P. Jones

Roel Schroeven

--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
robertvstepp at gmail
Feb 16, 2021, 2:23 PM
Post #77 of 93 (358 views)
Permalink
On 21/02/16 11:03AM, Alan Gauld wrote:

>Python v1 was a good teaching language. v2 complicated it a bit
>but it was still usable. v3 is no longer a good teaching language
>(unless maybe you are teaching CompSci at university.)

[...]

>And that's just one example, the language is now full of meta goodness
>that makes it incomprehensible to beginners. In a teaching environment,
>with a teacher present to answer questions, it's probably usable,
>but for a self guided course it's increasingly inscrutable.

Hmm. I'm not sure I can agree, Alan. My son took to Python 3 like a duck to
water. Occasionally he has had questions for me, but, for the most part, he
has been entirely on his own with no issues. He now has several projects that
others are using, including a significant update to someone else's project he
was interested online to both update the Python and Qt.

Yes, there is a ton of meta-goodness in Python, but most of it can be ignored
to be able to *just use it*. My wife is using Python 3 in a robotics class
she teaches and her high school students find it accessible. AP computer
science second semester uses Python. I really don't think it is much of a
problem for most people. Of course on the Tutor list there often seems to be
some greatly puzzled people, but I think their issues stem from *never* having
tried to do anything even remotely technical other than clicking around in
the GUI programs they have become comfortable with.

--
Wishing you only the best,

boB Stepp
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
hjp-python at hjp
Feb 16, 2021, 3:19 PM
Post #78 of 93 (358 views)
Permalink
On 2021-02-14 00:52:43 +0000, Alan Gauld via Python-list wrote:
> On 14/02/2021 00:07, Mr Flibble wrote:
> > The neos Python implementation will not be dealing
> > with Python byte code in any form whatsoever.
>
> Ok but what do you do with the disassembler module?

What do PyPy, Jython, IronPython etc. do with the disassembler module?
My guess is that they simply don't implement it. It's tightly coupled to
the CPython implementation and useless on any other implementation. A
disassembler module for their respective bytecode or machine language
might be useful, but that wouldn't be compatible with CPython's
disassembler in input nor output.

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

Attached Files:

Re: New Python implementation [ In reply to ]
python-list at python
Feb 16, 2021, 6:00 PM
Post #79 of 93 (357 views)
Permalink
On 16/02/2021 22:23, boB Stepp wrote:

>> And that's just one example, the language is now full of meta goodness
>> that makes it incomprehensible to beginners.
>
> Hmm. I'm not sure I can agree, Alan. My son took to Python 3 like a duck to
> water.

That's interesting. I knew you were teaching him but not
how he got on. Good for him.

My comments stem from the feedback emails I get from my tutorial.
People get messages like "foo is not an iterable" or references
to range objects and such and it confuses them.

I never got those kinds of messages for the v.1 tutorial...

> Yes, there is a ton of meta-goodness in Python, but most of it can be ignored
> to be able to *just use it*.

But the problem I see is that you can't ignore it because
it bubbles to the surface in error messages. And if you
don't know what it means you don't know that you can ignore it!
That's where a teacher/mentor comes in, they can say "Oh that's OK
just ignore it!" but if you are on your own you think
"Oh no! What do I do now?"

But as I say, I can't find anything better so I'll stick
with it for now.

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
arj.python at gmail
Feb 16, 2021, 6:12 PM
Post #80 of 93 (358 views)
Permalink
Greetings list,

> Even if Python is my choice language for personal projects, I am not
certain it
is the right language to use in a classroom context.

This sums the view of most teachers in my country. In here for A level
at Cambridge for Computer Studies you can choose either Java, or VB or
Python

The teachers' logic seems to tell them that VB is the simplest of all and
more fitted for students. Since we organise the local Python usergroup
<https://www.pymug.com>,
we have been encouraging the adoption of Python. This happens from
experience when teachers think for students, they think student will think
like that etc

The way schools examinations are set up, learning programming is a bore.
Programming requires experimentation and projects. The students must be
permitted to explore the wide deep sea that is Python. On one of my projects
on Github, i have a toy language, someone from Slovakia (14 years old)
built
an IDE for it, what was needed was only guidance where he was stuck.

The hurdle with Python if any is the setting up and getting the command
'python'
to appear in the terminal, which is very easy to get up and running
nowadays.

When i was in high school, i did not take Computer Studies, but was
learning programming
on my own, including Python. The irony is that my friends who were learning
Python
got disgusted with it. Loops and functions turned out to be hard for them.
That's because
learning for the exam makes you learn the language close to theory. Some
commandline
stuffs and some numbers stuffs surely is not exiting. Mastery comes with
projects, exciting ones.
Then whatever the syllabus requires becomes easy. It's a means to an end
rather than the end
in itself.

The teachers' reaction is a reaction to the design of the syllabus. The
folks seem to think that let's
water it down to a very theoretical approach, strike out practise, strike
out the fun out of it and
sure the students will find it easier. Since effort is disliked by humans,
less effort in learning programming
will make students happy.

Then, if it was no Python at that time, it might be no Python for life.
With that mindset ongoing,
those students think they know Python, they studied it, but they missed the
whole thing. Forest,
trees and leaves. They know only the color of the sign board leading to the
place.

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://www.pythonkitchen.com>
github <https://github.com/Abdur-RahmaanJ>
Mauritius
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
python-list at python
Feb 16, 2021, 6:18 PM
Post #81 of 93 (357 views)
Permalink
On 16/02/2021 21:22, Tarjei Bærland via Python-list wrote:

> To me, it depends on what you want out of including programming in
> mathematics education.

That's a really important subclass distinction.
If programming is seen as an adjunct to math then the aims
can be simplified considerably since you are only interested
in pure computation. Things like networking, interfacing
to peripherals and the like can be ignored.
Likewise you probably don't care about creating large projects wit
multiple files etc.

With those constraints there are probably better languages
than python. You mention Logo and I had fun with that back
in the 80s and early 90s. But ultimately it wasn't suitable
for the kind of real-world programming I needed.

That's why I chose python for my tutorial. Its not only
teachable at a basic level but it is actually usable on
larger, real-world type projects once you've learned it.
You never need to throw away your skills.

> If the aim is to quickly get the students to "be creative" with
> programming by themselves, my feeling is that Python is too unwieldy for
> a beginner.

Don't underestimate the interactive prompt. It gives instant
feedback and is moire usable for beginners than most Lisp-style
REPLs.

Logo works too of course. But almost anything you can do in
Logo you can do almost as easily in Python. Be it list
handling or turtle graphics.

> minutes. They get the feeling of designing their own computational
> procedure much quicker than in Python. (Yes, of course, the introductory
> excercises in Python are a bit more advanced than "add two numbers".)

But they don't need to be. My tutor starts off with precisely that...

> I am honestly not sure what quite what my feelings are regarding this,
> perhaps Python is the best of all possible options.

Its a good compromise. Its got faults (see my other post!) but
I haven't found anything clearly better.

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
ikorot01 at gmail
Feb 16, 2021, 7:02 PM
Post #82 of 93 (358 views)
Permalink
Hi,



On Tue, Feb 16, 2021, 8:15 PM Abdur-Rahmaan Janhangeer <arj.python@gmail.com>
wrote:

> Greetings list,
>
> > Even if Python is my choice language for personal projects, I am not
> certain it
> is the right language to use in a classroom context.
>
> This sums the view of most teachers in my country. In here for A level
> at Cambridge for Computer Studies you can choose either Java, or VB or
> Python
>
> The teachers' logic seems to tell them that VB is the simplest of all and
> more fitted for students. Since we organise the local Python usergroup
> <https://www.pymug.com>,
> we have been encouraging the adoption of Python. This happens from
> experience when teachers think for students, they think student will think
> like that etc
>

How old are the teachers?
And is it for school or university?


Thank you.


> The way schools examinations are set up, learning programming is a bore.
> Programming requires experimentation and projects. The students must be
> permitted to explore the wide deep sea that is Python. On one of my
> projects
> on Github, i have a toy language, someone from Slovakia (14 years old)
> built
> an IDE for it, what was needed was only guidance where he was stuck.
>
> The hurdle with Python if any is the setting up and getting the command
> 'python'
> to appear in the terminal, which is very easy to get up and running
> nowadays.
>
> When i was in high school, i did not take Computer Studies, but was
> learning programming
> on my own, including Python. The irony is that my friends who were learning
> Python
> got disgusted with it. Loops and functions turned out to be hard for them.
> That's because
> learning for the exam makes you learn the language close to theory. Some
> commandline
> stuffs and some numbers stuffs surely is not exiting. Mastery comes with
> projects, exciting ones.
> Then whatever the syllabus requires becomes easy. It's a means to an end
> rather than the end
> in itself.
>
> The teachers' reaction is a reaction to the design of the syllabus. The
> folks seem to think that let's
> water it down to a very theoretical approach, strike out practise, strike
> out the fun out of it and
> sure the students will find it easier. Since effort is disliked by humans,
> less effort in learning programming
> will make students happy.
>
> Then, if it was no Python at that time, it might be no Python for life.
> With that mindset ongoing,
> those students think they know Python, they studied it, but they missed the
> whole thing. Forest,
> trees and leaves. They know only the color of the sign board leading to the
> place.
>
> Kind Regards,
>
> Abdur-Rahmaan Janhangeer
> about <https://compileralchemy.github.io/> | blog
> <https://www.pythonkitchen.com>
> github <https://github.com/Abdur-RahmaanJ>
> Mauritius
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
arj.python at gmail
Feb 16, 2021, 7:15 PM
Post #83 of 93 (358 views)
Permalink
Greetings,

age: After university to retirement
level: school, A Level is high school, not university
--
https://mail.python.org/mailman/listinfo/python-list
RE: New Python implementation [ In reply to ]
python-list at python
Feb 18, 2021, 9:26 AM
Post #84 of 93 (357 views)
Permalink
Dennis made the interesting comment "... Python has too much built in ..."

I understand his point. At the same time, I wonder what most people using
computers today, or in the future, need. Given serious amounts of computer
power, what many people may want is higher-level ways to get things done
without worrying how they are done. Python, like many such languages, has a
very basic core that is augmented by what could be libraries, packages,
modules and so on but have been chosen to be built-in to one distribution or
another.

Some people and organizations use some things so commonly, they want python
to start up automatically loading say numpy and pandas and other such
things. They may not care if the programmer knows how to make a linked list
or binary tree data structure. Many such details are encapsulated within
objects built and tested already.

I have seen subjects taught at various levels and python might qualify too.
I took a Physics course that required Calculus and used it to derive
formulas and other things. Others took one that sort of threw equations at
you without much explanation. I have even seen a course called Physics for
Poets. But at least the poets taking it knew science existed and perhaps to
take it seriously when others who had studied it better shared their
results, even if they have no interest in the methods.

We routinely have people learn how to use Word Processors or Spreadsheets
with no clue on how to build such a thing or anything about the Object
models used within or even knowing there is such a thing. Do they need to
know how to use the embedded methods to extend things with Visual Basic or
Javascript? They like getting closer to a WYSIWYG interface that handles
most of their usual needs and perhaps farm out harder things to experts when
needed.

So what if you teach some aspects of python that are needed all over, like
how to make things conditional or in a loop, but not how to make every
possible data structure. What if you deliberately do not teach functional
aspects of the language at first or ever? For some people that is enough to
enable them to then use additional instructions on how to find prepared and
tested chunks to use, even if not always optimally or efficiently. For those
who really want to be programmers, that still may actually be enough if
their task is to work using the tools we have developed, not in making new
tools from scratch. Quite a bit of programming today consists of reading
manual pages and cobbling together chunks that together do the job.

But obviously I would choose the classes where I understood more. Many here
would. But where does it end? Do most of us know how compilers or
interpreters get built or do we just work on top of existing implementations
others make available? Can you build an operating system from Scratch or
make microchips to run them on?

If the goal is Computer USE literacy, I think python has more than enough if
you include the modules that make hard things easy.

Just a thought. Admittedly it is hard these days to give a homework
assignment when the student can find a trivial way to get the result and not
do the hard work.


-----Original Message-----
From: Python-list <python-list-bounces+avigross=verizon.net@python.org> On
Behalf Of Dennis Lee Bieber
Sent: Thursday, February 18, 2021 12:45 AM
To: python-list@python.org
Subject: Re: New Python implementation

On Tue, 16 Feb 2021 11:03:33 +0000, Alan Gauld via Python-list
<python-list@python.org> declaimed the following:

>On 16/02/2021 07:35, Christian Gollwitzer wrote:
>> Am 16.02.21 um 06:36 schrieb dn:
>>> Pascal's value as a teaching language was that it embodied many
>>> aspects of structured programming, and like Python, consisted of a
>>> limited range of items which could be learned very quickly
>>
>> ROFL. Maybe that was true for Python when it was first invented.
>> Today it is not "a few simple things". Even just the core language,
>
>Python v1 was a good teaching language. v2 complicated it a bit but it
>was still usable. v3 is no longer a good teaching language (unless
>maybe you are teaching CompSci at university.)
>
>In fact in v3 things are so complex that I seriously considered
>dropping Python as the core language for my programming tutorial.
>Until I started looking for an alternative, and there really isn't
>anything much better. At least not that can also be used for real
>projects once you've learned it.

Depending upon the course intentions, I'd say Python is useful for
teaching general programming and getting to usable real-world programs.

For CompSci /theory/, OTOH, Python has too much built in, and would
get in the way of having someone implement things like linked-lists, deques,
hashed structures -- ie; the stuff that lies behind all those Python
built-ins. Pascal, Modula-2 (or is it up to 3 now), or one of the other
system programming languages: Edison from
https://www.amazon.com/Programming-personal-computer-Brinch-Hansen/dp/013730
2673
Implement a hashed-head multiple-linked list using Kemeny&Kurtz
level BASIC! (My algorithms instructor allowed the class to use any language
on that he could read -- so FORTRAN, BASIC, Pascal, Sigma Meta-Symbol,
COBOL... No Snobol, LISP, or APL -- for that final project: a phone book
directory/look-up system). Interestingly, I've only seen a hashed-head
multiple-linked list structure used in one real world application: The
Commodore Amiga file system.


--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

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

--
https://mail.python.org/mailman/listinfo/python-list
RE: New Python implementation [ In reply to ]
nospam at yrl
Feb 18, 2021, 2:47 PM
Post #85 of 93 (356 views)
Permalink
Avi and Dennis--

Two thoughtful replies to a deep and interesting question. You have prodded me
to poke my head over the wall to offer a real world point of view.

In the early days before Modula II, I was contracting to a company, quite
large and respected, that had just chucked out Ratfor and adopted Pascal as
their main development tool on VAX-VMS. With long hindsight it was a not
insignificant factor in their going bust.

I was happily developing some of the best code I have ever written using Macro
on a J-11 PDP 11/73, so I was an innocent bystander, with my own OS, with
'borrowed' XDT and CRC table look-up software, courtesy of Dave Cutler and Stu
Wecker respectively. It was a front end for the main project, supporting 1024
terminals feeding 200 transactions a second into the VAX over raw ethernet on
a DEQNA. So I sure learned how to do linked lists, and do them quickly.

The main team was sharing a VAX-750. Watching them trying to use a teaching
language to do real world work was not a joy to behold.

You have both hit on a real-world problem. Script Kiddies and Stack Exchange
<grin>

A comp sci course must use a real-world language to send confident
practitioners into the real world.

Python is an excellent choice in that regard.

Dennis' point about it being too good is valid. If it were my course (and
there is no chance of that) I'd do an extra credit module where they have to
mine and critique the cPython source etc. for lists and comprehensions and
itertools and all their uncles and aunts. After all c is the nearest they will
get to the metal.

I know this has to work. Two or three of the guys on that project were John
Lion's co-authors of the Red Book on Unix internals. They were awesome! (I
told you this was very long hindsight didn't I?)

On 18 Feb 2021 at 17:26:11 GMT, ""Avi Gross"" <avigross@verizon.net> wrote:

> Dennis made the interesting comment "... Python has too much built in ..."
>
> I understand his point. At the same time, I wonder what most people using
> computers today, or in the future, need. Given serious amounts of computer
> power, what many people may want is higher-level ways to get things done
> without worrying how they are done. Python, like many such languages, has a
> very basic core that is augmented by what could be libraries, packages,
> modules and so on but have been chosen to be built-in to one distribution or
> another.
>
> Some people and organizations use some things so commonly, they want python
> to start up automatically loading say numpy and pandas and other such
> things. They may not care if the programmer knows how to make a linked list
> or binary tree data structure. Many such details are encapsulated within
> objects built and tested already.
>
> I have seen subjects taught at various levels and python might qualify too.
> I took a Physics course that required Calculus and used it to derive
> formulas and other things. Others took one that sort of threw equations at
> you without much explanation. I have even seen a course called Physics for
> Poets. But at least the poets taking it knew science existed and perhaps to
> take it seriously when others who had studied it better shared their
> results, even if they have no interest in the methods.
>
> We routinely have people learn how to use Word Processors or Spreadsheets
> with no clue on how to build such a thing or anything about the Object
> models used within or even knowing there is such a thing. Do they need to
> know how to use the embedded methods to extend things with Visual Basic or
> Javascript? They like getting closer to a WYSIWYG interface that handles
> most of their usual needs and perhaps farm out harder things to experts when
> needed.
>
> So what if you teach some aspects of python that are needed all over, like
> how to make things conditional or in a loop, but not how to make every
> possible data structure. What if you deliberately do not teach functional
> aspects of the language at first or ever? For some people that is enough to
> enable them to then use additional instructions on how to find prepared and
> tested chunks to use, even if not always optimally or efficiently. For those
> who really want to be programmers, that still may actually be enough if
> their task is to work using the tools we have developed, not in making new
> tools from scratch. Quite a bit of programming today consists of reading
> manual pages and cobbling together chunks that together do the job.
>
> But obviously I would choose the classes where I understood more. Many here
> would. But where does it end? Do most of us know how compilers or
> interpreters get built or do we just work on top of existing implementations
> others make available? Can you build an operating system from Scratch or
> make microchips to run them on?
>
> If the goal is Computer USE literacy, I think python has more than enough if
> you include the modules that make hard things easy.
>
> Just a thought. Admittedly it is hard these days to give a homework
> assignment when the student can find a trivial way to get the result and not
> do the hard work.
>
>
> -----Original Message-----
> From: Python-list <python-list-bounces+avigross=verizon.net@python.org> On
> Behalf Of Dennis Lee Bieber
> Sent: Thursday, February 18, 2021 12:45 AM
> To: python-list@python.org
> Subject: Re: New Python implementation
>
> On Tue, 16 Feb 2021 11:03:33 +0000, Alan Gauld via Python-list
> <python-list@python.org> declaimed the following:
>
>> On 16/02/2021 07:35, Christian Gollwitzer wrote:
>>> Am 16.02.21 um 06:36 schrieb dn:
>>>> Pascal's value as a teaching language was that it embodied many
>>>> aspects of structured programming, and like Python, consisted of a
>>>> limited range of items which could be learned very quickly
>>>
>>> ROFL. Maybe that was true for Python when it was first invented.
>>> Today it is not "a few simple things". Even just the core language,
>>
>> Python v1 was a good teaching language. v2 complicated it a bit but it
>> was still usable. v3 is no longer a good teaching language (unless
>> maybe you are teaching CompSci at university.)
>>
>> In fact in v3 things are so complex that I seriously considered
>> dropping Python as the core language for my programming tutorial.
>> Until I started looking for an alternative, and there really isn't
>> anything much better. At least not that can also be used for real
>> projects once you've learned it.
>
> Depending upon the course intentions, I'd say Python is useful for
> teaching general programming and getting to usable real-world programs.
>
> For CompSci /theory/, OTOH, Python has too much built in, and would
> get in the way of having someone implement things like linked-lists, deques,
> hashed structures -- ie; the stuff that lies behind all those Python
> built-ins. Pascal, Modula-2 (or is it up to 3 now), or one of the other
> system programming languages: Edison from
> https://www.amazon.com/Programming-personal-computer-Brinch-Hansen/dp/013730
> 2673
> Implement a hashed-head multiple-linked list using Kemeny&Kurtz
> level BASIC! (My algorithms instructor allowed the class to use any language
> on that he could read -- so FORTRAN, BASIC, Pascal, Sigma Meta-Symbol,
> COBOL... No Snobol, LISP, or APL -- for that final project: a phone book
> directory/look-up system). Interestingly, I've only seen a hashed-head
> multiple-linked list structure used in one real world application: The
> Commodore Amiga file system.


--
To de-mung my e-mail address:- fsnospam$elliott$$
PGP Fingerprint: 1A96 3CF7 637F 896B C810 E199 7E5C A9E4 8E59 E248


--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
python-list at python
Feb 19, 2021, 3:23 AM
Post #86 of 93 (356 views)
Permalink
On 19/02/2021 03:51, Dennis Lee Bieber wrote:

> They chose Pascal as being more modern, and something taught in schools
> (yeah, like TurboPascal is going to be a good introduction to writing
> software for real-time ground control of satellites).

Funnily enough it was. Or at least for real-time telecomms control.
We wrote all our real-time stuff on VAX and later PC using Pascal
from the mid 80s through to early 1990s when we switched to C++.
But TurboPascal was not much like Pascal, it had all the
theoretical bits by-passed or removed.

I still use Pascal in the shape of Delphi for building windows
GUI apps today... But Delphi bears even less resemblance to
Wirth's Pascal, in fact its quite similar to Python in many
ways.

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
grant.b.edwards at gmail
Feb 19, 2021, 7:15 AM
Post #87 of 93 (356 views)
Permalink
On 2021-02-19, Alan Gauld via Python-list <python-list@python.org> wrote:
> On 19/02/2021 03:51, Dennis Lee Bieber wrote:
>
>> They chose Pascal as being more modern, and something taught in
>> schools (yeah, like TurboPascal is going to be a good introduction
>> to writing software for real-time ground control of satellites).
>
> Funnily enough it was. Or at least for real-time telecomms control.
> We wrote all our real-time stuff on VAX and later PC using Pascal
> from the mid 80s through to early 1990s when we switched to C++.
> But TurboPascal was not much like Pascal, it had all the
> theoretical bits by-passed or removed.

Back in the 80's we wrote real-time embedded software for cellular
telephone radios in Pascal. We even wrote the OS kernel in Pascal. It
worked great and was less error-prone than C.

--
Grant



--
https://mail.python.org/mailman/listinfo/python-list
RE: New Python implementation [ In reply to ]
python-list at python
Feb 19, 2021, 8:49 AM
Post #88 of 93 (356 views)
Permalink
Some of us here go way back and have stories to tell of what we did even
before Python existed. I won't rehash my history here now except to say I
did use PASCAL in graduate school and my first job before switching to C
which was less annoying to use.

What I am interested in, in this forum, is how Python grew and specifically
what motivated adding new features. I see it as a bit more like a Camel
created when a committee got together and decided to create a horse and one
of them wanted it to also do well in a desert and so on.

For teaching purposes, it can be useful to have a minimalist design and a
way to catch lots of errors such as by strong typing. Some of that may also
be useful in the real world. But in re-teaching someone now in another
language, I keep running into the fact that when I use newer and more
powerful features they feel overwhelmed as they vaguely remember the
built-in way and the new way uses a piping metaphor they are not familiar
with. I have had others who started with the new ways and don't even want to
know how an earlier version of the language did it.

In the real world, having to read, let alone maintain, code that others have
had a hand in shaping and reshaping can be hard work if each person did
things their own way. We have discussed the many ways you can format text in
python and if a program uses them all, here and there, ...

But for an individual programmer, it is great to use whichever method feels
best for you, and especially if you came to python from another language
that method was borrowed from or vice versa. Being a rich language has pro's
and cons. LISP only had cons.

-----Original Message-----
From: Python-list <python-list-bounces+avigross=verizon.net@python.org> On
Behalf Of Alan Gauld via Python-list
Sent: Friday, February 19, 2021 6:23 AM
To: python-list@python.org
Subject: Re: New Python implementation

On 19/02/2021 03:51, Dennis Lee Bieber wrote:

> They chose Pascal as being more modern, and something taught in
> schools (yeah, like TurboPascal is going to be a good introduction to
> writing software for real-time ground control of satellites).

Funnily enough it was. Or at least for real-time telecomms control.
We wrote all our real-time stuff on VAX and later PC using Pascal from the
mid 80s through to early 1990s when we switched to C++.
But TurboPascal was not much like Pascal, it had all the theoretical bits
by-passed or removed.

I still use Pascal in the shape of Delphi for building windows GUI apps
today... But Delphi bears even less resemblance to Wirth's Pascal, in fact
its quite similar to Python in many ways.

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


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

--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
grant.b.edwards at gmail
Feb 19, 2021, 9:21 AM
Post #89 of 93 (356 views)
Permalink
On 2021-02-19, Avi Gross via Python-list <python-list@python.org> wrote:

> Some of us here go way back and have stories to tell of what we did even
> before Python existed. I won't rehash my history here now except to say I
> did use PASCAL in graduate school and my first job before switching to C
> which was less annoying to use.

ITYM Pascal. ;)

--
Grant

--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
mstemper at gmail
Feb 19, 2021, 10:14 AM
Post #90 of 93 (351 views)
Permalink
On 19/02/2021 10.49, Avi Gross wrote:

> But for an individual programmer, it is great to use whichever method feels
> best for you, and especially if you came to python from another language
> that method was borrowed from or vice versa. Being a rich language has pro's
> and cons. LISP only had cons.

<https://www.youtube.com/watch?v=DcQDqZIN09I>

--
Michael F. Stemper
If you take cranberries and stew them like applesauce they taste much
more like prunes than rhubarb does.
--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
bschollnick at schollnick
Feb 19, 2021, 10:31 AM
Post #91 of 93 (351 views)
Permalink
>> that method was borrowed from or vice versa. Being a rich language has pro's
>> and cons. LISP only had cons.

Now, Now. That’s certainly not correct.

LISP does have a few Pros. Namely Job security. You’ll have a hard time replacing a experienced and professional LISP programmer.

- Benjamin



--
https://mail.python.org/mailman/listinfo/python-list
RE: New Python implementation [ In reply to ]
python-list at python
Feb 19, 2021, 11:01 AM
Post #92 of 93 (351 views)
Permalink
Benjamin,

I wonder if you understood my intended meaning not about the plusses and minuses of using a language like LISP but that it is fundamentally build on using the CONS concept to make lists in a poetic way but has no PROSE.

Not only does every language have what I meant by the usual meaning of pros and cons, but it depends on what other languages you are comparing it to, what kind of work you use the language for, is it for prototyping or final and efficient use, will someone else be extending or maintaining it, and which side of the bed you woke up on.

I used to be a fan of brevity as in whatever make me type less. But over time, many functions you call now have so many arguments, that I am now a fan of specifying the names of each argument as in function_name(arg1=value1, arg3=value3, ...) because it makes it much clearer what you want and prevents a certain class of errors. Nonetheless, I despise very long variable names, even when the editor allows for name completion. I thus like to place many commands on multiple lines to be read somewhat vertically and short lines. Others prefer the opposite. If a language hinders this style of multi-line, it is a plus or minus depending.

(cons "A" (cons "v" (cons "I" nil)))

-----Original Message-----
From: Python-list <python-list-bounces+avigross=verizon.net@python.org> On Behalf Of Benjamin Schollnick
Sent: Friday, February 19, 2021 1:31 PM
To: Michael F. Stemper <mstemper@gmail.com>
Cc: python-list@python.org
Subject: Re: New Python implementation


>> that method was borrowed from or vice versa. Being a rich language
>> has pro's and cons. LISP only had cons.

Now, Now. That’s certainly not correct.

LISP does have a few Pros. Namely Job security. You’ll have a hard time replacing a experienced and professional LISP programmer.

- Benjamin



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

--
https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation [ In reply to ]
python-list at python
Feb 19, 2021, 12:00 PM
Post #93 of 93 (351 views)
Permalink
On 19/02/2021 18:14, Michael F. Stemper wrote:

>> and cons. LISP only had cons.

:-)

LOL


--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


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

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal