Re: The slash "/" as used in the documentation

[Chris Angelico]

On Mon, Feb 11, 2019 at 6:49 PM Ian Kelly  wrote:
>
> On Mon, Feb 11, 2019 at 12:19 AM Terry Reedy  wrote:
> > The pass-by-position limitation is not in CPython, it is the behavior of
> > C functions, which is the behavior of function calls in probably every
> > assembly and machine language.  Allowing the flexibility of Python
> > function calls take extra code and slows function calls.
> >
> > math.sin, for instance, is a fast-as-possible wrapper around the C math
> > library sin function.  It extracts the C double from the Python float,
> > calls C sin, and returns the returned C double wrapped as a Python
> > float.  Coredevs decided that being able to call math.sin(x=.3) is
> > not worth the resulting slowdown.  I am rather sure that heavy users of
> > the math module would agree.
>
> For math.sin, sure, but what about, say, list.index? Here's the start
> of the implementation:
>
> static PyObject *
> listindex(PyListObject *self, PyObject *args)
> {
> Py_ssize_t i, start=0, stop=Py_SIZE(self);
> PyObject *v;
>
> if (!PyArg_ParseTuple(args, "O|O&O&:index", &v,
> _PyEval_SliceIndex, &start,
> _PyEval_SliceIndex, &stop))
>
>
> This is already paying the cost of not using C-style positional
> function arguments, but then it only takes an argument tuple, so it
> can't take keyword arguments anyway. Why?

How much of a performance penalty are you willing to accept for this?
It would apply to every C-implemented function, including tiny and
common ones like 1+2, just in case someone wanted to write
int.__add__(self=1, value=2). Try to pitch this to sysadmins and app
authors: "CPython 3.8 will be 3% slower, but you can pass keyword args
to dunders now!"

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The slash "/" as used in the documentation

[Chris Angelico]

On Mon, Feb 11, 2019 at 6:51 PM Terry Reedy  wrote:
> > and not normally accessible to pure Python functions without
> > some arm twisting.
>
> In my first response on this thread I explained and demonstrated how to
> access signature strings from Python, as done by both help() and IDLE.
> Please read if you are concerned about this.  There is hardly any extra
> difficulty.  I did not discuss how to process the signature string
> returned by str(signature) nor how to access the information in
> Signature objects otherwise, but the str and Signature docs cover these.

The feature of positional-only args isn't available to pure Python
functions at the moment, other than by taking *args and then mutating
your own sig. Hence the slash is unfamiliar to people.

If we want arbitrary consistency, it might be better to work that way:
to let pure Python functions take pos-only args. I doubt it would be
of particularly great benefit, but it wouldn't hurt.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The slash "/" as used in the documentation

[Terry Reedy]

On 2/11/2019 2:47 AM, Ian Kelly wrote:


For math.sin, sure, but what about, say, list.index?


Special-case conversion is a different issue from blanket conversion.
Some C functions have been converted to accept some or all args by 
keyword.  I don't know the status of list method conversion: discussed? 
accepted? rejected?  The people involved with conversion of documenting 
mostly don't read this list.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Can't run setup.py offline due to setup_requires - setup.py calls home

[Chris Narkiewicz via Python-list]

Hi,

I'm trying to build a debian package in offline environment (build server).

To build this package, I need to ship all python dependencies as source
packages and build them there. This is no problem for all, except one
package that has build-time dependencies: Automat-0.70.

debian/rules calls this pip to install all requirements from local
package collection:

pip3 install --log=... --no-cache --no-index --find-links=pypi
--no-binary=":all:" -r requirements.txt

Directory pypi contains ALL dependencies required for build.

This works ok when build server has connection to network, but fails for
offline builds. I pinpointed the problem to package Automat, that
specifies some dependencies via setup_requires=[...]:

setup(
...,
setup_requires=[
'setuptools-scm',
'm2r',
],
...
)

Trying to build Automat locally by calling setup.py fails immediately in
my offline environment:

$ python setup.py
...
distutils.errors.DistutilsError: Download error for
https://files.pythonhosted.org/packages/39/e7/9fae11a45f5e1a3a21d8a98d02948e597c4afd7848a0dbe1a1ebd235f13e/m2r-0.2.1.tar.gz#sha256=bf90bad66cda1164b17e5ba4a037806d2443f2a4d5ddc9f6a5554a0322aaed99:
[Errno 111] Connection refused


Is there any way to stop Distutils from calling home?

Best regards,
Chris Narkiewicz
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: My appreciation for python's great work to my country.

[Alex Kaye]

Kiyimba,

In my community in Arizona ( pop 7000) I am the
only one using Linux and the only one who is
studying Python, no one is coding. So spread your
knowledge among the youth of your commun ity. It is good for
their future.

Alex Kaye


On Sat, Feb 9, 2019 at 1:34 PM Terry Reedy  wrote:

> On 2/8/2019 4:37 AM, Kiyimba Godfrey wrote:
> > I take this opportunity to thank python for having designed such a
> wonderful program which has enabled computer scientists and programmers in
> my country Uganda, understand, design and create other computer application
> programs .
>
> You're welcome, and I appreciate your comment.  I donate time to
> development of Python and IDLE *because* they are particularly useful to
> beginners and people in less developed countries.
>
>
> --
> Terry Jan Reedy
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

exit 2 levels of if/else and execute common code

[Neal Becker]

I have code with structure:
```
if cond1:
  [some code]
  if cond2: #where cond2 depends on the above [some code]
[ more code]

  else:
[ do xxyy ]
else:
  [ do the same xxyy as above ]
```

So what's the best style to handle this?  As coded, it violates DRY.  
Try/except could be used with a custom exception, but that seems a bit heavy 
handed.  Suggestions?

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: exit 2 levels of if/else and execute common code

[Rhodri James]

On 11/02/2019 15:25, Neal Becker wrote:

I have code with structure:
```
if cond1:
   [some code]
   if cond2: #where cond2 depends on the above [some code]
 [ more code]

   else:
 [ do xxyy ]
else:
   [ do the same xxyy as above ]
```

So what's the best style to handle this?  As coded, it violates DRY.
Try/except could be used with a custom exception, but that seems a bit heavy
handed.  Suggestions?


If it's trivial, ignore DRY.  That's making work for the sake of making 
work in such a situation.


If it isn't trivial, is there any reason not to put the common code in a 
function?


--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

Re: exit 2 levels of if/else and execute common code

[Neal Becker]

Rhodri James wrote:

> On 11/02/2019 15:25, Neal Becker wrote:
>> I have code with structure:
>> ```
>> if cond1:
>>[some code]
>>if cond2: #where cond2 depends on the above [some code]
>>  [ more code]
>> 
>>else:
>>  [ do xxyy ]
>> else:
>>[ do the same xxyy as above ]
>> ```
>> 
>> So what's the best style to handle this?  As coded, it violates DRY.
>> Try/except could be used with a custom exception, but that seems a bit
>> heavy
>> handed.  Suggestions?
> 
> If it's trivial, ignore DRY.  That's making work for the sake of making
> work in such a situation.
> 
> If it isn't trivial, is there any reason not to put the common code in a
> function?
> 

Well the common code is 2 lines.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: exit 2 levels of if/else and execute common code

[Chris Angelico]

On Tue, Feb 12, 2019 at 2:27 AM Neal Becker  wrote:
>
> I have code with structure:
> ```
> if cond1:
>   [some code]
>   if cond2: #where cond2 depends on the above [some code]
> [ more code]
>
>   else:
> [ do xxyy ]
> else:
>   [ do the same xxyy as above ]
> ```
>
> So what's the best style to handle this?  As coded, it violates DRY.
> Try/except could be used with a custom exception, but that seems a bit heavy
> handed.  Suggestions?

One common way to do this is to toss a "return" after the cond2 block.
Means this has to be the end of a function, but that's usually not
hard. Or, as Rhodri suggested, refactor xxyy into a function, which
you then call twice.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Can't run setup.py offline due to setup_requires - setup.py calls home

[Ben Finney]

Chris Narkiewicz via Python-list  writes:

> debian/rules calls this pip to install all requirements from local
> package collection:
>
> pip3 install --log=... --no-cache --no-index --find-links=pypi
> --no-binary=":all:" -r requirements.txt

As you have observed, this fails because Setuptools does not correctly
handle the ‘setup_requires’ option
https://github.com/pypa/setuptools/issues/457>.

> Directory pypi contains ALL dependencies required for build.

All of the build dependencies, *including* the ones specified in
‘setup_requires’?

> This works ok when build server has connection to network, but fails for
> offline builds. I pinpointed the problem to package Automat, that
> specifies some dependencies via setup_requires=[...]:
>
> setup(
> ...,
> setup_requires=[
> 'setuptools-scm',
> 'm2r',
> ],
> ...
> )

To avoid the Setuptools bug, the PyPA recommends dropping the
‘setup_requires’ option and instead specifying build dependencies in a
PEP 518 formatted metadata file
https://github.com/pypa/setuptools/issues/293>.

You could create such a specification (by adding a metadata file),
ensure those dependencies are also present locally, and meanwhile
present the maintainers of this project with your merge request to add
that metadata file.

-- 
 \   “What do religious fundamentalists and big media corporations |
  `\   have in common? They believe that they own culture, they are so |
_o__) self-righteous about it …” —Nina Paley, 2011 |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: exit 2 levels of if/else and execute common code

[Dan Sommers]

On 2/11/19 9:25 AM, Neal Becker wrote:

I have code with structure:
```
if cond1:
   [some code]
   if cond2: #where cond2 depends on the above [some code]
 [ more code]

   else:
 [ do xxyy ]
else:
   [ do the same xxyy as above ]
```

So what's the best style to handle this?  As coded, it violates DRY.
Try/except could be used with a custom exception, but that seems a bit heavy
handed.  Suggestions?


Put some code, cond2, more code, and xxyy into separate
functions, and leave it the way it is.  We all have our own
levels of acceptable inelegance, and this one fits well
within mine.  Optionally, instead of separate calls to xxyy,
set a flag and  only call xxyy at the end if the flag is set.

Dan
--
https://mail.python.org/mailman/listinfo/python-list

Re: exit 2 levels of if/else and execute common code

[Neal Becker]

Chris Angelico wrote:

> On Tue, Feb 12, 2019 at 2:27 AM Neal Becker  wrote:
>>
>> I have code with structure:
>> ```
>> if cond1:
>>   [some code]
>>   if cond2: #where cond2 depends on the above [some code]
>> [ more code]
>>
>>   else:
>> [ do xxyy ]
>> else:
>>   [ do the same xxyy as above ]
>> ```
>>
>> So what's the best style to handle this?  As coded, it violates DRY.
>> Try/except could be used with a custom exception, but that seems a bit
>> heavy
>> handed.  Suggestions?
> 
> One common way to do this is to toss a "return" after the cond2 block.
> Means this has to be the end of a function, but that's usually not
> hard. Or, as Rhodri suggested, refactor xxyy into a function, which
> you then call twice.
> 
> ChrisA

Not bad, but turns out it would be the same return statement for both the 
normal return path (cond1 and cond2 satisfied) as well as the abnormal 
return, so not really much of an improvement.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: exit 2 levels of if/else and execute common code

[Chris Angelico]

On Tue, Feb 12, 2019 at 3:21 AM Neal Becker  wrote:
>
> Chris Angelico wrote:
>
> > On Tue, Feb 12, 2019 at 2:27 AM Neal Becker  wrote:
> >>
> >> I have code with structure:
> >> ```
> >> if cond1:
> >>   [some code]
> >>   if cond2: #where cond2 depends on the above [some code]
> >> [ more code]
> >>
> >>   else:
> >> [ do xxyy ]
> >> else:
> >>   [ do the same xxyy as above ]
> >> ```
> >>
> >> So what's the best style to handle this?  As coded, it violates DRY.
> >> Try/except could be used with a custom exception, but that seems a bit
> >> heavy
> >> handed.  Suggestions?
> >
> > One common way to do this is to toss a "return" after the cond2 block.
> > Means this has to be the end of a function, but that's usually not
> > hard. Or, as Rhodri suggested, refactor xxyy into a function, which
> > you then call twice.
> >
> > ChrisA
>
> Not bad, but turns out it would be the same return statement for both the
> normal return path (cond1 and cond2 satisfied) as well as the abnormal
> return, so not really much of an improvement.

Not sure what you mean there. The result would be something like this:

def frobnicate():
if cond1:
do_stuff()
if cond2:
do_more_stuff()
return
do_other_stuff()

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: exit 2 levels of if/else and execute common code

[Irv Kalb]

> On Feb 11, 2019, at 7:25 AM, Neal Becker  wrote:
> 
> I have code with structure:
> ```
> if cond1:
>  [some code]
>  if cond2: #where cond2 depends on the above [some code]
>[ more code]
> 
>  else:
>[ do xxyy ]
> else:
>  [ do the same xxyy as above ]
> ```
> 
> So what's the best style to handle this?  As coded, it violates DRY.  
> Try/except could be used with a custom exception, but that seems a bit heavy 
> handed.  Suggestions?
> 

I like the additional function approach others have mentioned.  But if you want 
a different approach, you could do this:

runExtraCode = True# set some Boolean
if cond1:
[some code]
if cond2:
[more code]
runExtraCode = False  # both conditions met, no need to run the extra 
code

if runExtraCode:
[do xxyy]


Irv

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: exit 2 levels of if/else and execute common code

[Neal Becker]

Chris Angelico wrote:

> On Tue, Feb 12, 2019 at 3:21 AM Neal Becker  wrote:
>>
>> Chris Angelico wrote:
>>
>> > On Tue, Feb 12, 2019 at 2:27 AM Neal Becker 
>> > wrote:
>> >>
>> >> I have code with structure:
>> >> ```
>> >> if cond1:
>> >>   [some code]
>> >>   if cond2: #where cond2 depends on the above [some code]
>> >> [ more code]
>> >>
>> >>   else:
>> >> [ do xxyy ]
>> >> else:
>> >>   [ do the same xxyy as above ]
>> >> ```
>> >>
>> >> So what's the best style to handle this?  As coded, it violates DRY.
>> >> Try/except could be used with a custom exception, but that seems a bit
>> >> heavy
>> >> handed.  Suggestions?
>> >
>> > One common way to do this is to toss a "return" after the cond2 block.
>> > Means this has to be the end of a function, but that's usually not
>> > hard. Or, as Rhodri suggested, refactor xxyy into a function, which
>> > you then call twice.
>> >
>> > ChrisA
>>
>> Not bad, but turns out it would be the same return statement for both the
>> normal return path (cond1 and cond2 satisfied) as well as the abnormal
>> return, so not really much of an improvement.
> 
> Not sure what you mean there. The result would be something like this:
> 
> def frobnicate():
> if cond1:
> do_stuff()
> if cond2:
> do_more_stuff()
> return
> do_other_stuff()
> 
> ChrisA
sorry, I left out the return:

if cond1:
   [some code]
   if cond2: #where cond2 depends on the above [some code]
 [ more code]

   else:
 [ do xxyy ]
else:
   [ do the same xxyy as above ]
return a, b, c

So if we return normally, or return via some other path, the return 
statement is the same, and would be duplicated.

-- 
https://mail.python.org/mailman/listinfo/python-list

Zato blog post: A successful Python 3 migration story

[Terry Reedy]

The migration was from 2.7 to 2.7 and 3.x, rather than 3.x only.
I think it worth reading for anyone interested in the subject.
https://zato.io/blog/posts/python-3-migration-success-story.html

60,000 lines of Python and Cython, 130 external dependencies (but only 
10 not already 3.x ready) took 2 people 80 hours total.


Their head start was to write the 2.7 modules, from the beginning, with 
the following at the top.
from __future__ import absolute_import, division, print_function, 
unicode_literals



--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: where is math_sin defined?

[Barry Scott]

> On 10 Feb 2019, at 16:43, Chris Angelico  wrote:
> 
> On Mon, Feb 11, 2019 at 3:37 AM Barry Scott  wrote:
>> 
>> On Sunday, 10 February 2019 15:15:32 GMT Jon Ribbens wrote:
>>> As an aside, how is 'math.sin' actually implemented? mathmodule.c
>>> refers to the function 'math_sin' but that name is not defined
>>> anywhere in the Python source code. I'm a bit mystified as to how
>>> CPython manages to compile!
>> 
>> I used gdb to find it:
>> 
> 
> Effective, if a little tedious.

Tedious? Its fast and accurate only took 20s and got the answer right first 
time.

I had spent a few minutes reading and greping the code and my grep fu found to 
many false positives.

Barry

> 
> My technique was to first confirm that there was nothing saying
> "math_sin" anywhere in the repo (trust but verify - doesn't hurt to do
> a quick "git grep"), then to search mathmodule.c for "sin(", since
> searching for "sin" on its own gave way too many hits. That led me to
> the definition of sinpi(), then to asin() and sin(), both being
> defined using the FUNC1 template.
> 
> ChrisA
> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Im trying to replicate the youtube video Creating my own customized celebrities with AI.

[Peter J. Holzer]

On 2019-02-10 16:28:24 -0500, Avi Gross wrote:
> >> tenserflow, pygame, scipy, and numby
[...]
> please mention that the tenser flow should be tensorflow.

Eight, sir; seven, sir;
Six, sir; five, sir;
Four, sir; three, sir;
Two, sir; one!
Tenser, said the Tensor.
Tenser, said the Tensor.
Tension, apprehension,
And dissention have begun.

SCNR,
hp


-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Replicating YouTube video AI code in python

[jadenfigger]

I'm trying to replicate the YouTube video,  
https://m.youtube.com/watch?v=NTlXEJjfsQU. The videos git hub address is, 
https://github.com/carykh/alignedCelebFaces. The video says I have to download 
python 3 and using pip download tensorflow, numpy, scipy, and pygame. I've 
tried downloading this but keep getting errors when trying to download the 
packages with pip. If anyone could show me a good tutorial or show me the steps 
that would be great. Thank you
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Replicating YouTube video AI code in python

[Abdur-Rahmaan Janhangeer]

what python version are you using? what errors are you getting?

Abdur-Rahmaan Janhangeer
http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ
Mauritius
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Can't run setup.py offline due to setup_requires - setup.py calls home

[Chris Narkiewicz via Python-list]

On 11/02/2019 15:57, Ben Finney wrote:
> All of the build dependencies, *including* the ones specified in
> ‘setup_requires’?

Yes. easy_install simply doesn't look there. If I provide
~/.pydistutils.cfg with a path to find_links, it works ok.

Config file in $HOME however is no-go for a CI or build servers, as I
have no control over automated build environment (launchpad.net in this
case).

> To avoid the Setuptools bug, the PyPA recommends dropping the
> ‘setup_requires’ option and instead specifying build dependencies in a
> PEP 518 formatted metadata file
> https://github.com/pypa/setuptools/issues/293>.

Ok, I took Automat-0.7.tar.gz package and I modified it:
1) removed setup_requires
2) added pyproject.toml with content:

[build-system]
requires = ["setuptools-scm", "m2r"]

3) package is dropped into pypi directory with all dependencies.

However, when I try to install Automat from source, it doesn't work.

(venv)$ pip3 install --no-index --find-links=pypi --no-binary=':all:'
--no-cache Automat

I see that those build-time dependencies are not installed and build
complains about missing scm and m2r packages.

Is there any extra step I have to take?

Best regards,
Chris



signature.asc
Description: OpenPGP digital signature
-- 
https://mail.python.org/mailman/listinfo/python-list

more pythonic way

[Felix Lazaro Carbonell]

 

Hello to everyone:

Could you please tell me wich way of writing this method is more pythonic:

 

..

def find_monthly_expenses(month=None, year=None):

month = month or datetime.date.today()

..

 

Or it should better be:

...

if not month:

month = datetime.date.today()

..

 

Cheers,

Felix.

 

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: more pythonic way

[Grant Edwards]

On 2019-02-11, Felix Lazaro Carbonell  wrote:

> Could you please tell me wich way of writing this method is more pythonic:
>
> def find_monthly_expenses(month=None, year=None):
> month = month or datetime.date.today()
>
> Or it should better be:
>
> if not month:
> month = datetime.date.today()

The most pythonic way is to do this:

   def find_monthly_expenses(month=datetime.date.today().month, 
year=datetime.date.today().year):
  ...

And then start a month-long argument on the mailing list about how the
behavior of parameter default values is wrong and needs be changed.

;)

-- 
Grant Edwards   grant.b.edwardsYow! I always have fun
  at   because I'm out of my
  gmail.commind!!!

-- 
https://mail.python.org/mailman/listinfo/python-list

RE: more pythonic way

[Felix Lazaro Carbonell]

Sorry I meant 
 

..

def find_monthly_expenses(month=None, year=None):

month = month or datetime.date.today().month

..
 

Or it should better be:

...

if not month:

month = datetime.date.today().month

..
 

Cheers,

Felix.

 
-- 
https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

RE: more pythonic way

[Felix Lazaro Carbonell]

-Mensaje original-
De: Python-list [mailto:python-list-bounces+felix=epepm.cupet...@python.org]
En nombre de Grant Edwards
Enviado el: lunes, 11 de febrero de 2019 02:46 p.m.
Para: python-list@python.org
Asunto: Re: more pythonic way

On 2019-02-11, Felix Lazaro Carbonell  wrote:

> Could you please tell me wich way of writing this method is more pythonic:
>
> def find_monthly_expenses(month=None, year=None):
> month = month or datetime.date.today()
>
> Or it should better be:
>
> if not month:
> month = datetime.date.today()

>The most pythonic way is to do this:
>
>   def find_monthly_expenses(month=datetime.date.today().month,
year=datetime.date.today().year):
>  ...
>
>And then start a month-long argument on the mailing list about how the
behavior of parameter default values is wrong and needs be changed.
>
>;)
>
>-- 
>Grant Edwards   grant.b.edwardsYow! I always have fun
>  at   because I'm out of my
>  gmail.commind!!!
>
>--

Thanks Grant:

 but now I think I should have mentioned that this is a method in a Django
model, and default arguments are evaluated once when the method is defined,
not each time the method is called.
So, your way, wil yield the date when Django was started and not the date in
wich this method is called, and the date I intend to get is the one when the
method is called. I think that I shouldn't call datetime.date.today() as a
default value for the method's parameters.

Cheers,
Felix.

-- 
https://mail.python.org/mailman/listinfo/python-list

RE: more pythonic way

[David Raymond]

My non-expert vote is for

if month is None:
month = datetime.date.today().month

Because you're checking for your default value, not whether the boolean version 
of what they did give you is True or False. It's explicit, it's not reliant on 
any __bool__() function implementations or overrides, etc.


-Original Message-
From: Python-list 
[mailto:python-list-bounces+david.raymond=tomtom@python.org] On Behalf Of 
Felix Lazaro Carbonell
Sent: Monday, February 11, 2019 2:30 PM
To: python-list@python.org
Subject: more pythonic way

 

Hello to everyone:

Could you please tell me wich way of writing this method is more pythonic:

 

..

def find_monthly_expenses(month=None, year=None):

month = month or datetime.date.today()

..

 

Or it should better be:

...

if not month:

month = datetime.date.today()

..

 

Cheers,

Felix.

 

-- 
https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: The slash "/" as used in the documentation

[Avi Gross]

Ian,

I want to make sure we are talking about the same things in the same ways. I
will thus limit my comments in this message.

If efficiency is your major consideration, then using only positional
arguments of known types you can place on the stack and optimize at compile
time may be a great way to go. It is not the way python generally goes as it
supports objects at run time that can be of any type and in many cases
allows any number of arguments to a function.

Python was designed till recently in a way that valued some more innovative
methods and that included allowing a combination of positional and keyword
arguments. The positional arguments can still be called with keyword but
only if moved beyond any other positional arguments. What evolved is NOT the
only way I have seen this done. But what I see now is not what you are
describing in some ways.

If you want to talk about recent or planned changes, fine. But make that
clear. I was talking about how in the past positional arguments did not have
defaults available at the def statement level. I was talking about how use
of the symbol "=" in the context of defining function parameters had
multiple meanings. It not only established that the parameter accepted a
keyword but also provided a default. The allowed syntax required a default,
even if it was None. I mean the following fails:

>>> def func(a,b=): pass
SyntaxError: invalid syntax

If in the future (or some other language) you want to allow some way of
assigning a default to positional arguments, fine. What I see today does
not. 

So if I understand you, there is a proposal or even plan to change some of
the current functionality. I still have not seen anyone post a reference as
requested. I am very open to seeing what people are considering or maybe
even implementing and in what ways it may not be compatible with present
functionality.



-Original Message-
From: Python-list  On
Behalf Of Ian Kelly
Sent: Monday, February 11, 2019 1:46 AM
To: Python 
Subject: Re: The slash "/" as used in the documentation

On Sun, Feb 10, 2019 at 2:18 PM Avi Gross  wrote:
> I am not sure how python implements some of the functionality it does 
> as compared to other languages with similar features. But I note that 
> there are rules, presumably some for efficiency, such as requiring all 
> keyword arguments to be placed after the last positional argument. I 
> mean I can call
> func(a,b,c,d=1,e=2) but not func(a,b,d=1, c, e=2).
>
> So if you allowed a keyword to optionally be used for any positional 
> argument other than the last, c, would it not require a change in this
rule?
> I mean func(a="invalid",b,c,d=1,e=2) would violate the rule and so 
> would making b a keyword version. In my example, and for this reason 
> only, maybe c could work.

My suggestion was not to allow keyword arguments to arbitrarily replace any
positional parameter, or to otherwise change argument-passing in any way.
The suggestion was to drop positional-only arguments from functions
implemented in C instead of just documenting them better. In the example
above, if you want to pass a by keyword, you would have to pass b and c by
keyword as well.
That would still be true for functions implemented in C if a, b, and c are
no longer positional-only.

> The original motivation for keyword arguments included the concept of 
> specifying a default if not used. Positional arguments have no default.
> Similarly, they are required if explicitly named in the function
definition.
> So we are intermingling multiple concepts in the previous design.

Positional arguments are allowed to have defaults, and keyword-only
arguments are allowed to not have defaults. These are all valid
syntax:

# Allows a and b to be passed either positionally or by keyword def foo(a=1,
b=2): pass

# b is keyword-only
def foo(a=1, *, b=2): pass

# Allows a and b to be passed either positionally or by keyword def foo(a,
b): pass

# b is keyword-only and has no default
def foo(a, *, b): pass

Positional-ONLY arguments are not directly supported by the language, but
they exist in the C API and can also have defaults. For example, dict.get
takes two positional-only arguments. The second argument is optional, and
its default is None.

My point is that the axis of positional-only versus positional-or-keyword
versus keyword-only, and the axis of required versus optional are entirely
separate.

> I won't go on except to say it would break lots of existing code and 
> potentially complicate new code.

Can you give an example of something that would be broken by updating C API
functions to name positional-only arguments instead of just updating them to
document that they're positional-only?
--
https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

RE: The slash "/" as used in the documentation

[Avi Gross]

Ian,

I now assume we are no longer talking about the past or even the present but
some planned future. In that future we are talking about how to define a
function with added or changed functionality. So nothing I wrote earlier
really applies because I was talking of how things did work in the absence
of the changes needed to make new functionality possible.

So let me make sure I understood you. We are talking about the function
prototype as in def fun(...) and perhaps the lambda equivalent. The user of
the function would only see changes in the help files or other documentation
but no special symbols would be used when they invoke a function, albeit new
error messages may also happen if done wrong.

The earlier messages talked about using a forward slash but you seem to use
an asterisk for the same purpose. You can use the very overloaded "*"
character as a delimiter between the parameters mentioned to the left and
any remaining ones to the right. The "=" symbol is thus now allowed on
either side of the divide and now ONLY means there is a default. 

I thought the discussion was about python, not the C API that arguably is
used as much of python is in C directly or indirectly. I thought we were
talking about updating everything at the top interpreted python levels.
Please make it clear if we are not.

Will the above functionality, if understood, break (or modify how it works)
existing python code? I mean code that only uses the asterisk to denote
multiplication, exponentiation, list expansion and dictionary expansion and
so on. 

Just based on what you wrote, maybe not. It depends on the new meaning of
not having a sole asterisk somewhere in the parameter list. If that means
evaluate old style, great. If it means something else, I won't speculate but
can picture problems.

I will talk about your C API question in another message.


-Original Message-
From: Python-list  On
Behalf Of Ian Kelly
Sent: Monday, February 11, 2019 1:46 AM
To: Python 
Subject: Re: The slash "/" as used in the documentation

On Sun, Feb 10, 2019 at 2:18 PM Avi Gross  wrote:
> I am not sure how python implements some of the functionality it does 
> as compared to other languages with similar features. But I note that 
> there are rules, presumably some for efficiency, such as requiring all 
> keyword arguments to be placed after the last positional argument. I 
> mean I can call
> func(a,b,c,d=1,e=2) but not func(a,b,d=1, c, e=2).
>
> So if you allowed a keyword to optionally be used for any positional 
> argument other than the last, c, would it not require a change in this
rule?
> I mean func(a="invalid",b,c,d=1,e=2) would violate the rule and so 
> would making b a keyword version. In my example, and for this reason 
> only, maybe c could work.

My suggestion was not to allow keyword arguments to arbitrarily replace any
positional parameter, or to otherwise change argument-passing in any way.
The suggestion was to drop positional-only arguments from functions
implemented in C instead of just documenting them better. In the example
above, if you want to pass a by keyword, you would have to pass b and c by
keyword as well.
That would still be true for functions implemented in C if a, b, and c are
no longer positional-only.

> The original motivation for keyword arguments included the concept of 
> specifying a default if not used. Positional arguments have no default.
> Similarly, they are required if explicitly named in the function
definition.
> So we are intermingling multiple concepts in the previous design.

Positional arguments are allowed to have defaults, and keyword-only
arguments are allowed to not have defaults. These are all valid
syntax:

# Allows a and b to be passed either positionally or by keyword def foo(a=1,
b=2): pass

# b is keyword-only
def foo(a=1, *, b=2): pass

# Allows a and b to be passed either positionally or by keyword def foo(a,
b): pass

# b is keyword-only and has no default
def foo(a, *, b): pass

Positional-ONLY arguments are not directly supported by the language, but
they exist in the C API and can also have defaults. For example, dict.get
takes two positional-only arguments. The second argument is optional, and
its default is None.

My point is that the axis of positional-only versus positional-or-keyword
versus keyword-only, and the axis of required versus optional are entirely
separate.

> I won't go on except to say it would break lots of existing code and 
> potentially complicate new code.

Can you give an example of something that would be broken by updating C API
functions to name positional-only arguments instead of just updating them to
document that they're positional-only?
--
https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

RE: The slash "/" as used in the documentation

[Avi Gross]

Ian,

Again, not having read whatever documentation we may be discussing, I may be
very wrong.

The topic is the C API. I started using C at Bell Laboratories in 1982
replacing other languages I had used before. I haven't felt a reason to use
it in the last few decades as I moved on to yet other languages but am quite
aware that many of those languages are largely interpreters written in
languages like C or C++ and then regularly patched by adding C-like code to
replace slower functionality. I assume the C API you are mentioning refers
to the process of how you write and compile and invoke library functions so
that the function called will properly place python data structures in some
kind of stack so that the C library can properly take it and perform
computations. Similarly, when the function returns, some additional mapping
may be done. The above is meant to be general and obviously the details
matter.

C as a stand-alone language used to have pretty much positional arguments
and often a fixed number of them. We often had multiple functions we could
call with slightly different names if we wanted special effects like not
requiring a third argument. Clearly some approaches were less efficient if
the two-argument version simply turned around and called the three-argument
version with a third argument set to a default. So, often you played other
games like requiring a third argument (or in some languages a dangling
comma) which the function might choose to replace with a default internally
if it is something like -1. Obviously C libraries that are external must be
used as-is while internal ones you have written might allow changes.

Some languages I have used do not so much support doing lots of command-line
level pre-processing of command-line arguments but provide helper functions
that can be called within the function call that take all the arguments and
do further processing and return a form that the function can more easily
use. This works even better when evaluation is lazy and you can access the
exact original text the programmer or user typed in before it is evaluated.
Python now allows a limited form of that if you ask for *args and **kwargs.

So is this mainly about efficiency and C libraries or more? You can easily
make a C function that expects positional arguments in a proper order and
then make a wrapper in python (or C or FORTRAN or whatever) with a slightly
different name that does preprocessing and/or postprocessing. Python is
loaded with such functionality that tends to allow more complex things to be
done less efficiently. So if the wrapper can evaluate your arguments and
figure out what to do with positional arguments, great. The wrapper function
might support an optional argument that specifies whether other argument
units are in feet, miles, meters or even parsecs and also accept keyword
arguments for those measures and rescale them and only then call the
efficient C function with all the right arguments in the right positions. If
you as a programmer find that slows things down, you can make sure you use
the right units for the function and call the underlying function directly
with everything in place according to those rules.

Ending with this. Is the reality that we are now talking about gradual
changes in documentation as individual C functions are updated but not at
this point about what normal python users are seeing in terms of the code?
If so, I repeat, I was not talking about that and my comments are not
applicable and I can go back to doing more useful things away from this
forum.

-Original Message-
From: Python-list  On
Behalf Of Ian Kelly
Sent: Monday, February 11, 2019 1:46 AM
To: Python 
Subject: Re: The slash "/" as used in the documentation

On Sun, Feb 10, 2019 at 2:18 PM Avi Gross  wrote:
> I am not sure how python implements some of the functionality it does 
> as compared to other languages with similar features. But I note that 
> there are rules, presumably some for efficiency, such as requiring all 
> keyword arguments to be placed after the last positional argument. I 
> mean I can call
> func(a,b,c,d=1,e=2) but not func(a,b,d=1, c, e=2).
>
> So if you allowed a keyword to optionally be used for any positional 
> argument other than the last, c, would it not require a change in this
rule?
> I mean func(a="invalid",b,c,d=1,e=2) would violate the rule and so 
> would making b a keyword version. In my example, and for this reason 
> only, maybe c could work.

My suggestion was not to allow keyword arguments to arbitrarily replace any
positional parameter, or to otherwise change argument-passing in any way.
The suggestion was to drop positional-only arguments from functions
implemented in C instead of just documenting them better. In the example
above, if you want to pass a by keyword, you would have to pass b and c by
keyword as well.
That would still be true for functions implemented in C if a, b, and c are
no longer positional-only.

> The original mot

Re: The slash "/" as used in the documentation

[Chris Angelico]

On Tue, Feb 12, 2019 at 7:26 AM Avi Gross  wrote:
> If you want to talk about recent or planned changes, fine. But make that
> clear. I was talking about how in the past positional arguments did not have
> defaults available at the def statement level. I was talking about how use
> of the symbol "=" in the context of defining function parameters had
> multiple meanings. It not only established that the parameter accepted a
> keyword but also provided a default.

When was this the case? Positional arguments with defaults is a
concept known in MANY languages, including C. The equals sign has
nothing to do with keyword arguments.

Calling on the D'Aprano Collection of Ancient Pythons for confirmation
here, but I strongly suspect that positional arguments with defaults
go back all the way to 1.x.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: more pythonic way

[Terry Reedy]

On 2/11/2019 2:46 PM, Felix Lazaro Carbonell wrote:


 def find_monthly_expenses(month=None, year=None):
 month = month or datetime.date.today().month

Or it should better be:



 if not month:
 month = datetime.date.today().month


As a 20+ year veteran, I would be fine either way.

--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: more pythonic way

[Sivan Grünberg]

+1 with David Raymond, it's nice to use condensed style when it leaves
things readable and logic. But if in doubt:
"Explicit is better than implicit.
Simple is better than complex."  :)

-Sivan

On Mon, Feb 11, 2019 at 10:19 PM David Raymond 
wrote:

> My non-expert vote is for
>
> if month is None:
> month = datetime.date.today().month
>
> Because you're checking for your default value, not whether the boolean
> version of what they did give you is True or False. It's explicit, it's not
> reliant on any __bool__() function implementations or overrides, etc.
>
>
> -Original Message-
> From: Python-list [mailto:python-list-bounces+david.raymond=
> tomtom@python.org] On Behalf Of Felix Lazaro Carbonell
> Sent: Monday, February 11, 2019 2:30 PM
> To: python-list@python.org
> Subject: more pythonic way
>
>
>
> Hello to everyone:
>
> Could you please tell me wich way of writing this method is more pythonic:
>
>
>
> ..
>
> def find_monthly_expenses(month=None, year=None):
>
> month = month or datetime.date.today()
>
> ..
>
>
>
> Or it should better be:
>
> ...
>
> if not month:
>
> month = datetime.date.today()
>
> ..
>
>
>
> Cheers,
>
> Felix.
>
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
> --
> https://mail.python.org/mailman/listinfo/python-list
>


-- 
Sivan Greenberg
Co founder & CTO
Vitakka Consulting
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: more pythonic way

[Peter Otten]

Grant Edwards wrote:

> On 2019-02-11, Felix Lazaro Carbonell  wrote:
> 
>> Could you please tell me wich way of writing this method is more
>> pythonic:
>>
>> def find_monthly_expenses(month=None, year=None):
>> month = month or datetime.date.today()
>>
>> Or it should better be:
>>
>> if not month:
>> month = datetime.date.today()
> 
> The most pythonic way is to do this:
> 
>def find_monthly_expenses(month=datetime.date.today().month,
>year=datetime.date.today().year):
>   ...
> 
> And then start a month-long argument on the mailing list about how the
> behavior of parameter default values is wrong and needs be changed.
> 
> ;)
> 

As far as arguments go I was thinking more about how this code can try and 
find the december expenses when it's only january ;)

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The slash "/" as used in the documentation

[Ian Kelly]

On Mon, Feb 11, 2019 at 1:35 PM Chris Angelico  wrote:
>
> On Tue, Feb 12, 2019 at 7:26 AM Avi Gross  wrote:
> > If you want to talk about recent or planned changes, fine. But make that
> > clear. I was talking about how in the past positional arguments did not have
> > defaults available at the def statement level. I was talking about how use
> > of the symbol "=" in the context of defining function parameters had
> > multiple meanings. It not only established that the parameter accepted a
> > keyword but also provided a default.
>
> When was this the case? Positional arguments with defaults is a
> concept known in MANY languages, including C. The equals sign has
> nothing to do with keyword arguments.
>
> Calling on the D'Aprano Collection of Ancient Pythons for confirmation
> here, but I strongly suspect that positional arguments with defaults
> go back all the way to 1.x.

The archived documentation shows that both parameter defaults and
keyword arguments have been around since at least 1.4. I can't
directly confirm that required parameters could be passed by keyword,
but I see nothing in there that says they can't, or that appears to
conflate parameters having defaults with keyword arguments, which is
as one would expect -- whether an argument is passed positionally or
by keyword is a property of the function *call* expression, whereas
whether a parameter has a default or not is a property of the function
*definition*. They happen to both use the = symbol followed by an
expression, but in different syntactical environments, and that is the
only correlation between them.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The slash "/" as used in the documentation

[boB Stepp]

On Mon, Feb 11, 2019 at 2:34 PM Chris Angelico  wrote:

> Calling on the D'Aprano Collection of Ancient Pythons for confirmation
> here, but I strongly suspect that positional arguments with defaults
> go back all the way to 1.x.

Has Steve's banishment ended yet?  The only postings I have recently
seen from him have been on the Tutor list.



-- 
boB
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: more pythonic way

[Peter Otten]

Felix Lazaro Carbonell wrote:

> Hello to everyone:

 
> Could you please tell me wich way of writing this method is more pythonic:
> def find_monthly_expenses(month=None, year=None):
> 
> month = month or datetime.date.today()

> Or it should better be:

> if not month:
> month = datetime.date.today()

Personally I would avoid a default because I'm unsure whether the current or 
the previous month is the right default. 

Also, the default month combined with a specific year doesn't make much 
sense to me, and someone who specifies find_monthly_expenses(month=6) in May 
probably wants the June of the past year...

Keep the function simple an make the arguments non-optional. If you can come 
up with a nice heuristic put it in a separate function.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The slash "/" as used in the documentation

[Ian Kelly]

On Mon, Feb 11, 2019 at 1:56 PM boB Stepp  wrote:
>
> On Mon, Feb 11, 2019 at 2:34 PM Chris Angelico  wrote:
>
> > Calling on the D'Aprano Collection of Ancient Pythons for confirmation
> > here, but I strongly suspect that positional arguments with defaults
> > go back all the way to 1.x.
>
> Has Steve's banishment ended yet?  The only postings I have recently
> seen from him have been on the Tutor list.

It should have ended some time in December. Perhaps he's decided not to return.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Can't run setup.py offline due to setup_requires - setup.py calls home

[Chris Narkiewicz via Python-list]

On 11/02/2019 19:30, Chris Narkiewicz via Python-list wrote:
> Is there any extra step I have to take?

Ok, I'll respond to myself, as this was really silly.
Debian ships hopelessly obsolete pip 9.PEP 518 is supported in pip 10+.

Cheers,
Chris



signature.asc
Description: OpenPGP digital signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: more pythonic way

[Jimmy Girardet]

The first one is used very often. Less verbose

Le 11 févr. 2019 à 20:41, à 20:41, Felix Lazaro Carbonell 
 a écrit:
> 
>
>Hello to everyone:
>
>Could you please tell me wich way of writing this method is more
>pythonic:
>
> 
>
>..
>
>def find_monthly_expenses(month=None, year=None):
>
>month = month or datetime.date.today()
>
>..
>
> 
>
>Or it should better be:
>
>...
>
>if not month:
>
>month = datetime.date.today()
>
>..
>
> 
>
>Cheers,
>
>Felix.
>
> 
>
>-- 
>https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The slash "/" as used in the documentation

[Chris Angelico]

On Tue, Feb 12, 2019 at 8:13 AM Avi Gross  wrote:
>
>
> Just Chris,

Can we keep things on the list please?

> I am thinking I missed the point of this discussion thus what I say makes no
> sense.

Not sure. You were fairly specific with your statements about how
things supposedly were in the past. What point of the discussion did
you miss that led you to say that?

> Yes, the equals is THE way you supply defaults for things you optionally
> want the user to be able to override. I seem to be talking top-level python
> and you guys are elsewhere so I must be in another discussion.
>
> On Tue, Feb 12, 2019 at 7:26 AM Avi Gross  wrote:
> > If you want to talk about recent or planned changes, fine. But make
> > that clear. I was talking about how in the past positional arguments
> > did not have defaults available at the def statement level. I was
> > talking about how use of the symbol "=" in the context of defining
> > function parameters had multiple meanings. It not only established
> > that the parameter accepted a keyword but also provided a default.

You state this as fact. That's what I responded to. What do you mean
by "top level Python" that might make your statement true?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Replicating YouTube video AI code in python

[jadenfigger]

The error I get typing  pip install -U  tensorflow into the command terminal
  Could not find a version that satisfies the requirement tensorflow (from 
versions: )
No matching distribution found for tensorflow.

Ive been able to install numpy, scipy, and pygame. Tensorflow is the only 
package that gives this error.

I've tried using python 3.7 and 3.6
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: exit 2 levels of if/else and execute common code

[Cameron Simpson]

On 11Feb2019 08:17, Irv Kalb  wrote:

On Feb 11, 2019, at 7:25 AM, Neal Becker  wrote:
I have code with structure:
```
if cond1:
 [some code]
 if cond2: #where cond2 depends on the above [some code]
   [ more code]

 else:
   [ do xxyy ]
else:
 [ do the same xxyy as above ]
```

So what's the best style to handle this?  As coded, it violates DRY.
Try/except could be used with a custom exception, but that seems a bit heavy
handed.  Suggestions?



I like the additional function approach others have mentioned.  But if you want 
a different approach, you could do this:

runExtraCode = True# set some Boolean
if cond1:
   [some code]
   if cond2:
   [more code]
   runExtraCode = False  # both conditions met, no need to run the extra 
code

if runExtraCode:
   [do xxyy]


I want to second this. As others have said, there's a trivialness 
threshold where you wouldn't bother, and that is subjective. But when 
you do, the above is often useful. If "runExtraCode" bothers you, 
consider "need_task", with a suitable "task" name.


I've got several things in the above form. The most recent I fiddled 
with was last night, in a monitor script which updates some information.  
It takes the form:


 updated = False
 while True:
   time.sleep(INTERSCAN_DELAY)
   for rpath, dirnames, filenames in os.walk(...):
 ...
 for filename in filenames:
   if new file found:
 scan file ...
 updated = true
 if updated:
   update top level record ...
   updated = False
 ...

which updates a state file on a per subdirectory frequency if something 
new is found. This falls into exactly the pattern Irv describes.


You'll notice my example starts with the flag variable being False, and 
makes it True if the extra code should run. I personally prefer that 
pattern (I like things to generally start False, or zero, or empty), but 
what values you use will depend on what you're doing.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

comp.lang.python

[Jaya Priya]

The comp.lang.python.announce newsgroup (or c.l.py.a for short) has been 
created in early 1998 as a companion newsgroup for comp.lang.python focused on 
Python-related announcements. ... other items of general interest to the Python 
community.
https://www.gangboard.com/big-data-training/data-science-training
-- 
https://mail.python.org/mailman/listinfo/python-list