Good name for interpreter binary about micropython HOT 40 CLOSED

I'm in favor of upython

from micropython.

Given that chickenpotpython would probably fly over people's heads, I
suppose I'll have to vote for upython as well.

On Tue, Dec 31, 2013 at 5:40 PM, Paul Sokolovsky
[email protected]:

I wanted to write that "py" name is a bit too generic, and if every
python-related project seized that name, there would be conflicts. Well,
there're conflicts, from http://docs.python.org/3/whatsnew/3.3.html :

The Python 3.3 Windows installer now includes a py launcher application that can be used to launch Python applications in a version independent fashion.

More info: http://docs.python.org/3/using/windows.html#launcher

So, it would be good idea to come up with a more unclashy name. IMHO,
"upython" would be both consistent, clear to users and unique - and based
on idea that "u" is common way to represent Greek letter "mu" for "micro";
"mpython" would mean "minipython". But even "mpython" is better than
current "py".

And this is of course borders on the question raised in Kickstarter
comments - on project shortname/nickname to use in context where full
"MicroPython" is too long.

—
Reply to this email directly or view it on GitHubhttps://github.com/dpgeorge/issues/17
.

from micropython.

+1 to upython

Send from my Samsung Galaxy Note II
El 01/01/2014 02:42, "Dr-Syn" [email protected] escribió:

Given that chickenpotpython would probably fly over people's heads, I
suppose I'll have to vote for upython as well.

On Tue, Dec 31, 2013 at 5:40 PM, Paul Sokolovsky
[email protected]:

I wanted to write that "py" name is a bit too generic, and if every
python-related project seized that name, there would be conflicts. Well,
there're conflicts, from http://docs.python.org/3/whatsnew/3.3.html :

The Python 3.3 Windows installer now includes a py launcher application
that can be used to launch Python applications in a version independent
fashion.

More info: http://docs.python.org/3/using/windows.html#launcher

So, it would be good idea to come up with a more unclashy name. IMHO,
"upython" would be both consistent, clear to users and unique - and
based
on idea that "u" is common way to represent Greek letter "mu" for
"micro";
"mpython" would mean "minipython". But even "mpython" is better than
current "py".

And this is of course borders on the question raised in Kickstarter
comments - on project shortname/nickname to use in context where full
"MicroPython" is too long.

—
Reply to this email directly or view it on GitHub<
https://github.com/dpgeorge/micropython/issues/17>
.

—
Reply to this email directly or view it on GitHubhttps://github.com/dpgeorge/issues/17#issuecomment-31417057
.

from micropython.

I also agree with upython.
But I counter propose mupython. Because:

• mu is umabiguous (although u is short for mu - mu is also generally accepted).
• having an m at the start associates it more easily with micro python
• mu is less likely than u to clash with future projects
• strangely its longer and therefore easier to spot as not a misspelling.

but of course upython is shorter...

from micropython.

upython - 👍

from micropython.

mupython +1

from micropython.

mupython is much better.

from micropython.

I voted for upython, but after reading the topic, I think now mupython is a
better name, although uPy ir more "scientific" it's true that not so much
people would understand it, so muPy would be a better abreviation.

2014/1/1 Jonathan Greig [email protected]

mupython is much better.

—
Reply to this email directly or view it on GitHubhttps://github.com/dpgeorge/issues/17#issuecomment-31422671
.

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton
de sitios diferentes, simplemente escribe un sistema operativo Unix."
– Linus Tordvals, creador del sistema operativo Linux

from micropython.

Damien's major effort needs an easy 'hook'
mupython mpython ..doesn't quite do it for me.

Its embedded python. ... pythembed embedpy
easily part of network of things ... pything PyTing
Damien's Python DamPython DamPy
George... Georgie Porgie :-) Bet you never heard that before ! :-| PudPy ....Its so sweet?! and has Pie reference

Any non-pom (Non-English) scratching their head by now?
Its from an English nursery rhyme
Georgie Porgie, Puddin' and Pie,
Kissed the girls and made them cry,
When the boys came out to play
Georgie Porgie ran away

Well ,Damien, Pick something with typing ease that ISN'T google search aliased already!!!
Example ... I search for Arduino CNC GCode to Stepper translator "GRBL" alot...
GRBL is the base code.... and people have made derivatives with "GRBL" some where in the name.
finding GRBL and its derivatives is so easy...Good google presence will really help with adoption. IMHO

Hugh Wallace

On Jan 1, 2014, at 6:21 AM, Jesús Leganés Combarro [email protected] wrote:

I voted for upython, but after reading the topic, I think now mupython is a
better name, although uPy ir more "scientific" it's true that not so much
people would understand it, so muPy would be a better abreviation.

2014/1/1 Jonathan Greig [email protected]

mupython is much better.

—
Reply to this email directly or view it on GitHubhttps://github.com/dpgeorge/issues/17#issuecomment-31422671
.

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton
de sitios diferentes, simplemente escribe un sistema operativo Unix."
– Linus Tordvals, creador del sistema operativo Linux
—
Reply to this email directly or view it on GitHub.

from micropython.

I am a fan of "muPy" or "uPy" (which would be the nickname for the official long name "MicroPython") because it falls in line with other well-known Python libraries and platforms. For example, NumPy, SciPy, FePy, PyPy.

from micropython.

Let me first say that the unix port was initially intended just for testing purposes, not suited for the real world. Hence the poor choice of binary name.

It looks like the unix port is gonna get some legs, so, yes, we need a better name.

In the code, I use "mp_" for everything Micro Python related. I like that because it's short and the simplest abbreviation for "Micro Python". "up_" would have been strange. "upy_" would have been okay, "mupy_" reads like muppet and is long :) So that's my rationale for function/type names in C.

For binary, I would say either upython or mupython.

Also I need a name for the board, since I want to make a separate repo for that (see update #18).

from micropython.

mp_ is fine for code, IMO.

upython reminds me of uWSGI. I don't think it will be lost on people that it means "micro."

from micropython.

Also I need a name for the board, since I want to make a separate repo for
that (see update #18#18
).

Some days ago I proposed to use "pyb" both in reference to "PYthon Board"
and also because it's being used on the code examples to reference to the
board components, and some people agried it was a good name... :-)

By the way, where are the code examples? Could you be able to upload them
to (another) repo? :-)

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton
de sitios diferentes, simplemente escribe un sistema operativo Unix."
– Linus Tordvals, creador del sistema operativo Linux

from micropython.

By the way, where are the code examples?

Wanted to ask that too.

Could you be able to upload them to (another) repo? :-)

IMHO they belong to the main repo, let's not spread too thin.

from micropython.

Look how many people here have actually posted μ instead of u for the binary name. Nobody. Using u is clearly wrong to start with. Also, for any OS that supports symbolic linking, it's not a major problem to provide the alternate spelling, I think it makes more sense to use mupython officially.

The pyb made immediate sense to me for the board.

from micropython.

Could you be able to upload them to (another) repo? :-)

IMHO they belong to the main repo, let's not spread too thin.

Inside a "examples" folder like Node.js projects does, for example? Ok, I
agree on that :-)

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton
de sitios diferentes, simplemente escribe un sistema operativo Unix."
– Linus Tordvals, creador del sistema operativo Linux

from micropython.

Maybe I did not understand it right, but you are discussing that you want
to find a name for the python module called by micropython to access the
internal functions of the stm controller?

If not just stop reading here ;)

Since the project is called micropython, I see no problem to call the
module micropython as well.
There are two scenarios.

1. One reads some python code and finds a command like "import mpy". I find
   it requires some extra neurons to figure out that the project micropython
   provides the module mpy. Basically, you would start to google mpy and just
   by chance find out that www.micropython.org is the home of mpy.
2. Someone learns about micropython and it might just confuse him to find
   snippets like mpy.ad(3), since mpy would not tell him anything what is
   going on. I would prefer a more task related name.

I guess other projects do similar. I believe there is no real benefit
shorten micropython by using mpython or mupython rather then saving a few
keypress. Many people do something like "import micropython as mp" anyhow.

The only drawback using micropython as name would be that there is a fear
that people would believe that micropython is "only" a python module, since
it is much more then this. But even then, I do not see a problem giving a
module the same name the larger project.

However, if you believe you need to separate the module name from the
project name, I would even go all the way to call the module
stm_io. Since we might have a pic_io, propeller_io and atmel_io later.

Just a total different idea ;)

Torsten

On 1 January 2014 16:33, Hugh Wallace [email protected] wrote:

Damien's major effort needs an easy 'hook'
mupython mpython ..doesn't quite do it for me.

Its embedded python. ... pythembed embedpy
easily part of network of things ... pything PyTing
Damien's Python DamPython DamPy
George... Georgie Porgie :-) Bet you never heard that before ! :-| PudPy
....Its so sweet?! and has Pie reference

Any non-pom (Non-English) scratching their head by now?
Its from an English nursery rhyme
Georgie Porgie, Puddin' and Pie,
Kissed the girls and made them cry,
When the boys came out to play
Georgie Porgie ran away

Well ,Damien, Pick something with typing ease that ISN'T google search
aliased already!!!
Example ... I search for Arduino CNC GCode to Stepper translator "GRBL"
alot...
GRBL is the base code.... and people have made derivatives with "GRBL"
some where in the name.
finding GRBL and its derivatives is so easy...Good google presence will
really help with adoption. IMHO

Hugh Wallace

On Jan 1, 2014, at 6:21 AM, Jesús Leganés Combarro <
[email protected]> wrote:

I voted for upython, but after reading the topic, I think now mupython
is a
better name, although uPy ir more "scientific" it's true that not so
much
people would understand it, so muPy would be a better abreviation.

2014/1/1 Jonathan Greig [email protected]

mupython is much better.

—
Reply to this email directly or view it on GitHub<
https://github.com/dpgeorge/micropython/issues/17#issuecomment-31422671>
.

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un
monton
de sitios diferentes, simplemente escribe un sistema operativo Unix."
– Linus Tordvals, creador del sistema operativo Linux
—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHubhttps://github.com/dpgeorge/issues/17#issuecomment-31424544
.

from micropython.

Maybe I did not understand it right, but you are discussing that you want
to find a name for the python module called by micropython to access the
internal functions of the stm controller?

We are discussing three names here:

• The main one, the name of the virtual machine. In the same way as
  CPython, Jython, IronPython, PyMite and TinyPy, it's being discussed to use
  uPython o muPython or similars.
• The name of the board itself. Almost nothing discussed yet, but pyb seems
  a good candidate :-)
• Name of the platform-dependent module, plainly nothing discussed, but
  probably the same name as the board (pyb for the STM/MicroPython Board,
  arduino for Arduino, etc)

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton
de sitios diferentes, simplemente escribe un sistema operativo Unix."
– Linus Tordvals, creador del sistema operativo Linux

from micropython.

We are discussing three names here:

Actually, as the title says, this ticket was opened to discuss solely the name of a binary executable file produced by checking out the source code from the repo, going to "unix" subdir, and running "make". Though yeah, people started to discuss 3 other things here too ;-).

from micropython.

Ok in that case
I vote for

• micropython for the bin (which would be equal to mi) on my zsh shell
  and hence, I do not care for long names). However, I dislike if the main
  exec file calls differently compared to the package name and I guess the
  package name would be micropython in most cases.
• micropython board for the board name, just to get it clear, this is the
  official board from the micropython project. Please do not use silly names
  like the arduino does. Still mixing up UNO, DUE or Duemilanove, or
  Diecimila. Anyhow, I would limit the official micropython board to a single
  board at a time. This board should be the reference design. A first
  starting point for new users and a reference source for experienced users
  and other projects to create individual third party designs. After all,
  micropython the software will run on a much more third-party devices later.
  Hence, I would go with a simple number... micropython board V1, V2, V3,
  etc. with sub-numbers for smaller revisions like V1.1 etc. Hmmm... later,
  there is a need how to distinguish between officially supported processor
  families and those which might receive a port outside of the micropython
  core development.

and

• stm_io (or a derivate if you dislike _ in module names) for the module
  name which clearly indicates what it is doing.
  Further I would vote to call the module names by the microcontroller family
  instead of using the board name, this would help to indicate that
  micropython runs in theory on all boards including the same processor.
  However, that would require to keep the pin assignments and other parts of
  the module flexible enough.
  Is there any plan to introduce a config file system to address different
  boards in the future, thus that one could call.

import stm_io
stm_io.loadconfig("micropython.config")

and all I/O assignments would be readily set for the micro python board
(sure None could look-out for a default file name).

Well guess this is getting OT ;)

Greetings

Torsten

On 1 January 2014 23:48, Paul Sokolovsky [email protected] wrote:

We are discussing three names here:

Actually, as the title says, this ticket was opened to discuss solely the
name of a binary executable file produced by checking out the source code
from the repo, going to "unix" subdir, and running "make". Though yeah,
people started to discuss 3 other things here too ;-).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/17#issuecomment-31432080
.

from micropython.

I suggest mvp.

from micropython.

Okay, let's keep this issue for it's original title, to discuss the binary that at the moment is unix/py.

The board/hardware is now in a separate repository called pyboard.

from micropython.

I vote for "micropython": this is a fine name, easy to read and remember and to google for.
In fact a simple Google search for micropython takes to the project-related pages.
On the contrary the other names seems already used by other projects:

• mpython referes to Monad-Python (https://github.com/dpiponi/Monad-Python);
• mupython is an already existing project (https://github.com/laou/MuPython)
• upython is used by a couple of existing projects (http://sourceforge.net/projects/upython/ and https://github.com/Enome/uPython)

from micropython.

Folks, how about "mipy" (pronounced "My-Pie")?

It's brief, doesn't appear encumbered by existing use, and doesn't have any negative associations in any (human) language I know.

I don't really want to be typing "micropython" every time I run it, and I don't think I'm alone in that!

from micropython.

Considering the info David mentions, micropython should really be the name for the interpreter. No nonsense or shortening of the name and is likely what someone would first type into the terminal if they cannot remember exactly.

Eventually this may make it's way into Debian/Ubuntu repositories (or at a minimum, a package provided at micropython.org) and the package should be named micropython.

I.E.
apt-get install python
python

apt-get install micropython
micropython

There are numerous other packages that work the same way. Just keep it simple.

As for the length of the binary name, anyone wanting to do multiple runs should be using a terminal where pressing up brings up the last issued command. I type micropython once and edit the file I want to run accordingly.

Like I mentioned before, create symbolic links for the shortened name(s) when it is determined. Typing the full micropython should "just work". All of the major OS support symbolic linking, if your still running XP, upgrade or use a batch script.

from micropython.

In most cases, you won't be running 'micropython' directly at all; it'll be loaded on the embedded system where it's supposed to execute. In the other cases, tab completion exists ;-)

from micropython.

micropython 💯

if project is called micropython and this repository is called micropython it just makes perfect sense to also call binary that way. its just intuitive everything else assumes something. if somebody finds it hard to type (which is funny since autocomplete exists since before i was born) there is always a possibility to create aliases...

from micropython.

In the other cases, tab completion exists ;-)

Are you sure it indeed exists? Open terminal on your Android phone and check if it indeed does. Wait, where's tab key at all on standard Android virtual keyboard?

Command names are selected not for optimistic conditions where you have brain-computer interface and need just think about something to have it typed, but for conservative environment, where there's no history, no completion, modem is damn slow, touchscreen is resistive, miscalibrated, or broken, and yet you need to run it many times in row ;-).

from micropython.

Quoting Paul Sokolovsky (2014-01-02 17:15:54)

In the other cases, tab completion exists ;-)

Are you sure it indeed exists? Open terminal on your Android phone and check if
it indeed does. Wait, where's tab key at all on standard Android virtual
keyboard?

Command names are selected not for optimistic conditions where you have
brain-computer interface and need just think about something to have it typed,
but for conservative environment, where there's no history, no completion,
modem is damn slow, touchscreen is resistive, miscalibrated, or broken, and yet
you need to run it many times in row ;-).

i'm not saying its going to work for everybody. but it makes sense for
majority. for those "edge" cases you can find solution otherwise.

Rok Garbas - http://www.garbas.si

from micropython.

While I don't want to demote my own work (!), I must say that I didn't intend the unix/py version of Micro Python to be used by the general public as an alternative to CPython on the unix command line. Beyond microcontrollers, I can see it being useful in games for a scripting engine, and perhaps on minimal Linux builds (by minimal I mean 16MB RAM minimal). But if you are on a fully fledged unix system, why not use CPython?

To answer my own question, perhaps your Python program is eating lots of memory and you need something a bit leaner (this has happened to me more than once). In that case Micro Python may be a good fit.

This is getting a bit off topic, but I think answers to the above question (why use MP instead of CPython?) are needed to decide what to call the binary.

I agree with @davidedb, that "micropython" is fool proof and future proof. I also agree with @pfalcon that unix commands are meant to be lean. Although, that's what "alias mp=micropython" is for :)

from micropython.

Are you sure it indeed exists? Open terminal on your Android phone and check if it indeed does

Does for me, but then that's because I use specific apps to interface with a real unix system when I want to do real unix things. The instances where you'd have to invoke micropython by name on an otherwise unconfigured system multiple times in a row are so vanishingly rare that, honestly, I don't think it's that worrisome.

Building a 'lean' command name for the unix port is somewhat nonsensical also as the unix port isn't actually the focus of this project--the microcontroller version's the focus; the unix port's just there for the convenience of devs testing out code.

@dpgeorge has it entirely correct: if you're going to be using it on a 'nix system, then alias it to something useful for you. Every project does not need to be everything for everyone; attempting to cover every edge case leads to feature creep, which leads to large binaries, which leads to leaving the scope of this project entirely ;-p

from micropython.

[OffTopic]

In the other cases, tab completion exists ;-)

Are you sure it indeed exists? Open terminal on your Android phone and
check if it indeed does. Wait, where's tab key at all on standard Android
virtual keyboard?

https://play.google.com/store/apps/details?id=org.pocketworkstation.pckeyboard

In the last version it also has the Windows logo key, and I can assure you
that's a wonderful keyboard (it's the one that I've been using both in my
tablets and smartphones since more than a year).

Namaste... ;-)

[/OffTopic]

After reading this latest mails, I remove my vote from mupython (as I did
from upython) and give it to plainly call the virtual machine/CLI command
as "micropython". Long? Sure, only problem would be with a 8.3 environment.
Clear? Absolutely :-)

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton
de sitios diferentes, simplemente escribe un sistema operativo Unix."
– Linus Tordvals, creador del sistema operativo Linux

from micropython.

I, too, change my vote to a simple: "micropython" :)

from micropython.

But if you are on a fully fledged unix system, why not use CPython?

Here's my take:

Indeed, if one writes an app to run on "full-fledged" system (4Gb, 100W power), then it makes no sense to spend time on anything else but writing the app and just use existing solutions like CPython.

I'm personally more interested in Ubiquitous Computing, whose idea is to put exactly as much as needed processing power where it is needed. So, when I want to write simple webapp I want to use toolset which will allow me to scale down say to 16Mb RAM/4Mb ROM router system, even if I initially develop it on 4Gb/100W box. CPython doesn't scale down to those requirements (it simply won't fit in 4Mb). So, instead of using CPython, and then port it to MicroPython (and yes, it will require porting), I'd rather use MicroPython right away.

And if I'd want to develop something useful for deeply embedded uPy system (I love the idea, it just needs to prove itself being really viable), I'd still prefer to do (big) part of development, testing, and debugging on a desktop system, because it's much more convenient (again, because using CPy for that will lead to unneeded surprises).

So, everything looks like having a "desktop" version of MicroPython is good thing to enable full potential of it and make development more productive and convenient. And doing it right (avoiding naming conflicts, choosing good name) will allow more people to leverage it easily (ultimately by installing from a distro package).

from micropython.

Building a 'lean' command name for the unix port is somewhat nonsensical also as the unix port isn't actually the focus of this project--the microcontroller version's the focus

Then people should not have strong opinions about it (like "call the binary the same as the project, because I have tab completion and don't care if someone else doesn't"). Indeed, I'm surprised that this ticket caught so much attention - it was intended for those few who care about such marginal questions, other naming discussions should have happened is separate tickets.

from micropython.

Ok, I guess we had good enough discussion and I just committed fe2690d which allows to write full-fledged scripts with unix port. @dpgeorge, can you please decide what will be the good name for the binary and rename it? Thanks!

from micropython.

The binary... and the source code folder...

Send from my Samsung Galaxy Note II
El 20/01/2014 00:24, "Paul Sokolovsky" [email protected] escribió:

Ok, I guess we had good enough discussion and I just committed fe2690dhttps://github.com/micropython/micropython/commit/fe2690da0a1b8556995f5a6d2368d250f504b4afwhich allows to write full-fledged scripts with unix port.
@dpgeorge https://github.com/dpgeorge, can you please decide what will
be the good name for the binary and rename it? Thanks!

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/17#issuecomment-32725863
.

from micropython.

No, only the unix binary. If you have any suggestions regarding source code folder, please open separate ticket.

from micropython.

I'd want to have the full word "python" in the name (eg not mpy).

As already pointed out, upython, mpython, mupython are already taken.

So, unless we want to clash with something existing / make some people unhappy, that really just leaves "micropython".

from micropython.

Let's go for it!

from micropython.