Is there a better way to create a list of None objects?
Hi, I thought I'd share the following piece of code that I have recently written (a) to check that what I have done is reasonable - even optimum, (b) to inform others who might be wanting to do similar things, and (c) to invite comment from the community. --- # # Yes: Create an empty list of Band Limits for this language # # Note. The rather complicated logic on the right-hand side of the # assignment below is used here because none of the following # alternatives had the desired effect: # # Logic Effect # # [None * 8]TypeError: unsupported operand type(s) for *: ... # [(None) * 8] TypeError: unsupported operand type(s) for *: ... # [((None)) * 8]TypeError: unsupported operand type(s) for *: ... # [(None,) * 8] [(None, None, None, None, None, None, None, None)] # list ((None) * 8) TypeError: unsupported operand type(s) for *: ... # diclll_BLim [thisISO_] = list ((None,) * 8) --- Thanks in anticipation. Stephen Tucker. -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there a better way to create a list of None objects?
On Thu, Aug 12, 2021 at 6:59 PM Stephen Tucker wrote: > > Hi, > > I thought I'd share the following piece of code that I have recently written > (a) to check that what I have done is reasonable - even optimum, > (b) to inform others who might be wanting to do similar things, and > (c) to invite comment from the community. > > --- > > # > > # Yes: Create an empty list of Band Limits for this language > > # > > # Note. The rather complicated logic on the right-hand side of the > > # assignment below is used here because none of the following > > # alternatives had the desired effect: > > # > > # Logic Effect > > # > > # [None * 8]TypeError: unsupported operand type(s) for *: ... > > # [(None) * 8] TypeError: unsupported operand type(s) for *: ... > > # [((None)) * 8]TypeError: unsupported operand type(s) for *: ... > > # [(None,) * 8] [(None, None, None, None, None, None, None, None)] > > # list ((None) * 8) TypeError: unsupported operand type(s) for *: ... > > # > > diclll_BLim [thisISO_] = list ((None,) * 8) > Why not just: [None] * 8 ? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there a better way to create a list of None objects?
You can achieve the same result by writing: [None] * 8 Comparing both cases in IPython I get: In [1]: %timeit list((None,)*8) 110 ns ± 0.785 ns per loop (mean ± std. dev. of 7 runs, 1000 loops each) In [2]: %timeit [None] * 8 88.2 ns ± 0.432 ns per loop (mean ± std. dev. of 7 runs, 1000 loops each) So the list multiplication appears a bit faster. Best Matthieu Le 8/12/2021 à 10:57 AM, Stephen Tucker a écrit : Hi, I thought I'd share the following piece of code that I have recently written (a) to check that what I have done is reasonable - even optimum, (b) to inform others who might be wanting to do similar things, and (c) to invite comment from the community. --- # # Yes: Create an empty list of Band Limits for this language # # Note. The rather complicated logic on the right-hand side of the # assignment below is used here because none of the following # alternatives had the desired effect: # # Logic Effect # # [None * 8]TypeError: unsupported operand type(s) for *: ... # [(None) * 8] TypeError: unsupported operand type(s) for *: ... # [((None)) * 8]TypeError: unsupported operand type(s) for *: ... # [(None,) * 8] [(None, None, None, None, None, None, None, None)] # list ((None) * 8) TypeError: unsupported operand type(s) for *: ... # diclll_BLim [thisISO_] = list ((None,) * 8) --- Thanks in anticipation. Stephen Tucker. -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there a better way to create a list of None objects?
Thanks for this feedback, Chris, Matthieu. Both are spot on - and thanks for the timing comparison, Matthieu. I suppose I didn't think to try the solution you suggest because I didn't think that I would end up with a single list, but 8 of them. OK, I'll stop wriggling. Stephen. On Thu, Aug 12, 2021 at 10:22 AM Matthieu Dartiailh wrote: > You can achieve the same result by writing: > [None] * 8 > > Comparing both cases in IPython I get: > > In [1]: %timeit list((None,)*8) > 110 ns ± 0.785 ns per loop (mean ± std. dev. of 7 runs, 1000 loops > each) > > In [2]: %timeit [None] * 8 > 88.2 ns ± 0.432 ns per loop (mean ± std. dev. of 7 runs, 1000 loops > each) > > So the list multiplication appears a bit faster. > > Best > > Matthieu > > Le 8/12/2021 à 10:57 AM, Stephen Tucker a écrit : > > Hi, > > > > I thought I'd share the following piece of code that I have recently > written > > (a) to check that what I have done is reasonable - even optimum, > > (b) to inform others who might be wanting to do similar things, and > > (c) to invite comment from the community. > > > > --- > > > > # > > > > # Yes: Create an empty list of Band Limits for this language > > > > # > > > > # Note. The rather complicated logic on the right-hand side of the > > > > # assignment below is used here because none of the following > > > > # alternatives had the desired effect: > > > > # > > > > # Logic Effect > > > > # > > > > # [None * 8]TypeError: unsupported operand type(s) for *: ... > > > > # [(None) * 8] TypeError: unsupported operand type(s) for *: ... > > > > # [((None)) * 8]TypeError: unsupported operand type(s) for *: ... > > > > # [(None,) * 8] [(None, None, None, None, None, None, None, None)] > > > > # list ((None) * 8) TypeError: unsupported operand type(s) for *: ... > > > > # > > > > diclll_BLim [thisISO_] = list ((None,) * 8) > > > > > > --- > > > > Thanks in anticipation. > > > > Stephen Tucker. > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there a better way to create a list of None objects?
On Thu, 12 Aug 2021 09:57:33 +0100, Stephen Tucker declaimed the following: > ># Logic Effect > ># > ># [None * 8]TypeError: unsupported operand type(s) for *: ... > ># [(None) * 8] TypeError: unsupported operand type(s) for *: ... > ># [((None)) * 8]TypeError: unsupported operand type(s) for *: ... > ># [(None,) * 8] [(None, None, None, None, None, None, None, None)] > ># list ((None) * 8) TypeError: unsupported operand type(s) for *: ... > In all the above, you've put the *8 INSIDE the list structure. You "working" example is actually creating a TUPLE stored (as the only element) inside a LIST. >>> [None] * 8 [None, None, None, None, None, None, None, None] >>> Creates a LIST of 8 elements, each being None. -- Wulfraed Dennis Lee Bieber AF6VN [email protected]://wlfraed.microdiversity.freeddns.org/ -- https://mail.python.org/mailman/listinfo/python-list
FW: Troubleshoot python app launch
From: [1]Tan Jane Sent: Wednesday, 11 August 2021 7:48 PM To: [2][email protected] Subject: Troubleshoot python app launch Hi, I encountered attached screenshot issue while launching the python application downloaded for windows. Please advice on the above. Thanks, Jane Sent from [3]Mail for Windows 10 References Visible links 1. mailto:[email protected] 2. mailto:[email protected] 3. https://go.microsoft.com/fwlink/?LinkId=550986 -- https://mail.python.org/mailman/listinfo/python-list
Re: on slices, negative indices, which are the equivalent procedures?
On Thu, 12 Aug 2021 13:17:32 +1200, dn via Python-list declaimed the following: >I've been trying to remember if we had negative-steps in FORTRAN >do-loops especially once the capability to define subscripting-ranges >came 'in' (but can't be bothered researching further). If it was >available, or available within other, older languages, then might this >explain Python's adoption? > As part of the DO loop, FORTRAN did allow decrementing -- but one also had then to put the start-end in correct order... DO 10 I = 32, 0, -1 -- Wulfraed Dennis Lee Bieber AF6VN [email protected]://wlfraed.microdiversity.freeddns.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: some problems for an introductory python test
Chris Angelico writes:
[...]
>> > [1] And boy oh boy was that good fun. The OS/2 Presentation Manager
>> > had a wealth of power available. Good times, sad that's history now.
>>
>> I know OS/2 only by name. I never had the pleasure of using it. In
>> fact, I don't even know how it looks. I must be a little younger than
>> you are. But not too younger because I kinda remember its name. Was it
>> a system that might have thought of competing against Microsoft Windows?
>> :-) That's what my memory tells me about it.
>
> History lesson!
>
> Once upon a time, IBM and Microsoft looked at what Intel was
> producing, and went, hey, we need to design an operating system that
> can take advantage of the fancy features of this 80286 thing. So they
> collaborate on this plan to make a 16-bit protected mode OS.
> Unfortunately, things didn't work out too well, partly because this
> was when Microsoft was at its most monopolistic, and they ended up
> parting company. IBM continued to make OS/2, but Microsoft took their
> part of the code and made Windows NT out of it.
How is it possible that Microsoft would take part of the code of OS/2?
Did IBM just hand it to them?
> (Aside: Windows NT's 16-bit applications and OS/2's 16-bit
> applications were actually identical and compatible. Unfortunately,
> Win32 introduced a very new API, so as soon as everyone moved to
> 32-bit everything, the schism became problematic. But it was actually
> possible to package up a single .EXE file with a 16-bit MS-DOS loader,
> a Win32 loader, and an OS/2 32-bit loader, all happily coexisting.
Beautiful. :-) So if all libraries were around in each system, they had
perfect compatibility?
> In the latter half of the 1990s, Windows came in three broad flavours:
> the 16-bit Windows 3.x line, which ran purely on top of DOS; the
> 32-bit Windows 95 line, which was the "home" OS and had to be heavily
> compatible with Windows 3, but still doing more things; and the
> Windows NT line, which was aimed at businesses. OS/2 was a viable
> option for businesses, but almost nobody took it seriously as a home
> OS. And Microsoft was using its marketing machine to push Windows
> fairly hard, so most people went that way.
>
> OS/2 had all kinds of amazing features (for its time). The default
> file system, HPFS ("High Performance File System"... IBM was good at
> many things, but imaginative naming wasn't one of them), did a
> spectacular job of maintaining reliability and performance on the
> ever-growing hard disks of the time. Yes, it coped remarkably well,
> even on *gigantic* drives that could carry, ooh, an entire gigabyte of
> data! I'm not kidding! We even had a drive that had TWO gigabytes of
> space, and HPFS managed it beautifully! Plus, it had this fancy
> concept of "extended attributes"; on older systems (like MS-DOS's
> "FAT" family), a file might be Read-Only, Hidden, a System file, or
> needing to be Archived, and that was it - but on HPFS, you could
> attach arbitrary data like "File type: DeScribe Word Processor" or
> "Double click action: Run CASMake.cmd". This allowed the GUI to store
> all kinds of information *on the file itself* instead of needing
> hidden files (or, in Windows' case, the registry) to track that kind
> of thing.
Yeah, that's kinda nice. Isn't that a UNIX design? A file is a
sequence of bytes? Users decide what to put in them? So OS/2 was
taking advantage of that to integrate it well with the system. Windows
was doing the same, but integrating the system with files in odd ways
--- such as a registry record to inform the system which programs open
which files? (That does sound more messy.)
UNIX's execve() is able to read the first line of an executable and
invoke its interpreter. I guess OS/2 was doing precisely that in a
different way?
> The default command interpreter and shell on OS/2 was fairly primitive
> by today's standards, and was highly compatible with the MS-DOS one,
> but it also had the ability to run REXX scripts. REXX was *way* ahead
> of its time. It's a shell language but remarkably well suited to
> building GUIs and other tools (seriously, can you imagine designing a
> GUI entirely in a bash script??).
I cannot imagine. I always wondered what REXX was about --- I saw
programs sometimes written in some website whose name is something like
Rosetta Code. REXX looked so weird. (``Who would program in that?'')
But I see now there is a context to it.
> It had features that we'd consider fairly normal or even primitive by
> Python's standards, but back then, Python was extremely new and didn't
> really have very much mindshare. REXX offered arbitrary-precision
> arithmetic, good databasing support, a solid C API that made it easy
> to extend, integrations with a variety of other systems... this was
> good stuff for its day. (REXX is still around, but these days, I'd
> rather use Python.)
Yeah, REXX looks horrible at first. But arbitrary-precision is
definitely very attractive.
Re: FW: Troubleshoot python app launch
On 2021-08-12 03:31, Tan Jane wrote: From: [1]Tan Jane Sent: Wednesday, 11 August 2021 7:48 PM To: [2][email protected] Subject: Troubleshoot python app launch Hi, I encountered attached screenshot issue while launching the python application downloaded for windows. Please advice on the above. This list strips attachments. Please copy and paste the error. -- https://mail.python.org/mailman/listinfo/python-list
Re: some problems for an introductory python test
On Fri, Aug 13, 2021 at 2:15 AM Hope Rouselle wrote: > > Chris Angelico writes: > > > History lesson! > > > > Once upon a time, IBM and Microsoft looked at what Intel was > > producing, and went, hey, we need to design an operating system that > > can take advantage of the fancy features of this 80286 thing. So they > > collaborate on this plan to make a 16-bit protected mode OS. > > Unfortunately, things didn't work out too well, partly because this > > was when Microsoft was at its most monopolistic, and they ended up > > parting company. IBM continued to make OS/2, but Microsoft took their > > part of the code and made Windows NT out of it. > > How is it possible that Microsoft would take part of the code of OS/2? > Did IBM just hand it to them? I presume both companies had all of the code. It was a matter of licensing, though. There were a few components that were saddled with awkward restrictions due to the dual ownership (for instance, HPFS386 was Microsoft-controlled, but vanilla HPFS was fine - kinda like the difference between LZW and LZ77). > > (Aside: Windows NT's 16-bit applications and OS/2's 16-bit > > applications were actually identical and compatible. Unfortunately, > > Win32 introduced a very new API, so as soon as everyone moved to > > 32-bit everything, the schism became problematic. But it was actually > > possible to package up a single .EXE file with a 16-bit MS-DOS loader, > > a Win32 loader, and an OS/2 32-bit loader, all happily coexisting. > > Beautiful. :-) So if all libraries were around in each system, they had > perfect compatibility? The 16-bit loaders were fine, but the 32-bit loaders were different, so this trick basically meant having three different copies of the code wrapped up in a single executable. > > Plus, it had this fancy > > concept of "extended attributes"; on older systems (like MS-DOS's > > "FAT" family), a file might be Read-Only, Hidden, a System file, or > > needing to be Archived, and that was it - but on HPFS, you could > > attach arbitrary data like "File type: DeScribe Word Processor" or > > "Double click action: Run CASMake.cmd". This allowed the GUI to store > > all kinds of information *on the file itself* instead of needing > > hidden files (or, in Windows' case, the registry) to track that kind > > of thing. > > Yeah, that's kinda nice. Isn't that a UNIX design? A file is a > sequence of bytes? Users decide what to put in them? So OS/2 was > taking advantage of that to integrate it well with the system. Windows > was doing the same, but integrating the system with files in odd ways > --- such as a registry record to inform the system which programs open > which files? (That does sound more messy.) Something like that, but with a lot more metadata. Modern OSes don't seem to work that way any more. > UNIX's execve() is able to read the first line of an executable and > invoke its interpreter. I guess OS/2 was doing precisely that in a > different way? Kinda, but instead of having the choice of interpreter be inside the file contents itself, the choice was in the file's metadata. Still part of the file, but if you open and read the file, it isn't any different. > > The default command interpreter and shell on OS/2 was fairly primitive > > by today's standards, and was highly compatible with the MS-DOS one, > > but it also had the ability to run REXX scripts. REXX was *way* ahead > > of its time. It's a shell language but remarkably well suited to > > building GUIs and other tools (seriously, can you imagine designing a > > GUI entirely in a bash script??). > > I cannot imagine. I always wondered what REXX was about --- I saw > programs sometimes written in some website whose name is something like > Rosetta Code. REXX looked so weird. (``Who would program in that?'') > But I see now there is a context to it. Yeah. It was a strange choice by today's standards, but back then, most of my GUI programs were written in REXX. https://en.wikipedia.org/wiki/VX-REXX http://www.edm2.com/0206/vrexx.html (There were other tools too - VisPro REXX, VREXX, DrDialog, and various others - but VX-REXX was where most of my dev work happened.) > > Probably the most > > notable feature, by today's standards, was that it had a single input > > queue. ... This means that, if the response to a > > keystroke is to change focus, then *even in a slow and lagged out > > system*, subsequent keys WOULD be sent to the new target window. That > > was AWESOME, and I really miss it. Except that I also don't. Because > > if a single application is having issues, now your entire keyboard and > > mouse is locked up... which kinda slightly sucks. Good luck resolving > > that problem. (We had some neat tools like WatchCat that could get > > around the single input queue via interrupt signals, and regain > > control. But it was still problematic.) > > Wow, I kinda feel the same as you here. I think this justifies perhaps > using a hardware solution. (Crazy idea?! L
Re: some problems for an introductory python test
On 2021-08-12, Hope Rouselle wrote: >> OS/2 had all kinds of amazing features (for its time). [...] Plus, >> it had this fancy concept of "extended attributes"; on older >> systems (like MS-DOS's "FAT" family), a file might be Read-Only, >> Hidden, a System file, or needing to be Archived, and that was it - >> but on HPFS, you could attach arbitrary data like "File type: >> DeScribe Word Processor" or "Double click action: Run >> CASMake.cmd". This allowed the GUI to store all kinds of >> information *on the file itself* instead of needing hidden files >> (or, in Windows' case, the registry) to track that kind of thing. > > Yeah, that's kinda nice. Isn't that a UNIX design? A file is a > sequence of bytes? Users decide what to put in them? I think what he's talking about is allowing the user to attach arbitrary _metadata_ to the file -- metadata that exists separately and independently from the normal data that's just a "sequence of bytes". IOW, something similar to the "resource fork" that MacOS used to have. https://en.wikipedia.org/wiki/Resource_fork > So OS/2 was taking advantage of that to integrate it well with the > system. Windows was doing the same, but integrating the system with > files in odd ways --- such as a registry record to inform the system > which programs open which files? (That does sound more messy.) Windows never had filesystems that supported metadata like OS/2 and MacOS did. The registry was an ugly hack that attempted (very poorly) to make up for that lack of metadata. > UNIX's execve() is able to read the first line of an executable and > invoke its interpreter. I guess OS/2 was doing precisely that in a > different way? No, that's not at all the same thing. The #! line is part of the normal file data. It's part of the 'sequence of bytes'. Metadata maintained by Unix filesystems comprises a very limited and pre-defined set of attributes present in the inode. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: some problems for an introductory python test
On Fri, Aug 13, 2021 at 5:03 AM Grant Edwards wrote: > > On 2021-08-12, Hope Rouselle wrote: > > >> OS/2 had all kinds of amazing features (for its time). [...] Plus, > >> it had this fancy concept of "extended attributes"; on older > >> systems (like MS-DOS's "FAT" family), a file might be Read-Only, > >> Hidden, a System file, or needing to be Archived, and that was it - > >> but on HPFS, you could attach arbitrary data like "File type: > >> DeScribe Word Processor" or "Double click action: Run > >> CASMake.cmd". This allowed the GUI to store all kinds of > >> information *on the file itself* instead of needing hidden files > >> (or, in Windows' case, the registry) to track that kind of thing. > > > > Yeah, that's kinda nice. Isn't that a UNIX design? A file is a > > sequence of bytes? Users decide what to put in them? > > I think what he's talking about is allowing the user to attach > arbitrary _metadata_ to the file -- metadata that exists separately > and independently from the normal data that's just a "sequence of > bytes". IOW, something similar to the "resource fork" that MacOS used > to have. https://en.wikipedia.org/wiki/Resource_fork Correct. OS/2's EAs are name/value pairs (with the value potentially being a set of values - think how a Python dict maps keys to values, but the values could be lists), with a few names having significance to the system, like .TYPE and .LONGNAME (used on file systems that didn't support longnames - yes, that's possible, since EAs could be stored in a hidden file on a FAT disk). > > So OS/2 was taking advantage of that to integrate it well with the > > system. Windows was doing the same, but integrating the system with > > files in odd ways --- such as a registry record to inform the system > > which programs open which files? (That does sound more messy.) > > Windows never had filesystems that supported metadata like OS/2 and > MacOS did. The registry was an ugly hack that attempted (very poorly) > to make up for that lack of metadata. Very poor indeed - it was very very common back then for Windows programs to blat themselves all over the registry and then leave it all behind when you nuke that thing. With EAs, it's all part of the file itself and will be cleaned up by a simple directory removal. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: some problems for an introductory python test
On 2021-08-12 18:52, Grant Edwards wrote: On 2021-08-12, Hope Rouselle wrote: OS/2 had all kinds of amazing features (for its time). [...] Plus, it had this fancy concept of "extended attributes"; on older systems (like MS-DOS's "FAT" family), a file might be Read-Only, Hidden, a System file, or needing to be Archived, and that was it - but on HPFS, you could attach arbitrary data like "File type: DeScribe Word Processor" or "Double click action: Run CASMake.cmd". This allowed the GUI to store all kinds of information *on the file itself* instead of needing hidden files (or, in Windows' case, the registry) to track that kind of thing. Yeah, that's kinda nice. Isn't that a UNIX design? A file is a sequence of bytes? Users decide what to put in them? I think what he's talking about is allowing the user to attach arbitrary _metadata_ to the file -- metadata that exists separately and independently from the normal data that's just a "sequence of bytes". IOW, something similar to the "resource fork" that MacOS used to have. https://en.wikipedia.org/wiki/Resource_fork So OS/2 was taking advantage of that to integrate it well with the system. Windows was doing the same, but integrating the system with files in odd ways --- such as a registry record to inform the system which programs open which files? (That does sound more messy.) Windows never had filesystems that supported metadata like OS/2 and MacOS did. The registry was an ugly hack that attempted (very poorly) to make up for that lack of metadata. FYI, NTFS does support Alternate Data Streams. UNIX's execve() is able to read the first line of an executable and invoke its interpreter. I guess OS/2 was doing precisely that in a different way? No, that's not at all the same thing. The #! line is part of the normal file data. It's part of the 'sequence of bytes'. Metadata maintained by Unix filesystems comprises a very limited and pre-defined set of attributes present in the inode. -- https://mail.python.org/mailman/listinfo/python-list
Re: some problems for an introductory python test
On Thu, 12 Aug 2021 12:09:58 -0300, Hope Rouselle declaimed the following: >How is it possible that Microsoft would take part of the code of OS/2? >Did IBM just hand it to them? > Because IBM subcontracted (IE: "paid") M$ to create an OS with XYZ features for their latest PC (under supervision of IBM design team).. https://en.wikipedia.org/wiki/OS/2 IBM owned the rights to OS/2, but it was written, for the most part, by M$ in parallel with M$ own "Windows" 16-bit OS. > >Yeah, that's kinda nice. Isn't that a UNIX design? A file is a >sequence of bytes? Users decide what to put in them? So OS/2 was >taking advantage of that to integrate it well with the system. Windows >was doing the same, but integrating the system with files in odd ways >--- such as a registry record to inform the system which programs open >which files? (That does sound more messy.) > Not really -- Have you looked at what a hash Linux graphical interfaces require to associate file types with how to open said files? On my Debian (VirtualBox) there is: wulfraed@debian:~$ cat ~/.config/mimeapps.list [Added Associations] text/html=firefox-esr.desktop; text/plain=gvim.desktop; x-scheme-handler/http=exo-web-browser.desktop x-scheme-handler/https=exo-web-browser.desktop x-scheme-handler/mailto=exo-mail-reader.desktop application/xml=gvim.desktop; text/x-scheme=gvim.desktop; application/vnd.kde.kxmlguirc=gvim.desktop; text/x-python=gvim.desktop; application/x-shellscript=gvim.desktop; [Default Applications] wulfraed@debian:~$ ... and all these wulfraed@debian:~$ ls /usr/share/applications atril.desktoppanel-desktop-handler.desktop claws-mail.desktop panel-preferences.desktop ... debian-uxterm.desktoppython3.7.desktop ... org.thonny.Thonny.desktopxsane.desktop org.xfce.Parole.desktop wulfraed@debian:~$ wulfraed@debian:~$ cat /usr/share/applications/python3.7.desktop [Desktop Entry] Name=Python (v3.7) Comment=Python Interpreter (v3.7) Exec=/usr/bin/python3.7 Icon=/usr/share/pixmaps/python3.7.xpm Terminal=true Type=Application Categories=Development; StartupNotify=true NoDisplay=true wulfraed@debian:~$ wulfraed@debian:~$ cat /etc/mime.types ### # # MIME media types and the extensions that represent them. # # The format of this file is a media type on the left and zero or more # filename extensions on the right. Programs using this file will map # files ending with those extensions to the associated type. # # This file is part of the "mime-support" package. Please report a bug using # the "reportbug" command of the "reportbug" package if you would like new # types or extensions to be added. # # The reason that all types are managed by the mime-support package instead # allowing individual packages to install types in much the same way as they # add entries in to the mailcap file is so these types can be referenced by # other programs (such as a web server) even if the specific support package # for that type is not installed. # # Users can add their own types if they wish by creating a ".mime.types" # file in their home directory. Definitions included there will take # precedence over those listed here. # ### application/activemessage application/andrew-insetez application/annodex anx application/applefile application/atom+xmlatom ... application/x-python-code pyc pyo ... text/x-python py ... wulfraed@debian:~$ cat /usr/share/applications/gvim.desktop [Desktop Entry] Name=gVim GenericName=Text Editor ... TryExec=gvim Exec=gvim -f %F Terminal=false Type=Application Keywords=Text;editor; Icon=gvim Categories=Utility;TextEditor;Development; StartupNotify=true MimeType=text/english;text/plain;text/x-makefile;text/x-c++hdr;text/x-c++src;text/x-chdr;text/x-csrc;text/x-java;text/x-moc;text/x-pascal;text/x-tcl;text/x-tex;application/x-shellscript;text/x-c;text/x-c++;text/x-python;text/x-python3 wulfraed@debian:~$ ALL of that is needed to link a Python source code file (.py) to GVIM editor, when clicked on from the desktop. >UNIX's execve() is able to read the first line of an executable and >invoke its interpreter. I guess OS/2 was doing precisely that in a >different way? > No... the UNIX/Linux shebang (and binary file equivalent magic-number) is a deliberately written part of a file's "data" content (granted, the linker writes it for executable binaries). The description for OS/2 is close to the little used Windows STREAMS feature. https://docs.microsoft.com/en-us/windows/win32/fileio/file-streams
Re: some problems for an introductory python test
On 2021-08-12, MRAB wrote: > >> Windows never had filesystems that supported metadata like OS/2 and >> MacOS did. The registry was an ugly hack that attempted (very poorly) >> to make up for that lack of metadata. >> > FYI, NTFS does support Alternate Data Streams. That is interesting -- and it was apparently intended to provide some sort of compatibility with MacOS data fork and resource fork. According to one article I found, nobody ever seems to have put that NTFS feature to use for anything other than hiding malware. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: some problems for an introductory python test
On Fri, 13 Aug 2021 04:41:42 +1000, Chris Angelico declaimed the following: >Yeah. It was a strange choice by today's standards, but back then, >most of my GUI programs were written in REXX. > >https://en.wikipedia.org/wiki/VX-REXX >http://www.edm2.com/0206/vrexx.html > There was a library for the Amiga ARexx that supported basic GUI implementation too... >And of COURSE nobody would ever take an old serial mouse, take the >ball out of it, and turn it into a foot-controlled signal... although Of course not -- you'd want an old joyboard for that https://en.wikipedia.org/wiki/Joyboard > >SysRq should theoretically be that. (That's Alt+PrtSc on a lot of >keyboards.) I'm not sure how it could best be handled though. It might While so marked, Windows, at least, interprets as "grab image of current Window", whereas is "grab image of entire display". >be that today's GUI systems (X11, Wayland, Cocoa, Win32, etc) just >wouldn't work with a single input queue. Would be curious to see if >any modern OS/GUI pair has a synchronous input queue like that. > Not "modern" in this era, but I'm fairly certain the Amiga used a single stream queue. But that stream was fed to every application running, leaving it up to the application to determine if the event was something it had to handle, or pass on further. It was also fairly easy to inject events into the stream (which could help finding some of the easter eggs in the OS -- rather difficult to hold down , , , , AND, while holding them down, eject and insert a floppy disk. [without the floppy, to put up a credits display for the people who had worked on parts of the OS... The floppy mess then brought up a display with approximately "we created Amiga, CBM messed it up"]) -- Wulfraed Dennis Lee Bieber AF6VN [email protected]://wlfraed.microdiversity.freeddns.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: some problems for an introductory python test
On 11Aug2021 09:11, Hope Rouselle wrote:
>Greg Ewing writes:
>> That may not be doing what you think it's doing. Consider also
>>
> if0: print('yes!')
>> yes!
>
>So, yes, that's puzzling.
>
0 == False
>True
if0: print("yes")
>yes
if(0): print("yes")
>
>
>What's going on there?
1: "if0" does not mean "if 0"; "if0" is a valid identifier. Like "x0", "x1".
2: It took me a while to see, but this is a type annotiation.
This line:
if0: print('yes!')
says that the name "if0" should contain a value described by the return
value of the expression "print('yes!')". Like this:
label : str
says that we expect a string in the variable "label".
Remember that Python is strongly typed, but variables may reference
objects of any type. Type annotations are optional things reflecting
that in practice most variables are expected to reference specific
types. This lets is run static linters against programmes to catch
mistakes exposed by the type descriptions.
Also, type annotations have _no_ runtime effect. So if that expression
returns an invalid type description, nobody cares!
However, if you hand this code to a type aware linter such as mypy you
might get bitter complaints about nonsense. (Or, since print() returns
None, no complaint - it just means you expect this variable to hold the
value None. You'd get complaints about unused variables etc.)
Cheers,
Cameron Simpson
--
https://mail.python.org/mailman/listinfo/python-list
Re: some problems for an introductory python test
On 12Aug2021 12:09, Hope Rouselle wrote: >Chris Angelico writes: >> [...] Plus, it had this fancy >> concept of "extended attributes"; on older systems (like MS-DOS's >> "FAT" family), a file might be Read-Only, Hidden, a System file, or >> needing to be Archived, and that was it - but on HPFS, you could >> attach arbitrary data like "File type: DeScribe Word Processor" or >> "Double click action: Run CASMake.cmd". This allowed the GUI to store >> all kinds of information *on the file itself* instead of needing >> hidden files (or, in Windows' case, the registry) to track that kind >> of thing. > >Yeah, that's kinda nice. Isn't that a UNIX design? A file is a >sequence of bytes? Users decide what to put in them? Yes, but extended attributes are outside the file data. They're very common on UNIX platforms these days. You can label arbitrary files with a file type or whatever else. (There are platform specific limitations, and even the OS API to deal with them is platform specific - Linux is different to FreeBSD is different to MacOS.) Also, Python has support for accessing these off-to-the-side data: https://docs.python.org/3/library/os.html#linux-extended-attributes Labelled "Linux" but also available for FreeBSD and IIRC OpenBSD. You do of course need filesystem support - FAT32 for example would not work with this - the filesystem needs a way to store these things. But ext4 and XFS on Linux, HFS+ on MacOS etc all support this. I've even got a CPython branch where I'm implementing the MacOS backend for these calls, a little stalled. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: some problems for an introductory python test
On 13/08/21 11:42 am, Cameron Simpson wrote:
2: It took me a while to see, but this is a type annotiation.
Interestingly, it seems to be parsed as a form of assignment with
a missing RHS.
>>> from ast import parse, dump
>>> dump(parse("if0: print('yes!')"))
"Module(body=[AnnAssign(target=Name(id='if0', ctx=Store()),
annotation=Call(func=Name(id='print', ctx=Load()),
args=[Constant(value='yes!', kind=None)], keywords=[]), value=None,
simple=1)], type_ignores=[])"
"An annotated assignment without the assignment? Eeuurgh!"
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
Re: some problems for an introductory python test
On 13/08/21 5:52 am, Grant Edwards wrote: I think what he's talking about is allowing the user to attach arbitrary _metadata_ to the file ... IOW, something similar to the > "resource fork" that MacOS used to have. The resource fork was used for more than just metadata, it was often the entire contents of the file. Applications had all the code in there, for example -- the data fork of an application was usually empty. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
pip doesn't work
So, whoever gets this, when I try to download packages using pip, it shows errors saying "'pip' is not recognized as an internal or external command, operable program or batch file." Is there a way to solve this? I tried modifying, even repairing three times, but still it doesn't work. If you have a solution, thank you. -- https://mail.python.org/mailman/listinfo/python-list
Re: pip doesn't work
On 13/08/2021 06:49, Ridit wrote: So, whoever gets this, when I try to download packages using pip, it shows errors saying "'pip' is not recognized as an internal or external command, operable program or batch file." Is there a way to solve this? I tried modifying, even repairing three times, but still it doesn't work. If you have a solution, thank you. Try invoking it with py -m pip ... instead of just pip ... -- https://mail.python.org/mailman/listinfo/python-list
