I sometimes use emojis in programs to highlight certain parts of the code (in open source libraries). I rarely use more than say 5-6 per script and I find they really stand out due to their colors in a text editor.
Typically, they are transient markers and will be removed when whatever issue they are associated with is closed.
My question is: are emojis liable to cause any issues in the general Python toolchain? This includes, but is not limited to: git, github, pypi, editors, linters, interpreter, CI/CD pipelines, command line usage...
I haven't seen any, but then again I rarely see emojis in code. This is a Python 3 only question, so Python 2 unicode aspects are out.
(This question is not about whether this looks professional or not. That's a valid, but entirely separate consideration.)
Some examples:
# ⚙️ this is where you configure foo
foo.max_cntr = 10
foo.tolerate_duplicates = False
# 🧟♂️🧟♂️🧟♂️ to indicate code to be removed
some dead code
# 👇 very important, don't forget to do this!
bar.deactivate_before_call()
In terms of risks, there aren't really any real ones. If you use them in comments they'll be removed/ignored at runtime anyway so performance-wise there's no issues.
The main issue that you could run into is that some Linux distributions (distros) DONT support emojis, so they'd fallback to some standard unicode character (generically a white rectangle with a cross through the middle), so this could make comments hard to understand.
But in personal use: no not really, there's no issues.
TLDR: Probably not, but maybe.
Related
I'm using Atom at work for editing Python code, and I'm running against a painful interaction between muscle memory and a labor-saving feature.
Near as I can tell, Atom will, when you paste a snippet of code, redo the indentation so that it's consistent with the indentation of the line it was pasted into, preserving relative indents.
If I didn't have any baggage from using editors without this feature, I'm pretty sure it'd be great, but as it is, I can't break my habit of selecting back to the preceding newline, and pasting that, which tends to do crazy things when pasting to or from the first line of a block.
I've tried to turn off Auto Indent on Paste, but it's not on anywhere I can find, and I'm not even sure it's the same feature; it's just what I hear about from people complaining about Atom going crazy when they paste Python.
So, where do I look to disable this? I'm willing to work up from no extensions back to what I've got installed, so assume a vanilla install.
I guess the workflow I'm looking for is "paste, manual re-indent", because at least that way I know what I'm getting and my response is always the same. As it stands, I don't have to think about it until it converts simple line rearrangements into syntactic garbage, which is worse than just adjusting things every time.
EDIT: In response to Milo Price, I have just now tried setting both autoIndentOnPaste and normalizeIndentOnPaste to false. The behavior is unchanged.
FURTHER EDIT: I had to reload the configuration for it to take. It's working now.
You have to set the config options autoIndentOnPaste and normalizeIndentOnPaste both to false, and then reload the configuration.
I am working on cross platform utility which involves drive scanning and the automagical creation of shell/batch files for the OSs upon which it runs. Unfortunately I cannot find one simple answer.
As stated in these links:
When to use os.name, sys.platform, or platform.system?
Reliably detect Windows in Python
Extract file name from path, no matter what the os/path format
Python: What OS am I running on?
and at http://docs.python.org/library/platform.html#module-platform
The various platform.system(), platform.platform(), sys.platform, os.name() etc. etc. all suffer the problem of not necessarily being future perfect. That is if an OS developer changes things a little, these may not work (at least until patched or revised). So obviously the best solution is to try a small part of each of the above, along with targeting some OS specific executable file with a call().
Which leaves my question:
Since the best way to determine this involves platform.system, sys.platform, and os.name (assuming only generalized recognition is needed), what are the various possible outputs for those programs? The docs.python.org sections on each of these modules only lists a few, and the pages are not exactly current. Specifically I would like to know the possible output on the last three mac OS's, Win XP- Win 8, and just knowing Linux covers my needs there. Any one know what the outputs are or where i can find them?
Thanks in advance.
Clarification:
What I am looking for here is the currently known values so that I can incorporate them into an existing project, with an eye towards future code revision being made easier on my end. So the CURRENT return values are what I am seeking (Last 3 gens of Mac OS* and Win * since beyond that probably isn't much used any more)
Edit: For the specific question of all possible return values:
Related stackoverflow answer for Possible values from sys.platform?
Post with the answers pointed to above:
aix3 aix4 atheos beos5 darwin freebsd2 freebsd3 freebsd4 freebsd5
freebsd6 freebsd7 generic irix5 irix6 linux2 mac netbsd1 next3 os2emx
riscos sunos5 unixware7
Also:
linux3, freebsd8, win32, dos, os2
and others.
(They were asking the same question in Aug 2006.)
Note:
As others have indicated, sys.platform is derived from the name that
the system vendor gives their system.
/Edit.
Not sure it's possible to have something so future-perfect. If you only want to know the OS (mac/win/linux) then see the examples for sys.platform.
Also, keeping things in a separate function like get_os_name lets you control or map the input-output if you see a lot of changes in the future - once a year per OS? Also convenient to combine with the other functions you've mentioned. So you can return a tuple based on (os_name, 32/64bit, variant) (where variant is things like XP, Win8, Darwin, etc.) depending on how it affects your script.
The docs.python.org sections on each of these modules only lists a few, and the pages are not exactly current.
Unfortunately true. But again, it's impossible to account for environments or platforms in the future or even all current ones. The logical thing to do is make sure it works on the current platforms that you have tested/developed for.
I am about to get a bunch of python scripts from an untrusted source.
I'd like to be sure that no part of the code can hurt my system, meaning:
(1) the code is not allowed to import ANY MODULE
(2) the code is not allowed to read or write any data, connect to the network etc
(the purpose of each script is to loop through a list, compute some data from input given to it and return the computed value)
before I execute such code, I'd like to have a script 'examine' it and make sure that there's nothing dangerous there that could hurt my system.
I thought of using the following approach: check that the word 'import' is not used (so we are guaranteed that no modules are imported)
yet, it would still be possible for the user (if desired) to write code to read/write files etc (say, using open).
Then here comes the question:
(1) where can I get a 'global' list of python methods (like open)?
(2) Is there some code that I could add to each script that is sent to me (at the top) that would make some 'global' methods invalid for that script (for example, any use of the keyword open would lead to an exception)?
I know that there are some solutions of python sandboxing. but please try to answer this question as I feel this is the more relevant approach for my needs.
EDIT: suppose that I make sure that no import is in the file, and that no possible hurtful methods (such as open, eval, etc) are in it. can I conclude that the file is SAFE? (can you think of any other 'dangerous' ways that built-in methods can be run?)
This point hasn't been made yet, and should be:
You are not going to be able to secure arbitrary Python code.
A VM is the way to go unless you want security issues up the wazoo.
You can still obfuscate import without using eval:
s = '__imp'
s += 'ort__'
f = globals()['__builtins__'].__dict__[s]
** BOOM **
Built-in functions.
Keywords.
Note that you'll need to do things like look for both "file" and "open", as both can open files.
Also, as others have noted, this isn't 100% certain to stop someone determined to insert malacious code.
An approach that should work better than string matching us to use module ast, parse the python code, do your whitelist filtering on the tree (e.g. allow only basic operations), then compile and run the tree.
See this nice example by Andrew Dalke on manipulating ASTs.
built in functions/keywords:
eval
exec
__import__
open
file
input
execfile
print can be dangerous if you have one of those dumb shells that execute code on seeing certain output
stdin
__builtins__
globals() and locals() must be blocked otherwise they can be used to bypass your rules
There's probably tons of others that I didn't think about.
Unfortunately, crap like this is possible...
object().__reduce__()[0].__globals__["__builtins__"]["eval"]("open('/tmp/l0l0l0l0l0l0l','w').write('pwnd')")
So it turns out keywords, import restrictions, and in-scope by default symbols alone are not enough to cover, you need to verify the entire graph...
Use a Virtual Machine instead of running it on a system that you are concerned about.
Without a sandboxed environment, it is impossible to prevent a Python file from doing harm to your system aside from not running it.
It is easy to create a Cryptominer, delete/encrypt/overwrite files, run shell commands, and do general harm to your system.
If you are on Linux, you should be able to use docker to sandbox your code.
For more information, see this GitHub issue: https://github.com/raxod502/python-in-a-box/issues/2.
I did come across this on GitHub, so something like it could be used, but that has a lot of limits.
Another approach would be to create another Python file which parses the original one, removes the bad code, and runs the file. However, that would still be hit-and-miss.
I am using Emacs 23.1.1 on GNU/Linux with autocomplete.el 1.3 and Ropemacs 0.6.
In Lisp programming, autocomplete.el shows the documentation (known as 'QuickHelp' in autocomplete.el) of the suggested completions. Python completion with ropemacs works, but does not show quick help for the Python completion. Is it possible to enable it and did somebody make it work?
Ropemacs does the job : Use the function rope-show-doc over the symbol or use the keybinding C-c d. Simple :)
I stopped using all the autocomplete stuff in all my developing environments. They rarely do what I want. Either the lists is too long, or too short, or not sorted well. Therefore I use dabbrev-expand in all my modes global-set-key to tab.
This works even quote well for text. Usually it is enough to get a good expansion from the local buffer where you are in. If I start typing in an empty buffer I open a second one which expand can use to look up its suggestions. This is not language sensitive, not does depend on the object you want to call a method of, but its still a big boost, and you get used to it. Maybe its not, you don't get "quick help" this way.
I've gotten omnicompletion with Pysmell to work before, but I can't seem to do it again.
I tried following some steps online, but most, if not all, of them are to vague and assume too much that you know what you are doing to some extent.
Can someone post a full, step-by-step tutorial on how to get code completion working properly, for complete Vim newbies (for dummies?)?
There's also Ctrl+n in insert mode which will autocomplete based on the words it has seen in any of the open buffers (even in other tabs).
You may try Pydiction (Excerpt below)
Description Pydiction allows you to
Tab-complete Python code in Vim,
including: standard, custom and
third-party modules and packages. Plus
keywords, built-ins, and string
literals.
Pyflakes has a vim plugin that does this pretty awesomely. Unlike Pydiction, you don't need to build a dictionary beforehand (so if you're bouncing between different virtualenvs it's a bit less hassle.) I haven't been using it long but it seems very slick.
Try hitting Ctrl-p while typing mid-word. Ctrl-p inserts the most recent word that starts with the prefix you're typing and Ctrl-n inserts the next match. If you have several possibilities, you can hit ctrl-p more than once to substitute each candidate in order.