Equivalent of "make install" for Python on windows?
Building python from source on windows is straightforward enough with PCBuild/build.bat. But it seems as though the resulting distribution that runs from these standard build dirs ends up sort of incomplete and/or fragmented - at least for what I am used to on *NIX. Binaries are in ./PCBuild/platform instead of ./bin, there is no pip, then get-pip.py installs the pip module but puts the pip script in ./Scripts. And other things… Is there some kind of install step that I am missing? It’s fine if this is just a matter of adjusting to a non-standard distribution config, but I have always had the feeling that the distribution doesn’t really work correctly. Cheers, -Patrick -- https://mail.python.org/mailman/listinfo/python-list
Re: Equivalent of "make install" for Python on windows?
Oh right, and another example: The binary names for debug builds have a _d suffix, but modules like pip (which I assume can only be installed with get-pip.py) expect them not to have this suffix. Once I started copying lots of .exe and .lib files around just to make the distribution work I started to think I was missing something. Cheers, -Patrick > On Jul 10, 2020, at 8:01 AM, Patrick Stinson wrote: > > Building python from source on windows is straightforward enough with > PCBuild/build.bat. But it seems as though the resulting distribution that > runs from these standard build dirs ends up sort of incomplete and/or > fragmented - at least for what I am used to on *NIX. > > Binaries are in ./PCBuild/platform instead of ./bin, there is no pip, then > get-pip.py installs the pip module but puts the pip script in ./Scripts. And > other things… > > Is there some kind of install step that I am missing? It’s fine if this is > just a matter of adjusting to a non-standard distribution config, but I have > always had the feeling that the distribution doesn’t really work correctly. > > Cheers, > -Patrick -- https://mail.python.org/mailman/listinfo/python-list
python installation help
please help me in installing python -- https://mail.python.org/mailman/listinfo/python-list
python software foundation
please uninstall the site packages of python 3.7.2 and tell me the result thank you (T.Jithesh) -- https://mail.python.org/mailman/listinfo/python-list
Re: python software foundation
On Sat, Jul 11, 2020 at 3:10 AM Jithesh Thirumaran wrote: > > please uninstall the site packages of python 3.7.2 and tell me the result > thank you The result was 1. You're welcome. ChrisA PS. If that answer wasn't very helpful, consider clarifying your question. :) -- https://mail.python.org/mailman/listinfo/python-list
Re: python installation help
On 2020-07-10, Deepak Didmania <6073sum...@gmail.com> wrote: > please help me in installing python Well I don't think anybody here has a Wizard Glass Ball. You need to state what is your problem, what erro message you have during istallation. -- https://mail.python.org/mailman/listinfo/python-list
unittest test discovery: regular packages vs. namespace packages
Hello, to my last question I got many helpful and enlightening answers. So I try again with a completely different topic. https://docs.python.org/3/library/unittest.html#test-discovery says about test discovery: "Unittest supports simple test discovery. In order to be compatible with test discovery, all of the test files must be modules or packages (including namespace packages) importable from the top-level directory of the project (this means that their filenames must be valid identifiers). [...] Note: As a shortcut, python -m unittest is the equivalent of python -m unittest discover." Therefore I expected python -m unittest to run all tests in the current directory and its subdirectories, regardless of whether the subdirectories contain a __init__.py or not. However, this only works for me if an (empty) __init__.py is present, i.e. the package is a regular one. As soon as I delete the __init__.py, turning the regular package into a namespace package, unittest doesn't find the test files any more. When I recreate __init__.py, the test file (e.g. test_demo.py) is found again. See demo session further down. I tried the following Python versions, all showed the same behavior: Python 3.7.1 (python.org) on Win10 Python 3.7.4 (python.org) on Win7 Python 3.7.7 (Anaconda) on Win10 Python 3.8.3 (Anaconda) on Win10 What am I missing / misunderstanding? Demo session: F:\demo>dir /s /b F:\demo\test_we4n7uke5vx F:\demo\test_we4n7uke5vx\test_demo.py F:\demo\test_we4n7uke5vx\__init__.py F:\demo>type test_we4n7uke5vx\__init__.py F:\demo>type test_we4n7uke5vx\test_demo.py import unittest class SomeTestCase(unittest.TestCase): def test_fail_always(self): self.assertTrue(False) F:\demo>py -m unittest F == FAIL: test_fail_always (test_we4n7uke5vx.test_demo.SomeTestCase) -- Traceback (most recent call last): File "F:\demo\test_we4n7uke5vx\test_demo.py", line 4, in test_fail_always self.assertTrue(False) AssertionError: False is not true -- Ran 1 test in 0.001s FAILED (failures=1) F:\demo>del test_we4n7uke5vx\__init__.py F:\demo>py -m unittest -- Ran 0 tests in 0.000s OK F:\demo>echo # > test_we4n7uke5vx\__init__.py F:\demo>py -m unittest F == FAIL: test_fail_always (test_we4n7uke5vx.test_demo.SomeTestCase) -- Traceback (most recent call last): File "F:\demo\test_we4n7uke5vx\test_demo.py", line 4, in test_fail_always self.assertTrue(False) AssertionError: False is not true -- Ran 1 test in 0.001s FAILED (failures=1) F:\demo> -- https://mail.python.org/mailman/listinfo/python-list
Re: python installation help
On Jul 10, 2020 1:04 PM, "Deepak Didmania" <6073sum...@gmail.com> wrote: > > please help me in installing python Visit this page: https://www.python.org/about/gettingstarted/ If you get stuck, reply-all and tell us: Your computer's operating system, Version of python you're trying to install, What you tried, Results you got that you weren't expecting. Don't attach screenshots as they probably won't come through. Bob Gailer -- https://mail.python.org/mailman/listinfo/python-list
Re: python software foundation
On 11/07/20 5:19 AM, Chris Angelico wrote: On Sat, Jul 11, 2020 at 3:10 AM Jithesh Thirumaran wrote: please uninstall the site packages of python 3.7.2 and tell me the result thank you The result was 1. @Chris, we should discuss this: A correct result would be 0. Did you notice any warning or error messages? https://unix.stackexchange.com/questions/308207/exit-code-at-the-end-of-a-bash-script-- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Friday Finking: Limiting parameters
Do you prefer to limit the number of parameters accepted by a single
function/method, and if so, how do you handle situations where more data
is needed?
TLDR; specific questions at the end of this msg
Along with one of our list-colleagues (a fellow graduate?survivor from
the time of mainframe computers, monolithic programs, when "structured
programming" was 'the latest new idea', and OOP[s] was one's exclamation
upon making a mistake) we have been re-reading and discussing "Code
Complete". It is 'an oldie, but a goodie', and Python progs may feel
so-superior by happily looking-past various C*/Java-based ideas.
The chapter on "High-Quality Routines" covers a lot of (hopefully, to
you) familiar ground, eg structural-decomposition, descriptive names,
manageability, readability, reliability, changeability, isolating
complexity, SRP, strong-cohesion, loose-coupling (and all the fun of the
fair...).
A particular focus is "Parameter passing issues" - that the list as an
whole presents a "consistent interface abstraction", that the parameters
are in a sensible sequence (that it matches any other similar function
signatures), and that assumptions are documented. The recommendation is
that the list be <= seven parameters. [I have a recollection that
someone else (?'Uncle Bob Martin') recommends <= three]
What should one do when a routine requires numbers of input values? Does
Python's lack of "interfaces" let us down?
If we were going to be pedantic, then the quick-and-dirty way to reduce
the parameter-count might be to use a collection, eg put a physical
address into a named-tuple or list called "address" instead of passing
"street", "town", "city", "postal_code", etc.
We shouldn't be childish when it comes to style-guides. If the data is
as cohesive as the components of an address, we should define a class.
Now we can pass a single instantiated-object, with style and flair!
However, the criticism of that idea is that it 'breaks' encapsulation -
the parameter's routine now needs to know which data-attributes exist
within the passed object - which is an example of close-coupling. Also,
if instead of creating a new object, eg "address", we passed across a
containing object, eg "person"; we might save ourselves some effort!
Sadly, we would (likely) be passing loads of unnecessary data, possibly
even in an insecure fashion.
Time for some compromise? How about we add a method to the "address"
example-object, which is then passed to the routine? It can be called,
and deliver the object's necessary attributes per the interface's spec.
NB we can do this in Python because a function/method is a "first-class
object"! Now our parameter list is shortened (hopefully to the
recommended degree) - thus also the degree of "coupling" between the
call-ing and call-ed routines, the data passed is minimised, and the
communication across the interface clarified. That said, haven't we now
built what other languages might call an "interface"?
Questions:
Is the idea of limiting the number of parameters passed across an
interface a real concern or somewhat an affectation?
Is three, five, seven, ... a valid limit (or warning-signal)?
Do you have a personal or corporate style or 'standard' to limit
parameter lists to seven parameters, or some other number?
Given that Python enables labeled arguments ("keyword arguments"), does
the concern really only apply to 'us' in terms of numbers of "positional
arguments"?
Why not simply create and pass a collection (to suit the 'standards
committee') and be done. What's the big deal, don't have time to waste,
bureaucracy (!)...
What about the similar Q+D solution using a class? After all, we could
just as easily build an extraction-routine into the calling-class, which
reaches into the passed-class for the data it needs - then we don't have
to go to the other team to ask their 'permission'/agreement/cooperation
or wait for them to build the requisite method!
Is passing a function as an argument a safe and valid way to do
business, or is it 'showing off'?
Does the pass-a-function idea making testing easier (of both the call-ed
and the call-ing routines) and might it make a change (eg adding another
field) easier to manage in-future?
What do you do?
Refs:
Steve McConnell, "Code Complete", Microsoft Press, 2004.
--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list
