Re: Changing calling sequence

[anthony.flury via Python-list]

Why not do :

  def TempsOneDayDT(date:datetime.date):
 return TempsOneDay(date.year, date.month, date.day)

No repeat of code - just a different interface to the same 
functionality.




-- Original Message --
From: "Michael F. Stemper" 
To: python-list@python.org
Sent: Wednesday, 11 May, 22 At 14:33
Subject: Changing calling sequence
I have a function that I use to retrieve daily data from a
home-brew database. Its calling sequence is;
def TempsOneDay( year, month, date ):
After using it (and its friends) for a few years, I've come to
realize that there are times where it would be advantageous to
invoke it with a datetime.date as its single argument.
As far as I can tell, there are three ways for me to proceed:
1. Write a similar function that takes a single datetime.date
   as its argument.
2. Rewrite the existing function so that it takes a single
   argument, which can be either a tuple of (year,month,date)
   or a datetime.date argument.
3. Rewrite the existing function so that its first argument
   can be either an int (for year) or a datetime.date. The
   existing month and date arguments would be optional, with
   default=None. But, if the first argument is an int, and
   either of month or date is None, an error would be raised.

The first would be the simplest. However, it is obviously WET
rather than DRY.
The second isn't too bad, but a change like this would require that
I find all places that the function is currently used and insert a
pair of parentheses. Touching this much code is risky, as well
as being a bunch of work. (Admittedly, I'd only do it once.)
The third is really klunky, but wouldn't need to touch anything
besides this function.
What are others' thoughts? Which of the approaches above looks
least undesirable (and why)? Can anybody see a fourth approach?
--
Michael F. Stemper
This post contains greater than 95% post-consumer bytes by weight.
--
https://mail.python.org/mailman/listinfo/python-list 



-- Anthony Fluryanthony.fl...@btinternet.com
--
https://mail.python.org/mailman/listinfo/python-list

Re: [Python-ideas] Re: New Tool Proposal

[anthony.flury via Python-list]

On 10/05/2022 15:04, Dan Stromberg wrote:


On Tue, May 10, 2022 at 3:15 AM Chris Angelico  wrote:

> It is often the case that developer write Code in Python and
then convert to a C extension module for performance regions.
>
> A C extension module has a lot of boiler plate code - for
instance the Structures required for each class, the functions for
Module initialization etc.
>
> My Idea is a simple tool that uses introspection tools to take a
Python module and to generate the relevant boiler plate for the
module - including blank functions for the module classes and for
methods. This tool would use type annotations (if given) to make
sensible choices for parameter and attribute types, including
using int and float directly rather than Internal objects
(depending on tool options).


Two things to say about this:
1) Sometimes abandoning a pure python module for a C extension for 
performance is a mistake - because Pypy is probably going to be much 
faster with the pure python module


Dan,

Thanks for your response, but I think PyPy will have a long way to go to 
make JIT generated code more efficient than hand crafted C extension.


for instance PyPy will almost certainly be unable to determine if 
integers, floats etc will need to use the Python runtime or can be 
optimized to use direct C types, another example would be lists - there 
are some cases where the C extension will always be a lot more efficient 
using C arrays than using the C list runtime machinery.


While there might be some cases where PyPy will be more efficient, I 
don't think that will be the case for all programs, and that ignores the 
fact that PyPi has major issues with the CAPI.



2) I've had some luck using m4 to maintain a single source file that 
is used to automatically generate both pure python and cython.  This 
is a little like using cpp in a C project.


For examples of #2, perhaps see:
https://stromberg.dnsalias.org/~strombrg/treap/
https://stromberg.dnsalias.org/svn/rolling_checksum_mod/trunk/
https://stromberg.dnsalias.org/~strombrg/sort-comparison/

It's often nice to keep the lines of the pure-python and cython having 
a 1-1 relationship, so that tracebacks report useful line numbers 
either way.  However, in the treap example I've dispensed with that 
because some methods were almost identical but had some boilerplate - 
and m4 was able to handle that nicely at the cost of lines being 1-1.


HTH

--
Anthony Flury
*Moble*: +44 07743 282707
*Home*: +44 (0)1206 391294
*email*: anthony.fl...@btinternet.com
--
https://mail.python.org/mailman/listinfo/python-list

Re: [docs] Reporting a Bug

[anthony.flury via Python-list]

This is exactly as expected.


Strip removes any of the characters in the passed string from both the 
front and the end of the string being stripped.


The letter 'T' from the start of 'The meaning of life' does not appear 
in the word 'meaning' so nothing is removed from the start of the 
string.



The letter 'e' from the end of 'The meaning of life' does appear in the 
word 'meaning' so it is removed from the sentence; it will then look at 
the next last letter 'f', but since this doesn't appear in the word 
'meaning' nothing else is removed and the new string is returned.


The argument passed to strip(..) method is the set of characters to be 
removed - so any characters in that set are removed from the start and 
end of the string.





-- Original Message --
From: "Jeff Jeffi" 
To: d...@python.org
Cc: python-list@python.org
Sent: Wednesday, 4 May, 22 At 10:36
Subject: [docs] Reporting a Bug

Hello dears,

First of all i am not sure about this issue   please advise me if 
there is any mistake   in my report.



 for example in python 3.6.3 shell:



x= "The meaning of life" x.strip("meaning")

'The meaning of lif'


As you see the letter "e" of  the word "life"  is removed.


Sincerely yours.
J.Mohammadi




 ___
docs mailing list -- d...@python.org
To unsubscribe send an email to docs-le...@python.org
https://mail.python.org/mailman3/lists/docs.python.org/ 


Member address: anthony.fl...@btinternet.com

-- Anthony Fluryanthony.fl...@btinternet.com
--
https://mail.python.org/mailman/listinfo/python-list

Re: Why doc call `__init__` as a method rather than function?

[anthony.flury via Python-list]

To me __init__ is a method, but that is implemented internally as 
function associated to a class



When you use A.__init__ on it's own and inspect it, then it will show 
that it is a function object - this is expected. The implementation 
internals of the runtime don't need to have a special implementation for 
a method.


Like all of the other  methods you shouldn't ever need to call 
them directly : these are called dunder methods and represent functions 
and features which are called by other operators.


The only recommended way to call A.__init__ is to create an instance of 
A : obj = A() - the __init__ method gets called automatically with a 
newly created object.


If you did call A.__init__() directly on a an already existing object :

 obj = A()
 A.__init__(obj)

for example - all that would happen is that the object itself would be 
reset : ie the obj's attributes would be reset to whatever the __init__ 
sets them to - if you need to do that it might be better to have a reset 
method.



 Regards,

Tony


-- Original Message --
From: "scruel tao via Python-list" 
To: "python-list@python.org" 
Sent: Friday, 15 Sep, 23 At 11:49
Subject: Why doc call `__init__` as a method rather than function?
```python
class A:
...   def __init__(self):
... pass
...
A.__init__

a = A()
a.__init__
>
```
On many books and even the official documents, it seems that many 
authors prefer to call `__init__` as a "method" rather than a 
"function".
The book PYTHON CRASH COURSE  mentioned that "A function that’s part of 
a class is a method.", however, ` A.__init__` tells that `__init__` is a 
function...

I wonder how can I call `__init__` as? Consider the output above.
Maybe both are OK? If you prefer or think that we must use one of the 
two, please explain the why, I really want to know, thanks!

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



-- Anthony Fluryanthony.fl...@btinternet.com
--
https://mail.python.org/mailman/listinfo/python-list

Re: error of opening Python

[anthony.flury via Python-list]

This isn't an error.


This is just a normal Python Header message announcing that you are 
using Python 3.11.3
The rest is just information from the build system : The build Id,  the 
date/time the build was made, and the version of the compiler.


There is nothing to fix.


-- Original Message --
From: "Abdelkhelk ashref salay eabakh via Python-list" 


To: python-list@python.org
Sent: Tuesday, 26 Sep, 23 At 13:27
Subject: error of opening Python
Dear Python team,
This is my not first time using Python, I tried to launch Python and it 
showed
"Python 3.11.3 (tags/v3.11.3:f3909b8, Apr  4 2023, 23:49:59) [MSC v.1934 
64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information." 
I
don't know what this meant and how to fix this. Could you please help 
me?

Thank you very much.
Kind regards
--
https://mail.python.org/mailman/listinfo/python-list 



-- Anthony Fluryanthony.fl...@btinternet.com
--
https://mail.python.org/mailman/listinfo/python-list

Re: pyinstaller wrong classified as Windows virus

[anthony.flury via Python-list]

Have you tried using Nuitka - rather than pyInstalller - it means you 
distribute a single executable and the Python run time library (which 
they probably have already), and it has the advantage that it is a bit 
quicker than standard python.


Rather than bundle the source code and interpreter in single executable, 
Nuitka actually compiles the Python source code to native machine code 
(via a set of C files), and  this native executable uses the Python 
runtime library to implement the python features.It does rely on you 
having a Windows C compiler available.


On 25/11/2021 17:10, Ulli Horlacher wrote:

Chris Angelico  wrote:


Unfortunately, if you're not going to go to the effort of getting your
executables signed

I cannot sign my executables (how can I do it anyway?), because Windows
deletes my executable as soon as I have compiled them! They exist only
for a few seconds and then they are gone.



another reason to just distribute .py files.

I cannot do that because my users do not have Python installed and they
are not allowed to do it.


--
Anthony Flury
*Moble*: +44 07743 282707
*Home*: +44 (0)1206 391294
*email*: anthony.fl...@btinternet.com 
--
https://mail.python.org/mailman/listinfo/python-list

Re: pyinstaller wrong classified as Windows virus

[anthony.flury via Python-list]

On 26/11/2021 07:13, Ulli Horlacher wrote

But consider another possibility that your compiler software is compromised

Then https://www.python.org/ftp/python/3.10.0/python-3.10.0-amd64.exe
is infected. I doubt this.


But you aren't using python3.10 to 'compile' the code to the executable 
that windows complains about: you are using pyinstaller, which if memory 
serves is a 3rd party application.


I assume that you have no problem running the script without pyinstaller ?

so Might pyinstaller be compromised in some way ?


   

Is this happening to only one set of code?

This is happening SOMETIMES, not always. With the SAME source code. When I
call pyinstaller often enough, then the virus scanner is quiet. In about 1
of 20 compile runs.




--
Anthony Flury
*Moble*: +44 07743 282707
*Home*: +44 (0)1206 391294
*email*: anthony.fl...@btinternet.com 
--
https://mail.python.org/mailman/listinfo/python-list

Re: How to detect an undefined method?

[anthony.flury via Python-list]

On 27/03/2022 15:59, dn wrote:


What is code coverage?
In the simplest words, code coverage is a measure of exhaustiveness of a
test suite. 100% code coverage means that a system is fully tested.


Sorry, but that is a gross over-simplification.

100% coverage means that you have tested all of the branches in a given 
module, or a given class; it absolutely does not mean it is fully tested.


For example I can write code and unit-test cases for a trivial piece of 
code, and to achieve 100% coverage, but for the code to still fail on 
invalid input data, or for the code to fail due to exceptions from 
library code that my code doesn't handle.


To claim to be fully tested a piece of code has to be exercised against 
*every* possible input and *every* single possible event from *every* 
single source - that alone makes 100% testing impossible. If you think 
logically about it, you can only test a very small fraction of all 
possible test cases; the key is to pick those cases which represent a 
good range of possible inputs and events (including both valid and 
invalid data, exceptions, errors etc).


At best 100% coverage measure means that every branch through the code 
has been executed at least once by your test cases. It doesn't prove 
that your test cases are complete, or that your code takes into account 
all possible occurrences - 100% coverage doesn't mean it is fully tested.


In terms of coverage,  achieving 100% coverage is a laudable target, but 
it is often either unachievable or not worth the effort; aiming to 
achieve a high value (say > 80%) is sensible target.


If you achieve your high coverage count by doing black-box testing (ie. 
by testing to the specification of code and thinking what can right and 
what can go wrong), then the coverage is a more useful measure - if you 
write your unit-tests by looking at the code, then all that a high 
measurement means is that you are able (mostly) to read and understand 
your own code.


--
Anthony Flury
*Moble*: +44 07743 282707
*Home*: +44 (0)1206 391294
*email*: anthony.fl...@btinternet.com
--
https://mail.python.org/mailman/listinfo/python-list