Re: on slices, negative indices, which are the equivalent procedures?
Hope Rouselle writes: > Hope Rouselle writes: > >> Dennis Lee Bieber writes: >> >>> On Sun, 15 Aug 2021 00:05:29 -0300, Jack Brandom >>> declaimed the following: >>> Dennis Lee Bieber writes: >>> > subscript: '.' '.' '.' | test | [test] ':' [test] [sliceop] > sliceop: ':' [test] >>> This is looking less readable, so, no, I prefer that previous, which was much clearer about slices. I can't even quite make the slices out in these rules. (But thanks for the opportunity to try.) >>> >>> The last part of "subscript" has the main "slice" notation (stripping >>> the quotes) >>> >>> [test] : [test] >>> >>> and the "stride" component is [sliceop] being >>> >>> : [test] >> >> Let's see. Let ``-->'' mean ``expands to''. Then >> >> subscript >> --> [test] ':' [test] [sliceop] >> --> [test] ':' [test] ':' [test] >> >> Does the brackets mean that its content count be omitted? > ^ > > _Do_ the brackets mean that its content _can_ be omitted? (This is ^^^ > really too much coffee. It's crazy where my attention goes.) Lol. Should I say _their_ content? I guess so. :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: on slices, negative indices, which are the equivalent procedures?
Hope Rouselle writes: > Dennis Lee Bieber writes: > >> On Sun, 15 Aug 2021 00:05:29 -0300, Jack Brandom >> declaimed the following: >> >>>Dennis Lee Bieber writes: >>> >> subscript: '.' '.' '.' | test | [test] ':' [test] [sliceop] sliceop: ':' [test] >> >>> >>>This is looking less readable, so, no, I prefer that previous, which was >>>much clearer about slices. I can't even quite make the slices out in >>>these rules. (But thanks for the opportunity to try.) >> >> The last part of "subscript" has the main "slice" notation (stripping >> the quotes) >> >> [test] : [test] >> >> and the "stride" component is [sliceop] being >> >> : [test] > > Let's see. Let ``-->'' mean ``expands to''. Then > > subscript > --> [test] ':' [test] [sliceop] > --> [test] ':' [test] ':' [test] > > Does the brackets mean that its content count be omitted? ^ _Do_ the brackets mean that its content _can_ be omitted? (This is really too much coffee. It's crazy where my attention goes.) -- https://mail.python.org/mailman/listinfo/python-list
Re: on perhaps unloading modules?
Greg Ewing writes:
> On 21/08/21 6:15 am, Hope Rouselle wrote:
> code()
>> 'def p():\n import math\n return math.e\n'
> exec(code())
> p
>>
> p()
>> 2.718281828459045
>
> Note that this pollutes the globals of the module that you're calling
> exec() from. For better isolation you can pass in an explicit globals
> dict:
>
> g = {}
> exec(code(), g)
> g['p']()
Oh! Now I understand how to use it! That's in fact what I was looking
for. I noticed it was polluting my environment and was thinking --- hm,
that's no good. Thank you.
So I believe I understand how to pollute their environment too. Say I
have a procedure called external that I'd like to make available to
them. It seems this is what I need to do.
--8<---cut here---start->8---
def external():
return "external"
def run():
s = """
def s(*args):
import math
return external(), math.e, args
"""
g = {}
exec(s, g)
g["external"] = external
return g
--8<---cut here---end--->8---
>>> student["s"](1, 2)
('external', 2.718281828459045, (1, 2))
That's good. So I can restrict their environment too, by removing some
built-ins and so on. (I wish I could restrict their syntax too, though,
but I fear that's not possible. For instance, it would be very useful
if I could remove loops. If the course doesn't let them use them, it is
silly to have to ask them kindly not to use them --- please be patient
with this poorly designed course. In reality there is a whole
department learning to run a course and there are many students helping
this department get a passing grade into how to do it.) :-D
Anyhow, your ideas have improved the outlook of this grader quite a lot.
Thank you!
--
https://mail.python.org/mailman/listinfo/python-list
Re: on perhaps unloading modules?
On 21/08/21 6:15 am, Hope Rouselle wrote:
code()
'def p():\n import math\n return math.e\n'
exec(code())
p
p()
2.718281828459045
Note that this pollutes the globals of the module that you're calling
exec() from. For better isolation you can pass in an explicit globals
dict:
g = {}
exec(code(), g)
g['p']()
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dogelog Runtime, Prolog to the Moon (2021)
We = Me and my cat named socrates
The cat is a very good programmer:
def meow():
print("meow meow, Prolog is not only SWI-Prolog")
Julio Di Egidio schrieb:
On Sunday, 15 August 2021 at 14:43:42 UTC+2, Mostowski Collapse wrote:
Yesterday we went into a little programming binge
Who is this "we"?
See also:
Python Version of Dogelog Runtime special
https://twitter.com/dogelogch/status/1426884473988292617
Python Version of Dogelog Runtime special
https://www.facebook.com/groups/dogelog
I haven't tried either but, assuming the code works ;), great stuff man.
You might be the one(s) who save Prolog from oblivion...
Julio
--
https://mail.python.org/mailman/listinfo/python-list
Re: on perhaps unloading modules?
Chris Angelico writes: > On Tue, Aug 17, 2021 at 4:02 AM Greg Ewing > wrote: >> The second best way would be to not use import_module, but to >> exec() the student's code. That way you don't create an entry in >> sys.modules and don't have to worry about somehow unloading the >> module. > > I would agree with this. If you need to mess around with modules and > you don't want them to be cached, avoid the normal "import" mechanism, > and just exec yourself a module's worth of code. This is looks very interesting. --8<---cut here---start->8--- Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:01:18) [MSC v.1900 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> >>> code >>> code() 'def p():\n import math\n return math.e\n' >>> p Traceback (most recent call last): File "", line 1, in NameError: name 'p' is not defined >>> exec(code()) >>> p >>> p() 2.718281828459045 --8<---cut here---end--->8--- This is also totally unsafe, right? But at least it won't give me those loading problems I had before. But I think I'm gonna go with Greg Ewing's first option --- running it all on a separate process, computing that report I was computing, then printing it out to the stdout and reading it from a controller process to know the student's results. This way I'm one step closer to safety --- I could chroot it and give it a limited period of time for execution. I suppose I could also customize Python's environment to only allow the modules I'd like to allow as well as the builtins I'd like to allow. (That would be interesting as well.) So, alright, let me learn how to spawn a process. Thanks very much. -- https://mail.python.org/mailman/listinfo/python-list
Re: on slices, negative indices, which are the equivalent procedures?
Dennis Lee Bieber writes: > On Sun, 15 Aug 2021 00:05:29 -0300, Jack Brandom > declaimed the following: > >>Dennis Lee Bieber writes: >> > >>> subscript: '.' '.' '.' | test | [test] ':' [test] [sliceop] >>> sliceop: ':' [test] > >> >>This is looking less readable, so, no, I prefer that previous, which was >>much clearer about slices. I can't even quite make the slices out in >>these rules. (But thanks for the opportunity to try.) > > The last part of "subscript" has the main "slice" notation (stripping > the quotes) > > [test] : [test] > > and the "stride" component is [sliceop] being > > : [test] Let's see. Let ``-->'' mean ``expands to''. Then subscript --> [test] ':' [test] [sliceop] --> [test] ':' [test] ':' [test] Does the brackets mean that its content count be omitted? -- https://mail.python.org/mailman/listinfo/python-list
Re: some problems for an introductory python test
Dennis Lee Bieber writes: > On Sun, 15 Aug 2021 00:15:58 -0300, Hope Rouselle > declaimed the following: > > Giganews seems to have just vomited up three days worth of traffic... > >>Dennis Lee Bieber writes: >> >>> >>> Granted, the fact that the Amiga used a shared common address space for >>> all running applications made IPC quite easy -- one looked up the >>> application message port, then added a small packet to the linked list >>> associated with the port. That small packet basically held the address of >>> the message port for returning data, and the address of the data being >>> passed. The closet thing I've seen to that capability on systems with >>> process-isolated virtual memory is (Open)VMS "mailbox" structures. The >>> difference being that the entire data had to be written (QIO) to the >>> mailbox, and the receiver had to read (another QIO call) the message -- >>> this allowed the address space to change. >>> >>> I've not seen anything equivalent in my light perusal of the Win32 API >>> (the various guide books aren't layed out in any way to be a reference), >>> and Linux seems to use UNIX sockets for IPC... No way to search for a >>> connection point by name... >> >>I don't know anything about Amiga, REXX et cetera, so I might be totall >>off here. But since you spoke of your perusal of the Win32 API, let me >>add a tiny bit. I gave myself a quick tour through the Win32 API using >>Pavel Yosifovich's book ``Windows 10 System Programming''. It's a two >>volume work. The thing that impressed me the most was the many ways to >>do the IPC. The purpose the work is clearly to show what is available >>and it it probably does the job well. (I ignored Windows for most of my >>life and now I decided to take a look at it. I don't feel it has much >>of the elegance of UNIX. It's what it is.) > > For a book that was published only a year ago -- it seems to be hard to > find... Amazon has v1, but not v2. Indeed. I believe it's because it's not quite released yet. I had found it here: https://leanpub.com/windows10systemprogrammingpart2 And this seems to be a sort-of-early-release. I'm not really sure. > I have the "Windows Internals 6th" both volumes. > > The closet those get to IPC is something called ALPC -- and that is > declared to be internal only, not available to third party programmers. > > "Programming Windows 6th" is focused on using C# (which, for the most > part, means using the "managed" API, not the Win32 API directly). Makes sense. > "Mailslots" (I'm using Google to find Windows IPC options) initially > sound close to Amiga message ports... Except there is no status return > inherent to the system; Amiga messages contain a return address so a > program can wait for the status of processing by the destination address. > They also don't qualify as VMS mailboxes as there can only be one reader > (the creator of the mailslot). VMS mailboxes allow multiple writers and/or > multiple readers. > > "File mapping" doesn't provide any form of queuing -- multiple > "writers" would require manually implementing some protocol to track "next > available space" in the mapped file. It would allow bidirectional message > passing, but again that requires some rather nasty overhead information > (when is the return status valid -- it is presumed the client wanting the > return status would get it from the same memory space as the message it > sent, and that space can't be reused until the client explicitly frees it > -- again by some overhead protocol changing headers of free space. > > "Data Copy" also sounds close to Amiga message ports (closer than > "Mailslots"), but the online documentation doesn't indicate if it queues > messages. The documentation doesn't illustrate HOW to return TRUE or FALSE > (processed/rejected). It advices that the receiver should treat the data as > read-only -- though I have to wonder if it /could/ write a return status > into the same message structure before "returning TRUE". > > Named Pipes and Sockets both have the "tied to endpoints" problem, and > in the case of Pipes, may only allow one sender to connect at a time > (sockets are also one connection, but normally the receivers spawns a > thread for each active connection and the connections are made using > different allocated sockets). Thanks for these summaries! -- https://mail.python.org/mailman/listinfo/python-list
Re: port to PDOS (especially mainframe)
On Saturday, April 17, 2021 at 11:12:38 PM UTC+10, Paul Edwards wrote: > https://github.com/s390guy/SATK/commits/master/README > > and I can see that on 2014-08-13 he cited 3.3 as an > explicit requirement. Note that the work I was doing to make a C90-compliant version of Python 3.3 hasn't progressed since late June 2021. You can see my work to date in python*.zip in custom.zip at http://pdos.org C:\devel\python\Modules>pdmake -f makefile.w32 BFN. Paul. -- https://mail.python.org/mailman/listinfo/python-list
Making command-line args available to deeply-nested functions
Hi, TL;DR: If I have a command-line argument for a program, what is the best way of making this available to a deeply-nested[1] function call without passing the parameter through every intermediate function? Long version: If I have, say, a command-line program to send an email with a personalised salutation, a naive approach to the function calls might look like the following create_email(..., args.salutation_server_credentials) create_body(..., args.salutation_server_credentials) create_salutation(..., args.salutation_server_credentials) where args.salutation_server_credentials could be given on the command-line or read from a configuration file by the top-level, but is only ever actually needed by the create_salutation function. I can see that the top-level could just create an object from a class which encapsulates everything, but what if I want to keep the salutation generation separate, so that I can have a separate program which just generates the salutation and print it to the terminal? I guess I am really asking how to avoid "passing through" arguments to functions which only need them to call other functions, so maybe the answer is just to avoid nesting. Cheers, Loris Footnotes: [1] Is a TL;DR allowed to have footnotes? Probably not, but just to clarify, I would consider the third of three levels as being already "deeply-nested". -- This signature is currently under construction. -- https://mail.python.org/mailman/listinfo/python-list
Re: Making command-line args available to deeply-nested functions
Julio Di Egidio writes:
> On Friday, 20 August 2021 at 11:54:00 UTC+2, Loris Bennett wrote:
>> Hi,
>>
>> TL;DR:
>>
>> If I have a command-line argument for a program, what is the best way
>> of making this available to a deeply-nested[1] function call without
>> passing the parameter through every intermediate function?
>
> To not pass arguments you need shared state ("global variables"): and
> options in shard state, unless you have very good reasons to do
> otherwise, is simply a no no.
Doesn't that slightly depend on the size of your "globe"? If a program
does a few, in some sense unrelated things, and, say, only runs for a
few minutes, could you not decide to make a particular parameter global,
even though only one function needs it? In general, however, I would
also avoid this.
>
>> I can see that the top-level could just create an object from a class
>> which encapsulates everything, but what if I want to keep the salutation
>> generation separate, so that I can have a separate program which just
>> generates the salutation and print it to the terminal?
>
> Yes, that's basically the way to go: parse arguments into a structure (an
> object) that contains all options/parameters then pass that down. Next level:
> some sections of your code may require a certain subset of those options, some
> may require some other, so you would structure your options object in
> sub-objects for the various sets of correlated options, then rather pass just
> the sub-object(s) that are relevant to the section of code you are calling.
> Variations are of course possible, anyway that's the basic idea.
>
> Also have a look at the "argparse" library, it does all the heavy lifting for
> the parsing and creation of those objects, definitely advised for in non
> trivial
> cases: .
I am already using 'argparse' ('configargparse' actually). What aspect
should I be looking at in order to produce "sub-objects"?
>> I guess I am really asking how to avoid "passing through" arguments to
>> functions which only need them to call other functions, so maybe the
>> answer is just to avoid nesting.
>
> No, you don't get rid of code structure just not to pass arguments to
> a function... Code may be poorly structured, but that's another
> story.
As I am writing new code it is more a question of imposing structure,
rather than getting rid of structure. Unwritten code for a given
purpose obviously has some sort of structure with regards to, say, loops
and conditions, but I am less sure about the implications for how the
code should be nested. Another argument against deeply-nested functions
is the increased complexity of testing.
Cheers,
Loris
--
This signature is currently under construction.
--
https://mail.python.org/mailman/listinfo/python-list
