Re: MacOSX SpeechRecognition installation problems
I would suggest using virtual environment (virtualenv, for example) for installing such packages. Dealing with directory permissions on MacOS is complicated, and using "sudo" is not the right way. Moreover, during the next OS upgrade the permissions will be updated as well, and chances are that your global package configuration breaks anyways. Regards, Anton >> On 8 Dec 2016, at 09:18, Michael Torrie wrote: >> >> On 12/07/2016 11:09 PM, 3dB wrote: >> trying to install SpeechRecognition for Python results in error: >> >> running install_lib >> creating /Library/Python/2.7/site-packages/speech_recognition >> error: could not create >> '/Library/Python/2.7/site-packages/speech_recognition': Permission denied >> >> >> Any advice on how to fix? > > Are you using sudo? > >> >> Follow information may be helpful: >> >> MacOSX 10.12.1 >> Python 2.7.10 (default, Jul 30 2016, 18:31:42) >> [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin >> >> /usr/local/bin/brew >> /usr/bin/python >> >> pip 9.0.1 from /Library/Python/2.7/site-packages/pip-9.0.1-py2.7.egg (python >> 2.7) > > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Get min and max dates
DFS wrote:
>dts= ['10-Mar-1998',
> '20-Aug-1997',
> '06-Sep-2009',
> '23-Jan-2010',
> '12-Feb-2010',
> '05-Nov-2010',
> '03-Sep-2009',
> '07-Nov-2014',
> '08-Mar-2013']
>Of course, the naive:
>min(dates) = '03-Sep-2009'
>max(dates) = '23-Jan-2010'
>is wrong.
>Not wanting to use any date parsing libraries, I came up with:
>
>m=[('Dec','12'),('Nov','11'),('Oct','10'),('Sep','09'),
> ('Aug','08'),('Jul','07'),('Jun','06'),('May','05'),
> ('Apr','04'),('Mar','03'),('Feb','02'),('Jan','01')]
>#create new list with properly sortable date (MMDD)
>dts2 = []
>for d in dts:
> dts2.append((d[-4:]+dict(m)[d[3:6]]+d[:2],d))
>print 'min: ' + min(dts2)[1]
>print 'max: ' + max(dts2)[1]
>
>$python getminmax.py
>min: 20-Aug-1997
>max: 07-Nov-2014
>which is correct, but I sense a more pythonic way, or a one-liner list
>comprehension, is in there somewhere.
I'd use strptime from the time module.
Then you could write
dts2.append(strptime(d,'%d-%b-%Y)
min and max return a struct_time type that can easily converted to
the original date format
--
Dipl.-Inform(FH) Peter Heitzer, [email protected]
--
https://mail.python.org/mailman/listinfo/python-list
Snakify - free introductory Python online course with exercises
Hi fellow Pythonistas, Let me show you my project - an introductory Python online course: https://snakify.org/ . Our key features are 100+ exercises with deep mathematical approach and a neat website to solve them online using a step-by-step debugger. We already have thousands of happy users each month in Russia, including 30 high schools and 7 universities, and we started being used in some UK and US schools. Please, share this link to anyone who starts learning Python. Thanks, Vitaly Pavlenko cxielamiko @gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On 08/12/2016 07:24, Gregory Ewing wrote:
BartC wrote:
(I'm in the middle of porting my console editor to Linux. But one
problem is that on one Linux, half the key combinations (eg.
Shift+Ctrl+B) are not recognised.
If you're reading characters from a tty device in raw
mode (which I assume is what you mean by "console editor")
I'm not aware of *any* Unix system that will let you
distinguish between Ctrl+B and Shift+Ctrl+B that way.
That's because the tty driver delivers ASCII characters,
and there are no separate ASCII codes for shifted control
characters.
Run the code below and start pressing keys. On both of my Linuxes, I get
escape sequences shown when I Insert, Delete, Home, End, Page Up, Page
Down, Up, Down, Left, Right and most of the function keys; not just
single ASCII codes.
But I also get different sequences, on Ubuntu, when I press Shift, Ctrl
or Alt with those keys, but not all shifts nor combinations will work
(some have special meanings anyway).
Then I try the same on Debian (I think it is) on a Raspberry Pi, and
most Shift and Ctrl are ignored, except for Ctrl A to Z (with a few gaps).
(Neither will see Shift+Ctrl+B, which means go to start of the file,
same as Ctrl+Home. Ubuntu sees Ctrl+Home, but not Debian, although it
will report Alt+Home. And some laptop keyboards already have Home on an
Alternate-Function shift! It's a mess.)
Except that was only two Linuxes; perhaps on others, the keyboard will
likely be crippled in some other way.
No, they'll all be the same -- if it has an ASCII code,
you'll be able to get it from a tty device, otherwise you
won't.
How people manage to do anything on such an OS I've no idea.
Programs that need to be able to distinguish all of the
modifiers are normally implemented as GUI applications,
which get keyboard input a different way.
How do they work; what magic do they use to get that key information,
and why can't it be done outside of a GUI? As I understand a Linux GUI
is built on top of Linux.
--
# Python 2 because of the 'print' handling
def getch(): # adapted from first getch I saw on the internet
import sys, tty, termios
fd = sys.stdin.fileno()
old_settings = termios.tcgetattr(fd)
tty.setraw(sys.stdin.fileno())
ch = sys.stdin.read(1)
termios.tcsetattr(fd, termios.TCSADRAIN, old_settings)
return ord(ch)
print "Press keys"
print ("Hit Escape twice to quit")
escape=0
while 1:
k=getch()
if k==27:
print
print "Esc ",
if escape: break
elif k==13:
print "Enter"
elif k==10:
print "Newline"
elif k<=26:
print "Ctrl",chr(k+64)
else:
print chr(k),
escape = k==27
--
(On another test, using a C-based getch(), pressing Enter returns code
10 not 13; another difference to note. Either code appears to clash with
Ctrl-M or Ctrl-J, a difference from Windows where Ctrl-J, Ctrl-M and
Enter are distinct keys, as they are in actuality.)
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
BartC wrote: Run the code below and start pressing keys. On both of my Linuxes, I get escape sequences shown when I Insert, Delete, Home, End, Page Up, Page Down, Up, Down, Left, Right and most of the function keys; not just single ASCII codes. That's probably because your terminal window is emulating some model of glass teletype and sending the same sequence of characters that a real terminal of that kind would send in response to those keys. You'll likely get different sequences depending on what terminal is being emulated. How do they work; what magic do they use to get that key information, and why can't it be done outside of a GUI? It doesn't have to be done in a GUI, but you'd have to deal with whatever raw keyboard input device the GUIs are built on. I'm not familiar with the details on Linux. Look into /dev/input if you're curious. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Name resolution and the (wrong?) LEGB rule
Sometimes the Python name resolution is explained using a LEGB rule. For instance, in [1] (I think also the Learning Python book gives the same): "if a particular name:object mapping cannot be found in the local namespaces, the namespaces of the enclosed scope are being searched next. If the search in the enclosed scope is unsuccessful, too, Python moves on to the global namespace, and eventually, it will search the built-in namespace (side note: if a name cannot found in any of the namespaces, a NameError will is raised)." AFAIK, Python has static scoping: the scope for a name is given during the bytecode compilation. This means that before executing the program, Python already know in which namespace to look for an object. So, it seems to me that the LEGB rule is wrong, and this is what actually happens: * local name (LOAD_FAST instruction): Python looks (only) in the local namespace, and if it does not find the name, then it raises an UnboundLocalError * global name (LOAD_GLOBAL): at first Python looks in the globals(), and in case the name is not there, it looks in the builtins namespace; if the name is neither in the global nor in the builtin namespace, it raises a NameError * enclosing scope (LOAD_DEREF): there is a closure, and Python looks for the name in the enclosing namespace Is that right, or am I missing something? Thanks, Marco [1] http://sebastianraschka.com/Articles/2014_python_scope_and_namespaces.html -- Marco Buttu INAF-Osservatorio Astronomico di Cagliari Via della Scienza n. 5, 09047 Selargius (CA) Phone: 070 711 80 217 Email: [email protected] -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On Thu, Dec 8, 2016, at 01:20, Gregory Ewing wrote: > BartC wrote: > > And globbing doesn't take care of all of it: a Linux program still has > > to iterate over a loop of filenames. The same as on Windows, except the > > latter will need to call a function to deliver the next filename. > > Actually, most of them will require *two* loops, one to > iterate over a sequence of filespecs, and another for > the files matching each filespec. Speaking of which, I think I've advocated before for fileinput to perform these loops, and for some mechanism for argparse to do it, etc... seems like it's about that time again. There are other issues, like needing a way to do Windows' version of wildcard parsing with all its quirks, or at least some of its quirks - "*.*" for all files and "*." for files not containing any dot being the most commonly used in the real world. > Whereas the unix program only requires one loop. -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On Wed, Dec 7, 2016, at 00:15, Steven D'Aprano wrote:
> and the shell expands the metacharacters ? {...} * [...] regardless of
> how much
> smarts the command itself has.
>
> There are thousands of programs I might use, and they may implement who
> knows
> how many different globbing rules:
>
> - some might support * and ? but not {...}
Just to point out, brace expansion isn't globbing. The most important
difference is that brace expansion doesn't care what files exist. {a,b}c
becomes "ac bc" regardless of if the files exist. {a,b}* becomes a* b*,
and if no files match one or both of these, it does whatever the shell
does in such cases.
This is why you can do commands like "mv
fix_a_ty{op,po}_in_this_filename"
--
https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On Wed, Dec 7, 2016, at 03:50, Peter Otten wrote: > Is there an equivalent to > > # touch -- -r > > on Windows? Doesn't need one - options conventionally start with /, and filenames can't contain /. -- https://mail.python.org/mailman/listinfo/python-list
Re: Get min and max dates
Am Donnerstag, 8. Dezember 2016 14:47:31 UTC+1 schrieb DFS: > On 12/8/2016 12:16 AM, Steven D'Aprano wrote: > > On Thursday 08 December 2016 03:15, DFS wrote: > > > >> dts= ['10-Mar-1998', > >> '20-Aug-1997', > >> '06-Sep-2009', > >> '23-Jan-2010', > >> '12-Feb-2010', > >> '05-Nov-2010', > >> '03-Sep-2009', > >> '07-Nov-2014', > >> '08-Mar-2013'] > >> > >> Of course, the naive: > >> min(dates) = '03-Sep-2009' > >> max(dates) = '23-Jan-2010' > >> is wrong. > >> > >> Not wanting to use any date parsing libraries, I came up with: > > > > > > That's where you have gone wrong. By not using a date parsing library which > > works and has been tested, you have to write your own dodgy and possibly > > buggy > > parsing routine yourself. > > > > Why reinvent the wheel? > > > Because the "wheel" is a pain in the ass. > Why? And why do you use this wording? > -- > import time > dts=['10-Mar-1908','20-Aug-1937','06-Sep-1969','23-Jan-1952'] > def date_to_seconds(string): > return time.mktime(time.strptime(string, '%d-%b-%Y')) > print min(dts, key=date_to_seconds) > -- > > OverflowError: mktime argument out of range > > (snip) > > I like that flexibility, but mktime is apparently useless for dates > prior to 'the epoch'. With a little more experience in Python programming you should have discovered that time.mktime is not even required to do your calculations. Please remove time.mktime from the function date_to_seconds and rename the function to date_to_timestruct. -- Paolo -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On 2016-12-08, Random832 wrote: > On Wed, Dec 7, 2016, at 03:50, Peter Otten wrote: >> Is there an equivalent to >> >> # touch -- -r >> >> on Windows? > > Doesn't need one - options conventionally start with /, and filenames > can't contain /. But _paths_ can, and Windows command-line apps and shells choke on paths when written with "/" separators because way-back when the MS-DOS "designers" decided to use "/" as the default option character. So, to avoid _that_ problem, Windows command line apps and the cmd.exe shell only allow "\" as a path separator. Back in the day, you could change the DOS option character to "-", and then type paths they way God intended: with "/" as the separator. -- Grant Edwards grant.b.edwardsYow! I want another at RE-WRITE on my CEASAR gmail.comSALAD!! -- https://mail.python.org/mailman/listinfo/python-list
Linux terminals vs Windows consoles - was Re: python 2.7.12 on Linux behaving differently than on Windows
On 12/08/2016 05:43 AM, BartC wrote:
> (Neither will see Shift+Ctrl+B, which means go to start of the file,
> same as Ctrl+Home. Ubuntu sees Ctrl+Home, but not Debian, although it
> will report Alt+Home. And some laptop keyboards already have Home on an
> Alternate-Function shift! It's a mess.)
Yes terminal-emulators on Linux are very different than consoles on
Windows because of a ton of historical baggage. Unlike a Windows
console, ttys on Unix are designed to connect to serial lines that are
essentially 2-way data pipes. Thus all keyboard handling has to be
wrapped up in escape codes that travel along with the screen data down
those pipes.
Now you may consider this an obsolete model. But the abstraction is
still particularly useful in the linux world as I can connect my
terminal emulator to a variety of mechanisms including remote ssh
connections, plain old telnet, actual serial lines, etc. You may not
find that useful, but like I've said in this thread, I use this
functionality every day. In Windows I would instead use a dedicated
program like Putty to access these various communication streams and
interpret them.
The reason you are seeing such different codes is because there are
different schemes for terminals. Back in the day we dealt with real
terminals. A little CRT with a keyboard and a serial link. The
terminal would interpret various codes coming in the serial link and do
things like move the cursor, underline, bold, inverse, etc. Different
companies developed their own competing terminals that had some feature
they thought people would like. So we had vt100, vt200, Sun, Dec, ANSI,
and other terminal types. Some terminals could even interpret escape
codes and draw vector graphics on the CRT. Unix had to support them all
because people used all kinds of different terminals even in the same
environment.
Now we mostly just use one terminal type, "xterm." But you can still
find variations as you've found. But if you have the correct TERM
environment variable set (it usually is), you can and should use a
terminal library to decode and encode your escape sequences.
>
>>> Except that was only two Linuxes; perhaps on others, the keyboard will
>>> likely be crippled in some other way.
>>
>> No, they'll all be the same -- if it has an ASCII code,
>> you'll be able to get it from a tty device, otherwise you
>> won't.
>>
>
>>> How people manage to do anything on such an OS I've no idea.
The best way to handle terminals is to use a terminal library that
understands many different terminal types (encodings). For example,
instead of getting a raw keyboard ascii code that could vary from
terminal emulation to terminal emulation, use ncurses to process the
keystrokes and give you some kind of normalized sequence.
Alternatively pick one terminal type and require all your users to use
that type of terminal.
But just know that all terminal types share some limitations with
regards to the modifier keys. Some you just can't get via the terminal
interface.
> How do they work; what magic do they use to get that key information,
> and why can't it be done outside of a GUI? As I understand a Linux GUI
> is built on top of Linux.
X windows came much later than terminals and they built a more robust
protocol that allows client programs to access full keyboard state
information.
Applications running on a terminal don't have this information solely
because there's never been a facility for encoding this information into
escape codes. There's no other great technical reason for this
limitation. It's entirely possible that we could create a new,
non-standard terminal type that supported the shift modifier.
> # Python 2 because of the 'print' handling
>
> def getch(): # adapted from first getch I saw on the internet
> import sys, tty, termios
> fd = sys.stdin.fileno()
> old_settings = termios.tcgetattr(fd)
> tty.setraw(sys.stdin.fileno())
> ch = sys.stdin.read(1)
> termios.tcsetattr(fd, termios.TCSADRAIN, old_settings)
> return ord(ch)
>
> print "Press keys"
> print ("Hit Escape twice to quit")
>
> escape=0
> while 1:
> k=getch()
>
> if k==27:
> print
> print "Esc ",
> if escape: break
> elif k==13:
> print "Enter"
> elif k==10:
> print "Newline"
> elif k<=26:
> print "Ctrl",chr(k+64)
> else:
> print chr(k),
>
> escape = k==27
>
> --
Raw terminal handling is indeed crufty! That's why I prefer to use
ncurses when I need anything more basic than standard in and standard out.
> (On another test, using a C-based getch(), pressing Enter returns code
> 10 not 13; another difference to note. Either code appears to clash with
> Ctrl-M or Ctrl-J, a difference from Windows where Ctrl-J, Ctrl-M and
> Enter are distinct keys, as they are in actuality.)
Interesting. I wouldn't have thought ENTER would return a
Re: calling a program from Python batch file
On Wednesday, 7 December 2016 18:23:23 UTC, Michael Torrie wrote: > Does Pexpect work on Windows? Apparently yes: https://pexpect.readthedocs.io/en/stable/overview.html#pexpect-on-windows "New in version 4.0: Windows support" > In the OP's case it looks like the standard in pipe is sufficient. Agreed. Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On Wed, Dec 7, 2016, at 15:29, Lew Pitcher wrote: > But, point of fact is that the feature to disable globbing is not often > needed. Most Unix programs that accept filenames are happy to accept a > list of filenames. There is not much call for a program to perform it's own > globbing, like is required in Windows. > > In fact, I can only think of three Unix "commandline" programs that need > shell globbing disabled: > find - which performs it's own filename matching > grep - which uses regular expressions to search the contents of files, > and > sed - which uses regular expressions to edit the contents of files. > (I'm sure that there are a few more examples, though). tar can do its own filename matching in some contexts, to match files inside the archive for example. 7z does its own filename matching to allow distinguishing "extract from multiple archives" [x \*.zip] from "extract a list of filenames from a single archive" [x a.zip b.zip] - a BartC-compliant command line paradigm if I ever saw one. I suspect it also allows you to match files inside the archives in the list part. scp lets you pass glob patterns to be matched on the remote server. also, quoting for scp is somewhat unpleasant, since metacharacters in general, not just globs but also $variables, quotes,`commands` etc, are interpreted by both the local shell and the remote shell. sftp is a little more sane, but still has remote globs for fetching, and quotes to escape those globs. -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On Wed, Dec 7, 2016, at 22:41, Steven D'Aprano wrote: > Python's fnmatch lib is a good example. It has, or at least had, no > support for escaping metacharacters. Anyone relying on Python's fnmatch and > glob > modules alone for globbing will be unable to handle legitimate file names. That's not true. You can "escape" metacharacters by enclosing them in square brackets, forming a character class of a single character. I've done the same in SQL, so it occurred to me immediately. But of course you have to know you have to do this, and it's not immediately obvious that it will work for the square bracket characters themselves. Other implementations of globbing (including native windows) don't do this and don't even *have* square brackets as metacharacters. -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On Thursday December 8 2016 11:48, in comp.lang.python, "Random832" wrote: > On Wed, Dec 7, 2016, at 15:29, Lew Pitcher wrote: >> But, point of fact is that the feature to disable globbing is not often >> needed. Most Unix programs that accept filenames are happy to accept a >> list of filenames. There is not much call for a program to perform it's own >> globbing, like is required in Windows. >> >> In fact, I can only think of three Unix "commandline" programs that need >> shell globbing disabled: >> find - which performs it's own filename matching >> grep - which uses regular expressions to search the contents of files, >> and >> sed - which uses regular expressions to edit the contents of files. >> (I'm sure that there are a few more examples, though). > > tar can do its own filename matching in some contexts, to match files > inside the archive for example. > > 7z does its own filename matching to allow distinguishing "extract from > multiple archives" [x \*.zip] from "extract a list of filenames from a > single archive" [x a.zip b.zip] - a BartC-compliant command line > paradigm if I ever saw one. I suspect it also allows you to match files > inside the archives in the list part. > > scp lets you pass glob patterns to be matched on the remote server. > also, quoting for scp is somewhat unpleasant, since metacharacters in > general, not just globs but also $variables, quotes,`commands` etc, are > interpreted by both the local shell and the remote shell. sftp is a > little more sane, but still has remote globs for fetching, and quotes to > escape those globs. True. I had forgotten those. Still, it's a short list of programs that either need to do their own globbing, or need the shell to NOT glob for them. -- Lew Pitcher "In Skills, We Trust" PGP public key available upon request -- https://mail.python.org/mailman/listinfo/python-list
Re: Linux terminals vs Windows consoles - was Re: python 2.7.12 on Linux behaving differently than on Windows
On 12/08/2016 09:35 AM, Michael Torrie wrote: > Yes Control codes are, well control codes. Any ascii value under 32. > They are more or less common across terminal types. I don't know of any > way around that with terminals. That is to say that on all terminal types that I'm aware of, the ENTER key is encoded as Control-M, or 13. Since they are the same key, there's no way in any terminal to differentiate between pressing control-M and the enter key. I guess this limitation has been with us so long that people did other things. In unix terminal apps, often the meta key is used as a modifier. This is usually the "Alt" key. If you need to differentiate between ENTER and control-M specifically, you'll have to build a GUI app instead. One that won't be able to run remotely over a tty stream. I know you want your apps to be exactly the same across platforms, but that's not always possible, nor always desirable. For example, on Macs, control-key is not normally used, but rather the Command-key (the apple key) which happens to be where the Alt key is on our PC keyboards. -- https://mail.python.org/mailman/listinfo/python-list
Re: Linux terminals vs Windows consoles - was Re: python 2.7.12 on Linux behaving differently than on Windows
On 2016-12-08, Michael Torrie wrote: > Now we mostly just use one terminal type, "xterm." Or various other terminal emulators tha are mostly ANSI and Unicode aware... And the Linux console... It's interesting to note that the "real" xterm terminal emulator will still emulate a Tektronix storage-scope graphics terminal (a terminal that actually _implemented_ vector drawing rather than emulating it with a raster-scanned array of pixels). But, I know of plenty of people that still use real serial terminals connected via serial ports. Until very recently, one of my customers had a group of techs that bought used Wyse 50 (green monochrome CRT) serial terminals off e-bay, Craigsist, or wherever and refurbished them in-house so that they could be sent out to the field for installation (as retail POS terminals). Last time I heard, they were goint to switch to flat-screen "thin-clients". I got a chance to play with one of those, and it was an industrial Single-board-PC and LCD monitor built into a single unit running Windows. It was configured to boot up and run a Wyse-50 terminal emulator -- and connect to the "real" computer via an RS-232C serial port. :) -- Grant Edwards grant.b.edwardsYow! There's enough money at here to buy 5000 cans of gmail.comNoodle-Roni! -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On Thu, Dec 8, 2016 at 4:34 PM, Grant Edwards wrote: > > So, to avoid _that_ problem, Windows command line apps and the cmd.exe > shell only allow "\" as a path separator. In cmd you can usually clarify the intent with quotes, e.g. `dir C:/Windows` fails because it parses "Windows" as a parameter, but `dir "C:/Windows"` succeeds. -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On 2016-12-08, eryk sun wrote: > On Thu, Dec 8, 2016 at 4:34 PM, Grant Edwards > wrote: >> >> So, to avoid _that_ problem, Windows command line apps and the cmd.exe >> shell only allow "\" as a path separator. > > In cmd you can usually clarify the intent with quotes, e.g. `dir > C:/Windows` fails because it parses "Windows" as a parameter, but `dir > "C:/Windows"` succeeds. That works to get the "/" past cmd.exe's parser and with seems to work with cmd.exe's built-in commands, but programs that aren't internal to cmd.exe become an issue. -- Grant Edwards grant.b.edwardsYow! Here I am in 53 at B.C. and all I want is a gmail.comdill pickle!! -- https://mail.python.org/mailman/listinfo/python-list
Re: PonyORM: generators as a query syntax
On 12/08/2016 07:26 AM, Alex Kaye wrote: > Can you describe some uses or example for using ORM for a Newbie ? Simply put, ORM is a method for making objects that represent records in a database. It's usually done in such a way that the objects are "live." In other words if the object has an attribute representing a column in a table, if I assign to that, it will update the database automatically. As well ORM abstracts and encapsulates relations between database tables. So if two tables are related, if you delete an object from the first table, it will automatically ask the database to delete dependent, related records from the related table. https://en.wikipedia.org/wiki/Object-relational_mapping Some people think ORM is pointless and would rather just work directly with the databases using purpose query languages like SQL. One reason Django and other web frameworks use ORM is that it abstracts the specifics of the database engine so you can more easily switch from sqlite to mysql to posgresql or even use a commercial database engine. There has always been a lively debate over ORM. At some point the abstraction will leak and you'll get some database-specific problem you have to deal with in your app code. For PonyORM examples, see the pony orm web pages: https://docs.ponyorm.com/firststeps.html https://docs.ponyorm.com/queries.html Currently I'm planning to use it in a non-web application. I messed with it a bit last night and it works pretty well for what I need to use it for, which is pretty simple on the database end. -- https://mail.python.org/mailman/listinfo/python-list
Re: Name resolution and the (wrong?) LEGB rule
On Fri, Dec 9, 2016 at 1:51 AM, Marco Buttu wrote:
> "if a particular name:object mapping cannot be found in the local
> namespaces, the namespaces of the enclosed scope are being searched next. If
> the search in the enclosed scope is unsuccessful, too, Python moves on to
> the global namespace, and eventually, it will search the built-in namespace
> (side note: if a name cannot found in any of the namespaces, a NameError
> will is raised)."
>
> AFAIK, Python has static scoping: the scope for a name is given during the
> bytecode compilation. This means that before executing the program, Python
> already know in which namespace to look for an object. So, it seems to me
> that the LEGB rule is wrong,
It isn't wrong, but there are some parts of it that can be resolved at
compile time. Once a function is compiled, it cannot normally gain or
lose local names. There are a few situations that can mess with that
(a star import or 'exec' statement, in Python 2), and when the
compiler detects one of those, it has to avoid the usual optimization.
The "usual optimization" is exactly what you describe: that different
bytecodes represent Local, Enclosing, and Global/Built-in scope
lookups. (Globals can be created or removed at run-time, so there's no
optimization possible there.) But in terms of language specifications,
the lookup rules are the same; it's just that the CPython compiler
takes advantage of information that it can see ("these are the only
locals for this function") to speed up execution.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Linux terminals vs Windows consoles - was Re: python 2.7.12 on Linux behaving differently than on Windows
On 12/08/2016 10:05 AM, Grant Edwards wrote: > Or various other terminal emulators tha are mostly ANSI and Unicode > aware... > > And the Linux console... True. > > It's interesting to note that the "real" xterm terminal emulator will > still emulate a Tektronix storage-scope graphics terminal (a terminal > that actually _implemented_ vector drawing rather than emulating it > with a raster-scanned array of pixels). Yeah I played around with that for fun a few months ago. The reason I did was that someone on a forum was complaining about a problem with that mode and I had never heard of it before! > But, I know of plenty of people that still use real serial terminals > connected via serial ports. Until very recently, one of my customers > had a group of techs that bought used Wyse 50 (green monochrome CRT) > serial terminals off e-bay, Craigsist, or wherever and refurbished > them in-house so that they could be sent out to the field for > installation (as retail POS terminals). Last time I heard, they were > goint to switch to flat-screen "thin-clients". I got a chance to play > with one of those, and it was an industrial Single-board-PC and LCD > monitor built into a single unit running Windows. It was configured > to boot up and run a Wyse-50 terminal emulator -- and connect to the > "real" computer via an RS-232C serial port. :) Very interesting. -- https://mail.python.org/mailman/listinfo/python-list
Re: Detect Linux Runlevel
On 2016-12-07 07:30, Marko Rauhamaa wrote: > Tim Chase : > > On 2016-12-07 00:29, Marko Rauhamaa wrote: > >> A word a warning: your code doesn't lock /var/run/utmp before > >> access, which is a race condition. The file may be updated at any > >> time, and ordinary file reads may yield corrupted records. > > > > Since the code is reading in record-sized blocks and never > > writing, I'm not sure how much possibility there is for a race > > condition. At worst, I imagine that it would result in reading > > the old data which isn't a horrible condition. > > If you read a full record at an offset, you might be right. However, > your code uses Python's buffered I/O: > > with open(utmp_fname, "rb") as f: > while True: > bytes = f.read(XTMP_STRUCT_SIZE) > > instead of os.open() and os.read(). Interesting. I read up on os.open() and os.read() https://docs.python.org/2/library/os.html#os.read but didn't notice anything there clarifying that it was unbuffered compared to the __builtins__.open() and fp.read() functions. Could you point me to resources where I can learn more about the distinctions? > > For under a certain block-size (PIPE_BUF, which I think used to be > > the minimum POSIX requirement of 512b, but is now 4096b on Linux), > > *nix operating systems were atomic in their reading and writing. > > That particular guarantee is true for pipes and FIFOs only. Ah, my error in misreading that as globally applicable. Thanks for ensuring accuracy. -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Get min and max dates
Datetime has greater range I believe. I can't paste from my work computer, but try this: min(datetime.datetime.strptime(s, "%d-%b-%Y") for s in dts) You should get the 1908 date instead of the 1969 date. In general, you should always use datetime instead of time for doing date manipulation and date arithmetic. It's a *whole lot better*. Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Name resolution and the (wrong?) LEGB rule
Chris Angelico wrote:
> On Fri, Dec 9, 2016 at 1:51 AM, Marco Buttu wrote:
>> "if a particular name:object mapping cannot be found in the local
>> namespaces, the namespaces of the enclosed scope are being searched next.
>> If the search in the enclosed scope is unsuccessful, too, Python moves on
>> to the global namespace, and eventually, it will search the built-in
>> namespace (side note: if a name cannot found in any of the namespaces, a
>> NameError will is raised)."
>>
>> AFAIK, Python has static scoping: the scope for a name is given during
>> the bytecode compilation. This means that before executing the program,
>> Python already know in which namespace to look for an object. So, it
>> seems to me that the LEGB rule is wrong,
It might be sufficient to say that the LE part is usually statically
determined while the GB part is dynamic.
The odd beast is the class namespace:
>>> x = "outer"
>>> class C:
... print(x)
... x = "inner"
... print(x)
... del x
... print(x)
...
outer
inner
outer
> It isn't wrong, but there are some parts of it that can be resolved at
> compile time. Once a function is compiled, it cannot normally gain or
> lose local names. There are a few situations that can mess with that
> (a star import or 'exec' statement, in Python 2), and when the
> compiler detects one of those, it has to avoid the usual optimization.
>
> The "usual optimization" is exactly what you describe: that different
> bytecodes represent Local, Enclosing, and Global/Built-in scope
> lookups. (Globals can be created or removed at run-time, so there's no
> optimization possible there.) But in terms of language specifications,
> the lookup rules are the same; it's just that the CPython compiler
> takes advantage of information that it can see ("these are the only
> locals for this function") to speed up execution.
If it is only an optimization why doesn't a failing local lookup fall back
to the global namespace?
--
https://mail.python.org/mailman/listinfo/python-list
Re: Detect Linux Runlevel
Tim Chase : > Interesting. I read up on os.open() and os.read() > https://docs.python.org/2/library/os.html#os.read > but didn't notice anything there clarifying that it was unbuffered > compared to the __builtins__.open() and fp.read() functions. > > Could you point me to resources where I can learn more about the > distinctions? It is not explained very clearly in the documentation, but the os.* functions are thin wrappers around the analogous C functions (system calls or standard library functions). There is just this allusion: Note that using the file descriptor directly will bypass the file object methods, ignoring aspects such as internal buffering of data. https://docs.python.org/3/library/os.html?#file-descriptor-op erations> The os.* facilities are ultimately documented in the Linux man pages. File object buffering can be turned off by adding buffering=0 to the high-level open() builtin function: When no buffering argument is given, the default buffering policy works as follows: * Binary files are buffered in fixed-size chunks; the size of the buffer is chosen using a heuristic trying to determine the underlying device’s “block size” and falling back on io.DEFAULT_BUFFER_SIZE. On many systems, the buffer will typically be 4096 or 8192 bytes long. https://docs.python.org/3/library/functions.html#open> In general, system programming is best done using system programming facilities, ie, os.*. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Name resolution and the (wrong?) LEGB rule
On Fri, Dec 9, 2016 at 5:03 AM, Peter Otten <[email protected]> wrote: >> The "usual optimization" is exactly what you describe: that different >> bytecodes represent Local, Enclosing, and Global/Built-in scope >> lookups. (Globals can be created or removed at run-time, so there's no >> optimization possible there.) But in terms of language specifications, >> the lookup rules are the same; it's just that the CPython compiler >> takes advantage of information that it can see ("these are the only >> locals for this function") to speed up execution. > > If it is only an optimization why doesn't a failing local lookup fall back > to the global namespace? Define "failing". Do you mean that this should print "outer"? x = "outer" def f(): print(x) x = "inner" f() There are plenty of languages where this is true, but they work because the defined scope of a variable is "from its declaration down". Python doesn't work like that. Neither does JavaScript, although it's a bit bizarre in a few ways. The lookup doesn't fail; it finds a local variable that doesn't have a value. At least, I'm pretty sure that's how it works. Is there a language specification stating this? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: MacOSX SpeechRecognition installation problems
Anton, Thanks for the detailed response. I will look into virtualenv and others. Please excuse beginner's question, but is Xcode of any use in this type of situation? -- https://mail.python.org/mailman/listinfo/python-list
Re: MacOSX SpeechRecognition installation problems
On 12/08/2016 11:23 AM, 3dB wrote: > Anton, Thanks for the detailed response. I will look into virtualenv > and others. Please excuse beginner's question, but is Xcode of any > use in this type of situation? Not directly, but it does provide a C compiler, which some Python modules require when you build and install them. So having Xcode installed could be a requirement for installing some python modules (but not all, nor is it required to run python scripts). Are you asking if there are some nice IDEs available for working with Python? -- https://mail.python.org/mailman/listinfo/python-list
Re: Name resolution and the (wrong?) LEGB rule
Chris Angelico wrote: > On Fri, Dec 9, 2016 at 5:03 AM, Peter Otten <[email protected]> wrote: >>> The "usual optimization" is exactly what you describe: that different >>> bytecodes represent Local, Enclosing, and Global/Built-in scope >>> lookups. (Globals can be created or removed at run-time, so there's no >>> optimization possible there.) But in terms of language specifications, >>> the lookup rules are the same; it's just that the CPython compiler >>> takes advantage of information that it can see ("these are the only >>> locals for this function") to speed up execution. >> >> If it is only an optimization why doesn't a failing local lookup fall >> back to the global namespace? > > Define "failing". Do you mean that this should print "outer"? > > x = "outer" > def f(): > print(x) > x = "inner" > f() I mean it could, as classes already work that way. I think the current behaviour is a design decision rather than an implementation accident. > There are plenty of languages where this is true, but they work > because the defined scope of a variable is "from its declaration > down". Python doesn't work like that. Neither does JavaScript, > although it's a bit bizarre in a few ways. The lookup doesn't fail; it > finds a local variable that doesn't have a value. At least, I'm pretty > sure that's how it works. Is there a language specification stating > this? I found https://www.python.org/dev/peps/pep-0227/ -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
ll command line, but within a program or from a
GUI entry box), does it let you do all this meta-character and
meta-expression stuff that you're on about?
If so, please tell me how to define '$base="thefile"' from inside
LibreOffice, and how to make use of it in the file dialog entry box.
If not, then what you're arguing about is meaningless.
For example, a quick and simple way of backing up a file with a date stamp:
steve@runes:~$ cp alloc.txt{,-`date +%Y%m%d`}
steve@runes:~$ ls alloc.txt*
alloc.txt alloc.txt-20161208
Pretty good. Except I just tried that method in Firefox to save a page:
c.html{,-`date +%Y%m%d`}
and it worked - sort of. I just got a saved page called:
c.html{,-`date +%Y%m%d`}
Does this mean Firefox is broken?
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On Fri, Dec 9, 2016 at 6:15 AM, BartC wrote: > On 08/12/2016 03:41, Steven D'Aprano wrote: >> >> On Thursday 08 December 2016 12:15, BartC wrote: >> > >>> That's all. I know the value of keeping things straightforward instead >>> of throwing in everything you can think of. The file-matching is done by >>> WinAPI functions. > > >> So you're happy with the fact that there are legitimate file names that >> your >> program simply has no way of dealing with? > > > Perfectly. Such names are illegal on its home OS which is Windows, and > ill-advised elsewhere. Awesome. Since you're using Windows as your definition of "ill-advised", I take it you assume that file names should be case insensitive, too, right? Cool. Let me know when you've figured out the uppercase and lowercase equivalents of this file name: "ßẞıİiIÅσςσ" ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Get min and max dates
DFS wrote:
>
> Not wanting to use any date parsing libraries,
>
If you happen reconsider date parsing libraries
the strptime function from the datetime module
might be useful
#!/usr/bin/env python3
from datetime import datetime
dates = [ '10-Mar-1998' ,
'20-Aug-1997' ,
'06-Sep-2009' ,
'23-Jan-2010' ,
'12-Feb-2010' ,
'05-Nov-2010' ,
'03-Sep-2009' ,
'07-Nov-2014' ,
'08-Mar-2013' ]
dict_dates = { }
print( )
for this_date in dates :
dt = datetime.strptime( this_date , '%d-%b-%Y' )
sd = dt.strftime( '%Y-%m-%d' )
print( ' {0} {1}'.format( this_date , sd ) )
dict_dates[ sd ] = this_date
min_date = min( dict_dates.keys() )
max_date = max( dict_dates.keys() )
print( '\n {0} {1} min'.format( dict_dates[ min_date ] , min_date ) )
print( '\n {0} {1} max'.format( dict_dates[ max_date ] , max_date ) )
--
Stanley C. Kitching
Human Being
Phoenix, Arizona
--
https://mail.python.org/mailman/listinfo/python-list
Re: MacOSX SpeechRecognition installation problems
Thanks Michael, I think I was confusing Virtual Environment (VE) with IDE. Probably best if I get to grips with virtualenv to start with since I can't complete installations at present and VE appears to offer best solution. -- https://mail.python.org/mailman/listinfo/python-list
Re: MacOSX SpeechRecognition installation problems
Michael, I tried installing virtual env but got similar permissions error: IOError: [Errno 13] Permission denied: '/Library/Python/2.7/site-packages/virtualenv.py' -- https://mail.python.org/mailman/listinfo/python-list
Re: MacOSX SpeechRecognition installation problems
On 12/08/2016 01:26 PM, 3dB wrote: > Thanks Michael, > > I think I was confusing Virtual Environment (VE) with IDE. > > Probably best if I get to grips with virtualenv to start with since I > can't complete installations at present and VE appears to offer best > solution. Despite Anton's warning about sudo, you definitely could use it to install the module to /Library and get on with using it for now, and learn about virtual environments once you've got some python experience. The problem was that the install function of the package wanted to write files to that location in /Library, which non-root users cannot do. Prefacing that command with sudo will elevate access temporarily allowing the installation to proceed. That's what I would do if I were you. Who cares if you have to redo it after you reinstall the OS, or even move to a different computer. Yes virtual environments are nice and self-contained and require no special privileges to use. But if you don't know anything about python, that's going to be an advanced topic for now. -- https://mail.python.org/mailman/listinfo/python-list
Re: MacOSX SpeechRecognition installation problems
On 12/08/2016 01:48 PM, 3dB wrote: > Michael, > > I tried installing virtual env but got similar permissions error: > > IOError: [Errno 13] Permission denied: > '/Library/Python/2.7/site-packages/virtualenv.py' Just to get virtual environment support you definitely have to install this package, and it must go to the system packages area. So I think sudo is a must for this one. sudo -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
Random832 wrote: Just to point out, brace expansion isn't globbing. The most important difference is that brace expansion doesn't care what files exist. However, it's something that the shell expands into multiple arguments, giving it similar characteristics for the purposes of this discussion. The main difference is that you're unlikely to accidentally get a million file names or 131072 bytes of arguments that way. :-) -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On Fri, Dec 9, 2016 at 8:15 AM, Gregory Ewing
wrote:
> The main difference is that you're unlikely to accidentally
> get a million file names or 131072 bytes of arguments that
> way. :-)
python3 argcount.py
{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}
65537
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: MacOSX SpeechRecognition installation problems
Sorry, I haven't been following this thread carefully. Michael's use of "sudo" caught my eye though. I know virtualenv might be "special", but shouldn't this work? pip install --user virtualenv It will wind up in $HOME/.local/lib/python2.7/site-packages (or similar) I believe. Skip On Thu, Dec 8, 2016 at 3:11 PM, Michael Torrie wrote: > On 12/08/2016 01:48 PM, 3dB wrote: > > Michael, > > > > I tried installing virtual env but got similar permissions error: > > > > IOError: [Errno 13] Permission denied: '/Library/Python/2.7/site- > packages/virtualenv.py' > > Just to get virtual environment support you definitely have to install > this package, and it must go to the system packages area. So I think > sudo is a must for this one. > > sudo > > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
Grant Edwards wrote: But _paths_ can, and Windows command-line apps and shells choke on paths when written with "/" separators because way-back when the MS-DOS "designers" decided to use "/" as the default option character. To be fair to them, the use of "/" for options can be traced back to earlier systems such as CP/M and RT-11, which didn't even have hierarchial file systems, so choice of path separators wasn't an issue. The "/" made a kind of sense in those systems, because options were thought of as annotations attached to an argument rather than as arguments in their own right. They were typically written straight after the argument they applied to without any space between, or after the command name itself if they didn't apply to any particular argument. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: MacOSX SpeechRecognition installation problems
On 12/08/2016 02:27 PM, Skip Montanaro wrote: > Sorry, I haven't been following this thread carefully. Michael's use of > "sudo" caught my eye though. I know virtualenv might be "special", but > shouldn't this work? > > pip install --user virtualenv > > It will wind up in $HOME/.local/lib/python2.7/site-packages (or similar) I > believe. Ahh yes, that's probably correct. -- https://mail.python.org/mailman/listinfo/python-list
Re: Linux terminals vs Windows consoles - was Re: python 2.7.12 on Linux behaving differently than on Windows
Michael Torrie wrote: Interesting. I wouldn't have thought ENTER would return a line feed. Possibly you have the terminal in "cbreak" mode, which provides a character at a time but still does things like translate CR->LF. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On 08/12/2016 19:36, Chris Angelico wrote: On Fri, Dec 9, 2016 at 6:15 AM, BartC wrote: On 08/12/2016 03:41, Steven D'Aprano wrote: On Thursday 08 December 2016 12:15, BartC wrote: That's all. I know the value of keeping things straightforward instead of throwing in everything you can think of. The file-matching is done by WinAPI functions. So you're happy with the fact that there are legitimate file names that your program simply has no way of dealing with? Perfectly. Such names are illegal on its home OS which is Windows, and ill-advised elsewhere. Awesome. Since you're using Windows as your definition of "ill-advised", I take it you assume that file names should be case insensitive, too, right? Cool. Let me know when you've figured out the uppercase and lowercase equivalents of this file name: "ßẞıİiIÅσςσ" Python3 tells me that original, lower-case and upper-case versions are: ßẞıİiIÅσςσ ßßıi̇iiåσςσ SSẞIİIIÅΣΣΣ (Python2 failed to run the code: s="ßẞıİiIÅσςσ" print (s) print (s.lower()) print (s.upper()) ) But, given that, what's your point? That some esoteric Unicode characters have ill-defined upper and lower case versions, and therefore it is essential to treat them distinctly in EVERY SINGLE ALPHABET including English? I guess that means that if I try a write a book about a character called HarrY potter or james BOND then I cannot be sued. -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Linux terminals vs Windows consoles - was Re: python 2.7.12 on Linux behaving differently than on Windows
Michael Torrie wrote: For example, on Macs, control-key is not normally used, but rather the Command-key (the apple key) which happens to be where the Alt key is on our PC keyboards. Actually, Alt is usually mapped to Option on a Mac. The Mac Command key corresponds the "Windows" or "Meta" key on other keyboards, I think (but is used in a very different way). -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On Fri, Dec 9, 2016 at 8:42 AM, BartC wrote: > Python3 tells me that original, lower-case and upper-case versions are: > > ßẞıİiIÅσςσ > ßßıi̇iiåσςσ > SSẞIİIIÅΣΣΣ Now lower-case the upper-case version and see what you get. And upper-case the lower-case version. Because x.upper().lower() should be the same as x.lower(), right? And x.lower().upper().lower() is the same too. Right? >>> x = "ßẞıİiIÅσςσ" >>> x.upper().lower() == x.lower() False >>> x.upper().lower() == x.lower().upper().lower() False > (Python2 failed to run the code: > > s="ßẞıİiIÅσςσ" > print (s) > print (s.lower()) > print (s.upper()) > ) I don't know what you mean by "failed", but you shouldn't have non-ASCII characters in Python 2 source code without a coding cookie. Also, you should be using a Unicode string. Or just stick with Py3. > But, given that, what's your point? That some esoteric Unicode characters > have ill-defined upper and lower case versions, and therefore it is > essential to treat them distinctly in EVERY SINGLE ALPHABET including > English? Yes, because it's Unicode's fault, isn't it. The world was so nice and simple before Unicode came along and created all these messes for us to have to deal with. And you're quite right - these characters are esoteric and hardly ever used. [1] And they're so ill-defined that nobody could predict or figure out what the upper-case and lower-case forms are. It's not like there are rules that come from the languages where they're used. > I guess that means that if I try a write a book about a character called > HarrY potter or james BOND then I cannot be sued. This is not legal advice, but I think you'll agree that "HarrY" is not equal to "Harry". Whether it's a good idea to have two files in the same directory that have those names, it's certainly the case that the names can be distinguished. (Sir HarrY is a very distinguished name.) And if you decide not to distinguish between "Y" and "y", then which of the above characters should be not-distinguished? ChrisA [1] Okay, to be fair, one of the ones I used *is* esoteric. But most of them aren't. -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
Gregory Ewing : > Grant Edwards wrote: >> But _paths_ can, and Windows command-line apps and shells choke on >> paths when written with "/" separators because way-back when the >> MS-DOS "designers" decided to use "/" as the default option >> character. > > To be fair to them, the use of "/" for options can be traced back to > earlier systems such as CP/M and RT-11, which didn't even have > hierarchial file systems, so choice of path separators wasn't an > issue. I find it a bit annoying that "/" cannot be used in Linux filenames. Slashes have very common everyday uses and it's a pity they are reserved. Instead, ASCII control characters are allowed, which is of no use. And the Linux example of the other day is just terrible. Globs can do surprising damage if filenames should start with a minus sign. The naive command: cp *.c backup/ should really be: cp ./*.c backup/ or: cp -- *.c backup/ but who does that? Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On 08/12/2016 22:31, Chris Angelico wrote:
On Fri, Dec 9, 2016 at 8:42 AM, BartC wrote:
Python3 tells me that original, lower-case and upper-case versions are:
ßẞıİiIÅσςσ
ßßıi̇iiåσςσ
SSẞIİIIÅΣΣΣ
Now lower-case the upper-case version and see what you get. And
upper-case the lower-case version. Because x.upper().lower() should be
the same as x.lower(), right? And x.lower().upper().lower() is the
same too. Right?
I get this (although I suspect Thunderbird will screw up the tabs); the
code I used follows at the end:
L U L->U U->L
Aa A A a Letters
65 97 65 65 97 Ordinals
11 1 1 1 Lengths
32 32 32 32 32
11 1 1 1
ßß SS SS ss
223 223 83 83 115
11 2 2 2
ẞß ẞ SS ß
7838 223 783883 223
11 1 2 1
ıı I I i
305 305 73 73 105
11 1 1 1
İi̇ İ İ i̇
304 105 304 73 105
12 1 2 2
ii I I i
105 105 73 73 105
11 1 1 1
Ii I I i
73 105 73 73 105
11 1 1 1
Åå Å Å å
8491 229 8491197 229
11 1 1 1
σσ Σ Σ σ
963 963 931 931 963
11 1 1 1
ςς Σ Σ σ
962 962 931 931 963
11 1 1 1
σσ Σ Σ σ
963 963 931 931 963
11 1 1 1
zz Z Z z
122 122 90 90 122
11 1 1 1
I've added A, space and z.
As I said some characters have ill-defined upper and lower case
conversions, even if some aren't as esoteric as I'd thought.
In English however the conversions are perfectly well defined for A-Z
and a-z, while they are not meaningful for characters such as space, and
for digits.
In English such conversions are immensely useful, and it is invaluable
for many purposes to have upper and lower case interchangeable (for
example, you don't have separate sections in a dictionary for letters
starting with A and those starting with a).
So it it perfectly possible to have case conversion defined for English,
while other alphabets can do what they like.
It is a little ridiculous however to have over two thousand distinct
files all with the lower-case normalised name of "harry_potter".
What were we talking about again? Oh yes, belittling me because I work
with Windows!
---
tab=" "
def ord1(c):return ord(c[0])
def showcases(c):
print (c,tab,c.lower(),tab,c.upper(),tab,c.lower().upper(),tab,
c.upper().lower())
def showcases_ord(c):
print (ord1(c),tab,ord1(c.lower()),tab,ord1(c.upper()),tab,
ord1(c.lower().upper()),tab,ord1(c.upper().lower()))
def showcases_len(c):
print (len(c),tab,len(c.lower()),tab,len(c.upper()),tab,
len(c.lower().upper()), tab,len(c.upper().lower()))
s="A ßẞıİiIÅσςσz"
print ("OrgL U L->U U->L")
for c in s:
showcases(c)
showcases_ord(c)
showcases_len(c)
print()
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On Fri, Dec 9, 2016 at 10:03 AM, Marko Rauhamaa wrote: > I find it a bit annoying that "/" cannot be used in Linux filenames. > Slashes have very common everyday uses and it's a pity they are > reserved. Instead, ASCII control characters are allowed, which is of no > use. How would you do otherwise? How do you separate directories in a path? Remember, it needs to be easy to type, and easy to read. You could pick some other keyboard character, but you won't really gain much. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Linux terminals vs Windows consoles - was Re: python 2.7.12 on Linux behaving differently than on Windows
On 12/08/2016 02:46 PM, Gregory Ewing wrote: > Michael Torrie wrote: >> For example, on Macs, >> control-key is not normally used, but rather the Command-key (the apple >> key) which happens to be where the Alt key is on our PC keyboards. > > Actually, Alt is usually mapped to Option on a Mac. The Mac > Command key corresponds the "Windows" or "Meta" key on other > keyboards, I think (but is used in a very different way). I was talking about position on the keyboard. But yes, good point. -- https://mail.python.org/mailman/listinfo/python-list
Re: Name resolution and the (wrong?) LEGB rule
On Fri, 9 Dec 2016 01:51 am, Marco Buttu wrote: > Sometimes the Python name resolution is explained using a LEGB rule. > For instance, in [1] (I think also the Learning Python book gives the > same): > > "if a particular name:object mapping cannot be found in the local > namespaces, the namespaces of the enclosed scope are being searched > next. If the search in the enclosed scope is unsuccessful, too, Python > moves on to the global namespace, and eventually, it will search the > built-in namespace (side note: if a name cannot found in any of the > namespaces, a NameError will is raised)." > > AFAIK, Python has static scoping: the scope for a name is given during > the bytecode compilation. This means that before executing the program, > Python already know in which namespace to look for an object. So, it > seems to me that the LEGB rule is wrong, and this is what actually > happens: > > * local name (LOAD_FAST instruction): Python looks (only) in the local > namespace, and if it does not find the name, then it raises an > UnboundLocalError > > * global name (LOAD_GLOBAL): at first Python looks in the globals(), and > in case the name is not there, it looks in the builtins namespace; if > the name is neither in the global nor in the builtin namespace, it > raises a NameError > > * enclosing scope (LOAD_DEREF): there is a closure, and Python looks for > the name in the enclosing namespace > > Is that right, or am I missing something? Thanks, Marco You are partly right, but you are also missing a few things. (1) Technically, the LOAD_* byte codes are implementation details, and there is no requirement for Python interpreters to use them. In fact, Jython being built on the JVM and IronPython being built on the .Net runtime cannot use them. Even a C-based interpreter is not required to implement name resolution in the same way. (2) There are some odd corner cases in Python 2 where you use exec() or import * inside a function to create local variables, where the CPython interpreter no longer uses LOAD_FAST to resolve locals. (I'm going by memory here, so I may have some of the details wrong.) You can experiment with that if you like, but the behaviour has changed in Python 3 so its no longer relevant except as a historical detail for those stuck on Python 2. (To be precise, import * is forbidden inside functions, and exec() must take an explicit namespace argument rather than implicitly applying to the local function scope.) (3) However, the most important case you've missed is code executed inside a class namespace during class creation time: class C(object): a = 1 def test(): # intentionally no self b = 2 return a + b c = 3 d = test() + c Don't forget classes nested inside classes... I consider the LEGB rule to be a statement of intent, describing how a Python implementation is expected to behave, *as if* it were following the LEGB rule, not necessarily a statement of the implementation of any specific Python implementation. -- 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: MacOSX SpeechRecognition installation problems
> > pip install --user virtualenv > > > > It will wind up in $HOME/.local/lib/python2.7/site-packages (or similar) I > > believe. Michael, Skip, I've noticed that Python is in the highest level of the drive, HDD/Library/Python as opposed to usr/Library. Does that present a problem? Also noticed that Python folder contains both versions 2.6 and 2.7. -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On 12/08/2016 04:19 PM, BartC wrote: > What were we talking about again? Oh yes, belittling me because I work > with Windows! Yes it's kind of getting that way, which means this conversation is at an end. I don't think Chris or Steven or anyone else who has gone round and round with you has meant to demean you personally. Some of the responses have been a bit strong, because your own arguments have come off rather harsh--something along the lines of you can't believe anyone would actually use Linux, let alone like it because it's so backwards compared to the way you are used to, in your own opinion. None of this would matter much, but you apparently want to port your programs to run under Linux, which is going to be a really rough experience without a little broad-mindedness on your part. And now for something completely different, and to move the thread back on topic, I think everyone would be well served to watch this little educational and informational Python video: https://www.youtube.com/watch?v=kQFKtI6gn9Y -- https://mail.python.org/mailman/listinfo/python-list
Re: MacOSX SpeechRecognition installation problems
> pip install --user virtualenv > > It will wind up in $HOME/.local/lib/python2.7/site-packages (or similar) I > believe. Skip, thanks, that worked for virtualenv. I'll now try sudo for Speechrecognition. -- https://mail.python.org/mailman/listinfo/python-list
Re: MacOSX SpeechRecognition installation problems
On 12/08/2016 05:19 PM, 3dB wrote: >>> pip install --user virtualenv >>> >>> It will wind up in $HOME/.local/lib/python2.7/site-packages (or >>> similar) I believe. > > Michael, Skip, > > I've noticed that Python is in the highest level of the drive, > HDD/Library/Python as opposed to usr/Library. Does that present a > problem? > > Also noticed that Python folder contains both versions 2.6 and 2.7. OS X ships with both Python 2.6 and 2.7 apparently. The default is probably 2.7. System-wide libraries and other data are installed to /Library, which is not typically writable to a normal user. There are versions of all of these directories installed in your user home directory, which are writable to you and don't require any special privileges. Skip was saying if you can install to the directories in your home directory, ($HOME/Library/whatever instead of /Library/whatever) that is best since it doesn't modify the system at all and so it won't get overwritten by system updates or re-installs. If you can run without root privileges (without sudo) and use directories in your own home directory for python modules you should. I don't use OS X, so beyond this I am not of much help. Perhaps other Mac users will see this thread and pipe up. -- https://mail.python.org/mailman/listinfo/python-list
Re: MacOSX SpeechRecognition installation problems
On 12/08/2016 05:22 PM, 3dB wrote: >> pip install --user virtualenv >> >> It will wind up in $HOME/.local/lib/python2.7/site-packages (or similar) I >> believe. > > Skip, thanks, that worked for virtualenv. > > I'll now try sudo for Speechrecognition. You should be able to install speach recognition to the local virtualenv also. Shouldn't need sudo now. I think, anyway. -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On Fri, Dec 9, 2016 at 10:19 AM, BartC wrote: > I get this (although I suspect Thunderbird will screw up the tabs); the code > I used follows at the end: Actually it came through just fine. Although, point of note: the case conversions of individual characters are not the same as the case conversions of the whole string. > As I said some characters have ill-defined upper and lower case conversions, > even if some aren't as esoteric as I'd thought. Can you show me any character with ill-defined conversions? > In English however the conversions are perfectly well defined for A-Z and > a-z, while they are not meaningful for characters such as space, and for > digits. Correct; caseless characters don't change. There's no concept of "upper-case 5", and no, it isn't "%", despite people who think that "upper-case" means "hold shift" :) > In English such conversions are immensely useful, and it is invaluable for > many purposes to have upper and lower case interchangeable (for example, you > don't have separate sections in a dictionary for letters starting with A and > those starting with a). That's not quite the same; that's a *collation order*. And some dictionaries will sort them all in together, but others will put the uppercase before the lowercase (ie sorting "AaBbCcDd"). It's not that they're considered identical; it's that they're placed near each other in the sort. In fact, it's possible to have collations without conversions - for instance, it's common for McFoo and MacFoo to be sorted together in a list of names. > So it it perfectly possible to have case conversion defined for English, > while other alphabets can do what they like. And there we have it. Not only do you assume that English is the only thing that matters, you're happy to give the finger to everyone else on the planet. > It is a little ridiculous however to have over two thousand distinct files > all with the lower-case normalised name of "harry_potter". It's also ridiculous to have hundreds of files with unique two-letter names, but I'm sure someone has done it. The file system shouldn't stop you, any more than it should stop you from having "swimmer" and "swirnrner" in the same directory (in some fonts, they're indistinguishable). > What were we talking about again? Oh yes, belittling me because I work with > Windows! Or because you don't understand anything outside of what you have worked with, and assume that anything you don't understand must be inferior. It's not a problem to not know everything, but you repeatedly assert that other ways of doing things are "wrong", without acknowledging that these ways have worked for forty years and are strongly *preferred* by myriad people around the world. I grew up on OS/2, using codepage 437 and case insensitive file systems, and there was no way for me to adequately work with other Latin-script languages, much less other European languages (Russian, Greek), and certainly I had no way of working with non-alphabetic languages (Chinese, Japanese). Nor right-to-left languages (Hebrew, Arabic). And I didn't know anything about the Unix security model, with different processes being allowed to do different things. Today, the world is a single place, not lots of separate places that sorta kinda maybe grudgingly talk to each other. We aren't divided according to "people who use IBMs" and "people who use DECs". We shouldn't be divided according to "people who use CP-850" and "people who use Windows-1253". The tools we have today are capable of serving everyone properly. Let's use them. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On 09/12/2016 00:55, Chris Angelico wrote: On Fri, Dec 9, 2016 at 10:19 AM, BartC wrote: So it it perfectly possible to have case conversion defined for English, while other alphabets can do what they like. And there we have it. Not only do you assume that English is the only thing that matters, you're happy to give the finger to everyone else on the planet. I haven't given the finger to anybody. I'm not an expert on all these other languages, but I don't want to tell them what to do either. /They/ decide what meaning upper/lower has, if any. Or maybe we can just do away with it altogether. (What are Python's .lower/.upper used for, after all? With any such functions, you are guaranteed to find a Unicode sequence which is going to give trouble. So take them out so as not to offend anyone!) It does seem however as though users of other languages are telling /me/ how I should deal with English, which is what I spend nearly 100% of my life dealing with (those language lessons not having worked out...). It is a little ridiculous however to have over two thousand distinct files all with the lower-case normalised name of "harry_potter". It's also ridiculous to have hundreds of files with unique two-letter names, but I'm sure someone has done it. The file system shouldn't stop you With a case-sensitive file system, how do you search only for 'harry', not knowing what combinations of upper and lower case have been used? (It's a good thing Google search isn't case sensitive!) What were we talking about again? Oh yes, belittling me because I work with Windows! Or because you don't understand anything outside of what you have worked with, and assume that anything you don't understand must be inferior. It's not a problem to not know everything, but you repeatedly assert that other ways of doing things are "wrong", without acknowledging that these ways have worked for forty years and are strongly *preferred* by myriad people around the world. I grew up on OS/2, using codepage 437 and case insensitive file systems, and there was no way for me to adequately work with other Latin-script languages, I developed applications that needed to work in French, German and Dutch, apart from English. That might have been long enough ago that I may have had to provide some of the fonts (both bitmap and vector), as well as implement suitable keyboard layouts used with digitising tablets. /And/ provide support in the scripting languages that went with them. Not particularly demanding in terms of special or quirky characters (or word-order issues when constructing messages for translation) but it's not quite the same as my assuming everything was 7-bit ASCII and in English. much less other European languages (Russian, Greek), and certainly I had no way of working with non-alphabetic languages (Chinese, Japanese). Nor right-to-left languages (Hebrew, Arabic). Did you really need to work with all those languages, or is this a generic 'I'. -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
With a case-sensitive file system, how do you search only for 'harry', not knowing what combinations of upper and lower case have been used? (It's a good thing Google search isn't case sensitive!) On Linux, I'd do "find . -iname harry". A lot, but not all, of the tools usually have options to ignore case. I don't know how this works with unicode, as I don't normally have to deal with non-ASCII, either. Probably the only time I see unicode is when I see files with symbols for currencies instead of the ISO-3 currency code (I work in finance) and occasionally in company names. Regards, Nate On Thu, Dec 8, 2016 at 7:34 PM, BartC wrote: > On 09/12/2016 00:55, Chris Angelico wrote: > >> On Fri, Dec 9, 2016 at 10:19 AM, BartC wrote: >> > > So it it perfectly possible to have case conversion defined for English, >>> while other alphabets can do what they like. >>> >> >> And there we have it. Not only do you assume that English is the >> only thing that matters, you're happy to give the finger to everyone >> else on the planet. >> > > I haven't given the finger to anybody. I'm not an expert on all these > other languages, but I don't want to tell them what to do either. /They/ > decide what meaning upper/lower has, if any. > > Or maybe we can just do away with it altogether. (What are Python's > .lower/.upper used for, after all? With any such functions, you are > guaranteed to find a Unicode sequence which is going to give trouble. So > take them out so as not to offend anyone!) > > It does seem however as though users of other languages are telling /me/ > how I should deal with English, which is what I spend nearly 100% of my > life dealing with (those language lessons not having worked out...). > > >> It is a little ridiculous however to have over two thousand distinct files >>> all with the lower-case normalised name of "harry_potter". >>> >> >> It's also ridiculous to have hundreds of files with unique two-letter >> names, but I'm sure someone has done it. The file system shouldn't >> stop you >> > > With a case-sensitive file system, how do you search only for 'harry', not > knowing what combinations of upper and lower case have been used? (It's a > good thing Google search isn't case sensitive!) > > What were we talking about again? Oh yes, belittling me because I work with >> >>> Windows! >>> >> >> Or because you don't understand anything outside of what you have >> worked with, and assume that anything you don't understand must be >> inferior. It's not a problem to not know everything, but you >> repeatedly assert that other ways of doing things are "wrong", without >> acknowledging that these ways have worked for forty years and are >> strongly *preferred* by myriad people around the world. I grew up on >> OS/2, using codepage 437 and case insensitive file systems, and there >> was no way for me to adequately work with other Latin-script >> languages, >> > > I developed applications that needed to work in French, German and Dutch, > apart from English. That might have been long enough ago that I may have > had to provide some of the fonts (both bitmap and vector), as well as > implement suitable keyboard layouts used with digitising tablets. /And/ > provide support in the scripting languages that went with them. > > Not particularly demanding in terms of special or quirky characters (or > word-order issues when constructing messages for translation) but it's not > quite the same as my assuming everything was 7-bit ASCII and in English. > > much less other European languages (Russian, Greek), and > >> certainly I had no way of working with non-alphabetic languages >> (Chinese, Japanese). Nor right-to-left languages (Hebrew, Arabic). >> > > Did you really need to work with all those languages, or is this a generic > 'I'. > > > -- > Bartc > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On Fri, Dec 9, 2016 at 12:34 PM, BartC wrote: > With a case-sensitive file system, how do you search only for 'harry', not > knowing what combinations of upper and lower case have been used? (It's a > good thing Google search isn't case sensitive!) This is handled by "case correlations", which aren't quite the same as case conversions. In Python, that's the .casefold() method. You casefold the string "harry", and then casefold every file name that might potentially match, and see if they become the same. Taking my original example string: >>> "ßẞıİÅσςσ".casefold() 'ıi̇åσσσ' Any string that casefolds to that same string should be considered a match. This does NOT stop you from having multiple such files in the directory. >> much less other European languages (Russian, Greek), and >> certainly I had no way of working with non-alphabetic languages >> (Chinese, Japanese). Nor right-to-left languages (Hebrew, Arabic). > > > Did you really need to work with all those languages, or is this a generic > 'I'. In the 90s? No, I didn't, otherwise I'd have had a lot of trouble. Today? Yep. I can, and I do. Not as much as I work with English, but I definitely do support them. Took a good bit of work to make some of the RTL text behaviours the way I wanted them, but everything else was pretty smooth. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Working around multiple files in a folder
Emile van Sebille wrote: > On 11/21/2016 11:27 AM, [email protected] wrote: >> I have a python script where I am trying to read from a list of files >> in a folder and trying to process something. As I try to take out the >> output I am presently appending to a list. >> >> But I am trying to write the result of individual files in individual >> list or files. >> >> The script is as follows: >> >> import glob >> def speed_try(): >> #OPENING THE DICTIONARY >> a4=open("/python27/Dictionaryfile","r").read() >> #CONVERTING DICTIONARY INTO WORDS >> a5=a4.lower().split() >> list1=[] >> for filename in glob.glob('/Python27/*.txt'): >> a1=open(filename,"r").read() >> a2=a1.lower() >> a3=a2.split() >> for word in a3: >> if word in a5: >> a6=a5.index(word) >> a7=a6+1 >> a8=a5[a7] >> a9=word+"/"+a8 >> list1.append(a9) >> elif word not in a5: >> list1.append(word) >> else: >> print "None" >> >> x1=list1 >> x2=" ".join(x1) >> print x2 >> >> Till now, I have tried to experiment over the following solutions: >> >> a) def speed_try(): >>#OPENING THE DICTIONARY >>a4=open("/python27/Dictionaryfile","r").read() >>#CONVERTING DICTIONARY INTO WORDS >>a5=a4.lower().split() >>list1=[] >>for filename in glob.glob('/Python27/*.txt'): >> a1=open(filename,"r").read() >> a2=a1.lower() >> a3=a2.split() >>list1.append(a3) >> >> >> x1=list1 >> print x1 >> >> Looks very close but I am unable to fit the if...elif...else part. >> >> b) import glob >> def multi_filehandle(): >> list_of_files = glob.glob('/Python27/*.txt') >> for file_name in list_of_files: >> FI = open(file_name, 'r') >> FI1=FI.read().split() >> FO = open(file_name.replace('txt', 'out'), 'w') >> for line in FI: > > at this point, there's nothing left to be read from FI having been > fully drained to populate FI1 -- maybe you want to loop over FI1 > instead? > > Emile > > >> FO.write(line) >> >> FI.close() >> FO.close() >> >> I could write output but failing to do processing of the files >> between opening and writing. >> >> I am trying to get examples from fileinput. >> >> If anyone of the learned members may kindly suggest how may I >> proceed. >> >> I am using Python2.x on MS-Windows. >> >> The practices are scripts and not formal codes so I have not followed >> style guides. >> >> Apology for any indentation error. >> >> Thanking in advance. >> >> *goggles in shock* that was painful to read! The best I could make of it was, he's trying to match words in some.txt against a dictionary. (OP) should not code like a horror movie. Try to avoid dismembering your variable names and numbering the body parts like a serial killer. Instead try to pick names that matter. Use functions to hide the gory complexity.. Maybe like this (I dunno what you are doing).. dict_file = '/python27/Dictionaryfile' txt_file_path = '/Python27/*.txt' def open_file(fname, mode='r'): lines = open(fname, mode).read() words = lines.lower().split() return words def get_files(path): file_list = [] for fname in glob.glob(path): file_list.append(fname) return file_list word_list = open_file(dict_file, mode) file_list = get_files(txt_file_path) for fname in file_list: do something and stick this in a func when you know what you were doing Otherwise you'll get minimal help online because your program is unreadable.. in-spite of the frivolous comments. -- https://mail.python.org/mailman/listinfo/python-list
Re: Simple code and suggestion
g thakuri wrote:
> Dear Python friends,
>
> I have a simple question , need your suggestion the same
>
> I would want to avoid using multiple split in the below code , what
> options do we have before tokenising the line?, may be validate the
> first line any other ideas
>
> cmd = 'utility %s' % (file)
> out, err, exitcode = command_runner(cmd)
> data = stdout.strip().split('\n')[0].split()[5][:-2]
>
> Love,
import re
? regex/pattern matching module..
--
https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On Fri, 9 Dec 2016 12:32 pm, Dennis Lee Bieber wrote: > There is always VMS: > > volume:[dir.sub.subsub]fn.ext;ver > > (where volume could be a hardware device or a logical name -- which is NOT > the same as an environment variable; only other place I've seen something > similar is the Amiga -- where DH0: [or HD0: later] was the physical hard > drive 0, SYS: was a logical name for the drive the system was loaded off, > and OS: could have been the volume name assigned when formatting; and > asking for files by volume name rather than drive name would result in a > prompt to insert the named volume into ANY drive slot, and the OS would > figure out where it was; the only time one was asked to insert media into > a specific drive is when there was an open file on the drive -- since open > files went through drive specific file handler instances) Sounds similar to classic Mac OS, where you had: volume:path where the path uses : as directory separators. Removable media (floppies, removable hard drives) could be unplugged and re-inserted into any physical drive, and the OS would track where the media was and whether it was physically mounted or not. -- 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: python 2.7.12 on Linux behaving differently than on Windows
On Thu, Dec 8, 2016, at 20:38, Dennis Lee Bieber wrote: > On Thu, 08 Dec 2016 10:37:27 -0500, Random832 > declaimed the following: > >There are other issues, like needing a way to do Windows' version of > >wildcard parsing with all its quirks, or at least some of its quirks - > >"*.*" for all files and "*." for files not containing any dot being the > >most commonly used in the real world. > > > In the original 8.3 scheme -- no files "contained" a dot Yes, but they do now, and the compatibility quirks persist. At some point in the process *?. are translated to other reserved characters <>" in order to allow the same native functions to perform both the 'quirks mode' and more rigorous logic. -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
Chris Angelico :
> On Fri, Dec 9, 2016 at 10:03 AM, Marko Rauhamaa wrote:
>> I find it a bit annoying that "/" cannot be used in Linux filenames.
>> Slashes have very common everyday uses and it's a pity they are
>> reserved. Instead, ASCII control characters are allowed, which is of
>> no use.
>
> How would you do otherwise? How do you separate directories in a path?
> Remember, it needs to be easy to type, and easy to read. You could
> pick some other keyboard character, but you won't really gain much.
There are numerous ways. For example:
[ "firmware", "CP/M", "2016-12-09" ]
path("firmware", "CP/M", "2016-12-09")
file:///firmware/CP%2fM/2016-12-09
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
Random832 : > On Thu, Dec 8, 2016, at 20:38, Dennis Lee Bieber wrote: >> In the original 8.3 scheme -- no files "contained" a dot > > Yes, but they do now, and the compatibility quirks persist. When porting a Python program to Windows, I noticed the filename "aux" is not allowed in Windows. I suspect it's the same with "lst", "prn", "con" and what not. In Linux, "." and ".." are taboo. So is "". Marko -- https://mail.python.org/mailman/listinfo/python-list
