Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #26027 > unrolled thread

from future import pass_function

Back to article view | Back to comp.lang.python

Contents

  from future import pass_function Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2012-07-25 10:40 +0200
    Re: from future import pass_function Philipp Hagemeister <phihag@phihag.de> - 2012-07-25 12:30 +0200
    Re: from future import pass_function Nicholas Cole <nicholas.cole@gmail.com> - 2012-07-25 11:33 +0100
    Re: from future import pass_function Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-07-25 07:02 -0400
    Re: from future import pass_function Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-25 11:33 +0000
      Re: from future import pass_function Ross Ridge <rridge@csclub.uwaterloo.ca> - 2012-07-25 21:42 -0400
        Re: from future import pass_function Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-26 02:38 +0000
          Re: from future import pass_function Ross Ridge <rridge@csclub.uwaterloo.ca> - 2012-07-25 23:30 -0400
            Re: from future import pass_function Chris Angelico <rosuav@gmail.com> - 2012-07-26 13:53 +1000
              Re: from future import pass_function Ross Ridge <rridge@csclub.uwaterloo.ca> - 2012-07-26 00:03 -0400
                Re: from future import pass_function Ethan Furman <ethan@stoneleaf.us> - 2012-07-25 21:32 -0700
                  Re: from future import pass_function John Ladasky <john_ladasky@sbcglobal.net> - 2012-07-26 13:55 -0700
                  Re: from future import pass_function Ethan Furman <ethan@stoneleaf.us> - 2012-07-26 14:23 -0700
                    Re: from future import pass_function John Ladasky <john_ladasky@sbcglobal.net> - 2012-07-26 15:20 -0700
                    Re: from future import pass_function John Ladasky <john_ladasky@sbcglobal.net> - 2012-07-26 15:20 -0700
                  Re: from future import pass_function John Ladasky <john_ladasky@sbcglobal.net> - 2012-07-26 13:55 -0700
                Re: from future import pass_function Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-07-26 08:43 +0100
            Re: from future import pass_function alex23 <wuwei23@gmail.com> - 2012-07-25 21:20 -0700
          Re: from future import pass_function Rusi <rustompmody@gmail.com> - 2012-07-25 22:09 -0700
          Re: from future import pass_function Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2012-07-26 08:59 +0200
            Re: from future import pass_function Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-26 09:26 +0000
              Re: from future import pass_function Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2012-07-26 13:45 +0200
                Re: from future import pass_function Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-26 15:21 +0000
                  Re: from future import pass_function Joel Goldstick <joel.goldstick@gmail.com> - 2012-07-26 12:55 -0400
                  RE: from future import pass_function "Prasad, Ramit" <ramit.prasad@jpmorgan.com> - 2012-07-26 17:19 +0000
                  Re: from future import pass_function Chris Angelico <rosuav@gmail.com> - 2012-07-27 03:33 +1000
                  Re: from future import pass_function Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-07-27 00:25 +0100
                  Re: from future import pass_function Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-07-27 00:23 +0100
        Re: from future import pass_function alex23 <wuwei23@gmail.com> - 2012-07-25 21:17 -0700
    Re: from future import pass_function Chris Angelico <rosuav@gmail.com> - 2012-07-26 02:05 +1000
      Re: from future import pass_function Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2012-07-26 08:39 +0200
        Re: from future import pass_function Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-26 08:36 +0000
        Re: from future import pass_function Terry Reedy <tjreedy@udel.edu> - 2012-07-26 10:38 -0400
    Re: from future import pass_function Ethan Furman <ethan@stoneleaf.us> - 2012-07-25 09:28 -0700
    Re: from future import pass_function Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-07-25 12:48 -0400
    Re: from future import pass_function Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-07-25 14:17 -0400
    Re: from future import pass_function Michael Hrivnak <mhrivnak@hrivnak.org> - 2012-07-26 01:20 -0400
      Re: from future import pass_function Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2012-07-26 08:42 +0200
        Re: from future import pass_function Michael Hrivnak <mhrivnak@hrivnak.org> - 2012-07-26 17:15 -0400
    Re: from future import pass_function Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-07-26 08:50 +0100
      Re: from future import pass_function Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2012-07-27 08:39 +0200
    Re: from future import pass_function Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-07-26 05:16 -0400
    Re: from future import pass_function Chris Angelico <rosuav@gmail.com> - 2012-07-26 19:42 +1000
    Re: from future import pass_function Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-07-26 06:00 -0400
    Re: from future import pass_function rusi <rustompmody@gmail.com> - 2012-07-26 08:01 -0700
    Re: from future import pass_function Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-07-26 14:01 -0400
    Re: from future import pass_function Chris Angelico <rosuav@gmail.com> - 2012-07-27 04:14 +1000
    Re: from future import pass_function John Ladasky <john_ladasky@sbcglobal.net> - 2012-07-26 13:48 -0700
      Re: from future import pass_function Ian Kelly <ian.g.kelly@gmail.com> - 2012-07-26 15:18 -0600
      Re: from future import pass_function Ethan Furman <ethan@stoneleaf.us> - 2012-07-26 15:35 -0700
      Re: from future import pass_function Terry Reedy <tjreedy@udel.edu> - 2012-07-27 00:21 -0400
    Re: from future import pass_function Michael Hrivnak <mhrivnak@hrivnak.org> - 2012-07-26 17:20 -0400

Page 1 of 3  [1] 2 3  Next page →

#26027 — from future import pass_function

Hi!

I just had an idea, it occurred to me that the pass statement is pretty 
similar to the print statement, and similarly to the print() function, 
there could be a pass() function that does and returns nothing.

Example:
    def pass():
        return

    try:
        do_something()
    except:
        pass()


One thing I don't like about this is the syntax

    class foo(object):
        pass()


What do you think?

Uli

[toc] | [next] | [standalone]

#26031

[Multipart message — attachments visible in raw view] — view raw

Unlike the print statement, pass has no overboarding complexity (like
>>, printing tuples, etc.) - it just serves as a marker (and
practicality beats purity).

And you don't ever want to use pass as a value (say, for map() or the
right side of an assignment). In fact, if pass were a function, users
could construct strange code like

x = pass()

def pass():
   raise Exception('Are you slacking off? Get back to work!')

And don't forget that while the parentheses mainly confuse users,
they're also making it harder to type, and feel like useless overhead
(similar to the parentheses in  if (x):  ). In fact, I'd argue that if
pass were a function, None would be the better placeholder:

try:
    do_something()
except:
    None # 2 hard-to-type (on a German keyboard) characters shorter
    # (and probably way faster: No function call overhead and no need
    #  to actually find out what pass happens to be in this context)

- Philipp


On 07/25/2012 10:40 AM, Ulrich Eckhardt wrote:
> Hi!
>
> I just had an idea, it occurred to me that the pass statement is pretty
> similar to the print statement, and similarly to the print() function,
> there could be a pass() function that does and returns nothing.
>
> Example:
>    def pass():
>        return
>
>    try:
>        do_something()
>    except:
>        pass()
>
>
> One thing I don't like about this is the syntax
>
>    class foo(object):
>        pass()
>
>
> What do you think?
>
> Uli

[toc] | [prev] | [next] | [standalone]

#26032

On Wed, Jul 25, 2012 at 9:40 AM, Ulrich Eckhardt
<ulrich.eckhardt@dominolaser.com> wrote:
> What do you think?
>

I enjoyed the question, but actually I don't think this is a good idea.

1.  If you really needed something like this, you could define it easily.

def do_nothing(*args, **keywords):
   return None

2. If it were a built-in function, you would be able to override it,
and then there would be chaos.

Best,

Nicholas

[toc] | [prev] | [next] | [standalone]

#26034

On Wed, Jul 25, 2012 at 4:40 AM, Ulrich Eckhardt
<ulrich.eckhardt@dominolaser.com> wrote:
> What do you think?

retort:

def foo():
    None

-- Devin

[toc] | [prev] | [next] | [standalone]

#26036

On Wed, 25 Jul 2012 10:40:45 +0200, Ulrich Eckhardt wrote:

> Hi!
> 
> I just had an idea, it occurred to me that the pass statement is pretty
> similar to the print statement, 
[...]
>     try:
>         do_something()
>     except:
>         pass()

What's the point of this? If you intend to do nothing, why call a 
function instead?

There's a surprising amount of effort involved behind the scenes in 
calling a function. Python has to:

1) look up the function's name to get access to the function object
2) push any arguments onto the stack
3) determine the function object's type
4) look up its __call__ method
5) match the arguments (if any) with the parameter list (if any)
6) execute the function body
7) push the return result (None) onto the stack in case it's needed
8) and pop it off the stack.

Turning pass into a function instead of a statement would essentially 
take something that does *nothing at all* into something that 
(figuratively speaking) jumps up to its feet, runs around the room three 
times, and then sits back down again.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#26052

Ulrich Eckhardt wrote:
> I just had an idea, it occurred to me that the pass statement is pretty
> similar to the print statement, 
[...]
>     try:
>         do_something()
>     except:
>         pass()

Steven D'Aprano  <steve+comp.lang.python@pearwood.info> wrote:
>What's the point of this?

Remember everything you've said about why its a good thing the that
print statement is now a function?  That.

					Ross Ridge

-- 
 l/  //	  Ross Ridge -- The Great HTMU
[oo][oo]  rridge@csclub.uwaterloo.ca
-()-/()/  http://www.csclub.uwaterloo.ca/~rridge/ 
 db  //	  

[toc] | [prev] | [next] | [standalone]

#26053

On Wed, 25 Jul 2012 21:42:18 -0400, Ross Ridge wrote:

> Ulrich Eckhardt wrote:
>> I just had an idea, it occurred to me that the pass statement is pretty
>> similar to the print statement,
> [...]
>>     try:
>>         do_something()
>>     except:
>>         pass()
> 
> Steven D'Aprano  <steve+comp.lang.python@pearwood.info> wrote:
>>What's the point of this?
> 
> Remember everything you've said about why its a good thing the that
> print statement is now a function?  That.

I can't believe I actually have to point this out explicitly, but pass is 
not print. Apart from them both starting with the letter "P", they are 
nothing alike. There are good reasons for making print a function, and 
they don't apply to pass because pass doesn't do what print does.

The examples of pass-as-a-function shown by the Original Poster don't 
give any clue of what advantage there is to make pass a function. It 
appears that the only reason for this suggested change is that he would 
rather write "pass()" instead of "pass", possibly because he thinks it 
looks cool.

(Actually, I reckon that what is driving this idea is that the OP is a 
beginner, and he's got a syntax error a few times from writing "pass()", 
and so he thought it would be easier to force other people to change tens 
or hundreds of thousands of Python programs to use "pass()" instead of 
"pass" than to just learn to stop putting parentheses after it. I 
remember what it was like to be a beginner with six weeks experience in a 
twenty year old language, full of shiny new ideas for "improving" it.)

But of course I could be wrong. Ulrich, if you are still reading this, if 
you have good examples for how pass as a function would actually be 
better, and how it will let you do things in Python that can't easily be 
done now, I'm very interested to hear them. Who knows, if the idea is 
good enough, some day it may even happen.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#26055

Steven D'Aprano  <steve+comp.lang.python@pearwood.info> wrote:
>What's the point of this?
 
Ross Ridge wrote:
> Remember everything you've said about why its a good thing the that
> print statement is now a function?  That.

Steven D'Aprano  <steve+comp.lang.python@pearwood.info> wrote:
>I can't believe I actually have to point this out explicitly, but pass is 
>not print. Apart from them both starting with the letter "P", they are 
>nothing alike. There are good reasons for making print a function, and 
>they don't apply to pass because pass doesn't do what print does.

No, they're very much alike.  That's why all your arguments for print
as function also apply just as well to pass a function.  Your arguments
had very little to do what what print actually did.

					Ross Ridge

-- 
 l/  //	  Ross Ridge -- The Great HTMU
[oo][oo]  rridge@csclub.uwaterloo.ca
-()-/()/  http://www.csclub.uwaterloo.ca/~rridge/ 
 db  //	  

[toc] | [prev] | [next] | [standalone]

#26056

On Thu, Jul 26, 2012 at 1:30 PM, Ross Ridge <rridge@csclub.uwaterloo.ca> wrote:
> Steven D'Aprano  <steve+comp.lang.python@pearwood.info> wrote:
>>I can't believe I actually have to point this out explicitly, but pass is
>>not print. Apart from them both starting with the letter "P", they are
>>nothing alike. There are good reasons for making print a function, and
>>they don't apply to pass because pass doesn't do what print does.
>
> No, they're very much alike.  That's why all your arguments for print
> as function also apply just as well to pass a function.  Your arguments
> had very little to do what what print actually did.

Except that print / print() is executable. Execution proceeds through
your code, comes to a "print", and goes off to handle that, then comes
back to your code. But "pass" doesn't have code attached to it. Why
should it be a function?

One of the reasons for print becoming a function was its strange
collection of modifiers. How do you, with the print statement, send
output to someplace other than stdout? How do you make it not put a
newline? Far more logical to make those into keyword-only arguments to
a function, and far easier to later add more such options. What
parameters do you give to "pass"?

The pass keyword exists because Python can't have an empty pair of
braces, or an empty semicolon, to represent a "null statement". It
needs a keyword. That keyword is syntax, not code.

ChrisA

[toc] | [prev] | [next] | [standalone]

#26057

Ross Ridge <rridge@csclub.uwaterloo.ca> wrote:
> No, they're very much alike.  That's why all your arguments for print
> as function also apply just as well to pass a function.  Your arguments
> had very little to do what what print actually did.

Chris Angelico  <rosuav@gmail.com> wrote:
>Except that print / print() is executable. Execution proceeds through
>your code, comes to a "print", and goes off to handle that, then comes
>back to your code. But "pass" doesn't have code attached to it. Why
>should it be a function?

For consistancy with print.  What it does doesn't matter any more than
what print did mattered.

					Ross Ridge

-- 
 l/  //	  Ross Ridge -- The Great HTMU
[oo][oo]  rridge@csclub.uwaterloo.ca
-()-/()/  http://www.csclub.uwaterloo.ca/~rridge/ 
 db  //	  

[toc] | [prev] | [next] | [standalone]

#26060

Ross Ridge wrote:
> Ross Ridge <rridge@csclub.uwaterloo.ca> wrote:
>> No, they're very much alike.  That's why all your arguments for print
>> as function also apply just as well to pass a function.  Your arguments
>> had very little to do what what print actually did.
> 
> Chris Angelico  <rosuav@gmail.com> wrote:
>> Except that print / print() is executable. Execution proceeds through
>> your code, comes to a "print", and goes off to handle that, then comes
>> back to your code. But "pass" doesn't have code attached to it. Why
>> should it be a function?
> 
> For consistancy with print.  What it does doesn't matter any more than
> what print did mattered.

Of course what print did mattered.  `print` was not changed to `print()` 
because a function looks cooler; it was changed because it does stuff, 
and what it does could be changed with parameters, and overriding it 
with your own custom thingie was a useful thing to do.

What code does `pass` run?  When do we pass parameters to `pass`?   When 
do we need to override `pass`?

Answers:  None.  Never.  Still waiting for a reply from the OP for a use 
case.

How does that quote go?  "A foolish consistency is the hobgoblin of 
little minds"?  This definitely fits that category.

~Ethan~

[toc] | [prev] | [next] | [standalone]

#26114

On Wednesday, July 25, 2012 9:32:33 PM UTC-7, Ethan Furman wrote:

> What code does `pass` run?  When do we pass parameters to `pass`?   When 
> do we need to override `pass`?
> 
> Answers:  None.  Never.  Still waiting for a reply from the OP for a use 
> case.

When I brought up this same issue some months ago...

https://groups.google.com/forum/?fromgroups#!topic/comp.lang.python/CB_5fek2b8A

...it wasn't because I wanted to pass parameters to "pass", it was because I wanted to define a do-nothing function as an optional behavior within another function.  In other words, I wanted to pass "pass."

[toc] | [prev] | [next] | [standalone]

#26120

John Ladasky wrote:
> On Wednesday, July 25, 2012 9:32:33 PM UTC-7, Ethan Furman wrote:
> 
>> What code does `pass` run?  When do we pass parameters to `pass`?   When 
>> do we need to override `pass`?
>>
>> Answers:  None.  Never.  Still waiting for a reply from the OP for a use 
>> case.
> 
> When I brought up this same issue some months ago...
> 
> https://groups.google.com/forum/?fromgroups#!topic/comp.lang.python/CB_5fek2b8A
> 
> ...it wasn't because I wanted to pass parameters to "pass", it was because I wanted to define a do-nothing function as an optional behavior within another function.  In other words, I wanted to pass "pass."

That's a reasonable thing to want, and quite easily accomplished by 
passing `lambda: None`  or `lambda *args, **kwargs: None` instead.  I 
don't think this is difficult to do, nor common enough to justify making 
every other `pass` a time-consuming do-nothing operation, instead of 
just a do-nothing operation

~Ethan~

[toc] | [prev] | [next] | [standalone]

#26122

On Thursday, July 26, 2012 2:23:02 PM UTC-7, Ethan Furman wrote:

> That's a reasonable thing to want, and quite easily accomplished by 
> passing `lambda: None`  or `lambda *args, **kwargs: None` instead.

That's the same solution that Steven D'Aprano proposed the last time we had this discussion.  Which, I agree, is reasonable (although I continue to have a certain instinctive aversion to lambda).

[toc] | [prev] | [next] | [standalone]

#26123

On Thursday, July 26, 2012 2:23:02 PM UTC-7, Ethan Furman wrote:

> That's a reasonable thing to want, and quite easily accomplished by 
> passing `lambda: None`  or `lambda *args, **kwargs: None` instead.

That's the same solution that Steven D'Aprano proposed the last time we had this discussion.  Which, I agree, is reasonable (although I continue to have a certain instinctive aversion to lambda).

[toc] | [prev] | [next] | [standalone]

#26121

On Wednesday, July 25, 2012 9:32:33 PM UTC-7, Ethan Furman wrote:

> What code does `pass` run?  When do we pass parameters to `pass`?   When 
> do we need to override `pass`?
> 
> Answers:  None.  Never.  Still waiting for a reply from the OP for a use 
> case.

When I brought up this same issue some months ago...

https://groups.google.com/forum/?fromgroups#!topic/comp.lang.python/CB_5fek2b8A

...it wasn't because I wanted to pass parameters to "pass", it was because I wanted to define a do-nothing function as an optional behavior within another function.  In other words, I wanted to pass "pass."

[toc] | [prev] | [next] | [standalone]

#26068

On 26/07/2012 05:03, Ross Ridge wrote:
> Ross Ridge <rridge@csclub.uwaterloo.ca> wrote:
>> No, they're very much alike.  That's why all your arguments for print
>> as function also apply just as well to pass a function.  Your arguments
>> had very little to do what what print actually did.
>
> Chris Angelico  <rosuav@gmail.com> wrote:
>> Except that print / print() is executable. Execution proceeds through
>> your code, comes to a "print", and goes off to handle that, then comes
>> back to your code. But "pass" doesn't have code attached to it. Why
>> should it be a function?
>
> For consistancy with print.  What it does doesn't matter any more than
> what print did mattered.
>
> 					Ross Ridge
>

My all time favourite engineering quote, from the UK Ptarmigan tactical 
communications project, springs to my mind here regarding your comments 
about the comparison of print and pass.  "I might not be a mechanical 
engineer, but that's fucking wrong".

-- 
Cheers.

Mark Lawrence.

[toc] | [prev] | [next] | [standalone]

#26059

On Jul 26, 1:30 pm, Ross Ridge <rri...@csclub.uwaterloo.ca> wrote:
> No, they're very much alike.

Repetition isn't evidence. You keep making this claim, so support it.

> That's why all your arguments for print
> as function also apply just as well to pass a function.  Your arguments
> had very little to do what what print actually did.

As far as I can see, the only arguments Steven made were against pass
as a function, with an illustration of the function call cost that
pass-as-function would incur.

Your arguments, on the other hand, amount to nothing more than "nuh
uh!"

[toc] | [prev] | [next] | [standalone]

#26061

Ulrich:
If you take a look at pep 3105 you find five rationales.
http://www.python.org/dev/peps/pep-3105/#rationale

If the first were the only one then your suggestion would have merit.
There are also the other 4 in which pass and print dont really
correspond.

Steven wrote earlier:
> I have an axe that has been passed down for generations through my
> family, from my father, his father before him, and his father, and his
> father before him. Occasionally we replace the handle, or put on a new
> head, but that axe is almost as good as the day my great-great-
> grandfather made it.

Yeah I see that you are always wielding your great-great-grandfather's
axe. As for example

On Jul 26, 7:38 am, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> (Actually, I reckon that what is driving this idea is that the OP is a
> beginner, and he's got a syntax error a few times from writing "pass()",
> and so he thought it would be easier to force other people to change tens
> or hundreds of thousands of Python programs to use "pass()" instead of
> "pass" than to just learn to stop putting parentheses after it. I
> remember what it was like to be a beginner with six weeks experience in a
> twenty year old language, full of shiny new ideas for "improving" it.)


Do you sharpen it sometimes?

[toc] | [prev] | [next] | [standalone]

#26065

Am 26.07.2012 04:38, schrieb Steven D'Aprano:
> The examples of pass-as-a-function shown by the Original Poster don't
> give any clue of what advantage there is to make pass a function.

Just read the text, it just struck me how similar pass and print are, 
i.e. that neither actually needs to be a keyword. In some cases, I would 
rather use "return" to replace "pass" though.


> It appears that the only reason for this suggested change is that he
> would rather write "pass()" instead of "pass", possibly because he
> thinks it looks cool.

I have no idea where you got the "cool" from, it is not in my posting. I 
stated clearly that "I just had an idea", which should signal that I 
haven't thought about this for any extended period of time. Then I asked 
"What do you think?" exactly because I wanted to discuss this. No need 
to get defensive. ;)


> (Actually, I reckon that what is driving this idea is that the OP is a
> beginner, and he's got a syntax error a few times from writing "pass()",
> and so he thought it would be easier to force other people to change tens
> or hundreds of thousands of Python programs to use "pass()" instead of
> "pass" than to just learn to stop putting parentheses after it.

So, and in order to force people to write parens or break their code I 
have considered the possibility of importing that feature from 
__future__ for those people that want it? Seriously, Steven, as much as 
I like your regular contributions here, this time you had better logged 
off and taken a walk, because you come across as _very_ arrogant here.


> But of course I could be wrong. Ulrich, if you are still reading this, if
> you have good examples for how pass as a function would actually be
> better, and how it will let you do things in Python that can't easily be
> done now, I'm very interested to hear them. Who knows, if the idea is
> good enough, some day it may even happen.

No there is nothing that you strictly need a pass() function for.


In summary, after reading this thread I have a lot of good arguments 
against this idea and few arguments supporting the idea. In any case I 
have many more arguments than those that I came up with myself, which is 
exactly what I asked for.


Thanks to all that took part in this discussion!

Uli

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web