Re: How to solve the given problem?
On Fri, 4 Mar 2022 10:02:30 -0800 (PST), NArshad declaimed the following: >You have made everything too complicated. Just adjust the units left in the >second feed into the third and fourth feed because the fish is special and >that's it. The next day the second feed will be 100 units the way it used to >be. > My solution is generalized for 1) any number of periods in the day, 2) mis-feed discovered at any point during the day, 3) works with any shape of feeding schedule. >What's wrong with the solution which I have written? Nothing IF you can justify that it meets the documented requirements. >From your original post: """ Implement some methods to distribute the remaining 40 unit in the rest of the day and propose the new patterns. Try to keep the distribution similar to the current feeding pattern. """ Rephrased some, with emphasis, into what I see as the two major requirements to be met: * distribute the remaining 40 unit IN THE REST OF THE DAY * TRY TO KEEP THE DISTRIBUTION SIMILAR TO THE CURRENT FEEDING PATTERN "Remaining 40 unit" is really a noise clause resulting only from the /example/ input schedule and feedings. Any programmatic solution should not know, ahead of time, what the schedule was, nor what the feedings actually were. There is no sense to writing a program in which all the input data is hard-coded -- you might as well hard-code the output too, while you are at it. I consider "..some methods" to also be noise clause -- the alternative interpretation is that you are supposed to create multiple programs doing different types of solutions to the one problem. Assume, for example, that a fish#2 has a feeding schedule that looks like: 150 100 20 20 20 20 20 20 100 150 (A big feed at start of day, an almost as large in second hour, six hours at a constant 20, and then a large feed near the end, followed by a really big feed to keep it happy overnight -- it seems to make more sense than slowly starving the fish during the afternoon ). That planned distribution could be called a bathtub curve -- high start and ends with a flat middle. (as a sideways histogram) *** ** ** ** ** ** ** ** ** *** Again, assume error in first two feeds as: 150 60 HOW DOES DUMPING THE 40 UNITS INTO HOUR 3 AND 4 SATISFY EITHER OF THE REQUIREMENTS? (... rest of day, and similar distribution). -=-=-=- C:\Users\Wulfraed\Documents\_Hg-Repositories\REXX>rexx feedme.rex Enter planned feeding schedule (feed units for each time period, space separated) 150 100 20 20 20 20 20 20 100 150 Enter actual feeding schedule up to current feed period 150 60 PLAN: 10 time periods 620 total feed units ACTUAL :2 time periods 210 total feed units dispensed MIS-FEED: 40 underfed SCHEDULE: 150 60 |> 23 22 22 22 22 22 111166 C:\Users\Wulfraed\Documents\_Hg-Repositories\REXX> -=-=-=- (I modified the script to put |> at the point where the modified feedings begin) The result, as a histogram *** ** **- **. **. **. **. **. ***. + (Not very visible as each * is 10 units, and using . for 2.5, - for 5, + for 7.5) -- Wulfraed Dennis Lee Bieber AF6VN wlfr...@ix.netcom.comhttp://wlfraed.microdiversity.freeddns.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Behavior of the for-else construct
On 03Mar2022 14:24, computermaster360 wrote: >I want to make a little survey here. > >Do you find the for-else construct useful? Have you used it in >practice? Do you even know how it works, or that there is such a thing >in Python? I used Python for years before understanding the for-else (and therefore, without seeing a use for it). Finally made the time to wrap my head around it quite recently and have used it a few times since. It is a little niche, but when you want it, it is very nice indeed. Certainly avoids managing a special flag variable (which can be fiddly and therefore fragile) for "did my loop not run to completion"? I sort of wish it had both "used break" and "did not use break" branches, a bit like try/except/else. But not very much. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: Behavior of the for-else construct
On 2022-03-04 23:47:09 +, Avi Gross via Python-list wrote:
> I am not sure a reply is needed, Peter, and what you say is true. But
> as you point out, when using a German keyboard, I would already have
> a way to enter symbols like ä, ö, ü and ß and no reason not to include
> them in variable names and so on if UNICODE is being used properly. I
> can use my last name in German notation as a variable in Python now:
>
> Groß = 144
> Groß / 12
> 12.0
Yes, I'm using umlauts occasionally in variable names in Python, and
I've also used Greek characters and others.
But in Python I CAN use them. I DON'T HAVE to.
That's a big difference.
Characters like [] or {} are a part of Python's syntax. You can't avoid
using them. If you can't type them, you can't write Python. If it is
awkward to enter them (like having to type Alt-91 or pasting them from a
character table) it is painful to write programs.
German keyboards aquired an AltGr key and the ability to type these
characters in the mid to late 1980's. Presumably because those
characters were common in C and other programming languages and
programmers were complaining. I assume the same happened with keyboards
for other languages. These days you can assume that everybody can type
all ASCII characters (and knows how to do it).
But if you add arbitrary unicode characters to the syntax of your
language, for example using «» to delimit code blocks and ⦃ ⦄ for sets
and ∅ for None, then every programmer will have to figure out how to
enter those characters. And 90 % will probably say "Fuggedaboutit, I'm
not going to learn a new programming language I can't even type!"
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |-- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
signature.asc
Description: PGP signature
--
https://mail.python.org/mailman/listinfo/python-list
Re: Behavior of the for-else construct
I am not sure a reply is needed, Peter, and what you say is true. But as you
point out, when using a German keyboard, I would already have a way to enter
symbols like ä, ö, ü and ß and no reason not to include them in variable names
and so on if UNICODE is being used properly. I can use my last name in German
notation as a variable in Python now:
Groß = 144
Groß / 12
12.0
But even if I was German (and despite living in Austria for a year, I am not) I
might want to write some things in French which might not be on that Keyboard,
unless it includes everything in ISO 8859-1, albeit that standard is missing
letters used rarely in some languages.
I have also used characters from Spanish and French and Hungarian and others as
names in programs with no problems, albeit getting them in is not trivial on my
very solid American English keyboard but can be done many ways. A fairly simple
way is to use something like this using Google translate:
https://translate.google.com/?sl=de&tl=en&op=translate
Pick the language you want and pop up a keyboard and type a bit and then
copy/paste like this: גרוס
If I had to do this all the time, and occasionally I do, you can get other
pop-up keyboards or helpers that take several keystrokes you memorize and
convert it, ...
But it rarely is worth doing this if others will be using my code and
complaining or trying to edit it.
Chris has already pointed out the dangers of wandering too far from standard
practice and making code hard for anyone else to deal with so yes, I would not
rewrite key components or do something like make new function names that point
to existing standard functions and only use the new (often not pronounceable)
names.
-Original Message-
From: Peter J. Holzer
To: python-list@python.org
Sent: Fri, Mar 4, 2022 5:57 pm
Subject: Re: Behavior of the for-else construct
On 2022-03-04 00:38:22 +, Avi Gross via Python-list wrote:
> I have seen major struggles to get other character sets into
> languages. Any new language typically should have this built in from
> scratch and should consider adding non-ASCII characters into the mix.
> Mathematicians often use lots of weird braces/brackets as an example
> while normal programs are limited to [{( and maybe < and their
> counterparts. This leads to odd Python behavior (other languages too)
> where symbols are re-used ad nauseam. { can mean set or dictionary or
> simply some other way to group code.
I think the main reason for this is that people have to be able to type
the code. I do remember the days when German keyboards didn't have
brackets and braces and you had to type alt-123 to get a {. Made it real
fun to program in C ...
If you design a language and in IDE together (the way Smalltalk was
designed back in the 1970s or maybe Visual Basic) you can use all sorts
of funky characters because you can also provide a standard way to enter
them. But if you expect your users to type programs in a standard text
editor (even a fancy one like Emacs or Vim or VS Code), you have to
restrict yourself to a character set that most people can comfortably
type on their keyboards with the key mapping provided by their OS. Which
for historical reasons means US-ASCII.
hp
--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | h...@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: Behavior of the for-else construct
On Sat, 5 Mar 2022 at 10:28, Peter J. Holzer wrote: > > On 2022-03-04 11:34:07 +1100, Chris Angelico wrote: > > On Fri, 4 Mar 2022 at 10:09, Avi Gross via Python-list > > wrote: > > > The drumbeat I keep hearing is that some people hear/see the same > > > word as implying something else. ELSE is ambiguous in the context it > > > is used. > > > > What I'm hearing is that there are, broadly speaking, two types of > > programmers [1]: > > > > 1) Those who think about "for-else" as a search tool and perfectly > > understand how it behaves > > 2) Those who have an incorrect idea about what for-else is supposed to > > do, don't understand it, and don't like it. > > 3) Those who understand what it does und don't even find it*s syntax > very confusing, yet only very rarely find it useful. > > I have probably used it a handful of times in 8 years of Python > programming. Coincidentally, I think I used it just this week - but I > can't find it any more which probably means that it was either in a > throwaway script or I have since rewritten the code. > Part of group 1. It doesn't matter how often or rarely you use the feature; there are a LOT of features of Python that I use only occasionally, if ever. But as long as you know how to use it, it's there when you need it. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Behavior of the for-else construct
On 2022-03-04 11:34:07 +1100, Chris Angelico wrote: > On Fri, 4 Mar 2022 at 10:09, Avi Gross via Python-list > wrote: > > The drumbeat I keep hearing is that some people hear/see the same > > word as implying something else. ELSE is ambiguous in the context it > > is used. > > What I'm hearing is that there are, broadly speaking, two types of > programmers [1]: > > 1) Those who think about "for-else" as a search tool and perfectly > understand how it behaves > 2) Those who have an incorrect idea about what for-else is supposed to > do, don't understand it, and don't like it. 3) Those who understand what it does und don't even find it*s syntax very confusing, yet only very rarely find it useful. I have probably used it a handful of times in 8 years of Python programming. Coincidentally, I think I used it just this week - but I can't find it any more which probably means that it was either in a throwaway script or I have since rewritten the code. hp -- _ | Peter J. Holzer| Story must make more sense than reality. |_|_) || | | | h...@hjp.at |-- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" signature.asc Description: PGP signature -- https://mail.python.org/mailman/listinfo/python-list
Re: Behavior of the for-else construct
Yes, Rob,
I keep wondering how many decades it will take before people here understand
how I make a point with an example that is not intended in any way to be
complete or the way I would do it.
No, I would not normally use the exception method, let alone in this case. This
one practically screams for the method you suggest and iterate on a list of
directories made from splitting the PATH variable. And, yes that method would
likely use a for loop with a break if it is found and is a candidate for using
the ELSE clause to note it has not been found.
But it is not an unusual idiom these days to use exceptions in places I never
dreamed of in my earlier programming languages. A common example is always
testing before accidentally dividing by zero and now code that depends on
throwing the right exception and dealing with it, especially if the exception
happens rarely.
So in situations where almost all programs are found in the first component of
PATH, perhaps the exception approach is not horrible. It may even at times be
done with less coding effort than other alternatives. Not my preferred way, of
course.
-Original Message-
From: Rob Cliffe via Python-list
To: python-list@python.org
Sent: Fri, Mar 4, 2022 5:22 pm
Subject: Re: Behavior of the for-else construct
On 04/03/2022 20:52, Avi Gross via Python-list wrote:
>
> I have an observation about exception handling in general. Some people use
> exceptions, including ones they create and throw, for a similar idea. You
> might for example try to use an exception if your first attempt fails that
> specifies trying the next attempt. In my example of the PATH variable, you
> might use something like calling a function and giving it what you are
> looking for as well as a local copy of the PATH variable content and the
> exception would be to call the function again with the first component of
> PATH removed until you fail with an empty PATH. Yes, this is similar to just
> having a recursive function.
That sounds neither readable nor efficient compared with using split()
plus a loop. Maybe you mean this to be a toy, unrealistic example?
> So the example tossed at us looks a bit more like this and it does run the
> ELSE not because the loop is not done but because the loop never calls a
> break:
>
> for x in range(0):
> print(x)
> else:
> print("Finally finished!")
This would be more readable with a `zeroiterations` keyword, which
accurately describes both the semantics and the intent.
> Which leads me right back to wondering why the sentinel approach is so bad!
>
>
It's not that bad, but it's more convenient and readable if it can be
avoided.
Best wishes
Rob Cliffe
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: Behavior of the for-else construct
On 2022-03-04 14:04:48 -0600, Om Joshi wrote:
> I'm not sure if anyone has mentioned it on this thread, but with
> respect to your comment about adding either on.empty or a decorator,
> the Django template syntax uses
>
> {% for x in iterator %}
> {{ x }}
> {% empty %}
> Empty
> {% endfor %}
>
> and this seems to work quite well and be incredibly intuitive, at
> least for Django html templates.
OTOH it is frequently not what you want.
Take this example from the Django docs:
{% for athlete in athlete_list %}
{{ athlete.name }}
{% empty %}
Sorry, no athletes in this list.
{% endfor %}
If athlete_list is empty, it will produce:
Sorry, no athletes in this list.
which is awful typography. You don't want a list with a single item, you
want that text *instead of* the list.
So you would have to write
{% if athlete_list %}
{% for athlete in athlete_list %}
{{ athlete.name }}
{% empty %}
{% else %}
Sorry, no athletes in this list.
{%endif %}
anyway.
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |-- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
signature.asc
Description: PGP signature
--
https://mail.python.org/mailman/listinfo/python-list
Re: Behavior of the for-else construct
On 2022-03-04 08:38:52 -0600, Tim Chase wrote:
> On 2022-03-04 11:55, Chris Angelico wrote:
> > In MS-DOS, it was perfectly possible to have spaces in file names
>
> DOS didn't allow space (0x20) in filenames unless you hacked it by
> hex-editing your filesystem (which I may have done a couple times).
> However it did allow you to use 0xFF in filenames which *appeared* as
> a space in most character-sets.
I may be misremembering (it's been 30+ years), but I seem to remember
that a simple fopen("with space.txt", "w") in Turbo C would create a
file with a space (actually called "WITH SPA.TXT", because upper case
only and 8+3).
It was a bad idea to do this, though, because there was no way to
manipulate such a file from command.com (You'd have to write another C
program).
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |-- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
signature.asc
Description: PGP signature
--
https://mail.python.org/mailman/listinfo/python-list
Re: Behavior of the for-else construct
On 2022-03-04 00:38:22 +, Avi Gross via Python-list wrote:
> I have seen major struggles to get other character sets into
> languages. Any new language typically should have this built in from
> scratch and should consider adding non-ASCII characters into the mix.
> Mathematicians often use lots of weird braces/brackets as an example
> while normal programs are limited to [{( and maybe < and their
> counterparts. This leads to odd Python behavior (other languages too)
> where symbols are re-used ad nauseam. { can mean set or dictionary or
> simply some other way to group code.
I think the main reason for this is that people have to be able to type
the code. I do remember the days when German keyboards didn't have
brackets and braces and you had to type alt-123 to get a {. Made it real
fun to program in C ...
If you design a language and in IDE together (the way Smalltalk was
designed back in the 1970s or maybe Visual Basic) you can use all sorts
of funky characters because you can also provide a standard way to enter
them. But if you expect your users to type programs in a standard text
editor (even a fancy one like Emacs or Vim or VS Code), you have to
restrict yourself to a character set that most people can comfortably
type on their keyboards with the key mapping provided by their OS. Which
for historical reasons means US-ASCII.
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |-- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
signature.asc
Description: PGP signature
--
https://mail.python.org/mailman/listinfo/python-list
Re: Behavior of the for-else construct
On 04/03/2022 20:52, Avi Gross via Python-list wrote:
I have an observation about exception handling in general. Some people use
exceptions, including ones they create and throw, for a similar idea. You might
for example try to use an exception if your first attempt fails that specifies
trying the next attempt. In my example of the PATH variable, you might use
something like calling a function and giving it what you are looking for as
well as a local copy of the PATH variable content and the exception would be to
call the function again with the first component of PATH removed until you fail
with an empty PATH. Yes, this is similar to just having a recursive function.
That sounds neither readable nor efficient compared with using split()
plus a loop. Maybe you mean this to be a toy, unrealistic example?
So the example tossed at us looks a bit more like this and it does run the ELSE
not because the loop is not done but because the loop never calls a break:
for x in range(0):
print(x)
else:
print("Finally finished!")
This would be more readable with a `zeroiterations` keyword, which
accurately describes both the semantics and the intent.
Which leads me right back to wondering why the sentinel approach is so bad!
It's not that bad, but it's more convenient and readable if it can be
avoided.
Best wishes
Rob Cliffe
--
https://mail.python.org/mailman/listinfo/python-list
Re: Behavior of the for-else construct
Om (unless your first name is Joshi),
Yes, your example captures some of my intent. I have not studied Django but
your example suggests it uses special notation using a sort of set of braces
like I have talked about "{%" and "%}" that allows freedom in using what might
otherwise need keywords. Anything between braces can be an extension of the
language in a context where users do not put their own variable names.
But again, any language defined can be set up to do things their own way. In
Python, I believe the contents of a loop are not examined at all if skipped so
searching in it for some clause of what to do if empty is not doable. The ELSE
clause is a way to get the attention if there has been no break.
I would not be shocked if some language has a FOR command return a value such
as the number of iterations if run and something like None if not and allows
something like:
result = for ...
That might return 0 or None if it was part of the language but it is not.
Avi (my current first name)
-Original Message-
From: Om Joshi
To: Avi Gross
Cc: python-list
Sent: Fri, Mar 4, 2022 3:04 pm
Subject: Re: Behavior of the for-else construct
I'm not sure if anyone has mentioned it on this thread, but with respect to
your comment about adding either on.empty or a decorator, the Django template
syntax uses
{% for x in iterator %}
{{ x }}
{% empty %}
Empty
{% endfor %}
and this seems to work quite well and be incredibly intuitive, at least for
Django html templates. I took a look and it has other enhancements like a way
to know when you are in the last iteration of the loop.
{% if forloop.last %}
...
{% endif %}
And also for the first item using forloop.first and a generalized counter in
forloop.counter ..
On Fri, 04 Mar 2022 13:45:21 -0600 Avi Gross via Python-list
wrote
> {NOTE, after some diversion, this long message does revert a bit to the
> topic.}
>
> Ah, Chris, the games we played when we were young and relatively immature!
>
> Has anyone else played with embedding "escape sequences" or other gimmicks
> in unexpected places like filenames so that on the right terminals, such as
> the VT100, it displayed oddly or was hard to open or delete as what showed
> was not quite the underlying representation?
>
> The main reason for the restrictions in olden days was cost. Everything was
> so costly including storage/memory and CPU time. Clearly it is a lot easier
> to have fixed-length filenames that fit into say 16 bytes, or storing
> multiple flags about file permissions as single bits, even if it meant lots
> of bit-twiddling or using masks to retrieve their values. We think nothing
> of creating structures that have many others embedded in them as attributes
> or function calls that allow a hundred optional arguments so that the
> function spends much of the time used just figuring out what was set before
> doing whatever calculation is required to fulfill the request.
>
> I was reading a novel recently (Jack Reacher Series) where the main
> character is noticing how much technology has changed as they have been
> ignoring it for a decade or so. Everything seems to be coming up faster. My
> view was that if something seems ten times as fast as it was, it also
> probably is doing a hundred or ten thousand times as much to get that
> result. The real speed changes are often counterbalanced by expecting to do
> more. A web page served may display a screen of text but to transmit it may
> include not just lots of padding in the HTML, but have all kinds of code
> such as in Java or JavaScript or lots of back and forth with the server to
> keep something like a graph displayed being refreshed ...
>
> So back to filenames, the concept of having to search for long filenames
> that may not even be stored sequentially in large blocks that can be read
> (ahead) efficiently, may have seemed to be so illogical as not to be
> considered. So given that the shorter ones were not allowed to have embedded
> spaces, it made sense to treat them like tokens that could be broken up at
> whitespace. As mentioned, languages (or other programs) would often parse a
> command line and create something like this for the main program in C with
> suitable version in Python and other languages:
>
> main(int argc, char *argv[])
>
> The code variations on the above do suppose that something has already
> parsed the command line that invoked them and partitioned it properly into
> individual strings placed in an array of such strings and also returned how
> many arguments it saw. Users invoking the program needed to be careful such
> as using double quotes around anything with embedded spaces, where allowed.
>
> But like many paradigms, there can be a shift. Consider the fact that
> languages like Python are constantly parsing things like names. Can you
> create a variable name like "me first" with a
Re: Getting Syslog working on OSX Monterey
On 2022-02-28 22:05:05 +, Barry Scott wrote: > On 28 Feb 2022, at 21:41, Peter J. Holzer wrote: > > On 2022-02-27 22:16:54 +, Barry wrote: > >> I have always assumed that if I want a logger syslog handler that I would > >> have > >> to implement it myself. So far I have code that uses syslog directly and > >> have > >> not written that code yet. > > > > What do you mean by using syslog directly? The syslog(3) library > > function also just sends messages to a "syslog listener" (more commonly > > called a syslog daemon) - at least on any unix-like system I'm familiar > > with (which doesn't include MacOS). It will, however, always use the > > *local* syslog daemon - AFAIK there is no standard way to open a remote > > connection (many syslog daemons can be configured to forward messages to > > a remote server, however). > > I'm re-reading the code to check on what I'm seeing. (Its been a long > time since I last look deeply at this code). > > You can write to /dev/log if you pass that to > SysLogHandler(address='/dev/log'), but the default is to use a socket > to talk to a network listener on localhost:514. There are no deamons > listening on port 514 on my Fedora systems or mac OS. If you are saying that SysLogHandler should use a system specific default (e.g. "/dev/log" on Linux) instead of UDP port 514 everywhere, I agree 99 % (the remaining 1 % is my contrarian alter ego arguing that that's really the distribution maintainer's job since a Linux distribution might use some other socket). If you are saying it should use the libc syslog routines, I disagree for at least two reasons: a) they are OS specific, b) you can't configure the destination. So that would remove useful functionality. In any case it seems strange to me that you want to rewrite it just to avoid passing a single parameter to the constructor (or - more likely - adding a single line to a config file). > What you do not see used in the SyslogHandler() is the import syslog > and hence its nor using openlog() etc from syslog API. For good reasons. The C syslog API is missing important functionality. hp -- _ | Peter J. Holzer| Story must make more sense than reality. |_|_) || | | | h...@hjp.at |-- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" signature.asc Description: PGP signature -- https://mail.python.org/mailman/listinfo/python-list
Re: [python-uk] Fwd: It Will Never Work in Theory: live!
On 2022-03-04 20:48, BELAHCENE Abdelkader wrote: hi, I receive a lot of email from the python-list, I want to disable it, when I want to read the email, I want to go to he List. Please How to disable it. Regards This page explains how to unsubscribe: https://mail.python.org/mailman/listinfo/python-list Le jeu. 3 mars 2022 à 18:05, Steve Holden a écrit : A communication from my good friend Greg Wilsin (instigator of the Software Carpentry workshops) which may be of use to some. It certainly looks like great value for money. Kind regards, Steve -- Forwarded message - From: Greg Wilson Date: Tue, Mar 1, 2022 at 5:11 PM Subject: It Will Never Work in Theory: live! To: Steve Holden Hi Steve, On April 27, It Will Never Work in Theory is running two sets of online lightning talks from leading software engineering researchers in which they’ll summarize actionable findings from their work for practitioners. Tickets are now on sale at https://neverworkintheory.org/, and all money raised will to go Books for Africa. I hope to see you there, and if you could help spread the word or help sponsor it by matching money raised from ticket sales, we'd be very grateful. Cheers, Greg ___ python-uk mailing list python...@python.org https://mail.python.org/mailman/listinfo/python-uk -- https://mail.python.org/mailman/listinfo/python-list
Re: Behavior of the for-else construct
On 03/03/2022 19.54, Rob Cliffe wrote: On 04/03/2022 01:44, Ethan Furman wrote: On 3/3/22 5:32 PM, Rob Cliffe via Python-list wrote: > There are three types of programmer: those that can count, and those that can't. Actually, there are 10 types of programmer: those that can count in binary, and those that can't. 1, 10, many. No problem. Ah, a George Gamow fan. -- Michael F. Stemper Psalm 82:3-4 -- https://mail.python.org/mailman/listinfo/python-list
Re: Behavior of the for-else construct
On Sat, 5 Mar 2022 at 07:52, Avi Gross wrote: > > Chris, > > My example was precisely what to do when it is an empty closet: Does it correctly handle a closet with shirts in it, though? There's not a lot of point demonstrating an alternate use for the "else" clause when it is *absolutely identical* to simply placing two loops one after another. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Behavior of the for-else construct
Chris,
My example was precisely what to do when it is an empty closet:
> closet = []
>
> attic = ["Costumes", "Sheets", "Shirts" ]
>
> for item in closet:
> print(item)
> if item == "Shirts" : print("FOUND in closet!!")
> else:
> for item in attic:
> print(item)
> if item == "Shirts" : print("FOUND in attic!!")
Of course, for a more complete program, there is a reason to break out of
either loop if you find what you are looking for. I was illustrating an
alternate use in what I agree is a very incomplete example as it was meant only
to illustrate one point.
And my example may be implemented very differently if you need to search in
dozens of places. Consider the ubiquitous PATH variable. Many programs search
in one after another of the components for something like a filename. Doing
that with a series of nested FOR loops with each one nested in the ELSE of the
previous one might be a tad ridiculous!
I have an observation about exception handling in general. Some people use
exceptions, including ones they create and throw, for a similar idea. You might
for example try to use an exception if your first attempt fails that specifies
trying the next attempt. In my example of the PATH variable, you might use
something like calling a function and giving it what you are looking for as
well as a local copy of the PATH variable content and the exception would be to
call the function again with the first component of PATH removed until you fail
with an empty PATH. Yes, this is similar to just having a recursive function.
But I am hoping to get across my view that there are many ways to do things but
sometimes a new feature is useful because it is more direct or other reasons.
in the case we are discussing, what are the scope issues in:
eye = 1
for eye in ... :
pass
else:
eye = None
It looks like all references to eye refer to the same object. Some other
methods we have touched on (or others may bring up) may result in different
results as variables may be in other name spaces. My understanding of the
PYTHON-only implementation of the above is something like this. Imagine a FOR
loop that does not ignore the contents no matter what and the body looks like:
if SOMETHING_IS_BEING_DONE:
main code processing eye sequentially
else: # only used if nothing is being done normally
eye = None
The above made-up scenario would allow the external ELSE to be seen as the
implied else to an if that tests if the loop was actually entered. Of course it
is not implemented this way, but it would show why variable eye is in the same
scope in the several parts. Once you play with exceptions and other functions,
this may change.
The alternative suggestions about ELSE being associated confuse this issue so I
want to be clear.
The main meaning of the ELSE clause does not sound quite like this. It is
actually about what to do with a loop that terminates normally, as I think
Chris pointed out. This example finishes the loop normally and then does the
ELSE:
for x in range(6):
print(x)
else:
print("Finally finished!")
The following example is similar but quits early:
for x in range(6):
if x < 4: print(x)
else: break
else:
print("Finally finished!")
The (second) else clause is not run.
So the example tossed at us looks a bit more like this and it does run the ELSE
not because the loop is not done but because the loop never calls a break:
for x in range(0):
print(x)
else:
print("Finally finished!")
So unless I am missing something, the code would destroy the last value of the
variable even in a valid case when it looks like:
for aye in range(0):
pass
else:
aye = None
I mean if you used range(5) you would expect the value of aye==4 after the
loop. The above loop would leave it as aye==None which keeps it from being
undefined. To decide if the loop ran at all would thus require further code
such as:
if aye == None:
...
Which leads me right back to wondering why the sentinel approach is so bad!
-Original Message-
From: Chris Angelico
To: python-list@python.org
Sent: Fri, Mar 4, 2022 12:47 pm
Subject: Re: Behavior of the for-else construct
On Sat, 5 Mar 2022 at 03:44, Avi Gross via Python-list
wrote:
>
> Dieter,
>
> Your use is creative albeit it is not "needed" since all it does is make sure
> your variable is initialized to something, specifically None.
>
> So would this not do the same thing?
>
> eye = None
>
> for eye in range(0):
> print(eye)
>
> eye
>
> If I understand it, your example depends on a variable that is not yet
> initialized to be used in a loop and retain the last value after the loop.
> You then set it to None if it is not used as the loop is skipped. Others have
> shown an example similar to the above of using a sentinel that lets you know
> if the loop is skipped.
>
> Of course, there are some advantages in making it clear by doing it you way
> that the loop (for example if
Re: [python-uk] Fwd: It Will Never Work in Theory: live!
hi, I receive a lot of email from the python-list, I want to disable it, when I want to read the email, I want to go to he List. Please How to disable it. Regards Le jeu. 3 mars 2022 à 18:05, Steve Holden a écrit : > A communication from my good friend Greg Wilsin (instigator of the > Software Carpentry workshops) which may be of use to some. It certainly > looks like great value for money. > > Kind regards, > Steve > > > -- Forwarded message - > From: Greg Wilson > Date: Tue, Mar 1, 2022 at 5:11 PM > Subject: It Will Never Work in Theory: live! > To: Steve Holden > > > Hi Steve, > > On April 27, It Will Never Work in Theory is running two sets of online > lightning talks from leading software engineering researchers in which > they’ll summarize actionable findings from their work for practitioners. > Tickets are now on sale at https://neverworkintheory.org/, and all money > raised will to go Books for Africa. I hope to see you there, and if you > could help spread the word or help sponsor it by matching money raised > from ticket sales, we'd be very grateful. > > Cheers, > > Greg > > ___ > python-uk mailing list > python...@python.org > https://mail.python.org/mailman/listinfo/python-uk > -- https://mail.python.org/mailman/listinfo/python-list
Re: Behavior of the for-else construct
On 2022-03-04 at 11:14:29 -0500, Dennis Lee Bieber wrote: > Try to tell the difference between > > afileand > afile > > when doing a directory listing. Easy: log in over a 110 baud modem, where the characters take almost as much time as the beep. ;-) -- https://mail.python.org/mailman/listinfo/python-list
Re: Behavior of the for-else construct
I'm not sure if anyone has mentioned it on this thread, but with respect to
your comment about adding either on.empty or a decorator, the Django template
syntax uses
{% for x in iterator %}
{{ x }}
{% empty %}
Empty
{% endfor %}
and this seems to work quite well and be incredibly intuitive, at least for
Django html templates.
On Fri, 04 Mar 2022 13:45:21 -0600 Avi Gross via Python-list
wrote
> {NOTE, after some diversion, this long message does revert a bit to the
> topic.}
>
> Ah, Chris, the games we played when we were young and relatively immature!
>
> Has anyone else played with embedding "escape sequences" or other gimmicks
> in unexpected places like filenames so that on the right terminals, such as
> the VT100, it displayed oddly or was hard to open or delete as what showed
> was not quite the underlying representation?
>
> The main reason for the restrictions in olden days was cost. Everything was
> so costly including storage/memory and CPU time. Clearly it is a lot easier
> to have fixed-length filenames that fit into say 16 bytes, or storing
> multiple flags about file permissions as single bits, even if it meant lots
> of bit-twiddling or using masks to retrieve their values. We think nothing
> of creating structures that have many others embedded in them as attributes
> or function calls that allow a hundred optional arguments so that the
> function spends much of the time used just figuring out what was set before
> doing whatever calculation is required to fulfill the request.
>
> I was reading a novel recently (Jack Reacher Series) where the main
> character is noticing how much technology has changed as they have been
> ignoring it for a decade or so. Everything seems to be coming up faster. My
> view was that if something seems ten times as fast as it was, it also
> probably is doing a hundred or ten thousand times as much to get that
> result. The real speed changes are often counterbalanced by expecting to do
> more. A web page served may display a screen of text but to transmit it may
> include not just lots of padding in the HTML, but have all kinds of code
> such as in Java or JavaScript or lots of back and forth with the server to
> keep something like a graph displayed being refreshed ...
>
> So back to filenames, the concept of having to search for long filenames
> that may not even be stored sequentially in large blocks that can be read
> (ahead) efficiently, may have seemed to be so illogical as not to be
> considered. So given that the shorter ones were not allowed to have embedded
> spaces, it made sense to treat them like tokens that could be broken up at
> whitespace. As mentioned, languages (or other programs) would often parse a
> command line and create something like this for the main program in C with
> suitable version in Python and other languages:
>
>main(int argc, char *argv[])
>
> The code variations on the above do suppose that something has already
> parsed the command line that invoked them and partitioned it properly into
> individual strings placed in an array of such strings and also returned how
> many arguments it saw. Users invoking the program needed to be careful such
> as using double quotes around anything with embedded spaces, where allowed.
>
> But like many paradigms, there can be a shift. Consider the fact that
> languages like Python are constantly parsing things like names. Can you
> create a variable name like "me first" with an embedded space or even other
> symbols normally reserved such as parentheses? Most languages do not like
> such things. It makes it hard to parse if not quoted in some unique way. Yet
> languages like R happily allow such constructs if placed in back quotes
> (grave accents?) as in `me & you` as a variable name or the name of a
> function. Of course, you then never use the darn name without the extra
> quotes.
>
> Similarly, when you make an object like a DataFrame, can you include spaces
> and other things in the names of columns (or sometimes rows)? If so, is
> there only access some ways and not others?
>
> The answer often is not simple. As Chris repeatedly highlights, making a
> language consistent as you play with features can be VERY hard and sometimes
> not quite possible without relaxing some rules or making exceptions.
> Sometimes the answer varies. In base R a data.frame can be given a column
> name like "me + you" which it then stores as "me...you" leading to odd
> results. But it happily returns that result if you ask for mydf$me using
> auto-completion. Spell it out fully and it won't find it! A later package
> added on makes modified data.frame objects called tibbles which do not
> autocomplete but do completely store and let you access the name so mydf$me
> fails and mydf$"me + you" or mydf
On Fri, 04 Mar 2022 13:45:21 -0600 Avi Gross via Pyt
Re: Behavior of the for-else construct
{NOTE, after some diversion, this long message does revert a bit to the topic.}
Ah, Chris, the games we played when we were young and relatively immature!
Has anyone else played with embedding "escape sequences" or other gimmicks in
unexpected places like filenames so that on the right terminals, such as the
VT100, it displayed oddly or was hard to open or delete as what showed was not
quite the underlying representation?
The main reason for the restrictions in olden days was cost. Everything was so
costly including storage/memory and CPU time. Clearly it is a lot easier to
have fixed-length filenames that fit into say 16 bytes, or storing multiple
flags about file permissions as single bits, even if it meant lots of
bit-twiddling or using masks to retrieve their values. We think nothing of
creating structures that have many others embedded in them as attributes or
function calls that allow a hundred optional arguments so that the function
spends much of the time used just figuring out what was set before doing
whatever calculation is required to fulfill the request.
I was reading a novel recently (Jack Reacher Series) where the main character
is noticing how much technology has changed as they have been ignoring it for a
decade or so. Everything seems to be coming up faster. My view was that if
something seems ten times as fast as it was, it also probably is doing a
hundred or ten thousand times as much to get that result. The real speed
changes are often counterbalanced by expecting to do more. A web page served
may display a screen of text but to transmit it may include not just lots of
padding in the HTML, but have all kinds of code such as in Java or JavaScript
or lots of back and forth with the server to keep something like a graph
displayed being refreshed ...
So back to filenames, the concept of having to search for long filenames that
may not even be stored sequentially in large blocks that can be read (ahead)
efficiently, may have seemed to be so illogical as not to be considered. So
given that the shorter ones were not allowed to have embedded spaces, it made
sense to treat them like tokens that could be broken up at whitespace. As
mentioned, languages (or other programs) would often parse a command line and
create something like this for the main program in C with suitable version in
Python and other languages:
main(int argc, char *argv[])
The code variations on the above do suppose that something has already parsed
the command line that invoked them and partitioned it properly into individual
strings placed in an array of such strings and also returned how many arguments
it saw. Users invoking the program needed to be careful such as using double
quotes around anything with embedded spaces, where allowed.
But like many paradigms, there can be a shift. Consider the fact that languages
like Python are constantly parsing things like names. Can you create a variable
name like "me first" with an embedded space or even other symbols normally
reserved such as parentheses? Most languages do not like such things. It makes
it hard to parse if not quoted in some unique way. Yet languages like R happily
allow such constructs if placed in back quotes (grave accents?) as in `me &
you` as a variable name or the name of a function. Of course, you then never
use the darn name without the extra quotes.
Similarly, when you make an object like a DataFrame, can you include spaces and
other things in the names of columns (or sometimes rows)? If so, is there only
access some ways and not others?
The answer often is not simple. As Chris repeatedly highlights, making a
language consistent as you play with features can be VERY hard and sometimes
not quite possible without relaxing some rules or making exceptions. Sometimes
the answer varies. In base R a data.frame can be given a column name like "me +
you" which it then stores as "me...you" leading to odd results. But it happily
returns that result if you ask for mydf$me using auto-completion. Spell it out
fully and it won't find it! A later package added on makes modified data.frame
objects called tibbles which do not autocomplete but do completely store and
let you access the name so mydf$me fails and mydf$"me + you" or mydf$`me + you`
works but oddly an alternative format like mydf[, "me + you"] works while the
similar mydf[, `me + you`] fails!
My point is not about R but a more general one. I can rant about many other
languages, LOL! Allowing spaces or other characters in what used to be a more
easily viewable name that can be parsed easier, can lead to having to find
every place such things are used and seeing if they can be made to work
consistently. I show an example above where it is not consistent, in my view.
But when humans view things and their perceptions differ, you are inviting
disagreements about whatever you implement. You may end up having to make
people do more than they would
Re: Behavior of the for-else construct
On Fri, 4 Mar 2022 08:38:52 -0600, Tim Chase
declaimed the following:
>DOS didn't allow space (0x20) in filenames unless you hacked it by
>hex-editing your filesystem (which I may have done a couple times).
>However it did allow you to use 0xFF in filenames which *appeared* as
>a space in most character-sets.
>
>I may have caused a mild bit of consternation in school computer labs
>doing this. ;-)
>
Xerox CP/V actually allowed to be embedded in file names...
Try to tell the difference between
afile and
afile
when doing a directory listing.
{Though the BASIC interpreter gave it away -- doing a directory from within
the interpreter resulted in a hex representation of names with non-graphic
characters... In EBCDIC of course}
--
Wulfraed Dennis Lee Bieber AF6VN
wlfr...@ix.netcom.comhttp://wlfraed.microdiversity.freeddns.org/
--
https://mail.python.org/mailman/listinfo/python-list
Re: Behavior of the for-else construct
On Sat, 5 Mar 2022 at 03:44, Avi Gross via Python-list
wrote:
>
> Dieter,
>
> Your use is creative albeit it is not "needed" since all it does is make sure
> your variable is initialized to something, specifically None.
>
> So would this not do the same thing?
>
> eye = None
>
> for eye in range(0):
> print(eye)
>
> eye
>
> If I understand it, your example depends on a variable that is not yet
> initialized to be used in a loop and retain the last value after the loop.
> You then set it to None if it is not used as the loop is skipped. Others have
> shown an example similar to the above of using a sentinel that lets you know
> if the loop is skipped.
>
> Of course, there are some advantages in making it clear by doing it you way
> that the loop (for example if copied and used elsewhere) needs to include the
> else statement as an integral part.
>
> I would like to suggest a slight modification to the above as in if you are
> searching for something in either seq1 and if not found in seq2. Call it
> looking for your green shirt in the closet and if not found, looking in the
> attic. Would this code make sense as such a use in several ways? In English,
> look here first and if there is NOTHING there, look in the second place?
>
> closet = []
>
> attic = ["Costumes", "Sheets", "Shirts" ]
>
> for item in closet:
> print(item)
> if item == "Shirts" : print("FOUND in closet!!")
> else:
> for item in attic:
> print(item)
> if item == "Shirts" : print("FOUND in attic!!")
>
> Yes, as discussed, you could do an IF statement to check if closet is empty
> but for iterators, it gets ...
>
Make sure you 'break' after finding it. Otherwise, you'll keep
searching the rest of your closet, and then still go on to search your
attic. The "else:" clause doesn't help you here unless that break is
present.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Behavior of the for-else construct
On Sat, 5 Mar 2022 at 02:02, Tim Chase wrote: > > On 2022-03-04 11:55, Chris Angelico wrote: > > In MS-DOS, it was perfectly possible to have spaces in file names > > DOS didn't allow space (0x20) in filenames unless you hacked it by > hex-editing your filesystem (which I may have done a couple times). > However it did allow you to use 0xFF in filenames which *appeared* as > a space in most character-sets. Hmm, I'm not sure which APIs worked which way, but I do believe that I messed something up at one point and made a file with an included space (not FF, an actual 20) in it. Maybe it's something to do with the (ancient) FCB-based calls. It was tricky to get rid of that file, though I think it turned out that it could be removed by globbing, putting a question mark where the space was. (Of course, internally, MS-DOS considered that the base name was padded to eight with spaces, and the extension padded to three with spaces, so "READ.ME" would be "READ\x20\x20\x20\x20ME\x20", but that doesn't count, since anything that enumerates the contents of a directory would translate that into the way humans think of it.) > I may have caused a mild bit of consternation in school computer labs > doing this. ;-) Nice :) > > Windows forbade a bunch of characters in file names > > Both DOS and Windows also had certain reserved filenames > > https://www.howtogeek.com/fyi/windows-10-still-wont-let-you-use-these-file-names-reserved-in-1974/ > > that could cause issues if passed to programs. Yup. All because, way back in the day, they didn't want to demand the colon. If you actually *want* to use the printer device, for instance, you could get a hard copy of a directory listing like this: DIR >LPT1: and it's perfectly clear that you don't want to create a file called "LPT1", you want to send it to the printer. But noo it had to be that you could just write "LPT1" and it would go to the printer. > To this day, if you poke around on microsoft.com and change random > bits of URLs to include one of those reserved filenames in the GET > path, you'll often trigger a 5xx error rather than a 404 that you > receive with random jibberish in the same place. > > https://microsoft.com/…/asdfjkl → 404 > https://microsoft.com/…/lpt1 → 5xx > https://microsoft.com/…/asdfjkl/some/path → 404 > https://microsoft.com/…/lpt1/some/path → 5xx > > Just in case you aspire to stir up some trouble. > In theory, file system based URLs could be parsed such that, if you ever hit one of those, it returns "Directory not found". In practice... apparently they didn't do that. As a side point, I've been increasingly avoiding any sort of system whereby I take anything from the user and hand it to the file system. The logic is usually more like: If path matches "/static/%s": 1) Get a full directory listing of the declared static-files directory 2) Search that for the token given 3) If not found, return 404 4) Return the contents of the file, with cache markers Since Windows will never return "lpt1" in that directory listing, I would simply never find it, never even try to open it. This MIGHT be an issue with something that accepts file *uploads*, but I've been getting paranoid about those too, so, uhh... my file upload system now creates URLs that look like this: https://sikorsky.rosuav.com/static/upload-49497888-6bede802d13c8d2f7b92ca9fac7c That was uploaded as "pie.gif" but stored on the file system as ~/stillebot/httpstatic/uploads/49497888-6bede802d13c8d2f7b92ca9fac7c with some metadata stored elsewhere about the user-specified file name. So hey, if you were to try to upload a file that had an NTFS invalid character in it, I wouldn't even notice. Maybe I'm *too* paranoid, but at least I don't have to worry about file system attacks. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Behavior of the for-else construct
Avi Gross wrote at 2022-3-4 16:43 +: >Your use is creative albeit it is not "needed" since all it does is make sure >your variable is initialized to something, specifically None. > >So would this not do the same thing? > > eye = None > > for eye in range(0): > print(eye) > > eye It would. But, the `for` construct's main purpose is often to determine a value for the loop variable and in this case, I like that it itself can ensure that it gets a value. -- https://mail.python.org/mailman/listinfo/python-list
Re: Behavior of the for-else construct
Dieter,
Your use is creative albeit it is not "needed" since all it does is make sure
your variable is initialized to something, specifically None.
So would this not do the same thing?
eye = None
for eye in range(0):
print(eye)
eye
If I understand it, your example depends on a variable that is not yet
initialized to be used in a loop and retain the last value after the loop. You
then set it to None if it is not used as the loop is skipped. Others have shown
an example similar to the above of using a sentinel that lets you know if the
loop is skipped.
Of course, there are some advantages in making it clear by doing it you way
that the loop (for example if copied and used elsewhere) needs to include the
else statement as an integral part.
I would like to suggest a slight modification to the above as in if you are
searching for something in either seq1 and if not found in seq2. Call it
looking for your green shirt in the closet and if not found, looking in the
attic. Would this code make sense as such a use in several ways? In English,
look here first and if there is NOTHING there, look in the second place?
closet = []
attic = ["Costumes", "Sheets", "Shirts" ]
for item in closet:
print(item)
if item == "Shirts" : print("FOUND in closet!!")
else:
for item in attic:
print(item)
if item == "Shirts" : print("FOUND in attic!!")
Yes, as discussed, you could do an IF statement to check if closet is empty but
for iterators, it gets ...
-Original Message-
From: Dieter Maurer
To: Rob Cliffe
Cc: python-list@python.org
Sent: Fri, Mar 4, 2022 2:12 am
Subject: Re: Behavior of the for-else construct
Rob Cliffe wrote at 2022-3-4 00:13 +:
>I find it so hard to remember what `for ... else` means that on the very
>few occasions I have used it, I ALWAYS put a comment alongside/below the
>`else` to remind myself (and anyone else unfortunate enough to read my
>code) what triggers it, e.g.
>
> for item in search_list:
> ...
> ... break
> else: # if no item in search_list matched the criteria
>
>You get the idea.
>If I really want to remember what this construct means, I remind myself
>that `else` here really means `no break`. Would have been better if it
>had been spelt `nobreak` or similar in the first place.
One of my use cases for `for - else` does not involve a `break`:
the initialization of the loop variable when the sequence is empty.
It is demonstrated by the following transscript:
```pycon
>>> for i in range(0):
... pass
...
>>> i
Traceback (most recent call last):
File "", line 1, in
NameError: name 'i' is not defined
>>> for i in range(0):
... pass
... else: i = None
...
>>> i
>>>
```
For this use case, `else` is perfectly named.
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: Behavior of the for-else construct
On 2022-03-04 11:55, Chris Angelico wrote: > In MS-DOS, it was perfectly possible to have spaces in file names DOS didn't allow space (0x20) in filenames unless you hacked it by hex-editing your filesystem (which I may have done a couple times). However it did allow you to use 0xFF in filenames which *appeared* as a space in most character-sets. I may have caused a mild bit of consternation in school computer labs doing this. ;-) > Windows forbade a bunch of characters in file names Both DOS and Windows also had certain reserved filenames https://www.howtogeek.com/fyi/windows-10-still-wont-let-you-use-these-file-names-reserved-in-1974/ that could cause issues if passed to programs. To this day, if you poke around on microsoft.com and change random bits of URLs to include one of those reserved filenames in the GET path, you'll often trigger a 5xx error rather than a 404 that you receive with random jibberish in the same place. https://microsoft.com/…/asdfjkl → 404 https://microsoft.com/…/lpt1 → 5xx https://microsoft.com/…/asdfjkl/some/path → 404 https://microsoft.com/…/lpt1/some/path → 5xx Just in case you aspire to stir up some trouble. -tkc -- https://mail.python.org/mailman/listinfo/python-list
virtualenv and make DESTDIR=
Hi, How can I make installing a virtual environment honor DESTDIR? How can I install a virtual environment in $(DESTDIR)$(PREFIX), which behaves as being set-up in $(PREFIX)? (Of course, this virtual environment can not be used. My aim is to ship it as part of a rpm package) In Makefiles is good practice to honor DESTDIR in the "install" target, like this install: install -t $(DESTDIR)$(PREFIX)/bin build/bin/my-tool Now when running python3 -m venv $(DESTDIR)$(PREFIX) all paths in this virtual environment refer to $(DESTDIR)$(PREFIX) instead of just $$(PREFIX) Any ideas? Background: More about DESTDIR: https://www.gnu.org/prep/standards/html_node/DESTDIR.html Following Redhat's commendations, I want to install my (somewhat complex) software into /opt/my-software. To make it easier for users to use the software, my idea was to setup a virtual environment in /opt/my-software. Thus users can easily use /opt/my-software/bin/python and have the library provided by my-software available. My Software also includes some scripts, which will also reside in /opt/my-software/bin and refer to /opt/my-software/bin/python. This will avoid to require users to set up PYTHONPATH when thy want to use MY Software. -- Schönen Gruß Hartmut Goebel Dipl.-Informatiker (univ), CISSP, CSSLP, ISO 27001 Lead Implementer Information Security Management, Security Governance, Secure Software Development Goebel Consult, Landshut http://www.goebel-consult.de Blog: https://www.goe-con.de/blog/why-a-pki-is-barely-trustworthy Kolumne: https://www.goe-con.de/hartmut-goebel/cissp-gefluester/2011-11-in-troja-nichts-neues -- https://mail.python.org/mailman/listinfo/python-list
Re: Behavior of the for-else construct
On Fri, 4 Mar 2022 at 21:02, gene heskett wrote: > That makes the logic work, but who then cleans up the trash on the stack. > Thats a memory leak. > Not sure I follow? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Behavior of the for-else construct
On Friday, 4 March 2022 02:18:51 EST Chris Angelico wrote: > On Fri, 4 Mar 2022 at 18:13, Dieter Maurer wrote: > > Rob Cliffe wrote at 2022-3-4 00:13 +: > > >I find it so hard to remember what `for ... else` means that on the > > >very few occasions I have used it, I ALWAYS put a comment > > >alongside/below the `else` to remind myself (and anyone else > > >unfortunate enough to read my code) what triggers it, e.g. > > > > > > for item in search_list: > > > ... > > > ... break > > > > > > else: # if no item in search_list matched the criteria > > > > > >You get the idea. > > >If I really want to remember what this construct means, I remind > > >myself that `else` here really means `no break`. Would have been > > >better if it had been spelt `nobreak` or similar in the first > > >place. > > > > One of my use cases for `for - else` does not involve a `break`: > > the initialization of the loop variable when the sequence is empty. > > It is demonstrated by the following transscript: > > > > ```pycon > > > > >>> for i in range(0): > > ... pass > > ... > > > > >>> i > > > > Traceback (most recent call last): > > File "", line 1, in > > > > NameError: name 'i' is not defined > > > > >>> for i in range(0): > > ... pass > > ... else: i = None > > ... > > > > >>> i > > > > ``` > > > > For this use case, `else` is perfectly named. > > What's the point of this? Why not just put "i = None" after the loop? > That makes the logic work, but who then cleans up the trash on the stack. Thats a memory leak. > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list > . Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis -- https://mail.python.org/mailman/listinfo/python-list
Re: Behavior of the for-else construct
Op 4/03/2022 om 1:43 schreef Chris Angelico:
Think of it like this:
for item in search_list:
if condition: pass
else:
print("Condition not true for this item")
for item in search_list:
if condition: break
else:
print("Condition not true for any item")
There's a parallel here. Since a for-else loop is basically useless
without an if-break construct inside it, the else clause can be
thought of as the else on a massive if/elif chain:
if stuff[0].is_good:
print("This item is good", stuff[0])
elif stuff[1].is_good:
print("This item is good", stuff[1])
...
...
elif stuff[n].is_good:
print("This item is good", stuff[n])
else:
print("All items are bad")
As a loop, this looks like this:
for item in stuff:
if item.is_good:
print("This item is good", item)
break
else:
print("All items are bad")
The else is attached to the for so that it compasses ALL the if
statements, but it's still broadly saying "do this when we don't hit
the 'if' condition".
Whether that's a sufficient mnemonic, I don't know [...]
Certainly not for me. It could work for the specific use case you
mention, but nothing in the definition restricts it to be used for that
use case. As Rob Cliffe says in one of his posts, a for-loop can be
terminated with "break" for many conceptually different reasons. A
mnemonic that only works for one specific use case, even if it's the
most used one, doesn't work as a mnemonic for the general concept for me.
[...], but it doesn't
really matter; the construct is useful to those of us who want it, and
if other people ignore it, that's fine. Nobody ever said you had to
use or understand every single feature of the language you're using.
True, still, I agree with people who think nobreak would have been
better because it better conveys the intention. IIRC Raymond Hettinger
once said something like that too, so I'm in good company I guess.
--
"Honest criticism is hard to take, particularly from a relative, a friend,
an acquaintance, or a stranger."
-- Franklin P. Jones
--
https://mail.python.org/mailman/listinfo/python-list
Re: Behavior of the for-else construct
Op 4/03/2022 om 8:18 schreef Chris Angelico: On Fri, 4 Mar 2022 at 18:13, Dieter Maurer wrote: > One of my use cases for `for - else` does not involve a `break`: > the initialization of the loop variable when the sequence is empty. > It is demonstrated by the following transscript: > > ```pycon > >>> for i in range(0): > ... pass > ... > >>> i > Traceback (most recent call last): > File "", line 1, in > NameError: name 'i' is not defined > >>> for i in range(0): > ... pass > ... else: i = None > ... > >>> i > >>> > ``` > > For this use case, `else` is perfectly named. What's the point of this? Why not just put "i = None" after the loop? As I understand it: range(0) is just a (bad) example, it's actually about any arbitrary iterable. You don't know in advance if it's empty or not, and you want i to be initialized in all cases. (I don't think I have ever encountered that situation.) You could easily solve this by placing "i = None" before the loop, but I guess in situations where you want to initialize i with the result of an expensive operation Dieter's method could be a reasonable solution. This would actually be a good use case for computermaster360's proposal. -- "Honest criticism is hard to take, particularly from a relative, a friend, an acquaintance, or a stranger." -- Franklin P. Jones -- https://mail.python.org/mailman/listinfo/python-list
