Re: Class Definitions
[email protected] (Stefan Ram) writes: I expected this solution: class Main: def __init__( self ): self.value = 0 def count( self ): self.value += 1 but a student turned in the following solution: class Main: value = 0 def count(self): self.value += 1 I thought that the solution of the student had a shortcoming but I was not able to put my finger on it. Can you? Not exactly a shortcoming, but the fact that it works as a solution to your problem may cause the student to someday write something like: class Main: value = [] def add(self, x): self.value += [x] and be suprised by the resulting behavior. -- Alan Bawden -- https://mail.python.org/mailman/listinfo/python-list
Re: Class Definitions
On 13/11/2020 08:47, Alan Bawden wrote: [email protected] (Stefan Ram) writes: I expected this solution: class Main: def __init__( self ): self.value = 0 def count( self ): self.value += 1 but a student turned in the following solution: class Main: value = 0 def count(self): self.value += 1 I thought that the solution of the student had a shortcoming but I was not able to put my finger on it. Can you? Not exactly a shortcoming, but the fact that it works as a solution to your problem may cause the student to someday write something like: class Main: value = [] def add(self, x): self.value += [x] and be suprised by the resulting behavior. You are right to be concerned - although largely because the differences between class-variables and instance-variables is (sadly) one of those topics poorly-understood by many, and thus best avoided simply to prevent confusion. (I'll be the first to concur that this not a good reason, and particularly not for someone in education/training, but that's life ["as we know it, Jim"]) A worthwhile read is: https://docs.python.org/3/tutorial/classes.html (including @Alan's most-pertinent warning of the subtleties introduced by mutable data-structures) On the other hand, Python has long?always had an aversion to the object-induced 'boiler-plate' required in other languages - and I have to say, even building Python classes with __init__(), __str__(), and __repr__() etc "magic methods", can seem a slog for low return-value. AFTER teaching/learning about the 'classic form', you may like to consider DataClasses (Python 3.7+). These look very similar to your student's submission. One of their objectives is to cut-through a load of the boiler-plate - in many circumstances. https://www.python.org/dev/peps/pep-0557/ https://docs.python.org/3/library/dataclasses.html See also Counter Objects: https://docs.python.org/3/library/collections.html#counter-objects -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: Getting rid of virtual environments with a better dependency system
On 2020-11-12 10:56:45 +1100, Chris Angelico wrote: > On Thu, Nov 12, 2020 at 10:44 AM Dan Stromberg wrote: > > I do get a .../bin/backshift though, which is a bash script that > > knows how to start up python on the main module. So the user need > > not source something at install time or at run time. > > > > The install process is ./configure and make install, where > > ./configure is Not autoconf, but acts sort of like an autoconf > > script. > > > > Ah, fair enough. > > Did you know that, with a vanilla venv, you can actually just run a > Python interpreter from within there, without sourcing anything? Very > handy for automated scripts. This also works with the Python interpreter in the shebang line. So if your "make install" for "mytool" creates a venv in /usr/local/lib/mytool/venv and then replaces the shebang in /usr/local/bin/mytool with "#!/usr/local/lib/mytool/venv/python", the user can just invoke "mytool" without caring about the virtual environment. If you do that for every Python script, size may be a problem, though: I just checked a few of my venvs, and they are between 13 and 418 MB: Average 81 MB. hp -- _ | Peter J. Holzer| Story must make more sense than reality. |_|_) || | | | [email protected] |-- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" signature.asc Description: PGP signature -- https://mail.python.org/mailman/listinfo/python-list
Re: Getting rid of virtual environments with a better dependency system
On Fri, Nov 13, 2020 at 9:41 AM Peter J. Holzer wrote:
>
> On 2020-11-12 10:56:45 +1100, Chris Angelico wrote:
> > On Thu, Nov 12, 2020 at 10:44 AM Dan Stromberg wrote:
> > > I do get a .../bin/backshift though, which is a bash script that
> > > knows how to start up python on the main module. So the user need
> > > not source something at install time or at run time.
> > >
> > > The install process is ./configure and make install, where
> > > ./configure is Not autoconf, but acts sort of like an autoconf
> > > script.
> > >
> >
> > Ah, fair enough.
> >
> > Did you know that, with a vanilla venv, you can actually just run a
> > Python interpreter from within there, without sourcing anything? Very
> > handy for automated scripts.
>
> This also works with the Python interpreter in the shebang line.
>
> So if your "make install" for "mytool" creates a venv in
> /usr/local/lib/mytool/venv and then replaces the shebang in
> /usr/local/bin/mytool with "#!/usr/local/lib/mytool/venv/python", the
> user can just invoke "mytool" without caring about the virtual
> environment.
>
> If you do that for every Python script, size may be a problem, though: I
> just checked a few of my venvs, and they are between 13 and 418 MB:
> Average 81 MB.
>
Indeed. I would divide Python scripts into a few categories:
1) System scripts. If the script came from a Debian repository, it
runs in the Debian-provided Python and uses libraries installed with
apt/dpkg.
2) Scripts that don't really much care about their environment. These
will generally run in the latest master branch build of Python
(currently 3.10), and if they need anything installed, I install it
("globally") into that instance of Python. They can't interfere with
system scripts, but can interfere with each other.
3) Scripts that get their own venv. That could be because they
conflict with something else, or something else conflicts with them,
or they need specific versions of things, or anything.
At the moment, I can find a grand total of nine virtual environments
for various scripts. Some of them are because Python 3.10 can't run
the scripts in question; others probably could run, but I want a
consistent environment for my dev/staging so it's easier to push to
production. The largest env directory is 250ish MB, and they average
94MB, so my figures are fairly comparable to yours.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
How to start using python
I am new to Python and have downloaded the software onto my pc. There is no shortcut on my desktop. How the heck do I access it to start learning how to program with it? Anthony Steventon. -- This email has been checked for viruses by AVG. https://www.avg.com -- https://mail.python.org/mailman/listinfo/python-list
Re: How to start using python
On Nov 12, 2020 10:41 PM, "Anthony Steventon" wrote: > > I am new to Python and have downloaded the software onto my pc. There is no shortcut on my desktop. How the heck do I access it to start learning how to program with it? Visit www.Python.Org there should be some links to tutorials that should cover the topics of how to install python and how to start using it. If that does not help come back to us with more information including your operating system, the website from which you downloaded the installer, the name of the installer file, and what you did to install python. You also might try from a terminal or command prompt typing py, which should start up a python Interactive session. You should see>>> type 2 + 3 hit enter you should see a new line displaying five. Let us know how it goes and we'll give you a hand from there. Bob Gailer -- https://mail.python.org/mailman/listinfo/python-list
