Run Windows commands from Python console
Hello, I run Python console in Windows. Can I run cmd prompt commands there? If I run command dir I have: >>> dir What does it means? If i trying to create file I have error: >>> type NUL > hh.txt File "", line 1 type NUL > hh.txt ^ SyntaxError: invalid syntax What means line below: File "", line 1 I don't have any file. -- https://mail.python.org/mailman/listinfo/python-list
Re: Run Windows commands from Python console
On Sunday, September 3, 2017 at 7:57:14 AM UTC-5, g.mor...@gmail.com wrote:
> Hello,
>
> I run Python console in Windows. Can I run cmd prompt commands there?
>
> If I run command dir I have:
>
> >>> dir
>
>
> What does it means?
It means that the expression `dir` (in python's universe) is
a symbol for the built-in function named "dir", and when you
send a symbol to the python interpreter in interactive mode,
all python will do is send back some info about the symbol.
In this case, Python is telling you that the symbol `dir` is
not only a function object, it is a _built-in_ function
object.
To actually _invoke_ a python function -- even when the
function requires no arguments (as is the case with "dir")
-- you must use enclosing parentheses. Try this instead:
>>> dir()
['__builtins__', '__doc__', '__name__', '__package__']
Some languages will allow you to omit the parentheses when
calling a function that requires no arguments, but python
does not work that way; and i'm glad too, because i have a
very low tolerance for inconsistency. Just ask anyone here
who knows me! O:-)
> If i trying to create file I have error:
>
> >>> type NUL > hh.txt
> File "", line 1
> type NUL > hh.txt
>^
> SyntaxError: invalid syntax
That's not how you create a file with Python! To read or
write files, try using the built-in function named "open":
>>> fileObj = open("NEW_OR_EXISTING_FILENAME_HERE", 'w') # Write
or
>>> fileObj = open("EXISTING_FILENAME_HERE", 'r') # Read
> What means line below:
>
> File "", line 1
>
> I don't have any file.
Sure you do, it's just not readily apparent.
Python provides a "stdin" (aka: Standard Input) for which
input can be received, and a "stdout" (aka: Standard Output)
so that output can be, well, for lack of better word:
"outputted".
In fact, the built-in "print function" and built-in "input
function" are just wrappers around `sys.stdout.write(...)`
and `sys.stdin.readline('...')` respectively, and if you
don't believe me, then type this:
>>> import sys
>>> sys.stdout.write('Python rules!\n')
Python rules!
>>> value = sys.stdin.readline()
this is input! # <-- Type this yourself!
>>> value
'this is input!\n'
The same result can be achieved using the more powerful and
elegant built-in functions:
>>> value = input('Type Something Interesting: ')
Type Something Interesting: blah
>>> value
'blah'
>>> print('Python Rules!')
Python Rules!
You can view these "file streams" by importing the "sys"
module and typing `sys.stdin` or `sys.stdout` at the command
line, and, depending on where you type these commands, you
may receive different results for the streams as they can be
captured and redefined by unique interactive environments.
Here is session from IDLE (Python's built-in code editor):
>>> sys.stdin
>>> sys.stdout
As you can see, IDLE has captured these streams, so you'll
get a different result if you run the commands from a
windows prompt in python mode, or a unique environment.
You can even capture these streams for yourself, which is
helpful for logging purposes. Consult the "sys" module docs
for more details
--
https://mail.python.org/mailman/listinfo/python-list
ANN: psutil 5.3.0 with full unicode support is out
Hello all,
I'm glad to announce the release of psutil 5.3.0:
https://github.com/giampaolo/psutil
A blogpost describing the main changes is available here:
http://grodola.blogspot.com/2017/09/psutil-530-with-full-unicode-support-is.html
About
=
psutil (process and system utilities) is a cross-platform library for
retrieving information on running processes and system utilization (CPU,
memory, disks, network) in Python. It is useful mainly for system
monitoring, profiling and limiting process resources and management of
running processes. It implements many functionalities offered by command
line tools such as: ps, top, lsof, netstat, ifconfig, who, df, kill, free,
nice, ionice, iostat, iotop, uptime, pidof, tty, taskset, pmap. It
currently supports Linux, Windows, OSX, Sun Solaris, FreeBSD, OpenBSD and
NetBSD, both 32-bit and 64-bit architectures, with Python versions from 2.6
to 3.5 (users of Python 2.4 and 2.5 may use 2.1.3 version). PyPy is also
known to work.
What's new
==
**Enhancements**
- #802: disk_io_counters() and net_io_counters() numbers no longer wrap
(restart from 0). Introduced a new "nowrap" argument.
- #928: psutil.net_connections() and psutil.Process.connections() "laddr"
and
"raddr" are now named tuples.
- #1015: swap_memory() now relies on /proc/meminfo instead of sysinfo()
syscall
so that it can be used in conjunction with PROCFS_PATH in order to
retrieve
memory info about Linux containers such as Docker and Heroku.
- #1022: psutil.users() provides a new "pid" field.
- #1025: process_iter() accepts two new parameters in order to invoke
Process.as_dict(): "attrs" and "ad_value". With this you can iterate over
all
processes in one shot without needing to catch NoSuchProcess and do
list/dict
comprehensions.
- #1040: implemented full unicode support.
- #1051: disk_usage() on Python 3 is now able to accept bytes.
- #1058: test suite now enables all warnings by default.
- #1060: source distribution is dynamically generated so that it only
includes
relevant files.
- #1079: [FreeBSD] net_connections()'s fd number is now being set for real
(instead of -1). (patch by Gleb Smirnoff)
- #1091: [SunOS] implemented Process.environ(). (patch by Oleksii Shevchuk)
**Bug fixes**
- #989: [Windows] boot_time() may return a negative value.
- #1007: [Windows] boot_time() can have a 1 sec fluctuation between calls;
the
value of the first call is now cached so that boot_time() always returns
the
same value if fluctuation is <= 1 second.
- #1013: [FreeBSD] psutil.net_connections() may return incorrect PID.
(patch
by Gleb Smirnoff)
- #1014: [Linux] Process class can mask legitimate ENOENT exceptions as
NoSuchProcess.
- #1016: disk_io_counters() raises RuntimeError on a system with no disks.
- #1017: net_io_counters() raises RuntimeError on a system with no network
cards installed.
- #1021: [Linux] open_files() may erroneously raise NoSuchProcess instead of
skipping a file which gets deleted while open files are retrieved.
- #1029: [OSX, FreeBSD] Process.connections('unix') on Python 3 doesn't
properly handle unicode paths and may raise UnicodeDecodeError.
- #1033: [OSX, FreeBSD] memory leak for net_connections() and
Process.connections() when retrieving UNIX sockets (kind='unix').
- #1040: fixed many unicode related issues such as UnicodeDecodeError on
Python 3 + UNIX and invalid encoded data on Windows.
- #1042: [FreeBSD] psutil won't compile on FreeBSD 12.
- #1044: [OSX] different Process methods incorrectly raise AccessDenied for
zombie processes.
- #1046: [Windows] disk_partitions() on Windows overrides user's
SetErrorMode.
- #1047: [Windows] Process username(): memory leak in case exception is
thrown.
- #1048: [Windows] users()'s host field report an invalid IP address.
- #1050: [Windows] Process.memory_maps memory() leaks memory.
- #1055: cpu_count() is no longer cached; this is useful on systems such as
Linux where CPUs can be disabled at runtime. This also reflects on
Process.cpu_percent() which no longer uses the cache.
- #1058: fixed Python warnings.
- #1062: disk_io_counters() and net_io_counters() raise TypeError if no
disks
or NICs are installed on the system.
- #1063: [NetBSD] net_connections() may list incorrect sockets.
- #1064: [NetBSD] swap_memory() may segfault in case of error.
- #1065: [OpenBSD] Process.cmdline() may raise SystemError.
- #1067: [NetBSD] Process.cmdline() leaks memory if process has terminated.
- #1069: [FreeBSD] Process.cpu_num() may return 255 for certain kernel
processes.
- #1071: [Linux] cpu_freq() may raise IOError on old RedHat distros.
- #1074: [FreeBSD] sensors_battery() raises OSError in case of no battery.
- #1075: [Windows] net_if_addrs(): inet_ntop() return value is not checked.
- #1077: [SunOS] net_if_addrs() shows garbage addresses on SunOS 5.10.
(patch by Oleksii Shevchuk)
- #1077: [SunOS] net_connections() does not work on SunOS 5.10. (patch by
Oleksii Shevchuk)
- #1079: [FreeBSD] net_conne
Re: Run Windows commands from Python console
On Sun, Sep 3, 2017 at 7:56 AM, wrote:
>
> I run Python console in Windows. Can I run cmd prompt commands
> there?
Python doesn't know the first thing about CMD's "batch" language.
Also, Python's shell (i.e. REPL) is not a system administration shell
that implicitly runs external commands. You need to use the subprocess
module for that. For example:
>>> import subprocess
>>> subprocess.call(['icacls.exe', 'SomeFile.ext', '/grant',
'JaneDoe:(F)']).
If you need to run a CMD command, use shell=True with a command-line
string. For example:
>>> subprocess.call('icacls SomeFile.ext /grant %USERNAME%:(F)', shell=True)
FYI, being attached to a console for standard I/O doesn't mean you're
using a "Command Prompt" that can run CMD commands.
python.exe is a character (i.e. text user interface or command-line
interface) application that creates or inherits a console
automatically. You're probably used to running python.exe from cmd.exe
and inheriting CMD's console. But you can also run python.exe directly
from Explorer, in which case it creates its own console. If Python
creates its own console, the window will be destroyed automatically
when Python exits -- unless you create child processes that are also
attached to the console and remain running.
pythonw.exe is graphical or background application, not a character
application, so it doesn't create or inherit a console automatically.
Typically IDLE runs via pythonw.exe, in which case if you want a
console you need to call WinAPI AllocConsole() or AttachConsole().
Once attached to a console, you can open "CON", "CONIN$" , or
"CONOUT$".
> What means line below:
>
> File "", line 1
>
> I don't have any file.
Indeed, on Windows you cannot create a file named "". Python
uses this fake name for the code object it compiles when reading from
stdin (i.e. the file stream opened for console input).
It's not exactly smart about this, either, since whenever an exception
is raised in the REPL it will try to open this fake file multiple
times, including trying every entry in sys.path. For example, in a
typical Python 3.6 all-users installation, it will try opening the
following file paths:
C:\Program Files\Python36\python36.zip\
C:\Program Files\Python36\python36.zip\
C:\Program Files\Python36\DLLs\
C:\Program Files\Python36\lib\
C:\Program Files\Python36\
C:\Program Files\Python36\lib\site-packages\
...
Of course, all of these attempts to open "" necessarily fail on
Windows. On Unix, however, this can actually succeed, which is kind of
funny:
>>> open('', 'w').write('What the !@#$%^&*?')
18
>>> dit
Traceback (most recent call last):
File "", line 1, in
What the !@#$%^&*?
NameError: name 'dit' is not defined
--
https://mail.python.org/mailman/listinfo/python-list
How to get status of Autoplay video from browser
Hi , I have a URL where Video will start playing after launch (autoplay video) eg:https://techcrunch.com/ Another script will pause the video as soon as it detects a Video is playing. Now I need to verif the video is paused successfully or not. HOw to get the status of video? I am using Python Selenium webdriver, please let me know the solution for the same. -- https://mail.python.org/mailman/listinfo/python-list
Re: ANN: psutil 5.3.0 with full unicode support is out
On Sun, Sep 3, 2017 at 9:58 AM, Giampaolo Rodola' wrote: > > - #1040: all strings are encoded by using OS fs encoding. > - #1040: the following Windows APIs on Python 2 now return a string instead > of > unicode: > - Process.memory_maps().path > - WindowsService.bin_path() > - WindowsService.description() > - WindowsService.display_name() > - WindowsService.username() This seems wrong. User names, file paths, registry strings, etc are all Unicode in Windows. One cannot in general encode them as the legacy (as in it really should be avoided) 'mbcs' encoding, i.e. ANSI. Using the 'replace' handler will make a mess with best-fit replacements and question marks. For example, _winreg in Python 2 has to return unicode strings and always has, which should be the precedent for psutil. Python 2 code that supports Windows has to be able to handle this. -- https://mail.python.org/mailman/listinfo/python-list
Re: Case-insensitive string equality
On Sun, 3 Sep 2017 05:17 pm, Stephan Houben wrote: > Generally speaking, the more you learn about case normalization, > the more attractive case sensitivity looks Just because something is hard doesn't mean its not worth doing. And just because you can't please all the people all the time doesn't mean its not worthwhile. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
Op 2017-08-17, Rustom Mody schreef : > On Thursday, August 17, 2017 at 6:49:19 AM UTC+5:30, Mok-Kong Shen wrote: >> Am 17.08.2017 um 02:41 schrieb Steve D'Aprano: >> > By reference and by value are not the only two conventions. >> > >> > Perhaps if you go back to the 1950s you might be able to argue that >> > "reference" and "value" are the only two conventions, but >> > alternatives have existed for many decades, since *at least* 1960 >> > when Algol introduced "call by name". I'm a bit late to this discussion, but pelase allow me to add some (to me at least) fascinating history to this. In 1966, a very influential paper was published: P.J. Landin, "The Next 700 Programming Languages" See: https://www.cs.cmu.edu/~crary/819-f09/Landin66.pdf In this paper, Landin decribes a "family of unimplemented computing languages that is intended to span differences of application area by a unified framework". He calls this language (or family of languages) ISWIM. It is a language with Lisp-like semantics but "Algol-like" (i.e. infix) syntax, dynamically typed, and he introduces the novel idea to have "Indentation, used to indicate program structure." Sounds familiar to anybody? Yep, this is basically proto-Python. Anyway, then there is a later paper (from 1974) by G.D. Plotkin, "Call-by-name, call-by-value and the λ-calculus" (see http://www.sciencedirect.com/science/article/pii/0304397575900171 ). In this paper, Plotkin "examines the old question of the relationship between ISWIM and the λ-calculus, using the distinction between call-by-value and call-by-name." Yep, in 1974, what to call the calling convention of proto-Python was already an "old question". In this paper, Plotkin introduces the λV-calculus, the call-by-value lambda-calculus, to formalize what it is what ISWIM (and Python) are actually doing. This paper is, to the best of my knowledge, the closest thing to an "official" definition of what call-by-value actually means. Needless to say, according to the definition in Plotkin's paper, Python is "call-by-value". Stephan -- https://mail.python.org/mailman/listinfo/python-list
Have do_nothing as default action for dictionary?
Greetings,
I was playing around this piece of example code (written from memory).
def filter_text(key, value):
def do_nothing(text): return text
return {'this': call_this,
'that': call_that,
'what': do_nothing
}[key](value)
Is there a way to refactor the code to have the inner do_nothing
function be the default action for the dictionary?
The original code was a series of if statements. The alternatives
include using a lambda to replace the inner function or a try-except
block on the dictionary to return value on KeyError exception.
What's the most pythonic and fastest?
Thank you,
Chris R.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Case-insensitive string equality
On 9/3/17, Steve D'Aprano wrote: > On Sun, 3 Sep 2017 05:17 pm, Stephan Houben wrote: > >> Generally speaking, the more you learn about case normalization, >> the more attractive case sensitivity looks > > Just because something is hard doesn't mean its not worth doing. > > And just because you can't please all the people all the time doesn't mean > its > not worthwhile. I was thinking about compare where false positivity is acceptable (and well defined property). For example if somebody has case sensitive FS and wants to publish files and avoid name collision on any case insensitive FS then compare with false positive equals could be useful. Then backward compatibility problem could be (theoretically) simplified to enhancing equivalence classes in future. I mean something like -> equal = lambda a, b: any(f(a) == f(b) for f in C)# where C is enhanceble list of compare equals functions Could you think that such equivalence relation could solve problems which you describe in first mail in this thread? And if trying to "solve" unicode problem why not? -> a ≐ b a ⋵ L -- https://mail.python.org/mailman/listinfo/python-list
Re: Have do_nothing as default action for dictionary?
On Mon, Sep 4, 2017 at 5:31 AM, Christopher Reimer via Python-list
wrote:
> Greetings,
>
> I was playing around this piece of example code (written from memory).
>
>
> def filter_text(key, value):
>
> def do_nothing(text): return text
>
> return {'this': call_this,
>
> 'that': call_that,
>
> 'what': do_nothing
>
> }[key](value)
>
>
> Is there a way to refactor the code to have the inner do_nothing function be
> the default action for the dictionary?
Easy: use the .get() method.
return {'this': call_this,
'that': call_that,
}.get(key, do_nothing)(value)
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Have do_nothing as default action for dictionary?
Christopher Reimer via Python-list wrote:
> Greetings,
>
> I was playing around this piece of example code (written from memory).
>
>
> def filter_text(key, value):
>
> def do_nothing(text): return text
>
> return {'this': call_this,
>
> 'that': call_that,
>
> 'what': do_nothing
>
> }[key](value)
>
>
> Is there a way to refactor the code to have the inner do_nothing
> function be the default action for the dictionary?
If it does nothing, why invoke it at all?
LOOKUP = {"this": call_this, ...}
def filter_text(key, value):
> The original code was a series of if statements. The alternatives
> include using a lambda to replace the inner function or a try-except
> block on the dictionary to return value on KeyError exception.
>
> What's the most pythonic and fastest?
>
> Thank you,
>
> Chris R.
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Have do_nothing as default action for dictionary?
Christopher Reimer via Python-list wrote:
> Greetings,
>
> I was playing around this piece of example code (written from memory).
>
>
> def filter_text(key, value):
>
> def do_nothing(text): return text
>
> return {'this': call_this,
>
> 'that': call_that,
>
> 'what': do_nothing
>
> }[key](value)
>
>
> Is there a way to refactor the code to have the inner do_nothing
> function be the default action for the dictionary?
If it does nothing, why invoke it at all?
LOOKUP = {"this": call_this, ...}
def filter_text(key, value):
if key in LOOKUP:
return LOOKUP[key](value)
return value
If there are much more hits than misses:
def filter_text(key, value):
try:
process = return LOOKUP[key]
except KeyError:
return value
return process(value)
If you insist on invoking a noop func:
def do_nothing(text): return text
def filter_text(key, value):
return LOOKUP.get(key, do_nothing)(value)
With a collections.defaultdict (will grow to comprise new keys):
LOOKUP = defaultdict(LOOKUP, lambda: do_nothing)
def filter_key(key, value):
return LOOKUP[key](value)
> The original code was a series of if statements. The alternatives
> include using a lambda to replace the inner function or a try-except
> block on the dictionary to return value on KeyError exception.
>
> What's the most pythonic and fastest?
>
> Thank you,
>
> Chris R.
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Run Windows commands from Python console
On 9/3/2017 11:17 AM, eryk sun wrote:
On Sun, Sep 3, 2017 at 7:56 AM, wrote:
What means line below:
File "", line 1
I don't have any file.
Indeed, on Windows you cannot create a file named "". Python
uses this fake name for the code object it compiles when reading from
stdin (i.e. the file stream opened for console input).
It's not exactly smart about this, either, since whenever an exception
is raised in the REPL it will try to open this fake file multiple
times, including trying every entry in sys.path. For example, in a
typical Python 3.6 all-users installation, it will try opening the
following file paths:
C:\Program Files\Python36\python36.zip\
C:\Program Files\Python36\python36.zip\
C:\Program Files\Python36\DLLs\
C:\Program Files\Python36\lib\
C:\Program Files\Python36\
C:\Program Files\Python36\lib\site-packages\
...
Of course, all of these attempts to open "" necessarily fail on
Windows.
The result, after doing all the above, is tracebacks like
>>> def f():
... return 1/0
...
>>> f()
Traceback (most recent call last):
File "", line 1, in
File "", line 2, in f
ZeroDivisionError: division by zero
with source lines missing. Note that 'line 1' is misleading as the
'f()' call is on line 4. It is the first line of the 2nd statement.
In IDLE, trackbacks *do* include source lines.
>>> def f():
return 1/0
>>> f()
Traceback (most recent call last):
File "", line 1, in
f()
File "", line 2, in f
return 1/0
ZeroDivisionError: division by zero
Each statement is numbered, and treated as a file, so that line
numbering starts at 1 for each statement.
The secret to doing this is that traceback printing looks in
linecache.cache *before* trying to open a file, as described above.
When the file is read, it is added to the cache. IDLE stuffs the lines
for each statement into the cache and replaces linecache.checkcache with
a wrapper that prevents them from being deleted.
On Unix, however, this can actually succeed, which is kind of
funny:
>>> open('', 'w').write('What the !@#$%^&*?')
18
>>> dit
Traceback (most recent call last):
File "", line 1, in
What the !@#$%^&*?
NameError: name 'dit' is not defined
Won't happen with
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
testfixtures 5.2.0 released!
Hi All, I'm pleased to announce the release of testfixtures 5.2.0 featuring the following: * test_datetime and test_time now accept a [1]datetime instance during instantiation to set the initial value. * test_date now accepts a [2]date instance during instantiation to set the initial value. *Relax the restriction on adding, setting or instantiatingtest_datetimewithtzinfosuchthatif the tzinfo matches the one configured, then it's okay to add. This means that you can now instantiate a test_datetime with an existing [3]datetime instance that has tzinfo set. * testfixtures.django.compare_model() now ignores [4]many to many fields rather than blowing up on them. * Drop official support for Python 3.4, although things should continue to work. The package is on PyPI and a full list of all the links to docs, issue trackers and the like can be found here: [5]https://github.com/Simplistix/testfixtures Any questions, please do ask on the Testing in Python list or on the Simplistix open source mailing list... cheers, Chris References Visible links 1. (in Python v2.7) https://docs.python.org/2/library/datetime.html#datetime.datetime 2. (in Python v2.7) https://docs.python.org/2/library/datetime.html#datetime.date 3. (in Python v2.7) https://docs.python.org/2/library/datetime.html#datetime.datetime 4. (in Django v2.0) http://django.readthedocs.io/en/latest/ref/models/fields.html#django.db.models.ManyToManyField 5. https://github.com/Simplistix/testfixtures -- https://mail.python.org/mailman/listinfo/python-list
python multiprocessing question
hello i have create a 4 function using python(f1,f2,f3,f4) and i have 4 cores in my system. def f1() ... ... def f2() ... ... def f3() ... ... def f4() ... ... that functions operate independently of each other but how to use multiprocessing to define the cores to work that functions parallel to win some time ? sorry i am very new and i need some help or some example. -- https://mail.python.org/mailman/listinfo/python-list
Re: Case-insensitive string equality
Stefan Ram wrote: But of course, actually the rules of orthography require "Maße" or "Masse" and do not allow "MASSE" or "MASZE", just as in English, "English" has to be written "English" and not "english" or "ENGLISH". While "english" is wrong in English, there's no rule against using "ENGLISH" as an all-caps version. Are you saying that all-caps text is not allowed in German? If so, that's very different from English. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Case-insensitive string equality
On Mon, 4 Sep 2017 09:10 am, Gregory Ewing wrote: > Stefan Ram wrote: >> But of >> course, actually the rules of orthography require "Maße" or >> "Masse" and do not allow "MASSE" or "MASZE", just as in >> English, "English" has to be written "English" and not >> "english" or "ENGLISH". > > While "english" is wrong in English, there's no rule > against using "ENGLISH" as an all-caps version. It's not always wrong. If you're e.e. cummings, then you're allowed to avoid capitals. (If you're anyone else, you're either a derivative hack, or lazy.) And if you are referring to the spin applied to billiard balls, it is acceptable to write it as english. > Are you saying that all-caps text is not allowed in > German? If so, that's very different from English. Germans use ALLCAPS for headlines, book titles, emphasis etc just as English speakers do. For example: http://www.spiegel.de/politik/index.html -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Mon, 4 Sep 2017 04:15 am, Stephan Houben wrote: > Needless to say, according to the definition in Plotkin's paper, Python > is "call-by-value". According to Plotkin's definition, when you pass a value like a 100MB string: "This is a long string of text..." # continues on for millions more characters does the interpreter make a copy of the 100MB string? If not, then it isn't pass (call) by value. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Mon, Sep 4, 2017 at 12:05 PM, Steve D'Aprano wrote: > On Mon, 4 Sep 2017 04:15 am, Stephan Houben wrote: > >> Needless to say, according to the definition in Plotkin's paper, Python >> is "call-by-value". > > According to Plotkin's definition, when you pass a value like a 100MB string: > > "This is a long string of text..." # continues on for millions more > characters > > does the interpreter make a copy of the 100MB string? > > If not, then it isn't pass (call) by value. This is another proof that you can't divide everything into "pass by value" vs "pass by reference", unless you mess around with "passing a reference by value" or other shenanigans. In C, a string is not an entity; it's simply an array of characters. Arrays are never passed by value; yet everything in C is passed by value. So you pass a pointer... by value. What would you define LISP's semantics as? Pass by value? Pass by reference? Pass by name? Pass by immutability? Pass the salt? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Capital ß [was Re: Case-insensitive string equality]
On Sat, 2 Sep 2017 01:48 pm, Stefan Ram wrote:
> Steve D'Aprano writes:
>>[1] I believe that the German government has now officially recognised the
>>uppercase form of ß.
>
> [skip to the last paragraph for some "ß" content,
> unless you want to read details about German spelling rules.]
>
> The German language is as free as the English one. It does
> not come from a government.
Nevertheless, even in English there are de facto rules about what you can and
cannot use as text for official purposes. In most countries, you cannot change
your name to an unpronounceable "love symbol" as the late Artist Formally Known
As Prince did. You can't fill in your tax using Alienese
http://futurama.wikia.com/wiki/Alienese
or even Vietnamese, Greek or Arabic.
In Australia, the Victorian state government Department of Births Deaths and
Marriages doesn't even accept such unexceptional and minor variants as Zöe for
Zoe. Of course you are free to call yourself Zöe when you sign your emails, but
your birth certificate, passport and drivers licence will show it as Zoe.
> The 16 states (Bundesländer), agreed to a common institution
> ("Der Rat für deutsche Rechtschreibung") to write down the
> rules for their /schools/. The federal government is not
> involved. Most publishing houses volunteered to follow those
> school rules. Outside of schools or binding contracts,
> everyone is free to write as he likes.
I'm not suggesting that the Spelling Police will come arrest me in either
Germany or the UK/Australia if I were to write my name Ƽτευεη. Switzerland on
the other hand ... *wink*
But there are very strong conventions about what is acceptable, and often there
are actual laws in place that limit what letters are used in official
documentation and records, what is taught in schools, etc.
The 1996 spelling reforms, and their legal status, are described here:
https://en.wikipedia.org/wiki/German_orthography_reform_of_1996
and Der Rat für deutsche Rechtschreibung:
https://en.wikipedia.org/wiki/Council_for_German_Orthography
(Sorry for not linking to the German versions as well.)
> The "ß" sometimes has been uppercased to "SS" and sometimes
> to "SZ".
Historically, some German publishers used a distinct uppercase ß, while others
used a ligature of SZ, explicitly stating that this was an interim measure
until they decided on a good looking uppercase ß.
More about capital ß:
https://typography.guru/journal/germanys-new-character/
https://medium.com/@typefacts/the-german-capital-letter-eszett-e0936c1388f8
https://en.wikipedia.org/wiki/Capital_%E1%BA%9E
--
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
--
https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Mon, 4 Sep 2017 12:20 pm, Chris Angelico wrote: > This is another proof that you can't divide everything into "pass by > value" vs "pass by reference", unless you mess around with "passing a > reference by value" or other shenanigans. In C, a string is not an > entity; it's simply an array of characters. Arrays are never passed by > value; yet everything in C is passed by value. So you pass a > pointer... by value. Indeed. And we say that in C, arrays are not first-class entities. We might say that in C, arrays (and strings) are not actually values -- only the pointer to the first slot in the array is a value. The difference[1] between C and Python is that *top level Python code* abstracts away the pointer passing that goes on behind the scenes inside the interpreter. Your Python code treats strings and arrays (lists or tuples or even actual arrays) as first class values, while C does not. If you want a Python function to accept a string as argument, you simply declare the parameter (with or without optional type hint), and pass the string as needed. In C (as far as I understand it, correct me if I'm wrong) you cannot. You must declare the parameter as a *pointer* type, and explicitly pass a pointer to the start of the array, not the array itself. That makes arrays (and strings) in C a bit of an odd corner case, and an exception to the usual rules, like unboxed machine types in Java. We should acknowledge them, but as exceptional cases, and we should note that Python has no similar exceptional cases. All values in Python are first-class, and all are passed in precisely the same way. > What would you define LISP's semantics as? Pass by value? Pass by > reference? Pass by name? Pass by immutability? Pass the salt? My understanding is that LISP has more-or-less the same calling mechanism as Python, only it had it long before Barbara Liskov gave a name to it when describing CLU. [1] What, only one? *wink* -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Monday, September 4, 2017 at 7:50:22 AM UTC+5:30, Chris Angelico wrote: > On Mon, Sep 4, 2017 at 12:05 PM, Steve D'Aprano wrote: > > On Mon, 4 Sep 2017 04:15 am, Stephan Houben wrote: > > > >> Needless to say, according to the definition in Plotkin's paper, Python > >> is "call-by-value". > > > > According to Plotkin's definition, when you pass a value like a 100MB > > string: > > > > "This is a long string of text..." # continues on for millions more > > characters > > > > does the interpreter make a copy of the 100MB string? > > > > If not, then it isn't pass (call) by value. > > This is another proof that you can't divide everything into "pass by > value" vs "pass by reference", unless you mess around with "passing a > reference by value" or other shenanigans. In C, a string is not an > entity; it's simply an array of characters. Arrays are never passed by > value; yet everything in C is passed by value. So you pass a > pointer... by value. > > What would you define LISP's semantics as? Pass by value? Pass by > reference? Pass by name? Pass by immutability? Pass the salt? “Pass the logic" “Oops…” “You slob! You’ve messed my consistency-carpet." Earlier Ben Bacarisse wrote: > The core of the idea is actually what the value-set of Python programs is -- Yes! That!! Parameter-passing models and nomenclature is really a red-herring Its the “== is id” mess that is at the base of the mess: Simply put: pythonistas have no coherent/consistent sense of what python values are. And the endless parameter-passing-nomenclature arguments are just the fallout of that. Maybe that’s what Ben means by?? > the passing by value just drops out of that. -- https://mail.python.org/mailman/listinfo/python-list
Re: meaning of [ ]
On Sunday, September 3, 2017 at 5:10:13 PM UTC+5:30, Rick Johnson wrote:
> Andrej Viktorovich wrote:
> > I suppose p becomes array of strings but what [] means in this statement?
>
> Generally, it's an inline form of writing a loop that returns a list. There
> are other types as well.
Tsk tsk the confusioning continues
Rewrite
[p for p in sys.path]
as
[p | p ∈ sys.path]
Is that clearer?
And then as
{p | p ∈ sys.path}
And refresh the idea of set-builder notation
http://www.mathwords.com/s/set_builder_notation.htm
Note the the clunky ascii-fication of (most) programming languages (including
python)
is a minor distraction
The bigger and more real issue is that sets and lists are similar and different
Sets have no order, lists are ordered
As Peter pointed out this is a no-op
ie
[p for p in sys.path]
could be written as
list(sys.path)
[Not sure why he didnt say just sys.path]
Anyway this is a good example to distinguish
[p for p in sys.path]
from
{p for p in sys.path}
Both work in python
But the second is probably not correct because path-searching is order dependent
--
https://mail.python.org/mailman/listinfo/python-list
Re: ANN: psutil 5.3.0 with full unicode support is out
Hello Eryk,
it is true that the most correct way to represent strings in Python 2 is by
dealing with Unicode but it is also true that the most common scenario in
both the stdlib and most third party libs is to return and deal with str
(bytes) instead, so this is why I decided to do the same in psutil. Other
than _winreg I can't recall other APIs returning Unicode by default unless
explicitly asked (e.g os.getcwdu() or os.listdir(u'.')) and I didn't want
to duplicate psutil APIs in the same fashion.
It must be noted that many stdlib APIs in Python 2 are "broken" when it
comes to Unicode, see:
http://bugs.python.org/issue18695
...so the most convenient and definitive "fix" to correctly handle strings
in Python is switching to Python 3.
With that said, in psutil on Python 2 you are still supposed to be able
retrieve the "correct" string by using the "replace" error handler:
>>> unicode(proc.exe(), sys.getdefaultencoding(), errors="replace")
This is an example which filters processes with a funky name which works
with both Python 2
and 3:
import psutil, sys
PY3 = sys.version_info[0] == 2
LOOKFOR = u"ƒőő.exe"
for proc in psutil.process_iter(attrs=['name']):
name = proc.info['name']
if not PY3:
name = unicode(name, sys.getdefaultencoding(), errors="replace")
if LOOKFOR == name:
print("process %s found" % p)
This is IMO the best compromise for a lib which aims to work on both Python
2 and 3. It's either that or returning Unicode all over the place in Python
2, but that's something I considered and rejected because most of the times
the string is not supposed to have funky characters, so "practicality beats
purity" in this case.
On Sun, Sep 3, 2017 at 11:38 PM, eryk sun wrote:
> On Sun, Sep 3, 2017 at 9:58 AM, Giampaolo Rodola'
> wrote:
> >
> > - #1040: all strings are encoded by using OS fs encoding.
> > - #1040: the following Windows APIs on Python 2 now return a string
> instead
> > of
> > unicode:
> > - Process.memory_maps().path
> > - WindowsService.bin_path()
> > - WindowsService.description()
> > - WindowsService.display_name()
> > - WindowsService.username()
>
> This seems wrong. User names, file paths, registry strings, etc are
> all Unicode in Windows. One cannot in general encode them as the
> legacy (as in it really should be avoided) 'mbcs' encoding, i.e. ANSI.
> Using the 'replace' handler will make a mess with best-fit
> replacements and question marks. For example, _winreg in Python 2 has
> to return unicode strings and always has, which should be the
> precedent for psutil. Python 2 code that supports Windows has to be
> able to handle this.
>
--
Giampaolo - http://grodola.blogspot.com
--
https://mail.python.org/mailman/listinfo/python-list
Re: ANN: psutil 5.3.0 with full unicode support is out
On Sun, Sep 3, 2017 at 11:09 PM, Giampaolo Rodola' wrote:
>
> This is an example which filters processes with a funky name which works
> with both Python 2
> and 3:
>
> import psutil, sys
>
> PY3 = sys.version_info[0] == 2
> LOOKFOR = u"ƒőő.exe"
> for proc in psutil.process_iter(attrs=['name']):
> name = proc.info['name']
> if not PY3:
> name = unicode(name, sys.getdefaultencoding(), errors="replace")
> if LOOKFOR == name:
> print("process %s found" % p)
>
> This is IMO the best compromise for a lib which aims to work on both Python
> 2 and 3. It's either that or returning Unicode all over the place in Python
> 2, but that's something I considered and rejected because most of the times
> the string is not supposed to have funky characters, so "practicality beats
> purity" in this case.
The encoded name for ANSI codepage 1252 is "\x83oo.exe". Python 2's
default encoding is ASCII, so the decoded result is u'\ufffdoo.exe'.
Even if it should be the filesystem encoding ('mbcs'), the result is
u"ƒoo.exe". Neither equals u"ƒőő.exe".
Instead, shouldn't it encode LOOKFOR as "mbcs" with errors="replace"
before comparing it to proc.info['name']?
--
https://mail.python.org/mailman/listinfo/python-list
Re: Case-insensitive string equality
Op 2017-09-02, Pavol Lisy schreef : > But problem is that if somebody like to have stable API it has to be > changed to "do what the Unicode consortium said (at X.Y. )" :/ It is even more exciting. Presumably a reason to have case-insentivity is to be compatible with existing popular case-insentive systems. So here is, for your entertainment, how some of these systems work. * Windows NTFS case-insensitive file system A NTFS file system contains a hidden table $UpCase which maps characters to their upcase variant. Note: 1. This maps characters in the BMP *only*, so NTFS treats characters outside the BMP as case-insensitive. 2. Every character can in turn only be mapped into a single BMP character, so ß -> SS is not possible. 3. The table is in practice dependent on the language of the Windows system which created it (so a Turkish NTFS partition would contain i -> İ), but in theory can contain any allowed mapping: I can create an NTFS filesystem which maps a -> b. 4. Older Windows versions generated tables which were broken for certain languages (NT 3.51/Georgian). You may still have some NTFS partition with such a table lying around. * macOS case-insensitive file system 1. HFS+ is based on Unicode 3.2; this is fixed in stone because of backward compatibility. 2. APFS is based on Unicode 9.0 and does normalization as well Generally speaking, the more you learn about case normalization, the more attractive case sensitivity looks ;-) Also slim hope to have a single caseInsensitiveCompare function which "Does The Right Thing"™. Stephan -- https://mail.python.org/mailman/listinfo/python-list
Re: tkinter keypress events are a mess for numpad keys
Op 2017-08-29, Irmen de Jong schreef : > I'll have a look at https://www.tcl.tk/man/tcl8.6/TkCmd/keysyms.htm > but I don't have high hopes because I already tried empirically to > figure out the distinguishing attributes of the keypress event object, > on various platforms (Mac OS, Linux, Windows)... I would suggest trying to reproduce the issue in a small Tcl/Tk script. If the issue can be reproduced in Tcl I would suggest filing a bug report at https://core.tcl.tk/tk/reportlist . Stephan -- https://mail.python.org/mailman/listinfo/python-list
meaning of [ ]
Hello, Trying to understand command: [p for p in sys.path] It prints array of paths. I suppose p becomes array of strings but what [] means in this statement? -- https://mail.python.org/mailman/listinfo/python-list
Re: meaning of [ ]
Andrej Viktorovich wrote: > Hello, > > Trying to understand command: > [p for p in sys.path] > > It prints array of paths. I suppose p becomes array of strings but what [] > means in this statement? This is called "list comprehension", and paths = [p for p in sys.path if "foo" in p] is roughly equivalent to paths = [] for p in sys.path: if "foo" in p: paths.append(p) Your original example > [p for p in sys.path] just copies the items from sys.path into a new list. This is usually done with the more concise list(sys.path) -- https://mail.python.org/mailman/listinfo/python-list
Re: tkinter keypress events are a mess for numpad keys
Irmen de Jong wrote:
> Using tkinter in python3, I was trying to intercept
> individual keypresses (and releases) of keys on the numeric
> keypad. I want to use this as a simple joystick simulation.
> While you can bind the event, actually doing
> something sensible with it in a cross platform way seems
> utterly impossible.
Personally, none of my applications have needed to
differentiate between the "number-keys-on-the-keypad" and
the "number-keys-on-the-main-keyboard", so i'm not sure if
there is a clean solution here, much less a clean cross-
platform solution...
And although my initial reaction to your inquiry (assuming
there is no clean solution here...) was to lay blame on
tkinter for not observing its own cross-platform mandate,
the more i think about this, the more i wonder if tkinter
_should_ differentiate between these duplicate number keys?
Hmm...
Considering that (at a very high level) the sole purpose of
a keyboard is to send character information to a machine by
mapping keypresses to characters -- and not so much
concerning itself with key locations or duplicate keys -- i
think what you are doing is expecting a keyboard to function
in a manner for which it was not intented to function, and
while i'm a big fan of multi-purpose tools, i understand
also the practical importance of simplistic, single-purpose
design.
What are your thoughts on this?
> The distinguishing attribute of the event object is
> different depending on what OS you're using (keysym,
> keycode, keysym_num) and on Windows registering some keys
> doesn't even seem to work (or they're confused with the
> same keys on the normal keyboard area). The keysym
> names/values in the documentation are not correct either
Barring a clean cross-platform solution, i would suggest
one of the following:
(1) Appeal to the Tcl/Tk folks to standardize these "event
codes". After all, _they_ are the ones who market TK as a
cross platform GUI.
or
(2) Create your own mapping that can translate the keycodes,
keysyms, or keysym_nums to something consistent between the
platforms.
I have a feeling that #2 will be more efficient.
The good new is, that if the number keys (0-9) are your only
concern, then we're only talking about ten keys over three
major platforms here -- so (10 x 3 = 30) mappings --
shouldn't be too difficult. Of course, with solution #2 your
code will be at the mercy of future changes that are beyond
your control (aka: brittle), however, i doubt these codes
would change very much over time, if at all. A simple
template might look something like this:
evtMap = {...}
w.bind("", _evtKeyPress)
def _evtTrans(event):
...
def _evtKeyPress(event):
_evtTrans(event)
# Process event here...
Sucks to do this, but sometimes you have no choice.
PS: If i had nickle for every time i had to take a big
hammer and pound dents out of tkinter's hull to achieve a
more elegant work flow, well, you know the story. Tkinter
may be a rusty old tub, but she gets the job done if you're
willing to periodically scrape the barnacles from her belly,
patch the holes and apply a new coat of lead paint. As any
old salt will testify, she's a labour of love.
--
https://mail.python.org/mailman/listinfo/python-list
Re: meaning of [ ]
Andrej Viktorovich wrote: > I suppose p becomes array of strings but what [] means in this statement? Generally, it's an inline form of writing a loop that returns a list. There are other types as well. https://docs.python.org/3/tutorial/datastructures.html#list-comprehensions -- https://mail.python.org/mailman/listinfo/python-list
Re: Python... feeding an instance as an argument into a new instance.
On Saturday, September 2, 2017 at 6:34:59 PM UTC-4, Chris Roberts wrote: > Perhaps someone here could help me to get this into perspective. > Somehow when we start to feed an instance as the argument in a new instance. > my head explodes.. > in this case... > a = Foo() > b = Bar(a) > So... > a is a 'Foo instance' with properties and methods. > b is a 'Bar instance' > Since b is using the "a" instance as an argument?? > b=Bar(a) has what?? > > Is there an easier way to put into perspective how an instance of one class > is used as the argument into the instance of another class? > > Code below: > > class Foo(object): > bar = "Bar" # Class attribute. > > def __init__(self): > ##^ The first variable is the class instance in methods. > ## This is called "self" by convention, but could be any > name you want. > # ^ double underscore (dunder) methods are usually special. This one > # gets called immediately after a new instance is created. > > self.variable = "Foo" # instance attribute. > print self.variable, self.bar # <---self.bar references class > attribute > self.bar = " Bar is now Baz" # <---self.bar is now an instance > attribute > print self.variable, self.bar #variable will be a property of "a" and > self is the bound variable of a. > > def method(self, arg1, arg2): > # This method has arguments. You would call it like this: > instance.method(1, 2) > print "in method (args):", arg1, arg2 > print "in method (attributes):", self.variable, self.bar > > > a = Foo() # this calls __init__ (indirectly), output: > #a is Foo, a has a method called method, and properties such as "variable and > bar". > # Foo bar > # Foo Bar is now Baz > print a.variable # Foo > a.variable = "bar" > a.method(1, 2) # output: > # in method (args): 1 2 > # in method (attributes): bar Bar is now Baz > Foo.method(a, 1, >2) # <--- Same as a.method(1, 2). This makes it a little more > explicit what the argument "self" actually is. > print "##Above is all the a Foo object, and below is the b Bar object" > > class Bar(object): > def __init__(self, arg): > self.arg = arg > self.Foo = Foo() #this calls and runs the Foo class again. > > > b = Bar(a) #b is a Bar object, a is a Foo object with properties and > methods. then Bar() calls the Foo class again. > b.arg.variable = "something" > print a.variable # something !(I don't know why "a" prints "something" here.) > print b.Foo.variable # Foo > > > OUTPUT: > Foo Bar > Foo Bar is now Baz > Foo > in method (args): 1 2 > in method (attributes): bar Bar is now Baz > in method (args): 1 2 > in method (attributes): bar Bar is now Baz > ##Above is all the a Foo object, and below is the b Bar object > Foo Bar > Foo Bar is now Baz > something > Foo > > Thanks in advance... crzzy1 ... Steve and Irv, I see what you mean... I picked up on this example online and then tried to work it out on my own, but after seeing your replies, and looking further into cars examples I found how much more intuitive that makes it... Anyways, now I know where to better redirect my studies and energies. My work is sending me to a semi advanced (Core Python) class, and I am not ready, so trying to work on all my weak spots. Thanks -- https://mail.python.org/mailman/listinfo/python-list
Re: Case-insensitive string equality
On Sun, Sep 3, 2017 at 5:17 PM, Stephan Houben wrote: > Generally speaking, the more you learn about case normalization, > the more attractive case sensitivity looks ;-) Absolutely agreed. My general recommendation is to have two vastly different concepts: "equality matching" and "searching". Equality is case sensitive and strict; NFC/NFD normalization is about all you can do. Searching, on the other hand, can be case insensitive, do NFKC/NFKD normalization, and can even (in many contexts) strip off diacritical marks altogether, allowing people to search for "resume" and find "résumé", or to search for "muller" and find "Müller". There can be a whole swathe of other transformations done in search normalization too (collapse whitespace, fold punctuation into a few types, etc), though of course you need to be aware of context. But IMO it's far safer to NOT define things in terms of "equality". ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python... feeding an instance as an argument into a new instance.
On Saturday, September 2, 2017 at 7:45:14 PM UTC-5, Steve D'Aprano wrote: > On Sun, 3 Sep 2017 08:34 am, Chris Roberts wrote: > > > Perhaps someone here could help me to get this into > > perspective. Somehow when we start to feed an instance as > > the argument in a new instance. my head explodes.. in this > > case... > > > > a = Foo() > > b = Bar(a) > > > > So... a is a 'Foo instance' with properties and methods. b > > is a 'Bar instance' Since b is using the "a" instance as > > an argument?? b=Bar(a) has what?? > > It has attributes and methods, same as any other instance > of any other class. I think you are overthinking it. Or > perhaps underthinking it. In either case, using generic > nonsense classes like Foo and Bar adds no understanding. Yes. Even for seasoned programmers, generic names can obfuscate the overall model. And such names have no business in beginner, or even intermediate, coarses. > Suppose you build an Engine class: > > class Engine: > def __init__(self, fuel, capacity): > self.sparkplugs = [SparkPlug() for i in range(4)] Steven, why am i _not_ surprised that you drive a four-banger? ;-) > ... > def start(self): > ... > def stop(self): > ... > > So Engines have methods, and attributes such as capacity, > the kind of fuel they run on (petrol/gasoline, diesel or > LPG), etc. Some attributes (such as the sparkplugs) are > themselves instances of another class. Now we build a car > out of other objects: > > class Car: > def __init__(self, colour, engine, chassis, seats, dashboard, wheels, > brakes, parkingbrake, airbags, entertainment_system): > self.colour = colour > self.body = chassis.add_panels() > self.engine = engine > ... > def drive(self): This should be named "forward", as: (1) such a name meshes semantically against the "reverse" method, and (2) such a name clearly defines an intuitive vector path that is consistent with the car's three dimensional orientation, _orientation_ which is constrained by the mechanical capabilities of the car, and _mechanical_capabilities_, which are further constrained by the laws of physics. "Drive" is just too ambiguous. > ... > def reverse(self): > ... > def engage_parking_brake(self): > ... > > So Cars have methods, and attributes such as colour, > engine, brakes, airbags, etc. Some of those attributes are > themselves made of instances of another class. In fact > even "primitive" values such as ints, floats, lists, > strings, tuples, boolean flags etc are objects in Python. > In Python, it is objects all the way down: all values are > objects. Overall though, a very good introductory example of OOP. Good work Steven! We're going to make an OOP fan out of you yet, and given enough time, heck, you may even begin to appreciate the purity of Java. ;-) -- https://mail.python.org/mailman/listinfo/python-list
