[Python-ideas] Re: Optional keyword arguments

[Greg Ewing]

On 28/05/20 12:38 pm, Rob Cliffe wrote:
why not go 
further (as the OP suggested as far as I recall)

and allow the more concise

     def order(eggs = 4, spam ?= Spam()):
         etc.


That clutters up the header with things that are not part of
the function's signature. All the caller needs to know is that
the spam argument is optional. The fact that a new Spam object
is created on each call if he doesn't supply one is an
implementation detail.

--
Greg
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/DYQQLA5FT4UMYSVMVTJSMF3HU5R5IEVD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: An HTTP API to list versions of Python

[Serhiy Storchaka]

27.05.20 21:10, Christian Heimes пише:

Barry and Guido own the Python project on PyPI,
https://pypi.org/project/Python/ . There hasn't been an update since
2.5.0 in 2007.


There are also

https://pypi.org/project/python2/
https://pypi.org/project/python4/
https://pypi.org/project/cPython/

which are unrelated to the Python interpreter.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/2RR3ML3COL2Z2KRCBAPWJ6FA5PMOLWCK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Allowing assertEqual etc to take multiple items

[remi . lapeyre]

Hi Ram, this is not possible without breaking a lot of code, 
assertSequenceEqual() already takes a third argument:



Help on function assertSequenceEqual in module unittest.case:

assertSequenceEqual(self, seq1, seq2, msg=None, seq_type=None)
An equality assertion for ordered sequences (like lists and tuples).

For the purposes of this function, a valid ordered sequence type is one
which can be indexed, has a length, and has an equality operator.

Args:
seq1: The first sequence to compare.
seq2: The second sequence to compare.
seq_type: The expected datatype of the sequences, or None if no
datatype should be enforced.
msg: Optional message to use on failure instead of a list of
differences.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/UPPLDUPPD5TIAW2CU3G2TPVAHU3HNMQH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Allowing assertEqual etc to take multiple items

[Serhiy Storchaka]

28.05.20 11:02, Ram Rachum пише:
I recently submitted this PR 
, and I 
had to use assertSequenceEqual twice, just because I wanted to compare 3 
sequences to each other rather than 2.


You have wrote much more text in this message that you would save by not 
typing assertSequenceEqual twice.


Wouldn't it be possible to make assertEqual and its entire family 
(including assertSequenceEqual and the dozen of other methods) accept an 
arbitrary number of arguments, and compare all of them to each other? 
That way I could do this:


     self.assertSequenceEqual(sliced_tuple_0, sliced_tuple_1, sliced_range)


As Rémi said, it is breaking change.

We could discuss whether they'll do the faster version of a == b == c, 
or a more extensive check between every 2 items individually.


Why do you think it will be faster? `a == b == c` is the same as `a == b 
and b == c`, but a tiny bit slower.


You always can write

self.assertTrue(a == b == c)

But the advantage of two separate assertions is that you know what 
comparison fails if it fails and get more informative report.

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/DAYBXTFANOA72OEXGF3JZU7KSBNOIZEH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Allowing assertEqual etc to take multiple items

[Ram Rachum]

On Thu, May 28, 2020 at 11:42 AM Serhiy Storchaka 
wrote:

> 28.05.20 11:02, Ram Rachum пише:
> > I recently submitted this PR
> > , and
> I
> > had to use assertSequenceEqual twice, just because I wanted to compare 3
> > sequences to each other rather than 2.
>
> You have wrote much more text in this message that you would save by not
> typing assertSequenceEqual twice.
>

I see text written in emails as about x10,000 cheaper than text written in
code.


>
> > Wouldn't it be possible to make assertEqual and its entire family
> > (including assertSequenceEqual and the dozen of other methods) accept an
> > arbitrary number of arguments, and compare all of them to each other?
> > That way I could do this:
> >
> >  self.assertSequenceEqual(sliced_tuple_0, sliced_tuple_1,
> sliced_range)
>
> As Rémi said, it is breaking change.
>

I understand. We *could *slowly move towards having these keyword arguments
be keyword-only arguments, with a patient deprecation cycle. This would
probably be a good thing regardless. But I know that's a hard case to make
here.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/FJWTUTWVTIOZMWTTWGIW3EXUILVTHFWN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Optional keyword arguments

[Alex Hall]

On Thu, May 28, 2020 at 9:01 AM Greg Ewing 
wrote:

> On 28/05/20 12:38 pm, Rob Cliffe wrote:
> > why not go
> > further (as the OP suggested as far as I recall)
> > and allow the more concise
> >
> >  def order(eggs = 4, spam ?= Spam()):
> >  etc.
>
> That clutters up the header with things that are not part of
> the function's signature. All the caller needs to know is that
> the spam argument is optional.
>

I'm very surprised by this sentiment. The signature says that the default
value for spam is an instance of Spam, namely one constructed with no
arguments. That's useful information! I wrote a long post about this here:
https://mail.python.org/archives/list/python-ideas@python.org/message/6TGESU6AQSDFLIV2UBHAB4E2NVVREVPA/
-
do you have any thoughts on that?

(side note - I'm just seeing now how mailman handles inline images, which
is very disappointing)

The fact that a new Spam object
> is created on each call if he doesn't supply one is an
> implementation detail.
>

I don't think it is - knowing that the default isn't shared across calls
could be quite important. But aside from that, there's only one character
(`?`) which represents that detail, and that's an acceptable amount of
'clutter'. The rest (`=Spam()`) is just saying what the default value is,
and we don't usually consider that clutter.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/A3NHMQLN7LDNMCCMT7XZ3DT4SQZBOQTG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Optional keyword arguments

[Chris Angelico]

On Thu, May 28, 2020 at 5:05 PM Greg Ewing  wrote:
>
> On 28/05/20 12:38 pm, Rob Cliffe wrote:
> > why not go
> > further (as the OP suggested as far as I recall)
> > and allow the more concise
> >
> >  def order(eggs = 4, spam ?= Spam()):
> >  etc.
>
> That clutters up the header with things that are not part of
> the function's signature. All the caller needs to know is that
> the spam argument is optional. The fact that a new Spam object
> is created on each call if he doesn't supply one is an
> implementation detail.
>

Is it an implementation detail that 4 will be used for eggs if it
isn't passed? I think this is part of the function's API, not its
implementation.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/PPACG3BQVLI7XTO64ZDSIBHDOMTWUNHZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: An HTTP API to list versions of Python

[M.-A. Lemburg]

On 27.05.2020 23:46, Joseph Banks wrote:
> The downside to the FTP solution however is that little metadata is
> present about the versions
> 
> The FTP pages are primarily for downloading versions which isn't the aim
> of the proposal, it's to be able to fetch the metadata.
> 
> Adding some sort of metadata file to all versions on the FTP server
> would solve the problem but at that point I'm not sure the "doesn't need
> any new process" argument still holds water.

It was an FTP server. Nowadays, the files are served up via HTTPS.
The FTP server has been switched off long ago.

The point about not needing more process is that you always need
someone to maintain any such addition.

It would be fairly easy for someone to step up and start maintaining
such an index, perhaps even as a PyPI package, but such resources are
only useful when fully maintained over long periods of time.

In terms of meta data, the best we currently have are PEPs
for each minor release version, the downloads page on python.org
for release dates and PEP links, and the location I mentioned for
quickly grabbing the download files.

> On Wed, 27 May 2020 at 22:36, M.-A. Lemburg  > wrote:
> 
> On 27.05.2020 18:59, Antoine Pitrou wrote:
> > On Tue, 26 May 2020 22:19:12 -0400
> > Kyle Stanley mailto:aeros...@gmail.com>> wrote:
> >>
> >>> It could become more detailed about each minor versions, git
> tag, links 
> >> to changelogs, links to the repositories, to the docs, download
> links,
> >> and so on.
> >>
> >> I don't know that it needs to be said, but for now, I think we
> should start
> >> with a minimalist approach by keeping the API focused on reducing the
> >> number of *existing* locations to update, rather than predicting
> what might
> >> sort of fields might be useful to include. Otherwise, it could
> very well
> >> end up becoming more work to maintain compared to what it
> actually saves.
> >
> > Unless unusual fields are required in the returned information, how
> > about using PyPI as the information store?  That way, you don't
> have to
> > design a new API and implement a new backend...
> >
> > (that doesn't mean PyPI needs to host any downloadable files for
> Pyhon,
> > by the way - just the metadata)
> 
> Here's something which is close to an HTTP API and doesn't need any new
> process, since it's been working for ages...
> 
> https://www.python.org/ftp/python/
> 
> (and it's also easier to use than the regular python.org
>  download
> mechanisms)
> 
> If you're looking for the 1.x releases, you can find them here:
> 
> https://www.python.org/ftp/python/src/
> 
> Even earlier ones are on USENET.
> 
> -- 
> Marc-Andre Lemburg
> eGenix.com
> 
> Professional Python Services directly from the Experts (#1, May 27 2020)
> >>> Python Projects, Coaching and Support ...    https://www.egenix.com/
> >>> Python Product Development ...        https://consulting.egenix.com/
> 
> 
> ::: We implement business ideas - efficiently in both time and costs :::
> 
>    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
>     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>            Registered at Amtsgericht Duesseldorf: HRB 46611
>                https://www.egenix.com/company/contact/
>                      https://www.malemburg.com/
> ___
> Python-ideas mailing list -- python-ideas@python.org
> 
> To unsubscribe send an email to python-ideas-le...@python.org
> 
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> 
> https://mail.python.org/archives/list/python-ideas@python.org/message/XMURTTG67FWUZVQCXCQWHTGZTX7YYDGF/
> Code of Conduct: http://python.org/psf/codeofconduct/
> 

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, May 28 2020)
>>> Python Projects, Coaching and Support ...https://www.egenix.com/
>>> Python Product Development ...https://consulting.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   https://www.egenix.com/company/contact/
 https://www.malemburg.com/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to 

[Python-ideas] Re: Optional keyword arguments

[Steven D'Aprano]

On Thu, May 28, 2020 at 07:00:51PM +1200, Greg Ewing wrote:
> On 28/05/20 12:38 pm, Rob Cliffe wrote:
> >why not go further (as the OP suggested as far as I recall)
> >and allow the more concise
> >
> >     def order(eggs = 4, spam ?= Spam()):
> >         etc.
> 
> That clutters up the header with things that are not part of
> the function's signature. All the caller needs to know is that
> the spam argument is optional. 

I don't think you thought that through all the way.

"All I need to know is that the mode argument to `open()` is optional, I 
don't need to know whether it defaults to read or write..."

I don't think so.


> The fact that a new Spam object
> is created on each call if he doesn't supply one is an
> implementation detail.

Being an implementation detail implies that the functional behaviour 
will be identical either way, but that's incorrect under at least four 
circumstances:

- Spam objects are mutable, e.g. lists, dicts, set;

- calling Spam has side-effects;

- calling Spam is particularly costly;

- or if the result of calling Spam depends on the current state of 
  the runtime environment, e.g. anything time dependent, anything 
  to do with the state of the file system or a database, etc.


The default value used by a parameter is certainly important, and one of 
the most common reasons I call `help(func)` is to see what the default 
values are. They should be in the signature, and it is an annoyance when 
all the signature shows is that it is None, and then I have to trawl 
through screenfuls of docs, or search the web, to find out what the 
actual default is.


-- 
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IL3K5G2K4Y752HQKA26EEZCIGNOT56P4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Python __main__ function

[redradist]

Hi all,

In Python we often use the following syntax to call the main logic of script 
when it was ran:
```python
def main():
pass # whatever should be done for `python ./script.py`

if __name__ == '__main__':
main()
```

Maybe it is a time to introduce the new module level function like __main__ ?
Consider the following code:
```python
def __main__():
pass # whatever should be done for `python ./script.py`
```

It is much easy an less code to write ;)

Under-hood `Python` just will generate the following code:
```python
def __main__():
pass # whatever should be done for `python ./script.py`

# Below generated code
if __name__ == '__main__':
__main__()
```

If there are two `if __name__ == '__main__':` it is also not an issue:
```python
def __main__():
pass # whatever should be done for `python ./script.py`

def main():
pass # whatever should be done for `python ./script.py`

if __name__ == '__main__':
main()

# Below generated code
if __name__ == '__main__':
__main__()
```

Or we could require user to have only one `if __name__ == '__main__':` ...

What do you think, please share your opinion ...
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/FBT5BT7KYFVQCZYVAY6HSSWNKAVCXA5T/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Allowing assertEqual etc to take multiple items

[Ram Rachum]

Hi guys!

I'm a unittest newbie, so it's possible there's a better solution than what
I'm proposing here. If there is, please let me know.

I recently submitted this PR
, and I
had to use assertSequenceEqual twice, just because I wanted to compare 3
sequences to each other rather than 2.

Wouldn't it be possible to make assertEqual and its entire family
(including assertSequenceEqual and the dozen of other methods) accept an
arbitrary number of arguments, and compare all of them to each other? That
way I could do this:

self.assertSequenceEqual(sliced_tuple_0, sliced_tuple_1, sliced_range)

We could discuss whether they'll do the faster version of a == b == c, or a
more extensive check between every 2 items individually.


What do you think?
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/PSARHWK66COAEWKT3F5EIFFOSU7FADPF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Optional keyword arguments

[Richard Damon]

On 5/28/20 3:00 AM, Greg Ewing wrote:
> On 28/05/20 12:38 pm, Rob Cliffe wrote:
>> why not go further (as the OP suggested as far as I recall)
>> and allow the more concise
>>
>>  def order(eggs = 4, spam ?= Spam()):
>>      etc.
>
> That clutters up the header with things that are not part of
> the function's signature. All the caller needs to know is that
> the spam argument is optional. The fact that a new Spam object
> is created on each call if he doesn't supply one is an
> implementation detail.
>
But default values for arguments are really part of the responsibility
for the caller, not the called function. The classic implementation
would be that the caller passes all of the explicitly, and implicitly
defined parameters (those with default arguments). If the language
allows, you could have unpassed arguments that are passed as 'not
provided' and that the called function detects and fills in with a value
that isn't part of the API (which is sort of what the = None default
does). This can also be done in Python with the *args and **kwargs
parameters where the function can detect if something was passed there.

-- 
Richard Damon
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/RAXOC6RCAMMDPOR7GTLBR7S4MM5U4FT2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Optional keyword arguments

[Greg Ewing]

On 28/05/20 7:31 pm, Chris Angelico wrote:

Is it an implementation detail that 4 will be used for eggs if it
isn't passed?


That feels different to me somehow. I think it has something to do
with declarative vs. procedural stuff. The default value of eggs
being 4 is a static fact, but creating a new Spam object is not.
To my mind, procedural code belongs in the body of the function,
not in the header.

--
Greg
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/67LPYOOPPWXGLBV5JYGPDPEY6MPETMCL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python __main__ function

[Jose Veiga]

While is possible to use `if __name__ == '__main__':` several times in the
same script, your proposed magic function `def __main__()` cannot be
redefined. Not to speak about lexical scope differences between one
approach and the other.

So your proposal is reducing features instead of expanding them.


Jose Veiga
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/7FWVJ2S72DCX4ANOBEDZJMBSMNXUM76A/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Optional keyword arguments

[Greg Ewing]

On 28/05/20 8:57 pm, Steven D'Aprano wrote:

The default value used by a parameter is certainly important, and one of
the most common reasons I call `help(func)` is to see what the default
values are. They should be in the signature, and it is an annoyance when
all the signature shows is that it is None, and then I have to trawl
through screenfuls of docs, or search the web, to find out what the
actual default is.


I think we need a real example to be able to talk about this
meaningfully.

But I'm having trouble thinking of one. I can't remember ever
writing a function with a default argument value that *has* to
be mutable and *has* to have a new one created on each call
*unless* the caller provided one.

Anyone else have one?

--
Greg
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IK62W3TS7HKNRJO7NIQF7UYXCRVAOPVG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python __main__ function

[Paul Sokolovsky]

Hello,

On Thu, 28 May 2020 09:06:36 -
redrad...@gmail.com wrote:

> Hi all,
> 
> In Python we often use the following syntax to call the main logic of
> script when it was ran: ```python
> def main():
> pass # whatever should be done for `python ./script.py`
> 
> if __name__ == '__main__':
> main()
> ```
> 
> Maybe it is a time to introduce the new module level function like
> __main__ ?

For as long as it works (it does), there's no need to introduce
anything.


However, if you want to add special features, adding __main__() can be
useful. For example, for Python "strict mode" (which I hope to post for
beating to this list one of these years), I need to explicitly separate
"load time" from "run time" of a Python program. And to achieve that, I
exactly introduce a "main" function, and even call it __main__ (so the
name is taken!!111 ;-) ).


And in all fairness, all good ideas already came to somebody else years
ago. There's https://www.python.org/dev/peps/pep-0299/ , successfully
rejected yet back in 2002. (So, feel free to use it in your own
environment/Python dialect.)

[]

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/EPHA4JOFUMZS362GLHQMYFCEKMXKBV3Z/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Optional keyword arguments

[Dan Sommers]

On Thursday, May 28, 2020, at 06:47 -0400, Alex Hall wrote:

> On Thu, May 28, 2020 at 12:38 PM Greg Ewing 
> wrote:
>
>> On 28/05/20 8:57 pm, Steven D'Aprano wrote:
>> > The default value used by a parameter is certainly important, and one of
>> > the most common reasons I call `help(func)` is to see what the default
>> > values are. They should be in the signature, and it is an annoyance when
>> > all the signature shows is that it is None, and then I have to trawl
>> > through screenfuls of docs, or search the web, to find out what the
>> > actual default is.
>>
>> I think we need a real example to be able to talk about this
>> meaningfully.
>>
>> But I'm having trouble thinking of one. I can't remember ever
>> writing a function with a default argument value that *has* to
>> be mutable and *has* to have a new one created on each call
>> *unless* the caller provided one.
>>
>> Anyone else have one?
>>
>
> I think the most common cases are where the default is an empty list or
> dict ...

That's what I thought of:  an accumulator in a reduce or fold function.
The default is an empty list that has to be recreated at every function
call, but the caller can supply their own empty container that supports
some sort of extend or add functionality.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/UXPPJBSLTDE3FJYDDVIBV7L7L6DS5AOC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Optional keyword arguments

[Alex Hall]

On Thu, May 28, 2020 at 12:38 PM Greg Ewing 
wrote:

> On 28/05/20 8:57 pm, Steven D'Aprano wrote:
> > The default value used by a parameter is certainly important, and one of
> > the most common reasons I call `help(func)` is to see what the default
> > values are. They should be in the signature, and it is an annoyance when
> > all the signature shows is that it is None, and then I have to trawl
> > through screenfuls of docs, or search the web, to find out what the
> > actual default is.
>
> I think we need a real example to be able to talk about this
> meaningfully.
>
> But I'm having trouble thinking of one. I can't remember ever
> writing a function with a default argument value that *has* to
> be mutable and *has* to have a new one created on each call
> *unless* the caller provided one.
>
> Anyone else have one?
>

I think the most common cases are where the default is an empty list or
dict. Building on my ChainMap example from before, consider this code:

```
from collections import ChainMap

c1 = ChainMap().new_child()
c2 = ChainMap().new_child()

c1[1] = 2
print(c1[1])
c2[1] = 3
print(c1[1])
```

Here c1 and c2 have separate new children, so modifying c2 doesn't affect
c1, so '2' is printed twice. We can simulate what would happen if a new
default wasn't created each time by passing the same dict to both:

```
from collections import ChainMap

m = {}

c1 = ChainMap().new_child(m)
c2 = ChainMap().new_child(m)

c1[1] = 2
print(c1[1])
c2[1] = 3
print(c1[1])
```

Now the second print shows '3', even though we expect that value to be in
c2 but not c1.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/SMHX4C2OB2A4SRPEDVWA3UVXPGZOPXWA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Allowing assertEqual etc to take multiple items

[Steven D'Aprano]

On Thu, May 28, 2020 at 11:40:52AM +0300, Serhiy Storchaka wrote:

> Why do you think it will be faster? `a == b == c` is the same as `a == b 
> and b == c`, but a tiny bit slower.

That surprises me. I thought that the big advantage of chained 
comparisons is that results are only evaluated once.

a == expensive_expression == c

should be faster than calculating the expensive expression twice:

a == expensive_expression and expensive_expression == c

and even if the expression is just a name lookup, isn't one name lookup 
cheaper than two?

> You always can write
> 
> self.assertTrue(a == b == c)
> 
> But the advantage of two separate assertions is that you know what 
> comparison fails if it fails and get more informative report.

I agree that this is a very good argument for writing separate 
assertions.


-- 
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/GYVHSAH3VQY5AXKSW2PNKHUURSDHTDLP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Optional keyword arguments

[Steven D'Aprano]

On Wed, May 27, 2020 at 05:03:09AM +1000, Chris Angelico wrote:

> def foo():
> if False: x = 0
> # what is x now?
> 
> There is no *value* in x, yet x has a state. 

In Python code, no, it has no state, it's just an unbound name. That's 
literally a name that has nothing bound to it, hence no state.

In the CPython 3 implementation, it has a hidden state: there's a fixed 
array representing the locals, one of those array slots represents x, 
and there is some kind of C-level special state to distinguish between 
"this slot is filled" and "this slot is not filled". But that's purely 
an optimization. Locals can also be backed by a dict, like globals.

That is what happens in Jython, so when you call locals() you get back 
the actual local namespace dict and modifications to the variables 
works. (Unlike in CPython.)

# Jython 2.7
>>> def test():
... locals()['x'] = 999
... if False:
... # Fool the compiler into treating x as a local.
... x = None
... print(x)
...
>>> test()
999

IronPython appears to be different yet again, but I don't understand 
what it is doing so I can't explain it.

In CPython 2,  some locals were backed by the fast array slots, some 
were not. I think (but I'm not sure!) that if the compiler saw an exec 
or a star import inside a function, it switched off the fast array 
optimization. Or something like that.

The bottom line here is that the Python execution model has names. Names 
can be bound to a value (an object), or they can be unbound in which 
case they have no state *in Python*.

Whether that unboundness is represented by a nil pointer or a special 
magic value or is a consequence of a key being missing from a namespace 
dict is part of the implementation, not part of the Python semantics.


> So we could have some
> kind of definition of optional parameters where, rather than receiving
> a default, they would simply not be bound.

We could have an `if undef` keyword :-)

if undef x:
x = something

(Not entirely serious about this proposal.)


> def foo(?x):
> # what is x?
> 
> There would want to be a new way to query this state, though, because
> I think this code is ugly enough to die:
> 
> def foo(?x):
> try:
> x
> except UnboundLocalError:
> ... # do this if x wasn't passed in
> else:
> ... # do this if we have a value for x

There's always:

if 'x' in locals()


> (It's probably best to define this ONLY for local variables. Module or
> class name bindings behave differently, so they would simply never be
> in this unbound state.

Of course they are!

# Module level state.
x = None; del x  # Ensure x is unbound.
print(x)


I frequently write top-level module code that tests for the existence of 
a global or builtin:

try:
spam
except NameError:
def spam(): ...

That could become:

if undef spam:
def spam(): ...

I would be cross if `if undef` worked inside functions but not globally.



-- 
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/RG2JDSOYQXYRLRIZN5UVAPS5MDEHMGF4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Optional keyword arguments

[Chris Angelico]

On Thu, May 28, 2020 at 8:01 PM Steven D'Aprano  wrote:
>
> On Wed, May 27, 2020 at 05:03:09AM +1000, Chris Angelico wrote:
>
> > def foo():
> > if False: x = 0
> > # what is x now?
> >
> > There is no *value* in x, yet x has a state.
>
> In Python code, no, it has no state, it's just an unbound name. That's
> literally a name that has nothing bound to it, hence no state.
>

Is the UnboundLocalError that you'd get on trying to access 'x' a
CPython implementation detail or a language feature? If it's a
language feature, then the name 'x' must be in the state of "local
variable without a value". This is a valid situation. There is no
value, but this is the state of the variable. It's not "no state" any
more than zero is a non-number or NULL is a non-pointer.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/KLTFG3E7WB5R42OWJ3NL2VQ6NSTJO5CK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Optional keyword arguments

[Alex Hall]

On Thu, May 28, 2020 at 11:57 AM Steven D'Aprano 
wrote:

> On Wed, May 27, 2020 at 05:03:09AM +1000, Chris Angelico wrote:
>
> > def foo():
> > if False: x = 0
> > # what is x now?
> >
> > There is no *value* in x, yet x has a state.
>
> In Python code, no, it has no state, it's just an unbound name. That's
> literally a name that has nothing bound to it, hence no state.
>
> In the CPython 3 implementation, it has a hidden state: there's a fixed
> array representing the locals, one of those array slots represents x,
> and there is some kind of C-level special state to distinguish between
> "this slot is filled" and "this slot is not filled". But that's purely
> an optimization. Locals can also be backed by a dict, like globals.
>
> That is what happens in Jython, so when you call locals() you get back
> the actual local namespace dict and modifications to the variables
> works. (Unlike in CPython.)
>

Consider this code:

```
x = 1

def foo():
print(x)
x = 2

foo()
```

Here `print(x)` doesn't print '1', it gives `UnboundLocalError: local
variable 'x' referenced before assignment`. It knows that `x` is meant to
be a local and ignores the global value. That doesn't look like an
implementation detail to me - does Jython do something different?
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/7JEVW5XWZALBJLKHXDW4K2FMVQAQ77J3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python __main__ function

[jdveiga]

redradist＠gmail.com wrote:
> Hi all,
> In Python we often use the following syntax to call the main logic of script 
> when it
> was ran:
> def main():
> pass # whatever should be done for `python ./script.py`
> 
> if __name__ == '__main__':
> main()
> 
> Maybe it is a time to introduce the new module level function like __main__ ?
> Consider the following code:
> def __main__():
> pass # whatever should be done for `python ./script.py`
> 
> It is much easy an less code to write ;)
> Under-hood Python just will generate the following code:
> def __main__():
> pass # whatever should be done for `python ./script.py`
> 
> # Below generated code
> if __name__ == '__main__':
> __main__()
> 
> If there are two if __name__ == '__main__': it is also not an issue:
> def __main__():
> pass # whatever should be done for `python ./script.py`
> 
> def main():
> pass # whatever should be done for `python ./script.py`
> 
> if __name__ == '__main__':
> main()
> 
> # Below generated code
> if __name__ == '__main__':
> __main__()
> 
> Or we could require user to have only one if __name__ == '__main__':
> ...
> What do you think, please share your opinion ...


While is possible to use if __name__ == '__main__': several times in the
same script, your proposed magic function def __main__() cannot be
redefined. Not to speak about lexical scope differences between one
approach and the other.

So your proposal is reducing features instead of expanding them.

(Sorry for repeating the message. The first one went to another thread)
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/OIVWKH44TWQMVO5JOHKUCM7VMDSKVB7M/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python __main__ function

[Artemis]

> So your proposal is reducing features instead of expanding them.
Surely, the `__name__` variable would remain, so if people needed a more 
powerful way of doing it they could use that? But then, we introduce multiple 
ways of doing the same thing...
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/DJOVKWARD2XE5CX2FP4WRMYRAYPQYRGD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Optional keyword arguments

[Dominik Vilsmeier]

On 28.05.20 17:44, Christopher Barker wrote:


On Thu, May 28, 2020 at 3:50 AM Alex Hall mailto:alex.moj...@gmail.com>> wrote:

On Thu, May 28, 2020 at 12:38 PM Greg Ewing
mailto:greg.ew...@canterbury.ac.nz>>
wrote:


But I'm having trouble thinking of one. I can't remember ever
writing a function with a default argument value that *has* to
be mutable and *has* to have a new one created on each call
*unless* the caller provided one.


Actually, we need to one further: a default argument value that *has* to
be mutable and *has* to have a new one created on each call
*unless* the caller provided one ...

and *has* to treat None as valid value.


That's the scenario where you'd need to create a sentinel object to take
the role of None. However late binding of defaults won't save you from this.

The biggest advantage, as far as I understood, is that you can specify a
default (expression) as part of the function header and hence provide a
meaningful example value to the users rather than just None.

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/P3XDOGYMUJQQWKNKL5O3IZLRFGJYMLNI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python __main__ function

[jdveiga]

Artemis wrote:
> > So your proposal is reducing features instead of
> > expanding them.
> > Surely, the __name__ variable would remain, so if people needed a more
> > powerful way of doing it they could use that? But then, we introduce 
> > multiple ways of
> > doing the same thing...
> >

The OP is proposing as a possibility: "we could require user to have only one 
if __name__ == '__main__':". In that case, functionality will be reduced, won't 
it?

In any case, the proposal has been discussed and rejected in the past (PEP 299 
https://www.python.org/dev/peps/pep-0299/) as Paul Sokolovsky has pointed out.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/H5TJ5RELMIJVVUZOEDGZE4TCCPOJTVIG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python __main__ function

[David Mertz]

On Thu, May 28, 2020, 12:17 PM  wrote:

> The OP is proposing as a possibility: "we could require user to have only
> one if __name__ == '__main__':". In that case, functionality will be
> reduced, won't it?
>

I don't support the proposal. However, I've also never written a script
with multiple 'if __name__ == __main__' lines, and I think if I saw one I'd
complain in code review.

It's hard for me to imagine how multiple entry point to a script can be a
good thing.

>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ARMVJL5BXEVZAEZRBWWGMRGZ2IAOPTMR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Optional keyword arguments

[Christopher Barker]

On Thu, May 28, 2020 at 3:50 AM Alex Hall  wrote:

> On Thu, May 28, 2020 at 12:38 PM Greg Ewing 
> wrote:
>
>>
>> But I'm having trouble thinking of one. I can't remember ever
>> writing a function with a default argument value that *has* to
>> be mutable and *has* to have a new one created on each call
>> *unless* the caller provided one.
>>
>
Actually, we need to one further: a default argument value that *has* to
be mutable and *has* to have a new one created on each call
*unless* the caller provided one ...

and *has* to treat None as valid value.

That I'm really having trouble with :-)

-CHB


-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/VR4LRW6ZT5MV2654CICTYF25OFFWDTHO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python __main__ function

[redradist]

Cool !!

But it disappointed that this proposal was reject (
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/2WF26WMQIGSTYEPPW7R7P7BVB6XRHBR7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python __main__ function

[David Mertz]

On Thu, May 28, 2020, 3:06 PM Chris Angelico  wrote:

> There aren't multiple entry points, though. There would be multiple
> blocks of code that are skipped if the module is imported, but
> executed if it's run as a script. Remember, Python code is NOT
> declarative. That 'def' statement is an actual executable bit of code.
>

I take back my comment. I think I may have used the multiple __main__
blocks occasionally, for reasons Chris notes. Like I want something
configured BEFORE a function is defined (maybe a global that only makes
sense when run as script).

However, I haven't done it for a long while. I think when I was younger I
didn't value encapsulation sufficiently. That said, I don't want the
capability to change. There are lots of things I don't do stylistically,
but I don't want striken from the language.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/FPDFDFM66BZSHPYM3ZNYHEMZ4PTR5T3L/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python __main__ function

[Chris Angelico]

On Fri, May 29, 2020 at 5:54 AM  wrote:
>
> > -Original Message-
> > From: Chris Angelico 
> >
> > People can already put all their main logic into a function. If you want
> to unit-
> > test your main function, that's the best way to do it.
> > The trouble is, how much goes into main() and how much into if __name__
> > == '__main__'? For example: Does your main function accept a list of
> > arguments, or does it look in sys.argv? Neither answer is wrong. And that
> > means the best way is to NOT force everyone across all of Python to choose
> > the same way - let people write their code their way.
> >
>
> People write main entry points that are not exactly this?
>
> If __name__ == '__main__':
> sys.exit(main(sys.argv[1:]))
>

Of course they do! Much more common in my code is this:

if __name__ == "__main__":
main()

or some variation that fetches sys.argv but doesn't call sys.exit. And
quite a number of my projects include a global try/except around
main() to log errors to a file as well as to stderr (due to where
they're used), or process their args individually (for arg in
sys.argv[1:]: do_stuff(arg)), or some other variation. It's most
certainly NOT always exactly what you show there.

And that's the problem. If it's part of the language definition, it
will always have *exactly* the same semantics. As an idiom, it can be
varied slightly to suit the situation, but as a language feature, it's
rigid.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ITRCOHH525FPD5IQL7AWUY67IBBTGCLD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python __main__ function

[tritium-list]

(Apologies to Chris, reply vs. replay all error on my part)

> -Original Message-
> From: Chris Angelico 
> 
> People can already put all their main logic into a function. If you want
to unit-
> test your main function, that's the best way to do it.
> The trouble is, how much goes into main() and how much into if __name__
> == '__main__'? For example: Does your main function accept a list of
> arguments, or does it look in sys.argv? Neither answer is wrong. And that
> means the best way is to NOT force everyone across all of Python to choose
> the same way - let people write their code their way.
> 

People write main entry points that are not exactly this?

If __name__ == '__main__':
sys.exit(main(sys.argv[1:]))


Which is not to say this is the only use of the idiom about __name__ and
__main__, just that the community appears to be slowly converging on some
spelling of that.  I would be ok with some sugar for that spelling, but I
don't need it.  I would not be ok with getting rid of the current spelling.

> ChrisA
> ___
> Python-ideas mailing list -- python-ideas@python.org To unsubscribe send
> an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at https://mail.python.org/archives/list/python-
> id...@python.org/message/OYIJA7YRXRKEN3WMURTC4T2ZCKQBMTPV/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/PDU7NJXFKXCB6HFNJUGZAXNSHUNZ2U6Q/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python __main__ function

[Alex Hall]

On Thu, May 28, 2020 at 9:52 PM Paul Sokolovsky  wrote:

> On Fri, 29 May 2020 05:33:57 +1000
> Chris Angelico  wrote:
> > People can already put all their main logic into a function. If you
> > want to unit-test your main function, that's the best way to do it.
>

Yes, and I want to make it easy, even tempting, to do so.


> > The trouble is, how much goes into main() and how much into if
> > __name__ == '__main__'? For example: Does your main function accept a
> > list of arguments, or does it look in sys.argv? Neither answer is
> > wrong.


I would suggest that people write another function (maybe main without the
dunder) if they want something a little more custom (e.g. more arguments)
and have `__main__` call that. Really the line `def __main__(...):` would
almost mechanically replace `if __name__ == '__main__':`, so it's easy to
look at existing projects to see how this could be handled. They could also
give `__main__` optional arguments.


> And that means the best way is to NOT force everyone across all
> > of Python to choose the same way - let people write their code their
> > way.
>
> Yes. Besides, "principled" and "uncompromising" linters and code
> formatters are recently on a rise, so hopefully everyone/every team can
> choose a style per their likes, without putting burden on all the other
> users of the language.
>

 There is no forcing, there is no burden. Certainly the `if` method should
remain for those who need it (e.g. to check in two separate blocks) and for
compatibility. It would just encourage better scoping. Besides, it would be
applicable in the vast majority of cases.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/I4B7UX7NTWOGAZOBWXNT2RNC732XILZW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python __main__ function

[Chris Angelico]

On Fri, May 29, 2020 at 2:32 AM David Mertz  wrote:
>
> On Thu, May 28, 2020, 12:17 PM  wrote:
>>
>> The OP is proposing as a possibility: "we could require user to have only 
>> one if __name__ == '__main__':". In that case, functionality will be 
>> reduced, won't it?
>
>
> I don't support the proposal. However, I've also never written a script with 
> multiple 'if __name__ == __main__' lines, and I think if I saw one I'd 
> complain in code review.
>
> It's hard for me to imagine how multiple entry point to a script can be a 
> good thing.
>

There aren't multiple entry points, though. There would be multiple
blocks of code that are skipped if the module is imported, but
executed if it's run as a script. Remember, Python code is NOT
declarative. That 'def' statement is an actual executable bit of code.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/743C6XJ2DYARWCG4VVI62APXRELZKNVR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: An HTTP API to list versions of Python

[Wes Turner]

Does there need to be a webapp? Or could it just be a JSON-LD file in a
static site; maybe with a GH Action that validates (and maybe generates)
the data according to a schema.

Here's a rough sketch of a schema for this data:

"Generate Misc/NEWS from individual files" (2017)
https://github.com/python/core-workflow/issues/6#issuecomment-290493601

On Thu, May 28, 2020, 4:09 AM M.-A. Lemburg  wrote:

> On 27.05.2020 23:46, Joseph Banks wrote:
> > The downside to the FTP solution however is that little metadata is
> > present about the versions
> >
> > The FTP pages are primarily for downloading versions which isn't the aim
> > of the proposal, it's to be able to fetch the metadata.
> >
> > Adding some sort of metadata file to all versions on the FTP server
> > would solve the problem but at that point I'm not sure the "doesn't need
> > any new process" argument still holds water.
>
> It was an FTP server. Nowadays, the files are served up via HTTPS.
> The FTP server has been switched off long ago.
>
> The point about not needing more process is that you always need
> someone to maintain any such addition.
>
> It would be fairly easy for someone to step up and start maintaining
> such an index, perhaps even as a PyPI package, but such resources are
> only useful when fully maintained over long periods of time.
>
> In terms of meta data, the best we currently have are PEPs
> for each minor release version, the downloads page on python.org
> for release dates and PEP links, and the location I mentioned for
> quickly grabbing the download files.
>
> > On Wed, 27 May 2020 at 22:36, M.-A. Lemburg  > > wrote:
> >
> > On 27.05.2020 18:59, Antoine Pitrou wrote:
> > > On Tue, 26 May 2020 22:19:12 -0400
> > > Kyle Stanley mailto:aeros...@gmail.com>>
> wrote:
> > >>
> > >>> It could become more detailed about each minor versions, git
> > tag, links
> > >> to changelogs, links to the repositories, to the docs, download
> > links,
> > >> and so on.
> > >>
> > >> I don't know that it needs to be said, but for now, I think we
> > should start
> > >> with a minimalist approach by keeping the API focused on reducing
> the
> > >> number of *existing* locations to update, rather than predicting
> > what might
> > >> sort of fields might be useful to include. Otherwise, it could
> > very well
> > >> end up becoming more work to maintain compared to what it
> > actually saves.
> > >
> > > Unless unusual fields are required in the returned information, how
> > > about using PyPI as the information store?  That way, you don't
> > have to
> > > design a new API and implement a new backend...
> > >
> > > (that doesn't mean PyPI needs to host any downloadable files for
> > Pyhon,
> > > by the way - just the metadata)
> >
> > Here's something which is close to an HTTP API and doesn't need any
> new
> > process, since it's been working for ages...
> >
> > https://www.python.org/ftp/python/
> >
> > (and it's also easier to use than the regular python.org
> >  download
> > mechanisms)
> >
> > If you're looking for the 1.x releases, you can find them here:
> >
> > https://www.python.org/ftp/python/src/
> >
> > Even earlier ones are on USENET.
> >
> > --
> > Marc-Andre Lemburg
> > eGenix.com
> >
> > Professional Python Services directly from the Experts (#1, May 27
> 2020)
> > >>> Python Projects, Coaching and Support ...
> https://www.egenix.com/
> > >>> Python Product Development ...
> https://consulting.egenix.com/
> >
>  
> >
> > ::: We implement business ideas - efficiently in both time and costs
> :::
> >
> >eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
> > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
> >Registered at Amtsgericht Duesseldorf: HRB 46611
> >https://www.egenix.com/company/contact/
> >  https://www.malemburg.com/
> > ___
> > Python-ideas mailing list -- python-ideas@python.org
> > 
> > To unsubscribe send an email to python-ideas-le...@python.org
> > 
> > https://mail.python.org/mailman3/lists/python-ideas.python.org/
> > Message archived at
> >
> https://mail.python.org/archives/list/python-ideas@python.org/message/XMURTTG67FWUZVQCXCQWHTGZTX7YYDGF/
> > Code of Conduct: http://python.org/psf/codeofconduct/
> >
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Experts (#1, May 28 2020)
> >>> Python Projects, Coaching and Support ...https://www.egenix.com/
> >>> Python Product Development ...https://consulting.egenix.com/
> 

[Python-ideas] Re: Python __main__ function

[Chris Angelico]

On Fri, May 29, 2020 at 5:25 AM Alex Hall  wrote:
>
> On Thu, May 28, 2020 at 12:57 PM Paul Sokolovsky  wrote:
>>
>> And in all fairness, all good ideas already came to somebody else years
>> ago. There's https://www.python.org/dev/peps/pep-0299/ , successfully
>> rejected yet back in 2002. (So, feel free to use it in your own
>> environment/Python dialect.)
>
>
> Thanks for the link. Pity it was rejected. I can think of one reason I'd 
> quite like this beyond it being DRY and concise: I often see code written by 
> others like this:
>
> ```
> def foo(bar):
> print(bar)
>
> if __name__ == '__main__':
> bar = 3
> foo(bar)
> ```
>
> Now `bar` is both a local and global variable, which leads to both annoying 
> IDE warnings and actual bugs. I think I encountered a bug related to this 
> when someone used `eval()` (which was the right thing to do in this case) and 
> didn't specify the namespaces correctly, but name shadowing made it seem like 
> their code was correct.
>
> Point is, I'd like something that encourages people to put all their 
> `__main__` logic and variables into a function, rather than a module level 
> conditional.
>

People can already put all their main logic into a function. If you
want to unit-test your main function, that's the best way to do it.
The trouble is, how much goes into main() and how much into if
__name__ == '__main__'? For example: Does your main function accept a
list of arguments, or does it look in sys.argv? Neither answer is
wrong. And that means the best way is to NOT force everyone across all
of Python to choose the same way - let people write their code their
way.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/OYIJA7YRXRKEN3WMURTC4T2ZCKQBMTPV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python __main__ function

[Paul Sokolovsky]

Hello,

On Thu, 28 May 2020 16:05:52 -0400
 wrote:

[]

> People write main entry points that are not exactly this?
> 
> If __name__ == '__main__':
> sys.exit(main(sys.argv[1:]))

Yes, most of the time, I don't emulate C main function, so I write it
as:

if __name__ == "__main__":
main()

(Mind the double quotes!!)

And one sweet day, I intend to fully convert to write it:

if __name__ == "__main__":
__main__()


(The morale of the story: you won't get all people agree to your way,
can as well accept that.)


-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/UEZVZO6G256XRZ6AEGUJMUBBEY7QNWFI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python __main__ function

[Paul Sokolovsky]

Hello,

On Fri, 29 May 2020 05:33:57 +1000
Chris Angelico  wrote:

[]

> People can already put all their main logic into a function. If you
> want to unit-test your main function, that's the best way to do it.
> The trouble is, how much goes into main() and how much into if
> __name__ == '__main__'? For example: Does your main function accept a
> list of arguments, or does it look in sys.argv? Neither answer is
> wrong. And that means the best way is to NOT force everyone across all
> of Python to choose the same way - let people write their code their
> way.

Yes. Besides, "principled" and "uncompromising" linters and code
formatters are recently on a rise, so hopefully everyone/every team can
choose a style per their likes, without putting burden on all the other
users of the language.

> 
> ChrisA

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/PDRXTEDCFLMLDZDGT7UDXH6ENP2X2FOE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python __main__ function

[Alex Hall]

On Thu, May 28, 2020 at 12:57 PM Paul Sokolovsky  wrote:

> And in all fairness, all good ideas already came to somebody else years
> ago. There's https://www.python.org/dev/peps/pep-0299/ , successfully
> rejected yet back in 2002. (So, feel free to use it in your own
> environment/Python dialect.)
>

Thanks for the link. Pity it was rejected. I can think of one reason I'd
quite like this beyond it being DRY and concise: I often see code written
by others like this:

```
def foo(bar):
print(bar)

if __name__ == '__main__':
bar = 3
foo(bar)
```

Now `bar` is both a local and global variable, which leads to both annoying
IDE warnings and actual bugs. I think I encountered a bug related to this
when someone used `eval()` (which was the right thing to do in this case)
and didn't specify the namespaces correctly, but name shadowing made it
seem like their code was correct.

Point is, I'd like something that encourages people to put all their
`__main__` logic and variables into a function, rather than a module level
conditional.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/FZB5HUAP7AM3PZF4IC7MVEGDPTYJWPPH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python __main__ function

[Rhodri James]

On 28/05/2020 21:05, tritium-l...@sdamon.com wrote:

People write main entry points that are not exactly this?

If __name__ == '__main__':
 sys.exit(main(sys.argv[1:]))


Mostly I don't write main entry points at all.  If I do the dance, it's 
more likely to be:


if __name__ == '__main__':
test_this_module_to_destruction()

...though personally I prefer separate scripts for testing.  For the 
main program, I'm generally using argparse so there's no need to mess 
with sys.argv directly, and why on earth would I add complexity and 
indentation with an entirely unnecessary function wrapper?


--
Rhodri James *-* Kynesim Ltd
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/3ZY6X3GKGXGCQQMYMNOPRAMV5CWIBPMZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python __main__ function

[Chris Angelico]

On Fri, May 29, 2020 at 12:43 PM Jonathan Goble  wrote:
>
> On Thu, May 28, 2020 at 9:03 PM Greg Ewing  
> wrote:
>>
>> On 29/05/20 8:05 am, tritium-l...@sdamon.com wrote:
>>
>> > People write main entry points that are not exactly this?
>> >
>> > If __name__ == '__main__':
>> >  sys.exit(main(sys.argv[1:]))
>>
>> It's not clear that exiting with the return value of main() is
>> the most Pythonic thing to do -- it's more of a C idiom that
>> doesn't seem so useful when exceptions exist.
>
>
> If all you care about in terms of exit codes is 0 for success and 1 for error 
> (which is sufficient for most scripts), then yes, this is probably not needed.
>
> However, it's useful in two cases. One is if you're writing a script tool to 
> be distributed, where you probably want to have a blanket "except Exception" 
> clause in main() to catch everything and print a graceful failure message. In 
> that case, you probably want to suppress the ugly traceback, which requires 
> manually producing the appropriate exit code (probably 1, but maybe something 
> else).
>

But thanks to exception handling, we can unwind the stack in a
perfectly clean manner AND specify a return value, all in one simple
operation:

sys.exit(4)

You don't need to carry the return value from main. You don't have to
worry about how deep into your call stack the decision to exit is. You
just sys.exit with whatever value you want, and everything will be
cleaned up perfectly.

So the logic can simply be: If main returns, then it was successful,
and we exit zero. If main raises an exception, then it was
unsuccessful, and we exit one, or some other value if specified by the
exception. And that's spelled:

if __name__ == '__main__':
main()

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HSH4WCZ5UT7QYYDBBYGRLNQHUGUUKVXE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python __main__ function

[Christopher Barker]

I'm going to note here that it is perfectly reasonable to use Python as a
"scripting language" -- to, you know, write scripts.

And when I'm writing scripts, I make heavy use of the global namespace :-)

Granted, if it's really a quick and dirty script, I'll not bother with if
__name__ == "__main__" at all, but there is a middle ground, where I do.

There's no need to restrict Python to be more structured in this manner.

-CHB



On Thu, May 28, 2020 at 12:52 PM David Mertz  wrote:

> On Thu, May 28, 2020, 3:06 PM Chris Angelico  wrote:
>
>> There aren't multiple entry points, though. There would be multiple
>> blocks of code that are skipped if the module is imported, but
>> executed if it's run as a script. Remember, Python code is NOT
>> declarative. That 'def' statement is an actual executable bit of code.
>>
>
> I take back my comment. I think I may have used the multiple __main__
> blocks occasionally, for reasons Chris notes. Like I want something
> configured BEFORE a function is defined (maybe a global that only makes
> sense when run as script).
>
> However, I haven't done it for a long while. I think when I was younger I
> didn't value encapsulation sufficiently. That said, I don't want the
> capability to change. There are lots of things I don't do stylistically,
> but I don't want striken from the language.
>
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/FPDFDFM66BZSHPYM3ZNYHEMZ4PTR5T3L/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/QCVJTAFY5QDAAMAOOA3DQKAHWRK5ZIV5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Optional keyword arguments

[Greg Ewing]

On 29/05/20 12:17 am, Richard Damon wrote:

But default values for arguments are really part of the responsibility
for the caller, not the called function. The classic implementation
would be that the caller passes all of the explicitly,


I would say that's really a less-than-ideal implementation,
that has the consequence of requiring information to be put
in the header that doesn't strictly belong there.

To my mind, the signature consists of information that a
static type checker would need to verify that a call is valid.
That does not include default values of arguments. The fact
that a particular value is substituted if an argument is
omitted is part of the behaviour of the function, not part
of its signature.

By putting default values in the header, we're including a
tiny bit of behavioural information. By distinguishing between
one-time and per-call evaluation of defaults, we're adding a
bit more behavioural information.

Where do we draw the line? How much of the behaviour of the
function do we want to move into the header?

--
Greg
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/E6VPNSTZXB7UCUOUHGVD7W57HF6L6A2R/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python __main__ function

[Ethan Furman]

On 05/28/2020 01:05 PM, tritium-l...@sdamon.com wrote:


People write main entry points that are not exactly this?

If __name__ == '__main__':
 sys.exit(main(sys.argv[1:]))


I have never written an entry point that looks like that.

--
~Ethan~
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ACXVXLTZO42EEOYYZUXWDVHB3IIXKVPD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python __main__ function

[Jonathan Goble]

On Thu, May 28, 2020 at 9:03 PM Greg Ewing 
wrote:

> On 29/05/20 8:05 am, tritium-l...@sdamon.com wrote:
>
> > People write main entry points that are not exactly this?
> >
> > If __name__ == '__main__':
> >  sys.exit(main(sys.argv[1:]))
>
> It's not clear that exiting with the return value of main() is
> the most Pythonic thing to do -- it's more of a C idiom that
> doesn't seem so useful when exceptions exist.
>

If all you care about in terms of exit codes is 0 for success and 1 for
error (which is sufficient for most scripts), then yes, this is probably
not needed.

However, it's useful in two cases. One is if you're writing a script tool
to be distributed, where you probably want to have a blanket "except
Exception" clause in main() to catch everything and print a graceful
failure message. In that case, you probably want to suppress the ugly
traceback, which requires manually producing the appropriate exit code
(probably 1, but maybe something else).

Additionally, you might be writing a tool with more complex exit codes that
are part of its documented API. A few GNU tools are like this ("diff" is
the first example that comes to mind). Especially if you want to write a
(mostly) drop-in replacement for such a tool, mimicking the exit code
behavior can be critical.

So this type of entry point is useful even in Python, and tools that
generate entry point scripts* should continue to generate code like this.
It works even if you never put a return statement in main(), since the
script exits on its own with 1 on an unhandled exception, and the implicit
"return None" at the end of main() is treated by sys.exit as 0.

*pip, for example, does this. It's worth noting that most instances I've
seen of this have been automatically generated scripts like those; I've
rarely seen a handwritten example. And most cases of this that I see,
including pip's scripts, don't pass anything to main(), because you can
always get the argv from the sys module (and sys.argv[0] can be useful in
some cases).
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/OMB2D7C4HVJ5VZE7IS2GXRG53WEN4UV5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python __main__ function

[Greg Ewing]

On 29/05/20 8:05 am, tritium-l...@sdamon.com wrote:


People write main entry points that are not exactly this?

If __name__ == '__main__':
 sys.exit(main(sys.argv[1:]))


It's not clear that exiting with the return value of main() is
the most Pythonic thing to do -- it's more of a C idiom that
doesn't seem so useful when exceptions exist.

--
Greg
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/UEFQEB3YZIB45KWAHPBWSZLFDBSA672Y/
Code of Conduct: http://python.org/psf/codeofconduct/