Comments (40)
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.
- 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. - 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 referenceAny 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 awayWell ,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. IMHOHugh 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.
Related Issues (20)
- Update libffi to 3.3 or later to unblock CI for RV64. HOT 6
- ESP32-S3-FN8 SPIRAM errors on boot. HOT 8
- EXTI Power Voltage Detector doesn't work on STM32WB55 and STM32WL55 HOT 7
- RV32 native emitter fails compiling some of the tests HOT 22
- ESP32 wifi issues HOT 2
- Implement machine.USBDevice for ESP32-S3 HOT 2
- NUCLEO_F746ZG LAN stops working after few days.
- frambuf initalizes with ValueError HOT 8
- examples/network/https_client.py + cloudflare.com = OSError: 97 HOT 3
- ESP32-S3 FH4R2 v0.2 No WiFi HOT 3
- docs: Information missing about 'status' options while wifi is in AP mode + "Constants" module about security?
- Const with type hints is not optimized HOT 1
- Native code decorator should be best-effort
- docs: esp32s2 has no BLE support
- RP2350 / Pico 2 machine.lightsleep not working correctly HOT 1
- RP2350 / Pico 2 machine.deepsleep results in crash HOT 2
- asyncio: sleep_ms terminates early HOT 3
- BLE GATT descriptor set to DESCRIPTOR_READ (0x01) returns Error Code: Read Not Permitted (0x02) HOT 4
- memory allocation ESP32's HOT 3
- Concatenation (without "+" sign) of string and f-string becomes f-string HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from micropython.