Re: UTF_16 question
> On Apr 29, 2024, at 12:23 PM, jak via Python-list > wrote: > > Hi everyone, > one thing that I do not understand is happening to me: I have some text > files with different characteristics, among these there are that they > have an UTF_32_le coding, utf_32be, utf_16_le, utf_16_be all of them > without BOM. With those utf_32_xx I have no problem but with the > UTF_16_xx I have. If I have an utf_16_le coded file and I read it with > encoding='utf_16_le' I have no problem I read it, with > encoding='utf_16_be' I can read it without any error even if the data I > receive have the inverted bytes. The same thing happens with the > utf_16_be codified file, I read it, both with encoding='utf_16_be' and > with 'utf_16_le' without errors but in the last case the bytes are > inverted. What did I not understand? What am I doing wrong? > > thanks in advance > > -- > https://mail.python.org/mailman/listinfo/python-list That is why the BOM was created. A lot of files can be “correctly” read as either UTF-16-LE or UTF-1-BE encoded, as most of the 16 bit codes are valid, so unless the wrong encoding happens to hit something that is invalid (most likely something looking like a Surrogage Pair without a match), there isn’t an error in reading the file. The BOM character was specifically designed to be an invalid code if read by the wrong encoding (if you ignore the possibility of the file having a NUL right after the BOM) If you know the files likely contains a lot of “ASCII” characters, then you might be able to detect that you got it wrong, due to seeing a lot of 0xXX00 characters and few 0x00XX characters, but that doesn’t create an “error” normally. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python misbehavior
On 2/6/24 10:46 PM, Jim via Python-list wrote: Friends, Please forgive me if this is not the proper forum for dealing with an issue of mine, but I am at a loss in finding a fix for a python problem in the program ClipGrab. The program allows one to download videos or audios from YouTube and other media sites. My limited understanding of the process suggests that python facilitates the transfer of data from YouTube to ClipGrab. As of recently, I am unable to use the ClipGrab program and the issue at fault has something to do with python. In an "about" screen within ClipGrab my (now) incapable python script reads: youtube-dlp: (C:\Program Files (x86)\ClipGrab\python\python.exe: can't find '_main_' module in " ) Python: C:/Program Files (x86)/ClipGrab/python/python.exe (Python 3.8.9) Since this problem began I downloaded ClipGrab on to another desktop computer and it runs perfectly without a problem. The script on the "about" page does not indicate anything about "can't find -main- module" etc. Is there any advice you can offer to overcome this and recover my downloading connections to YouTube? Or, if this is the wrong group to handle such issues, could you please pass my message on to a better choice? Gratefully, Jim Haas Sent from my iPhone Python itself doesn't have any code to do this, but does have some support libraries that help. It looks like your "ClipGrab" program is using the python module "youtube-dlp" to get the data (that module probabaly has the details of how to do the operation), but somehow ClipGrab hasn't packaged the module into itself properly. You probably should seek help with the support for the ClipGrab program from the people that make it. If you look up the documentation for youtube-dlp, you may find that you can use that module directly, and not need the ClipGrab wrapper at all (though it may provide some benefits if you can get it working again). -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: How/where to store calibration values - written by program A, read by program B
On 12/28/2023 12:20 AM EST rbowman via Python-list <[1]python-list@python.org> wrote: On Wed, 27 Dec 2023 03:53:42 -0600, Greg Walters wrote: The biggest caveat is that the shared variable MUST exist before it can be examined or used (not surprising). There are a few other questions. Let's say config.py contains a variable like 'font' that is a user set preference or a calibration value calculated by A to keep with the thread title. Assuming both scripts are running, how does the change get propagated to B after it is set in A and written to the shared file? Is there a mechanism to allow both scripts to make updates? The easy way out is to assume the changes will be picked up when the scripts are restarted but this is not always acceptable. -- [2]https://mail.python.org/mailman/listinfo/python-list If one module does a: import config config.font = "New Value" Then every other module in that program that also did a import config will see the new value of that variable, as the assignment rebound the name in the module namespace to the new value. Note, it does NOT work if you did a from config import font font = "New Value" as that doesn't change the binding in the config module. IF you need to propagate to a different process, you need something different. References Visible links 1. mailto:python-list@python.org 2. https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Context without manager
Read the Fine context manager documentation. What “with with_expression as var” does is effectively: ob = with_expression var = ob.__enter__() And then at the end of the with, does a ob.__exit__() (With some parameters to __exit__, that could just be None, None, None for the simplest case). Note, YOUR program must now make sure that the __exit__ function is called, and handle any exceptions that got thrown, and that ob and var are put somewhere you can access them at that later time. > On Nov 27, 2023, at 12:24 PM, Piergiorgio Sartor via Python-list > wrote: > > On 26/11/2023 18.50, Dieter Maurer wrote: >> Piergiorgio Sartor wrote at 2023-11-25 22:15 +0100: >>> ... >>> Apparently, the "with" context manager is not usable >>> in classes, at least not with __init__() & co. >> You can use `with` in classes -- with any context manager. >> However, you would usually not use `with` with a file you have opened >> in `__init__`. >> If a class defines `__enter__` and `__exit__` (i.e. >> the "cntext manager protocol"), then its instances >> can be used with the `with` statement. >> The important use case for a context manager is the >> situation: >> set up a context (--> method `__enter__`) >> perform some operations in this context (--> body of `with` statement) >> tear down the context (--> method `__exit__`). >> If you do not have this case (e.g. usually if you open the file >> in a class's `__init__`), you do not use a context manager. > > Very clear, but what if the class is *not* "open()", > but something else _requiring_ using "with"? > How to do this in a "__init__()" of a class? > > In other words, what if "open()" could *only* be used > with "with" and not just by assigning "fp = open()"? > > The problem is I've some SDK of some device which > provides context manager *only* classes. > > I *cannot* do: > > device = device_open(...) > device.do_something() > device.close() > > I *must* do: > > with device_open() as device: > device.do_something() > > Nevertheless, I _need_ to have a class > where the device is opened in the __init__() > and used in some methods. > > Any ideas? > > bye, > > -- > > piergiorgio > > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Context without manager
Read the Fine context manager documentation. What “with with_expression as var” does is effectively: ob = with_expression var = ob.__enter__() And then at the end of the with, does a ob.__exit__() (With some parameters to __exit__, that could just be None, None, None for the simplest case). Note, YOUR program must now make sure that the __exit__ function is called, and handle any exceptions that got thrown, and that ob and var are put somewhere you can access them at that later time. > On Nov 27, 2023, at 12:24 PM, Piergiorgio Sartor via Python-list > wrote: > > On 26/11/2023 18.50, Dieter Maurer wrote: >> Piergiorgio Sartor wrote at 2023-11-25 22:15 +0100: >>> ... >>> Apparently, the "with" context manager is not usable >>> in classes, at least not with __init__() & co. >> You can use `with` in classes -- with any context manager. >> However, you would usually not use `with` with a file you have opened >> in `__init__`. >> If a class defines `__enter__` and `__exit__` (i.e. >> the "cntext manager protocol"), then its instances >> can be used with the `with` statement. >> The important use case for a context manager is the >> situation: >> set up a context (--> method `__enter__`) >> perform some operations in this context (--> body of `with` statement) >> tear down the context (--> method `__exit__`). >> If you do not have this case (e.g. usually if you open the file >> in a class's `__init__`), you do not use a context manager. > > Very clear, but what if the class is *not* "open()", > but something else _requiring_ using "with"? > How to do this in a "__init__()" of a class? > > In other words, what if "open()" could *only* be used > with "with" and not just by assigning "fp = open()"? > > The problem is I've some SDK of some device which > provides context manager *only* classes. > > I *cannot* do: > > device = device_open(...) > device.do_something() > device.close() > > I *must* do: > > with device_open() as device: > device.do_something() > > Nevertheless, I _need_ to have a class > where the device is opened in the __init__() > and used in some methods. > > Any ideas? > > bye, > > -- > > piergiorgio > > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: type annotation vs working code
My view of the issue is that the "trick" of "evaluating" a name to see if the object has been initialized is just a tad on the "tricky" side, and the annotation/value is really incorrect. The name at the point you are annotating it, isn't really a "bool" because a bool will always have either the value "True" or "False", while for this variable, you are really testing if it exists or not. Perhaps a better method would be rather than just using the name and catching the exception, use a real already_initialized flag (set to True when you initialize), and look it up with getattr() with a default value of False. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: GNU gettext: Print string translated and untranslated at the same time
> On Aug 17, 2023, at 10:02 AM, c.buhtz--- via Python-list
> wrote:
>
> X-Post: https://stackoverflow.com/q/76913082/4865723
>
> I want to display one string in its original source (untranslated) version
> and in its translated version site by site without duplicating the string in
> the python source code?
> It wouldn't be a big deal if it is only one word.
>
>print('The translated string "{}" is originally "{}".'.format(_('Hello'),
> 'Hello'))
>
> But in my situation it is a multi line string containing multiple paragraphs.
> It is a full text. I don't want to duplicate that string.
>
># Imagine 'Hello' as a 50x70 characters multi line string.
>original = 'Hello'
>translated = _('Hello')
>print('The translated string "{}" is originally "{}".'.format(translated,
> original))
>
> I do use the "class based API" of GNU gettext. My current approach, which is
> not working, is to somehow (how!?) disable (or mask) the translation function
> "_()" temporarily.
> But as described in the stackoverflow question (see first line of this mail)
> this do not work.
>
> def foobar(translate):
>if not translate:
># I try to mask the global _() builtins-function
>def _(txt):
>return txt
>
>return _('Hello')
>
> if __name__ == '__main__':
>
># To ilustrate that _() is part of "builtins" namespace
>print(_('No problem.'))
>
>print('The translated string "{}" is originally "{}".'
> .format(foobar(True), foobar(False)))
>
> This is the output:
>
>Traceback (most recent call last):
> File "/home/user/ownCloud/_transfer/./z.py", line 27, in
>.format(foobar(True), foobar(False)))
> File "/home/user/ownCloud/_transfer/./z.py", line 19, in foobar
>return _('Hello')
>UnboundLocalError: local variable '_' referenced before assignment
>
> The full MWE can be found at stackoverflow
> (https://stackoverflow.com/q/76913082/4865723).
>
> The question is if this can be solved somehow or if there is an alternative
> approach.
> The "_()" function is installed in the builtins namespace because of gettext
> class based API. This is nice.
> Maybe I can somehow manipulate that builtins namespace? I tried to import
> builtins and played around with it but couldn't find a way to do it.
>
> Thanks
> Christian Buhtz
>
> PS: This is IMHO not relevant for my question but if someone is interested
> the connection to productive code can be found in this issue:
> https://github.com/bit-team/backintime/issues/1473 There I describe what I
> want to achive and also provide a GUI mockup.
> --
> https://mail.python.org/mailman/listinfo/python-list
One thing to remember is that the _() function, which calls gettext doesn’t
need a literal string, so you can set a variable to ‘raw’ string, and then
translate it to another variable, so you can have both.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Multiple inheritance and a broken super() chain
On 7/3/23 1:38 PM, Peter Slížik via Python-list wrote:
Hello.
The legacy code I'm working with uses a classic diamond inheritance. Let me
call the classes *Top*, *Left*, *Right*, and *Bottom*.
This is a trivial textbook example. The classes were written in the
pre-super() era, so all of them initialized their parents and Bottom
initialized both Left and Right in this order.
The result was expected: *Top* was initialized twice:
Top.__init__() Left.__init__() Top.__init__() Right.__init__()
Bottom.__init__()
Now I replaced all parent init calls with *super()*. After this, Top was
initialized only once.
Top.__init__() Right.__init__() Left.__init__() Bottom.__init__()
But at this point, I freaked out. The code is complex and I don't have the
time to examine its inner workings. And before, everything worked correctly
even though Top was initialized twice. So I decided to break the superclass
chain and use super() only in classes inheriting from a single parent. My
intent was to keep the original behavior but use super() where possible to
make the code more readable.
class Top:
def __init__(self):
print("Top.__init__()")
class Left(Top):
def __init__(self):
super().__init__()
print("Left.__init__()")
class Right(Top):
def __init__(self):
super().__init__()
print("Right.__init__()")
class Bottom(Left, Right):
def __init__(self):
Left.__init__(self) # Here I'm calling both parents manually
Right.__init__(self)
print("Bottom.__init__()")
b = Bottom()
The result has surprised me:
Top.__init__() Right.__init__() Left.__init__() Top.__init__()
Right.__init__() Bottom.__init__()
Now, as I see it, from the super()'s point of view, there are two
inheritance chains, one starting at Left and the other at Right. But
*Right.__init__()* is called twice. What's going on here?
Thanks,
Peter
Because the MRO from Bottom is [Bottom, Left, Right, Top] so super() in
Left is Right. It doesn't go to Top as the MRO knows that Right should
go to Top, so Left needs to go to Right to init everything, and then
Bottom messes things up by calling Right again.
--
Richard Damon
--
https://mail.python.org/mailman/listinfo/python-list
Re: Problems Installing and getting started.
How are you trying to “Open” python? If you get that option screen, that sounds like you are trying to run the installer again. Knowing your Operating System would be very helpful. Python is normally run from the command line, or since you have the PyCharm IDE, it can run python on the program you have loaded into the project. > On May 31, 2023, at 11:55 AM, Mark Bass wrote: > > -- Forwarded message - > From: Mark Bass > Date: Wed, 31 May 2023 at 08:09 > Subject: Problems Installing and getting started. > To: > > > Good morning, > > I installed python several hours ago (from python.org), I then installed > the IDE PyCharm. I'm using AI to help with a project that requires > statistical analysis. > I cannot open python, when I double clicked a "Modify Setup" window > appeared with the three options Modify, Repair and Uninstall to click. I > assumed this was part of the final installation process and clicked Modify > - it seemed to be successful. I still could not open python. I asked the AI > and it suggested to click Repair, this still made no difference. I finally > Uninstalled it, shut down my laptop, had a coffee then re-installed it but > the same problem occurred. > Can you help ? Any suggestions? > I'm really pleased with the AI so far and looking forward to using Python > to get my project started. > Best Regards.Mark > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Addition of a .= operator
On 5/20/23 4:15 PM, Peter J. Holzer wrote: On 2023-05-20 10:54:59 -0700, Alex Jando wrote: I have many times had situations where I had a variable of a certain type, all I cared about it was one of it's methods. For example: hash = hash.hexdigest() num = num.value So what I'm suggesting is something like this: hash.=hexdigest() num.=value I actually needed to read those twice to get their meaning. I think hash .= hexdigest() num .= value would have been clearer (yes, I nag my colleagues about white-space, too). Do you have any examples (preferably from real code) where you don't assign to a simple variable? I feel that x += 1 isn't much of an improvement over x = x + 1 but self.data[line+len(chars)-1] += after is definitely an improvement over self.data[line+len(chars)-1] + self.data[line+len(chars)-1] + after hp For immutable types, it is just syntactic sugar, but for mutable type there is an important difference x = [] y = x x += [1] changes the list named by y, but x = [] y = x x = x + [] does not. The key is that if a type actually implements the inplace operator, then using the op= version doesn't bind the name to a new object but mutates the object to a new value. This just can't happen (as far as I can figure) for .= unless the object is defining something weird for the inplace version of the operation, which is probably best to not actually allow. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Weak Type Ability for Python
On 4/13/23 7:25 PM, avi.e.gr...@gmail.com wrote: s there any concept in Python of storing information in some way, such as text, and implementing various ideas or interfaces so that you can query if the contents are willing and able to be viewed in one of many other ways? There is nothing that I know of built into Python that does this. There is no reason you can't write your own class to implement this. Something that by "default" looks like a string, but in some contexts (operated on by certain types) sees if its string could be treated as a value of some other type, and if so, converts its value to that type and does the operation. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: How does a method of a subclass become a method of the base class?
On 3/26/23 1:43 PM, Jen Kris via Python-list wrote: The base class: class Constraint(object): def __init__(self, strength): super(Constraint, self).__init__() self.strength = strength def satisfy(self, mark): global planner self.choose_method(mark) The subclass: class UrnaryConstraint(Constraint): def __init__(self, v, strength): super(UrnaryConstraint, self).__init__(strength) self.my_output = v self.satisfied = False self.add_constraint() def choose_method(self, mark): if self.my_output.mark != mark and \ Strength.stronger(self.strength, self.my_output.walk_strength): self.satisfied = True else: self.satisfied = False The base class Constraint doesn’t have a "choose_method" class method, but it’s called as self.choose_method(mark) on the final line of Constraint shown above. My question is: what makes "choose_method" a method of the base class, called as self.choose_method instead of UrnaryConstraint.choose_method? Is it super(UrnaryConstraint, self).__init__(strength) or just the fact that Constraint is its base class? Also, this program also has a class BinaryConstraint that is also a subclass of Constraint and it also has a choose_method class method that is similar but not identical: def choose_method(self, mark): if self.v1.mark == mark: if self.v2.mark != mark and Strength.stronger(self.strength, self.v2.walk_strength): self.direction = Direction.FORWARD else: self.direction = Direction.BACKWARD When called from Constraint, it uses the one at UrnaryConstraint. How does it know which one to use? Thanks, Jen Perhaps the key point to remember is that when looking up the methods on an object, those methods are part of the object as a whole, not particually "attached" to a given class. When creating the subclass typed object, first the most base class part is built, and all the methods of that class are put into the object, then the next level, and so on, and if a duplicate method is found, it just overwrites the connection. Then when the object is used, we see if there is a method by that name to use, so methods in the base can find methods in subclasses to use. Perhaps a more modern approach would be to use the concept of an "abstract base" which allows the base to indicate that a derived class needs to define certain abstract methods, (If you need that sort of support, not defining a method might just mean the subclass doesn't support some optional behavior defined by the base) -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Precision Tail-off?
On 2/17/23 5:27 AM, Stephen Tucker wrote: Thanks, one and all, for your reponses. This is a hugely controversial claim, I know, but I would consider this behaviour to be a serious deficiency in the IEEE standard. Consider an integer N consisting of a finitely-long string of digits in base 10. Consider the infinitely-precise cube root of N (yes I know that it could never be computed unless N is the cube of an integer, but this is a mathematical argument, not a computational one), also in base 10. Let's call it RootN. Now consider appending three zeroes to the right-hand end of N (let's call it NZZZ) and NZZZ's infinitely-precise cube root (RootNZZZ). The key factor here is IEEE floating point is storing numbers in BINARY, not DECIMAL, so a multiply by 1000 will change the representation of the number, and thus the possible resolution errors. Store you numbers in IEEE DECIMAL floating point, and the variations by multiplying by powers of 10 go away. The *only *difference between RootN and RootNZZZ is that the decimal point in RootNZZZ is one place further to the right than the decimal point in RootN. No, since the floating point number is stored as a fraction times a power of 2, the fraction has changed as well as the power of 2. None of the digits in RootNZZZ's string should be different from the corresponding digits in RootN. Only if the storage format was DECIMAL. I rest my case. Perhaps this observation should be brought to the attention of the IEEE. I would like to know their response to it. That is why they have developed the Decimal Floating point format, to handle people with those sorts of problems. They just aren't common enough for many things to have adopted the use of it. Stephen Tucker. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question
On 2/1/23 12:46 PM, Grant Edwards wrote: C (the language) doesn't support Unicode at all. There are, however, libraries that can be used to deal with it. No, it does, but only optionally. provides functions that manipulate Unicode "Characters" The type char32_t will hold Unicode Code Points, and you can define string literals of that type with U"string" notation. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question
On 2/1/23 3:59 AM, mutt...@dastardlyhq.com wrote: On Wed, 1 Feb 2023 11:59:25 +1300 Greg Ewing wrote: On 31/01/23 10:24 pm, mutt...@dastardlyhq.com wrote: All languages have their ugly corners due to initial design mistakes and/or constraints. Eg: java with the special behaviour of its string class, C++ with "=0" pure virtual declaration. But they don't dump them and make all old code suddenly cease to execute. No, but it was decided that Python 3 would have to be backwards incompatible, mainly to sort out the Unicode mess. Given that, the opportunity was taken to clean up some other mistakes as well. Unicode is just a string of bytes. C supports it with a few extra library functions to get unicode length vs byte length and similar. Its really not that hard. Rewriting an entire language just to support that sounds a bit absurd to me but hey ho... No, Unicode is a string of 21 bit characters. UTF-8 is a representation that uses bytes, but isn't itself "Unicode". The key fact is that a "String" variable is indexed not by bytes of UTF-8 encoding, but by actual characters. Python3 will store a string as either a sequence of Bytes if the data is all Latin-1, as a sequence of 16-bit words if the data all fits on th BMP, and a sequence of 32 bit words if it has a value outside the BMP. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: To clarify how Python handles two equal objects
I think the key point is that "the operation" doesn't act on "names" but on "objects" (which are different sort of things), and thus there isn't an "the other" when talking about the object being operated on. Thinking of an operation being on a "name" is the mental model error. The only operations that operate on "names" are assignment operations. Augmented assignment operations are more complicatd, as they can either work on the object the name points on, if that object is mutable, or rebinds the name to a new object if it isn't. Thus a += b is NOT neccessarilily the same as a = a + b, as a += b might just mutate the object that a is bound to or might rebind in the manner of a = a + b; Thus: a = [ 1, 2, 3] b = a a += [4] will change the single list that a and b are bound to into [1, 2, 3, 4], while a = "foo" b = a a += "bar" will change a to be bound to the string object "foobar" but not b, since the string object "foo" wasn't mutable. Brings up the point, that you need to be careful with augmented assignment operators. On 1/11/23 1:28 PM, Jen Kris via Python-list wrote: Thanks for your comments. After all, I asked for clarity so it’s not pedantic to be precise, and you’re helping to clarify. Going back to my original post, mx1 = [ [ 1, 2, 3 ], [ 4, 5, 6 ], [ 7, 8, 9 ] ] arr1 = mx1[2] Now if I write "arr1[1] += 5" then both arr1 and mx1[2][1] will be changed because while they are different names, they are the assigned same memory location (pointer). Similarly, if I write "mx1[2][1] += 5" then again both names will be updated. That’s what I meant by "an operation on one is an operation on the other." To be more precise, an operation on one name will be reflected in the other name. The difference is in the names, not the pointers. Each name has the same pointer in my example, but operations can be done in Python using either name. Jan 11, 2023, 09:13 by r...@roelschroeven.net: Op 11/01/2023 om 16:33 schreef Jen Kris via Python-list: Yes, I did understand that. In your example, "a" and "b" are the same pointer, so an operation on one is an operation on the other (because they’re the same memory block). Sorry if you feel I'm being overly pedantic, but your explanation "an operation on one is an operation on the other (because they’re the same memory block)" still feels a bit misguided. "One" and "other" still make it sound like there are two objects, and "an operation on one" and "an operation on the other" make it sound like there are two operations. Sometimes it doesn't matter if we're a bit sloppy for sake of simplicity or convenience, sometimes we really need to be precise. I think this is a case where we need to be precise. So, to be precise: there is only one object, with possible multiple names to it. We can change the object, using one of the names. That is one and only one operation on one and only one object. Since the different names refer to the same object, that change will of course be visible through all of them. Note that 'name' in that sentence doesn't just refer to variables (mx1, arr1, ...) but also things like indexed lists (mx1[0], mx1[[0][0], ...), loop variables, function arguments. The correct mental model is important here, and I do think you're on track or very close to it, but the way you phrase things does give me that nagging feeling that you still might be just a bit off. -- "Peace cannot be kept by force. It can only be achieved through understanding." -- Albert Einstein -- https://mail.python.org/mailman/listinfo/python-list -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: No solution for "--verbose" (on stdout) output in Pythonds standard library?
> On Jan 4, 2023, at 8:56 AM, c.bu...@posteo.jp wrote: > > Hello, > > first I have to say that in my current and fresh humble opinion the > often seen "--verbose" switch in command line applications should > affect only the messages given to the users. This means messages on > "stdout". That is what this question is about. > > The logging module is not an option because it works on stderr and is > not intended to offer messages for the user but just for the system and > its admins via logs (log-files, syslog, stderr redirection, ...). > > Using logging handlers redirecting to stdout are considered as > workarounds by me and also not an option. > > This is not only my opinion but also part of the Python documentation: > https://docs.python.org/3/howto/logging.html#when-to-use-logging > > I'm so detailed here about that difference between stdout and stderr > because in the wild (e.g. on StackOverflow) you often find "use logging > log levels" as a solution for that problem, which IMHO isn't one. > > Now the question: > From my research on the docs it seems there is no feature in the > standard library which could help me to implement "--verbose" or > multiple verbosity levels like "-vvv"? > I found some workarounds/hacks. > https://stackoverflow.com/q/5980042/4865723 > But my experience with Python as a Swiss knife is that there is always > a standard solution for such basic and often reinvented things. I won't > believe that each Python developer writes its own verbose feature. ;) > -- > https://mail.python.org/mailman/listinfo/python-list First, I would say you are incorrect that Payton ALWAYS has a standard solution for “basic” problems, as some problems (like this) aren’t actual that easy to just provide a solution. “Verbosity” levels, need to be defined by an application, so can’t just be provided by Python, but WILL need some effort on by the programmer. Second, Stack Overflow is NOT a good source of “Truth” about things, it is just a source of what people on Stack Overflow think is truth, which is up to the reader to decide if it is actually usable. Now, it turns out that you CAN use argparse (or similar libraries) and logging (or similar libraries) to implement a form of verbosity. Start off by default to NOT have logging enabled (or only enable for “High” level messages). Different levels of Verbosity can enable lower levels of logging, and perhaps move the logging from the “default” of stderr to stdout, all of these are possible with these libraries. Whether this is an “abuse” of the logging library or not is up to you are the programmer to decide, no one is making you do it that way, or saying that is the way it should be done, just a way it COULD be done. Personally, I might consider the logging module for this, or I might just add print statements conditioned on a verbosity level set by the argument parsing module I was using. -- https://mail.python.org/mailman/listinfo/python-list
Re: What should go to stdout/stderr and why Python logging write everything to stderr?
> On Jan 3, 2023, at 10:38 AM, c.bu...@posteo.jp wrote: > Hello, > > this posting isn't about asking for a technical solution. My intention > is to understand the design decision Python's core developers made in > context of that topic. > > The logging module write everything to stderr no matter which logging > level is used. > > The argparse module does it more differentiated. If arguments are > mandatory but none are given then argparse produce a short version of > the usage info; on stderr. If the user request the usage info via "-h" > it goes to stdout. This is the behavior I would expect. > > Why does logging behave different? DEBUG and INFO imho should go to > stdout not stderr. > > Of course I could modify the handlers etc. to workaround this. But I > assume that there was something in mind of the Python developers when > they decided that. > > My goal is not to divide between the use of print() or logging.info() > in my own code. This would mess up a lot. > -- > https://mail.python.org/mailman/listinfo/python-list My thought are, that a “Log” should be a COMPLETE output of what is logged. Logged messages are NOT intended to be a message to the current user, but for a post operation analysis. Remember, a message sent by logging.info may never be seen, as that level of logging may be turned off. (You are providing ways to control how much is being set to the log, especially if going to the “screen”). As such, stderr is a often better spot to send the log than stdout, as the program may well be using stdout to interact with the user, and you don’t want the interaction cluttered with the logging. Also, I am fairly sure you can configure the logger to do what you want by just configuring two different logging handlers, one for stderr that does just errors, and one for stdout that shows all messages. If you don’t want the errors on stderr and stdout, just log the errors to a different logger which is on an error.* hierarchy and don’t let that hierarchy propagate up to the root logger. -- https://mail.python.org/mailman/listinfo/python-list
Re: Nonuniform PRNG?
On 12/7/22 2:37 PM, David Lowry-Duda wrote: On Wed, Dec 07, 2022 at 03:28:47PM -0300, Sabrina Almodóvar wrote: As far as I know, the state-of-the-art in statistical tests against PRNGs is the TestU01 library, available at http://simul.iro.umontreal.ca/testu01/tu01.html I'm familiar with this type of test. But as far as I can tell and have seen, these tests only tst against *uniform* PRNGs. I am not aware of any written tests against nonuniform PRNGs. I suspect it would be possible to mirror a lot of the ideas. For example, one common PRNG statistical test is to make many of matrices of various sizes and to study the ranks of these matrices. Presumably one could do a similar statistical analysis against what would be expected for any particular probability distribution. Running a candidate PRNG through this test will produce some sort of distribution, after all. But it would be much nicer if work on statistical tests against nonuniform PRNGs had already been done somewhere. The big problem is there are MANY variations of nonuniform random numbers, and all the variations lead to different statistics to test against. Most of the test can probably apply, but the new test criteria would need to be computed based on computing the exected results and expected variation in that result, largely based on various cross correlations of the numbers. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: How to make a variable's late binding crosses the module boundary?
On 8/27/22 7:42 AM, Mark Bourne wrote: Jach Feng wrote: I have two files: test.py and test2.py --test.py-- x = 2 def foo(): print(x) foo() x = 3 foo() --test2.py-- from test import * x = 4 foo() - Run test.py under Winows8.1, I get the expected result: e:\MyDocument>py test.py 2 3 But when run test2.py, the result is not my expected 2,3,4:-( e:\MyDocument>py test2.py 2 3 3 What to do? `from test import *` does not link the names in `test2` to those in `test`. It just binds objects bound to names in `test` to the same names in `test2`. A bit like doing: import test x = test.x foo = test.foo del test Subsequently assigning a different object to `x` in one module does not affect the object assigned to `x` in the other module. So `x = 4` in `test2.py` does not affect the object assigned to `x` in `test.py` - that's still `3`. If you want to do that, you need to import `test` and assign to `test.x`, for example: import test test.x = 4 test.foo() Yes, fundamental issue is that the statement from x import y makes a binding in this module to the object CURRECTLY bound to x.y to the name y, but if x.y gets rebound, this module does not track the changes. You can mutate the object x.y and see the changes, but not rebind it. If you need to see rebindings, you can't use the "from x import y" form, or at a minimum do it as: import x from x import y then later to get rebindings to x.y do a y = x.y to rebind to the current x.y object. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Trying to understand nested loops
On 8/6/22 8:12 AM, Chris Angelico wrote: On Sat, 6 Aug 2022 at 22:08, Richard Damon wrote: On 8/6/22 12:01 AM, Chris Angelico wrote: On Sat, 6 Aug 2022 at 13:54, Dan Stromberg wrote: On Fri, Aug 5, 2022 at 12:54 PM Grant Edwards wrote: In C, this doesn't do what it looks like it's supposed to do. if (foo) do_this(); and_this(); then_do_this(); It's been quite a while since I used C, but with the right compiler flag(s), I think this may be a thing of the past when compiling with gcc: https://developers.redhat.com/blog/2016/02/26/gcc-6-wmisleading-indentation-vs-goto-fail Ah yes, because compiler warnings are always viewed and acted upon. Have you ever watched the compilation of a large open-source project, done using the project's own build system and therefore the team's preferred warning settings? It's normal to have such a spew of warnings that you can't find anything interesting, or to have new warnings in new versions of GCC be utterly useless for the same reason. ChrisA You make it so you HAVE to fix the warning by adding the option to make warnings into errors. This does mean that you need to fix all the warnings that don't actually mean anything, Good code shouldn't generate many warnings, either you have warnings enabled that you don't care about, or your code is doing things you have told the complier you shouldn't do. I say again: have you ever watched the compilation of a large open-source project? You cannot turn warnings into errors, because there are ALWAYS warnings. Maybe, once upon a time, the policy was to ensure that there were no warnings on any major compiler; but times change, compilers add new warnings, new compilers join the club, and it becomes practically impossible to prevent warnings. Which, in turn, makes all warnings basically meaningless. Hmm. I don't think I've ever compiled gcc from source. Maybe I should do that, just to see whether gcc itself compiles with no warnings under gcc. ChrisA And for any project, that is a choice THEY made. For projects where code quality is actually a defined metric, there is normally a specified warning level (for a specified set of compilers and versions) that the code needs to compile at least nearly clean at. Yes, you can get that ton of warnings when at a higher warning level, but that is why you specify the warning level to use, and put the specific mitigations/suppressions for the few cases where the code is correct, but generates that warning. Yes, you can get a lot of warnings with another compiler, but that is because you aren't running at the correct warning level for that compiler, which is why the set of compilers that you are "warning free" on is specified. When you add a new compiler, it may first not be warning free until you make the effort (if you ever do) to make it warning free for that. Major open source projects will have a "toll gate" on the official repository that checks that additions keep the code to the standard it has established, -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Trying to understand nested loops
On 8/6/22 12:01 AM, Chris Angelico wrote: On Sat, 6 Aug 2022 at 13:54, Dan Stromberg wrote: On Fri, Aug 5, 2022 at 12:54 PM Grant Edwards wrote: In C, this doesn't do what it looks like it's supposed to do. if (foo) do_this(); and_this(); then_do_this(); It's been quite a while since I used C, but with the right compiler flag(s), I think this may be a thing of the past when compiling with gcc: https://developers.redhat.com/blog/2016/02/26/gcc-6-wmisleading-indentation-vs-goto-fail Ah yes, because compiler warnings are always viewed and acted upon. Have you ever watched the compilation of a large open-source project, done using the project's own build system and therefore the team's preferred warning settings? It's normal to have such a spew of warnings that you can't find anything interesting, or to have new warnings in new versions of GCC be utterly useless for the same reason. ChrisA You make it so you HAVE to fix the warning by adding the option to make warnings into errors. This does mean that you need to fix all the warnings that don't actually mean anything, Good code shouldn't generate many warnings, either you have warnings enabled that you don't care about, or your code is doing things you have told the complier you shouldn't do. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Subtract n months from datetime
On 6/21/22 12:29 AM, Paulo da Silva wrote: Hi! I implemented a part of a script to subtract n months from datetime. Basically I subtracted n%12 from year and n//12 from the month adding 12 months when it goes<=0. Then used try when converting to datetime again. So, if the day is for example 31 for a 30 days month it raises a ValuError exception. Then I subtract 1 to day and repeat. The code seems too naive and very very complicated! What is the best way to achieve this? Any existent module? At the very end, what I want is to subtract nx where x can be y, m, w, d for respectively years, months, weeks or days. I feel I am missing something here ... Thanks. Paulo The biggest issue with "subtracting months" is getting the right definition of what you mean by that, especially in the corner cases, once that is established, programming it is fairly easy. The problem is that a month isn't a fixed unit of time, but is a period anywhere from 28 to 31 days. (you get the same problem for years, but the difference is more special case, the presence or absent of Feb 29th.) The normal definition of this operation has the strange property that if you subtract a month, then add a month, you sometimes don't get back to the same day as you started with. Also subtracting one month, and then subtracting another month might get you a different day than subtracting 2 months at once (Think of Mar 31st). In short, this sort of date operation IS hard, and application specific, so while there may be pre-built modules that have this operation, you need to see if it uses a compatible definition of what you want. One alternative, which breaks other expectations, is to think of a month as 30 or 30.5 (so 2 months are 61 days) days, and add that. It says that often a month later than a given day isn't the same day of the month, but does make some operations less surprising. (This is hard to do to a date expressed as year-month-day, but trivial in some other formats like a timestamp.) -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Automatic Gain Control in Python?
From your description, your fundamental problem is you are trying to automatically "control" things that weren't designed to be automatically controlled in the way you are attempting. The smart speaker assumes the "user" will adjust the volume either with the controls or with verbal commands, So things will be a bit "clunky" in your results as you command the smart speaker volume level. Yes, you have an automated system that does most of what you want, but it is based on pieces not designed to be automated in this way, and you are running into the limitations caused by that. Yes, you could split the aux-out to bring it into another computer to listen to the sound level, and then using a sound input package get samples of what is playing, and analyze that data to get an average volume, and then issues the command to adjust the volume level. What you seem to be missing is that you could get the podcasts from a browser, and all a browser is is a program. It isn't that much work to write a rudimentary browser in python, especially if you don't actually need to display the results to a user, but are only trying to automate a particular task. You seem to feel strongly invested in your current code base, which is understandable, but it seems you have reached a point where you don't want to live with the limitations CAUSED by that system. Yes, there is likely a way to tack on another layer of "stuff" to adjust for this issue, but it likely is going to require some real programming. It may well be the design I am suggesting, of writing a program to fetch the podcast and save it requires a bit more work to get to the level you currently are at, but the results are a system that is actually designed to be controlled by automation. Maybe it is beyond you ability, but then so might the programming to get the volume. I will also add, that the way your describe going to your "community" gives me questions if this is a violation of copyright. Maybe it is something you can "Get away with", but I am not sure what you are doing is actually legitimate. On 5/29/22 1:09 AM, Steve GS wrote: You really need to understand what I am trying to do. It is not a simple lesson in use of podcasts. This is an automated system. I call it my NPR Jukebox. 15 years ago, I started with hourly URL calls to a browser to record specific NPR programs. It took a lot of coordination. I had to use IE because I needed to start and stop browsers on the hour and IE was the only one that could do that. Then web sites started "upgrading" to Edge. Through some trickery I was able to get Edge to do what IE did but it was unstable. I then discovered the Echo Smart Speaker. I set my program to announce the broadcast station or podcast by speaker to the smart speaker and it cured a lot of headaches. I then was able to call podcasts because the Echo handles them through TuneIn. Unfortunately, not all broadcasts ae available as podcasts. I am not here diddling around just playing podcasts. Let me repeat what I have already said. It is an automated system. Every hour for 48 hours on every weekend, my system using a well-developed Excel/VBA program that vocally talks to the SS hourly. The SS finds the audio and sends it to my Audacity recorder on another computer through aux-out to mic-in cable. The selections of audio are also transmitted to the community at the time of recording That part of the system is almost flawless, well compared to that I had before. Although the quality, tone, and timing of the announcement, the SS still gets confused once in a while and goes silent for the hour. I need to detect this too. Ok, now back to the original question. Podcasts and broadcasts apparently do not use the Dolby tone to balance the audio levels. And I receive highly fluctuating levels of audio. Sometimes it is between sides of a conversation, sometimes it is the podcast vs station identifications, then it is great differences between one web site and another. Then there's the differences with male and female voices. Imagine that you are watching TV late night then the commercials COME IN AT FULL BLAST. The technology of the industry grew up with male voices and apparently sees no reason to adjust for female. I have worked with audio systems and making recordings for more years that I want to admit. All I want is software to detect level changes over time and attempt to equalize them. It has to be work between the SS and the recorder and is to be checking all the time. The code is to: Listen to the audio level for about 10 seconds or so and raise or lower the level in small increments. It has nothing to do with understanding how to grab podcasts. The system is working very well for that. Footnote: “What rhymes with orange?” “No, it doesn’t..” -Original Message- From: Richard Damon On Behalf Of Richard
Re: Automatic Gain Control in Python?
On 5/28/22 5:29 PM, Steve GS wrote: I have an extensive Excel/VBA program that hourly calls and plays podcasts through a "smart" speaker. The output of the speaker feeds into another computer that records the m\audio using Audacity. It has become obvious that NPR does not regulate volumes for podcasts and broadcasts nor are programs in themselves regulated by volume. Audacity does not have an AGC. It has also been noted that Excel/VBA code cannot see the audio being played on the same computer. I would like to find code that will regulate the volume and give some semblance of control/moderation. Also, sometimes the Smart Speaker fails to play the program and I get an hour of silence before the next command to play happens. The code should detect that nothing is playing and send the command to the smart speaker again. Is there any Python code that I might be able to call from VBA that will monitor and regulate the volume of the audio? A few samples of code that can read/modify the audio will help me develop the final product. Suggestions appreciated. My first thought is you are solving the wrong problem. What seems a better option would be to get your code to actually connect up to the podcast and just download the audio directly, rather than trying to get the smart speaker to play the audio and record it with a microphone. That might require finding the API for the site that hosts the podcasts, to get it to send the files to you to "play". Once you have the files, it becomes simple signal processing to go over the files and AGCing them as needed. On a side note, make sure you are within your rights within Copyright law for what you are doing. Recording for PERSONAL use is probably within the bounds of "Fair Use", but the material is surely under Copyright, so be careful what you do with it. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: struggle to upgrade pip on visual studio code
On 4/22/22 6:11 AM, Tola Oj wrote: hello, i successfully installed openpyxl but it is saying this about my pip: WARNING: You are using pip version 22.0.2; however, version 22.0.4 is available.You should consider upgrading via the 'C:\Program Files\Python310\python.exe -m pip install --upgrade pip' command. And then when I try to upgrade using 'C:\Program Files\Python310\python.exe -m pip install --upgrade pip command it says this: C:\Program : The term 'C:\Program' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. At line:1 char:1 + C:\Program Files\Python310\python.exe -m pip install --upgrade pip+ ~~ + CategoryInfo : ObjectNotFound: (C:\Program:String) [], Comma ndNotFoundException + FullyQualifiedErrorId : CommandNotFoundException please what do I do? When a program name/path includes spaces, you need to put the whole name in quotes, like "C:\Program Files\Python310\python.exe" -m pip install --upgrade Now, if python is on your path (and 3.10 is the first python found), you should be able to simpify that to python -m pip install --upgrade -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: No shortcut Icon on Desktop
On 4/14/22 2:42 PM, Mirko via Python-list wrote: Am 13.04.2022 um 20:39 schrieb Dennis Lee Bieber: On Thu, 14 Apr 2022 03:38:11 +1000, Tim Deke declaimed the following: Dear Sir, I have successfully downloaded Python into my laptop but the shortcut icon is not appearing on the desktop. I am using Windows 10 with the PC specifications as per snap shot attached below. Can you advise what to do? Thank you Tim Deke Python normally does not create "shortcut icon"s -- one downloads an The Python Windows installer *absolutely* should. I do not know much about (modern) Windows, but one thing I do know is, that most Windows users are confused when after an installation there is no easy way to call the program. I do not understand, why the Windows installer *still* does not create a "Python 3.10" _*or similar*_ folder on the desktop with links to IDLE (with an icon text describing it properly as a Python Editor/IDE), the CHM and some introduction text in it. installer (which on my system would be saved in %userprofile%\downloads), and executes the installer (once). Python is not an all-in-one GUI development environment (ie; it is not something like Lazarus/FreePascal, Visual Studio, etc.). It is an interpreter for script files and depending upon how the installer sets up the environment, one may never need to directly invoke the Python interpreter -- one just invokes .py script files and the OS activates the correct interpreter. With all due respect, but do you really think that it is useful for a Python beginner to know how to run the bare interpreter? ;-) Wouldn't it be much better to educate them about IDLE which can be found in the "Startmenu"? I think the issue is that the 'python' interpreter/compiler isn't the sort of program that makes sense to make a desktop icon for, as it is a command line utility. Perhaps making an icon for IDLE, if it has also been installed, but then the issue becomes would people recognize 'IDLE' as 'Python' to click on. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: C is it always faster than nump?
On 2/25/22 2:47 PM, Chris Angelico wrote: On Sat, 26 Feb 2022 at 05:49, Richard Damon wrote: On 2/25/22 4:12 AM, BELAHCENE Abdelkader wrote: Hi, a lot of people think that C (or C++) is faster than python, yes I agree, but I think that's not the case with numpy, I believe numpy is faster than C, at least in some cases. My understanding is that numpy is written in C, so for it to be faster than C, you are saying that C is faster that C. Fortran actually, but ultimately, they both get compiled to machine code. Looking at the Github repo I see: Languages: Python. 62.5% C 35.3% C++. 1.0% Cython. 0.9% Shell. 0.2% Fortran. 0.1% So there is a bit of Fortan in there, but it looks like most of the heavy lifting is in C. My guess is the Fortran is likely some hooks to add Fortran modules into the program with numpy. ... The key point is that numpy was written by skilled programmers who carefully optimized their code to be as fast as possible for the major cases. Thus it is quite possible for the numpy code to be faster in C than code written by a person without that level of care and effort. This is clearly true. ChrisA -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: C is it always faster than nump?
On 2/25/22 4:12 AM, BELAHCENE Abdelkader wrote: Hi, a lot of people think that C (or C++) is faster than python, yes I agree, but I think that's not the case with numpy, I believe numpy is faster than C, at least in some cases. My understanding is that numpy is written in C, so for it to be faster than C, you are saying that C is faster that C. The key point is that numpy was written by skilled programmers who carefully optimized their code to be as fast as possible for the major cases. Thus it is quite possible for the numpy code to be faster in C than code written by a person without that level of care and effort. There are similar package available for many languages, including C/C++ to let mere mortals get efficient numerical processing. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: frozenset can be altered by |=
On 11/29/21 5:01 PM, Chris Angelico wrote: On Tue, Nov 30, 2021 at 8:55 AM Marco Sulla wrote: I must say that I'm reading the documentation now, and it's a bit confusing. In the docs, inplace operators as |= should not work. They are listed under the set-only functions and operators. But, as we saw, this is not completely true: they work but they don't mutate the original object. The same for += and *= that are listed under `list` only. Previously explained here: On Mon, 22 Nov 2021 at 14:59, Chris Angelico wrote: Yeah, it's a little confusing, but at the language level, something that doesn't support |= will implicitly support it using the expanded version: a |= b a = a | b and in the section above, you can see that frozensets DO support the Or operator. By not having specific behaviour on the |= operator, frozensets implicitly fall back on this default. The docs explicitly show that inplace operators are defined for the mutable set, and not defined for the immutable frozenset. Therefore, using an inplace operator on a frozenset uses the standard language behavior of using the binary operator, then reassigning back to the left operand. This is a language feature and applies to everything. You've seen it plenty of times with integers, and probably strings too. A frozenset behaves the same way that anything else does. ChrisA I suppose the question comes down to is it worth adding a reminder in the description of the inplace operators that if a type doesn't support the inplace operator, it is automatically converted into the equivalent assignment with the binary operator? -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: pyinstaller wrong classified as Windows virus
On 11/25/21 12:21 PM, Chris Angelico wrote: On Fri, Nov 26, 2021 at 4:18 AM 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. Are they really allowed to install your unsigned executables but are not allowed to install Python from a known and trusted source? If there's some bizarre loophole that allows them to run completely untrusted binary code, but not to run legitimate code that can be fetched from a variety of trusted places (including python.org, the Windows store, etc), then I'm afraid you're on your own, and will probably need to play around with the exact loophole to figure out what is going to be permitted. Alternatively, just go find the person who decides what gets installed, and request a Python interpreter to be added to the permitted list. That's probably easier, and it's certainly going to be better long-term. ChrisA My first guess is it isn't so much what is 'allowed' but what can be easily done. On a somewhat locked down computer, the user does not have admin rights, so needs to get 'IT' to run any installers that need admin permissions to run. And EXE that just needs to be copied to the computer and rhen just RUN, doesn't need IT to 'install' it (they just can't put it into Program Files, but that isn't really that important for programs that don't need an installer. Likely, just copying an EXE file from an outside source may still be against the rules (and needs approval), but some think if they can do it and no one complains, it must be ok. On the other hand, they may have given approval, knowing the source. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: on writing a while loop for rolling two dice
On 9/7/21 3:51 PM, Avi Gross via Python-list wrote: > and similarly changes any function imported directly > to also be fully qualified. One danger with this is that it can actual change the behavior of the program. Maybe more likely with global objects than functions, but still an issue. Remember, "from module import fun" will bind the name fun in this modules namespace to the current definiton of the object fun in the other modules name space. If after that point, something rebinds the name in the other module, the module that did the from import won't see that change, but if the reference is changed to module.fun, it will. Since that rebinding might even be some third module doing a 'monkey patch', detecting if it is safe is basically impossible. Admittedly, if this is an issue, the sensitivity to timing makes the difference something very fussy to exactly the order you do things, the cases where the difference is intended is likely fairly small. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: on floating-point numbers
> On Sep 5, 2021, at 6:22 PM, Peter J. Holzer wrote: > > On 2021-09-04 10:01:23 -0400, Richard Damon wrote: >>> On 9/4/21 9:40 AM, Hope Rouselle wrote: >>> Hm, I think I see what you're saying. You're saying multiplication and >>> division in IEEE 754 is perfectly safe --- so long as the numbers you >>> start with are accurately representable in IEEE 754 and assuming no >>> overflow or underflow would occur. (Addition and subtraction are not >>> safe.) >>> >> >> Addition and Subtraction are just as safe, as long as you stay within >> the precision limits. > > That depends a lot on what you call "safe", > > a * b / a will always be very close to b (unless there's an over- or > underflow), but a + b - a can be quite different from b. > > In general when analyzing a numerical algorithm you have to pay a lot > more attention to addition and subtraction than to multiplication and > division. > >hp > > -- Yes, it depends on your definition of safe. If ‘close’ is good enough then multiplication is probably safer as the problems are in more extreme cases. If EXACT is the question, addition tends to be better. To have any chance, the numbers need to be somewhat low ‘precision’, which means the need to avoid arbitrary decimals. Once past that, as long as the numbers are of roughly the same magnitude, and are the sort of numbers you are apt to just write, you can tend to add a lot of them before you get enough bits to accumulate to have a problem. With multiplication, every multiply roughly adds the number of bits of precision, so you quickly run out, and one divide will have a chance to just end the process. Remember, the question came up because the sum was’t associative because of fractional bits. That points to thinking of exact operations, and addition does better at that. -- https://mail.python.org/mailman/listinfo/python-list
Re: on floating-point numbers
On 9/4/21 9:40 AM, Hope Rouselle wrote:
> Chris Angelico writes:
>
>> On Fri, Sep 3, 2021 at 4:58 AM Hope Rouselle wrote:
>>>
>>> Hope Rouselle writes:
>>>
Just sharing a case of floating-point numbers. Nothing needed to be
solved or to be figured out. Just bringing up conversation.
(*) An introduction to me
I don't understand floating-point numbers from the inside out, but I do
know how to work with base 2 and scientific notation. So the idea of
expressing a number as
mantissa * base^{power}
is not foreign to me. (If that helps you to perhaps instruct me on
what's going on here.)
(*) A presentation of the behavior
>>> import sys
>>> sys.version
'3.8.10 (tags/v3.8.10:3d8993a, May 3 2021, 11:48:03) [MSC v.1928 64
bit (AMD64)]'
>>> ls = [7.23, 8.41, 6.15, 2.31, 7.73, 7.77]
>>> sum(ls)
39.594
>>> ls = [8.41, 6.15, 2.31, 7.73, 7.77, 7.23]
>>> sum(ls)
39.61
All I did was to take the first number, 7.23, and move it to the last
position in the list. (So we have a violation of the commutativity of
addition.)
>>>
>>> Suppose these numbers are prices in dollar, never going beyond cents.
>>> Would it be safe to multiply each one of them by 100 and therefore work
>>> with cents only? For instance
>>
>> Yes and no. It absolutely *is* safe to always work with cents, but to
>> do that, you have to be consistent: ALWAYS work with cents, never with
>> floating point dollars.
>>
>> (Or whatever other unit you choose to use. Most currencies have a
>> smallest-normally-used-unit, with other currency units (where present)
>> being whole number multiples of that minimal unit. Only in forex do
>> you need to concern yourself with fractional cents or fractional yen.)
>>
>> But multiplying a set of floats by 100 won't necessarily solve your
>> problem; you may have already fallen victim to the flaw of assuming
>> that the numbers are represented accurately.
>
> Hang on a second. I see it's always safe to work with cents, but I'm
> only confident to say that when one gives me cents to start with. In
> other words, if one gives me integers from the start. (Because then, of
> course, I don't even have floats to worry about.) If I'm given 1.17,
> say, I am not confident that I could turn this number into 117 by
> multiplying it by 100. And that was the question. Can I always
> multiply such IEEE 754 dollar amounts by 100?
>
> Considering your last paragraph above, I should say: if one gives me an
> accurate floating-point representation, can I assume a multiplication of
> it by 100 remains accurately representable in IEEE 754?
>
Multiplication by 100 might not be accurate if the number you are
starting with is close to the limit of precision, because 100 is
1.1001 x 64 so multiplying by 100 adds about 5 more 'bits' to the
representation of the number. In your case, the numbers are well below
that point.
>>> --8<---cut here---start->8---
>> ls = [7.23, 8.41, 6.15, 2.31, 7.73, 7.77]
>> sum(map(lambda x: int(x*100), ls)) / 100
>>> 39.6
>>>
>> ls = [8.41, 6.15, 2.31, 7.73, 7.77, 7.23]
>> sum(map(lambda x: int(x*100), ls)) / 100
>>> 39.6
>>> --8<---cut here---end--->8---
>>>
>>> Or multiplication by 100 isn't quite ``safe'' to do with floating-point
>>> numbers either? (It worked in this case.)
>>
>> You're multiplying and then truncating, which risks a round-down
>> error. Try adding a half onto them first:
>>
>> int(x * 100 + 0.5)
>>
>> But that's still not a perfect guarantee. Far safer would be to
>> consider monetary values to be a different type of value, not just a
>> raw number. For instance, the value $7.23 could be stored internally
>> as the integer 723, but you also know that it's a value in USD, not a
>> simple scalar. It makes perfect sense to add USD+USD, it makes perfect
>> sense to multiply USD*scalar, but it doesn't make sense to multiply
>> USD*USD.
>
> Because of the units? That would be USD squared? (Nice analysis.)
>
>>> I suppose that if I multiply it by a power of two, that would be an
>>> operation that I can be sure will not bring about any precision loss
>>> with floating-point numbers. Do you agree?
>>
>> Assuming you're nowhere near 2**53, yes, that would be safe. But so
>> would multiplying by a power of five. The problem isn't precision loss
>> from the multiplication - the problem is that your input numbers
>> aren't what you think they are. That number 7.23, for instance, is
>> really
>
> Hm, I think I see what you're saying. You're saying multiplication and
> division in IEEE 754 is perfectly safe --- so long as the numbers you
> start with are accurately representable in IEEE 754 and assuming no
> overflow or underflow would occur. (Addition and subtraction are not
> safe.)
>
Addition and Subtraction are
Re: configargparse - reading option from config only
On 8/27/21 3:37 AM, Loris Bennett wrote: > Richard Damon writes: > >> On 8/26/21 6:01 AM, Loris Bennett wrote: >>> Hi, >>> >>> When using configargparse, it seems that if a value is to be read from a >>> config file, it also has to be defined as a command-line argument in >>> order to turn up as an attribute in the parser namespace. >>> >>> I can sort of see why this is the case, but there are also some options >>> I would like to read just from the config file and not have them >>> available as command-line options. This would be, say, to prevent the >>> number of options on the command-line from becoming bloated by >>> little-used settings. >>> >>> Is there an elegant way to do this? >>> >>> Cheers, >>> >>> Loris >>> >> Look at the read() member function to supply the file name to read. Then >> in the config object there will be sections for each section in the >> config file. No need for any of these to be 'options' > Do you have a link for this? As far as I can see, the config files are > given in the following manner: > > p = > configargparse.ArgParser(default_config_files=['/etc/app/conf.d/*.conf', > '~/.my_settings']) > > I can obviously just read the config file with configparser, but the > idea of configargparse is that an option can be specified as an option, > in a config file, or as an environment variable, > > As far as I can tell, configargparse only loads entries from the config > file into the appropriate namespace if they have also been defined as > long options (i.e. with '--'). I was hoping to access *all* the config > file entries, regardless of whether they are also options, since the > config is obviously being read. > > Cheers, > > Loris > I misread your question, I thought you were talking about configparse. Question is, if configargparse doesn't do what you want, then it isn't the right tool. It looks like configargparse is SPECIFICALLY designed to allow the use to use a file as a shorthand to present command line arguements. The whole parsing structure is based on an enumerated set of options, if that isn't what you have, it is the wrong tool. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: configargparse - reading option from config only
On 8/26/21 6:01 AM, Loris Bennett wrote: > Hi, > > When using configargparse, it seems that if a value is to be read from a > config file, it also has to be defined as a command-line argument in > order to turn up as an attribute in the parser namespace. > > I can sort of see why this is the case, but there are also some options > I would like to read just from the config file and not have them > available as command-line options. This would be, say, to prevent the > number of options on the command-line from becoming bloated by > little-used settings. > > Is there an elegant way to do this? > > Cheers, > > Loris > Look at the read() member function to supply the file name to read. Then in the config object there will be sections for each section in the config file. No need for any of these to be 'options' -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: what to do with multiple BOMs
By the rules of Unicode, that character, if not the very first character of the file, should be treated as a “zero-width non-breaking space”, it is NOT a BOM character there. It’s presence in the files is almost certainly an error, and being caused by broken software or software processing files in a manner that it wasn’t designed for. > On Aug 19, 2021, at 1:48 PM, Robin Becker wrote: > > Channeling unicode text experts and xml people: > > I have xml entity with initial bytes ff fe ff fe which the file command says > is > UTF-16, little-endian text. > > I agree, but what should be done about the additional BOM. > > A test output made many years ago seems to keep the extra BOM. The xml > context is > > > xml file 014.xml > > > ]> > > the entitity file 014.ent is bombomdata > > b'\xff\xfe\xff\xfed\x00a\x00t\x00a\x00' > > The old saved test output of processing is > > b'\xef\xbb\xbfdata' > > which implies seems as though the extra BOM in the entity has been kept and > processed into a different BOM meaning utf8. > > I think the test file is wrong and that multiple BOM chars in the entiry > should have been removed. > > Am I right? > -- > Robin Becker > > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: optimization of rule-based model on discrete variables
On 6/13/21 12:15 PM, Elena via Python-list wrote:
> Hi, I have, say 10 variables (x1 ... x10) which can assume discrete finite
> values, for instance [0,1 or 2].
> I need to build a set of rules, such as:
>
> 1) if x1==0 and x2==1 and x10==2 then y = 1
> 2) if x2==1 and x3==1 and x4==2 and x6==0 then y = 0
> 3) if x2==0 and x3==1 then y = 2
> 4) if x6==0 and x7==2 then y = 0
> ...
> ...
> (actually it can be seen as a decision tree classifier).
>
> y can assume the same discrete value [0,1 or 2]
> I don't know a-priori anything about the number of rules and the
> combinations of the tested inputs.
>
> Given a dataset of X={(x1... x10)} I can calculate Y=f(X) where f is this
> rule-based function.
>
> I know an operator g that can calculate a real value from Y: e = g(Y)
> g is too complex to be written analytically.
>
> I would like to find a set of rules f able to minimize e on X.
>
> I know the problem can become NP-hard, but I would be fine also with a
> suboptimal solution.
>
> What's the best way to approach the problem?
> In case, does something already exist in python?
>
>
> thank you
My first feeling is that this doesn't have a lot of structure to do a
lot of optimizations, and just brute forcing might be the answer.
Of course, one option is just sort the rules by Y, then iterate through
the rules and see if any data matches, for that putting the dataset into
something like an SQLite database with indexes on the various X columns
might work (with 10 columns, the 45 indexes on each column pair might
make things reasonably efficient.)
The biggest gain would happen if you could look at the rule set and find
patterns in it. The big question is making sure that the rule set covers
every value in the data array, and never gives one input value two
different y values.
--
Richard Damon
--
https://mail.python.org/mailman/listinfo/python-list
Re: learning python ...
On 5/25/21 12:08 AM, hw wrote: > > Are all names references? When I pass a name as a parameter to a > function, does the object the name is referring to, when altered by > the function, still appear altered after the function has returned? I > wouldn't expect that ... If you mutate the object the parameter was bound to, the calling function will see the changed object. (This requires the object to BE mutateable, like a list, not an int) If you rebind that parameter to a new object, the calling function doesn't see the change, as its name wasn't rebound. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Unexpected Inheritance Problem
On 5/20/21 1:58 AM, Chris Angelico wrote: > On Thu, May 20, 2021 at 2:02 PM Richard Damon > wrote: >> Given the following definition of classes, I am getting an unexpected >> error of : >> >> TypeError: __init__() missing 2 required keyword-only arguments: >> 'idcode' and 'tag' >> >> On the call to create a GedcomHead in the call to GedcomHead() in >> Gedcom0Tag.add() >> >> class Gedcom0Tag(GedcomTag): >> """Represents a Level 0 Tag of a GEDCOM file""" >> >> @classmethod >> def add(cls, *, parent, tag: str, payload: str, level=0): >> >> Gedcom0Tag.add(parent, 'Head', '') >> > You're defining that add takes keyword-only args (because the asterisk > stops them from being passed positionally), but then you're calling it > with nothing but positional args. Is that the code you're using? I > would expect to see *three* missing kwonly args from this. > > ChrisA The last line wasn't copied but distiled from the rest of the code to simplify the segment. The actual code had the parameters named in the call. Peter found the error with too many underscores on init. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Unexpected Inheritance Problem
On 5/20/21 3:24 AM, Peter Otten wrote: > On 20/05/2021 06:00, Richard Damon wrote: > >> class GedcomHead(Gedcom0Tag): >> """GEDCOM 0 HEAD tag""" >> def ___init___(self, *, parent): > > An __init__ with three underscores; you must me joking ;) > Yes, that is what I was missing, too many underscores there, so GedcomHead didn't have an __init__ so it inherited inherited from it from its base with the wrong signature. Thank you. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Unexpected Inheritance Problem
Given the following definition of classes, I am getting an unexpected error of : TypeError: __init__() missing 2 required keyword-only arguments: 'idcode' and 'tag' On the call to create a GedcomHead in the call to GedcomHead() in Gedcom0Tag.add() Code: class GedcomTag: """Represents a Level of a Gedcom file""" def __init__(self, parent: 'GedcomTag', level: int, tag: str, payload: Optional[str]): pass class Gedcom0Tag(GedcomTag): """Represents a Level 0 Tag of a GEDCOM file""" def __init__(self, *, parent, idcode: Optional[str], tag: str): super().__init__(parent=parent, level=0, tag=tag, payload=idcode) @classmethod def add(cls, *, parent, tag: str, payload: str, level=0): """Add Tag based on text""" if tag == 'HEAD': data = GedcomHead(parent=parent) elif tag == 'TRLR': data = GedcomTRLR(parent=parent) else: data = Gedcom0Tag(idcode=tag, tag=payload, parent=parent) return data class GedcomHead(Gedcom0Tag): """GEDCOM 0 HEAD tag""" def ___init___(self, *, parent): super().__init__(parent=parent, idcode=None, tag="HEAD") Gedcom0Tag.add(parent, 'Head', '') Note: GedcomHead.__init__() doesn't have these parameters, somehow it seems be requiring the parameters for the __init__ call of the base class too, even though there is a call to it through the super().__init__() Is this expected? Can derived classes not provide values for parameters to construct the base classes? Is there something funny because I am making the call from a member of that base class? -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: for the installation of pycharm
On 5/8/21 10:49 AM, mishrasamir2...@gmail.com wrote: >Sir/madam, > >Please provide me the latest version of pycharm quickly. > >Samir Mishra You just need to go to the jetbrains web site and it is available there. They even have a free version there. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Disconnect comp.lang.python from python-list
On 5/6/21 9:44 AM, Jon Ribbens via Python-list wrote: > On 2021-05-06, Richard Damon wrote: >> On 5/6/21 6:12 AM, Jon Ribbens via Python-list wrote: >>> I think you're fundamentally missing the point that the newsgroup is >>> *already gatewayed to the mailing list*. Marking the group moderated >>> will not result in any more work for the moderators. In fact what you >>> say above is the opposite of the truth, as it will result in the link >>> between the poster and the moderators becoming more direct, not less >>> direct. >> It will. > How? How would switching from a bi-directional gateway to a moderated > group make any more work for anyone than the existing bi-directional > gateway to an unmoderated group? > >> First, python-list@python.org is NOT a "Moderated" mailing list by the >> standard definition of such. Maybe you could call it Moderatable, but >> most messages make it to the list without any intervention by a >> moderator. > Sounds like nearly all moderated lists/forums then. Then perhaps you have never been on a real Moderated mailing list or Forum. Lists/Forum when described as moderated normally means that a human eyeball looks at EVERY (or almost every) message before it goes public. >> The Mailman software that runs the list allows the administrators of >> the list to put select filters on posts, or to make certain posters >> moderated and need their posts reviewed, but most posts go through >> automatically and immediately. This works because the SMTP Email >> system have a must better presumption of the From address in the >> message actually being who the sender is then under NNTP rules. > The SMTP mail system makes no such assumption whatsoever. Maybe not be the absolute letter of the rules, but it does in practice. Especially if a person intends for their messages to be able to be delivered to most mail servers. At the very least, the email envelope will have an apparently valid email address, or most email systems will refuse it. Protocols like SPF will verify that the message does come from who it says, or at least there is a responsible party that will deal with things, or that whole domain get put into block lists. Email from 'known senders' tends to be reliably marked, and you need to subscribe to the list and become a 'known sender'. Once you have gone through the NNTP gateway, you lose all of that. >> Forging it is detectable in many cases and generally a violation of >> the TOS for most providers (and the ones that don't can easily be >> blocked). > Sounds a lot like Usenet then. Many Usenet providers do NOT require users to use valid email address as their From (You can't subscribe such an address to the mailing list to be able to post from it). They might prohibit explicitly forging someone else's email address, but Nym Shifiting is common and accepted on Usenet (SOME providers might limit it, but not all) >> While you could setup a robo-moderator to do a similar thing, Usenet >> posters will not have 'pre-subscribed' before posting, and the From >> address is no where near as relaible as invalid From addresses ARE >> allowed, and since the message comes via a NNTP injection source relay, >> non-verifiable. This make the job a LOT harder. > It makes essentially no difference at all. It sure does. Have you every actually TRIED to run a moderated Usenet group, or know anyone who has, especially a somewhat busy group? >> The current setup does put rules at the gateway that controls what gets >> onto the mailing list, and because it IS a gateway, there are easier >> grounds to establish that some posts just won't be gated over from >> usenet to the mailing list. Putting those same limits onto the moderated >> group itself would be against Usenet norms. This would mean that the >> Usenet moderation queue WILL require significant additional work over >> what is currently being done for the mailing list. > Could you explain what on earth you are on about here please? I am presuming that the current gateway isn't bringing all the messages from Usenet into the mailing list. This is obvious as we don't see the noise here. The Cabal that runs the 'Big-8' doesn't really care what sort of filters are added at such a gateway. To setup a moderated group that defines similar filters in place for messages getting to Usenet, particularly for a group intended to replace a 'reasonably' working unmoderated group, is likely not going to be viewed well. In the old days of actual voting for new groups, just saying you intended to do such got you a lot of negative votes. Not sayng you are going to do it, and then doing it, might get the Big-8 > >> If the idea is just to provide a NNTP accessible version of the mailing &
Re: Proposal: Disconnect comp.lang.python from python-list
On 5/6/21 9:12 AM, Jon Ribbens via Python-list wrote: > On 2021-05-06, Skip Montanaro wrote: >>> Are you unaware that the group is already gatewayed to a moderated >>> mailing list for which all of that work is already done? >> What is this moderation of which you speak? I'm one of the Python >> postmasters (I maintain the SpamBayes setup) and am aware of a >> multi-part tool chain (black hole lists, SpamBayes, greylisting, etc), >> but not of human moderation on a grand scale, just of the relatively >> few posts which are held for the admins/moderators by SpamBayes. My >> definition of "moderation" is that a human vets every post. > That's not a definition that anyone else would use, I think, > and I say that as a moderator of a Usenet group.. > >> That's certainly not the case for python-list@python.org. Posts gated >> from comp.lang.python to the mailing list only get passed through >> SpamBayes. All other elements of the tool chain occur ahead of the >> gateway. >> >> If we are using two different definitions of "moderation" I think it >> is important to be clear what we mean. > Are you saying that the messages that appear occasionally from people > such as Ethan Furman claiming to be moderators and alleging that > particular people have been banned or suspended are lies? And that the > message I received once saying that my comp.lang.python post had been > rejected from the list was also a lie? No, as I mentioned in my other post. a "Moderated Mailing List" is generally described as one which EVERY message is hand reviewed by a person, and alloweed onto the list. python-list is NOT such a list. One advantage of mediums like mailing lists, is that it is quite easy to setup methods where all the mail goes through a gatekeeper, and it automatically approves most messages, but a limited number of messages get held to be reviewed. This is generally NOT described as a Moderated List. Usenet being a distributed system, doesn't support this model. Either anybody can inject a message from wherever they are, no all messages are sent to be reviewed, the unmoderated and moderated is a VERY sharp line. In Usenet terms, lists like this would be described as loosely robo-moderated. And it works a lot better for mailing lists than for Usenet groups due to different rules about From: identification of messages. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Disconnect comp.lang.python from python-list
On 5/6/21 6:12 AM, Jon Ribbens via Python-list wrote: > On 2021-05-06, Richard Damon wrote: >> On 5/5/21 10:44 PM, Jon Ribbens via Python-list wrote: >>> On 2021-05-06, Richard Damon wrote: >>>> As someone with a long usenet background, converting the existing group >>>> to moderated would be practically impossible. It just isn't done. It >>>> would need to be a new group created with the .moderated tag. The >>>> problem is that some servers won't change and getting things mixed like >>>> that just creates propagation problems, so it just isn't done. >>> As someone with a longer usenet background, it can be done, and there >>> isn't any great reason not to do so in this case. But I did already >>> suggest creating a new moderated group instead if people feel that's >>> better. >> Not so sure you are longer than me, I started on usenet is the late 80s >> with dial up. > Yes, me too ;-) > >>> Are you unaware that the group is already gatewayed to a moderated >>> mailing list for which all of that work is already done? The only >>> difference is that currently that good work is then wasted and thrown >>> away from the point of view of the group participants. >> The big difference is that the mailing list directly gets its email from >> the senders, and that was totally over SMTP so some From: verification >> is possible, thus it make sense to let email addresses be validated for >> whitelisting. Submissions from the moderated group have lost all >> traceability to the original sender when it get forwarded via the NNTP >> transportation link, so such a white list might not be as viable, and on >> usenet many people intentionally post without valid From addresses, so a >> LOT more messages will end up in the moderation queue, so more work for >> the moderators. > I think you're fundamentally missing the point that the newsgroup is > *already gatewayed to the mailing list*. Marking the group moderated > will not result in any more work for the moderators. In fact what you > say above is the opposite of the truth, as it will result in the link > between the poster and the moderators becoming more direct, not less > direct. It will. First, python-list@python.org is NOT a "Moderated" mailing list by the standard definition of such. Maybe you could call it Moderatable, but most messages make it to the list without any intervention by a moderator. The Mailman software that runs the list allows the administrators of the list to put select filters on posts, or to make certain posters moderated and need their posts reviewed, but most posts go through automatically and immediately. This works because the SMTP Email system have a must better presumption of the From address in the message actually being who the sender is then under NNTP rules. Forging it is detectable in many cases and generally a violation of the TOS for most providers (and the ones that don't can easily be blocked). While you could setup a robo-moderator to do a similar thing, Usenet posters will not have 'pre-subscribed' before posting, and the From address is no where near as relaible as invalid From addresses ARE allowed, and since the message comes via a NNTP injection source relay, non-verifiable. This make the job a LOT harder. The current setup does put rules at the gateway that controls what gets onto the mailing list, and because it IS a gateway, there are easier grounds to establish that some posts just won't be gated over from usenet to the mailing list. Putting those same limits onto the moderated group itself would be against Usenet norms. This would mean that the Usenet moderation queue WILL require significant additional work over what is currently being done for the mailing list. If the idea is just to provide a NNTP accessible version of the mailing list, than perhaps rather than a comp.* group, putting it on gmane would be a viable option, that avoids some of the Usenet issues. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Disconnect comp.lang.python from python-list
On 5/5/21 10:44 PM, Jon Ribbens via Python-list wrote: > On 2021-05-06, Richard Damon wrote: >> On 5/5/21 9:40 PM, Jon Ribbens via Python-list wrote: >>> On 2021-05-06, Paul Bryan wrote: >>>> What's involved in moderating c.l.p? Would there be volunteers willing >>>> to do so? >>> Nothing at all is involved, apart from changing the status of the group. >>> The moderation would be done by the same people, in the same way, as the >>> moderation of the list is done now. They wouldn't need to do any work >>> they don't already do. >> As someone with a long usenet background, converting the existing group >> to moderated would be practically impossible. It just isn't done. It >> would need to be a new group created with the .moderated tag. The >> problem is that some servers won't change and getting things mixed like >> that just creates propagation problems, so it just isn't done. > As someone with a longer usenet background, it can be done, and there > isn't any great reason not to do so in this case. But I did already > suggest creating a new moderated group instead if people feel that's > better. Not so sure you are longer than me, I started on usenet is the late 80s with dial up. Yes, there have been a few successful conversions, but it is a lot of work, and there may be too many servers that don't really care that might get it wrong (google groups is one that could easily not care if they break things, they have already broken comp.lang.c++ > >> Basically, some machine would need to be designated to get all the >> submissions to the group, emailed to it, and people would need to log >> into the email account on that computer to approve all the posts, or a >> robot could perhaps be setup to auto-approve most based on some rules. > Are you unaware that the group is already gatewayed to a moderated > mailing list for which all of that work is already done? The only > difference is that currently that good work is then wasted and thrown > away from the point of view of the group participants. The big difference is that the mailing list directly gets its email from the senders, and that was totally over SMTP so some From: verification is possible, thus it make sense to let email addresses be validated for whitelisting. Submissions from the moderated group have lost all traceability to the original sender when it get forwarded via the NNTP transportation link, so such a white list might not be as viable, and on usenet many people intentionally post without valid From addresses, so a LOT more messages will end up in the moderation queue, so more work for the moderators. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Disconnect comp.lang.python from python-list
On 5/5/21 9:40 PM, Jon Ribbens via Python-list wrote: > On 2021-05-06, Paul Bryan wrote: >> What's involved in moderating c.l.p? Would there be volunteers willing >> to do so? > Nothing at all is involved, apart from changing the status of the group. > The moderation would be done by the same people, in the same way, as the > moderation of the list is done now. They wouldn't need to do any work > they don't already do. As someone with a long usenet background, converting the existing group to moderated would be practically impossible. It just isn't done. It would need to be a new group created with the .moderated tag. The problem is that some servers won't change and getting things mixed like that just creates propagation problems, so it just isn't done. Basically, some machine would need to be designated to get all the submissions to the group, emailed to it, and people would need to log into the email account on that computer to approve all the posts, or a robot could perhaps be setup to auto-approve most based on some rules. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: A 35mm film camera represented in Python object
On 4/1/21 6:41 PM, 2qdxy4rzwzuui...@potatochowder.com wrote: > On 2021-04-01 at 18:10:46 -0400, > Richard Damon wrote: > >> On 4/1/21 5:47 PM, D.M. Procida wrote: >>> D.M. Procida wrote: >>> >>>> Hi everyone, I've created <https://github.com/evildmp/C-is-for-Camera> - >>>> a representation of a Canonet G-III QL17 in Python. >>>> >>>> There's also documentation: <https://c-is-for-camera.readthedocs.io>. >>>> >>>> It's a pure Python model of the physical sub-systems of a camera and >>>> their interactions. So far it's at a fairly high level - I haven't yet >>>> got down to the level of individual springs and levers yet. >>> I'm now working on the exposure system, which in the published version >>> so far just models inputs and outputs of the system as a whole. I want >>> to start to model its functionality by modelling the interactions of its >>> components - the levers, cams and so on. >>> >>> It seems to me I have fundamentally two approaches that I could take: >>> >>> The first is to model the movement of each lever as a series of discrete >>> steps (hundreds of tiny steps, to maintain accuracy). Pro: it models >>> movement through physical positions; con: it's ugly that it breaks >>> continuous movement into arbitrary steps. >>> >>> The second is not to move each lever in such detail, but to consider its >>> interactions: given the state of each of the other parts of the system, >>> what *would* be the outcome if something were to try to move the lever >>> from such-and-such a position to another? Pro: it feels more elegant >>> than the brute-force stepping of the alternative; con: it also feels >>> like a bit of a cheat. >>> >>> But neither approach really captures for me the interaction of moving >>> analog components, which in the case of this camera also have some >>> circular logic to them - the movement of A determines that of B which >>> determines that of C which determines that of D which finally also >>> affects the movement of A. >>> >>> Any thoughts or wise ideas? >>> >>> Daniele >> If you keep track of the positions as a floating point number, the >> precision will be more than you could actually measure it. > I won't disagree with Richard, although I will give you a general > warning about floating point rounding issues: if you do, in fact, end > up with your first solution and lots and lots (millions? billions? > more?) of discrete calculations, be aware that what looks like a lot of > precision in the beginning may not be all that precise (or accurate) in > the end. > > Also, doesn't the overall motion of the camera as a whole also depend on > external factors, such as whether/how it's mounted or handheld, the > nature of the "ground" (e.g., soft wet sand vs. hard concrete > vs. someone standing on a boat in the water), an experienced > photographer "squeezing" the shutter release vs. a newbie "pressing the > button"? I can think of plenty of variables; I guess it depends on what > you're trying to model and how accurate you intend to be (or not to be). Actually, I would contend that due to all the factors that you can't take into account accurately makes the use of floating point more applicable. Yes, you need to realize that just because the value has many digits, you KNOW that is only an approximation, and you process accordingly, knowing you just has an approximation. The real question comes, what is the purpose of the simulation? You can NEVER simulate everything, and some parts of 'simulating' requires actual hardware to interact with. Sometimes the real thing is the best simulation available. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: A 35mm film camera represented in Python object
On 4/1/21 5:47 PM, D.M. Procida wrote: > D.M. Procida wrote: > >> Hi everyone, I've created <https://github.com/evildmp/C-is-for-Camera> - >> a representation of a Canonet G-III QL17 in Python. >> >> There's also documentation: <https://c-is-for-camera.readthedocs.io>. >> >> It's a pure Python model of the physical sub-systems of a camera and >> their interactions. So far it's at a fairly high level - I haven't yet >> got down to the level of individual springs and levers yet. > I'm now working on the exposure system, which in the published version > so far just models inputs and outputs of the system as a whole. I want > to start to model its functionality by modelling the interactions of its > components - the levers, cams and so on. > > It seems to me I have fundamentally two approaches that I could take: > > The first is to model the movement of each lever as a series of discrete > steps (hundreds of tiny steps, to maintain accuracy). Pro: it models > movement through physical positions; con: it's ugly that it breaks > continuous movement into arbitrary steps. > > The second is not to move each lever in such detail, but to consider its > interactions: given the state of each of the other parts of the system, > what *would* be the outcome if something were to try to move the lever > from such-and-such a position to another? Pro: it feels more elegant > than the brute-force stepping of the alternative; con: it also feels > like a bit of a cheat. > > But neither approach really captures for me the interaction of moving > analog components, which in the case of this camera also have some > circular logic to them - the movement of A determines that of B which > determines that of C which determines that of D which finally also > affects the movement of A. > > Any thoughts or wise ideas? > > Daniele If you keep track of the positions as a floating point number, the precision will be more than you could actually measure it. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: .title() - annoying mistake
On 3/22/21 4:20 PM, Christian Gollwitzer wrote: > Am 22.03.21 um 16:03 schrieb Robert Latest: >> Chris Angelico wrote: >>> Cool thing is, nobody in Python needs to maintain anything here. >> >> That's great because I'm actually having trouble with sending log >> messages over >> the socket conection you helped me with, would you mind having a look? > > You misunderstood the "here". > > (native German as well, but I think it means "for keeping .title() up > to date) > > I agree with Chris that .title() can be useful for "title-casing" a > single character, whatever that means. It should be documented, > though, that it is not suitable to title-case a string, not even in > English. > > Christian Part of the difficulty in getting clear documentation for this is that is it IS somewhat complicated. You title-case a string by Title-casing the first character of each word (and the primary issue error that started this was the definition of a 'word'), and lower casing the rest of the word. The complication comes in that title-casing a character 99.99% of the time doesn't give you a character in title-case, but more often in upper-case (or uncased). There are apparently only 31 actual characters that are 'Title-Case'. Thus the action of 'title-casing' a character is a bit strange to describe, especially to people used to simple languages which don't have any of the characters that cause the issue. We don't seem to have a problme that upper doesn't always return a true 'upper-case', like for '1' because we realize that many character don't have case, so it gets largly just assumed we know that. For title case, the fact that almost all characters do NOT have a 'title-case' form makes things a bit more awkward. Yes, perhaps the documentation could be made a bit more clear. I do note that the documentation for str.capitalize() does talk about using actual title case characters if the first character is a digraph. Something like that might make sense in the description of str.title() Note, that str.istitle() doesn't actually check if the character is a real 'title case' character, but that the string follows a rule similar to what str.title() produces. I am not positive that its description exactly matches what .title() produces, but it close, and the way it is written, "Python's".istitle() is False, as the s at the end needs to be uppper case to satisfy as ' is uncased, so the next cased character must be upper case. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: .title() - annoying mistake
On 3/21/21 10:28 PM, Chris Angelico wrote:
> On Mon, Mar 22, 2021 at 12:26 PM Richard Damon
> wrote:
>> On 3/21/21 7:31 PM, MRAB wrote:
>>> On 2021-03-21 22:30, Chris Angelico wrote:
>>>> On Mon, Mar 22, 2021 at 9:04 AM Grant Edwards
>>>> wrote:
>>>>> On 2021-03-21, Chris Angelico wrote:
>>>>>> On Mon, Mar 22, 2021 at 2:16 AM Robert Latest via Python-list
>>>>> wrote:
>>>>>>> I wonder if .title() properly capitalizes titles in any language.
>>>>> It doesn't in
>>>>>>> English (nor does it purport to), so it begs the question why it
>>>>> is there in
>>>>>>> the first place. German and Spanish don't have any special
>>>>> capitalization rules
>>>>>>> for titles; I don't know about any other languages.
>>>>>>>
>>>>>> It correctly title-cases a single character, as has been pointed out
>>>>>> already.
>>>>> Not according to the docs. The doc states that .title() converts the
>>>>> first character characger in each "word" to _upper_ case. Is the doc
>>>>> wrong?
>>>>>
>>>>> If you want titlecase, then you should call str.capitalize() which
>>>>> (again according to the doc) converts the first character to _title_
>>>>> case (starting in v3.8).
>>>>>
>>>> Hmm, maybe it's different in 3.10, but the docs I'm seeing look fine.
>>>> But maybe there's a better way to word it for both of them.
>>>>
>>> Python 3.9.2 (tags/v3.9.2:1a79785, Feb 19 2021, 13:44:55) [MSC v.1928
>>> 64 bit (AMD64)] on win32
>>> Type "help", "copyright", "credits" or "license" for more information.
>>>>>> help(str.title)
>>> Help on method_descriptor:
>>>
>>> title(self, /)
>>> Return a version of the string where each word is titlecased.
>>>
>>> More specifically, words start with uppercased characters and all
>>> remaining
>>> cased characters have lower case.
>>>
>>> '\N{LATIN CAPITAL LETTER DZ}', '\N{LATIN SMALL LETTER DZ}' and
>>> '\N{LATIN CAPITAL LETTER D WITH SMALL LETTER Z}' are all digraphs, so
>>> is it correct to say that .title() uppercases the first character?
>>> Kind of.
>> I think the clarification calling them upper cased characters is close
>> enough considering that there are only 31 title cased characters, all
>> digraphs.
>>
> But it's wrong, and it would lead people to the exact error of
> thinking that it's the same as upper() on str[0] and lower() on the
> rest.
>
> ChrisA
If it didn't mention that it was generating a 'titlecase' that could be
an argument, but since for 99.99% of characters Title Casing is
identical to upper case (and that character IS called the upper case),
but for the 31 listed digraphs, it means the titlecase version of that
digraph where the first 'letter' in the digraph is like the upper case
of its equivalent, and the second 'letter' in the digraph is like the
lower case of its equivalent.
Basically, titlecasing a word IS making the first letter upper case and
the rest lower case UNLESS the first letter is on of the 31 digraphs
which have a special titlecase version, then that is used for the first
letter. That gets pretty wordy for an explanation string.
--
Richard Damon
--
https://mail.python.org/mailman/listinfo/python-list
Re: .title() - annoying mistake
On 3/21/21 7:31 PM, MRAB wrote:
> On 2021-03-21 22:30, Chris Angelico wrote:
>> On Mon, Mar 22, 2021 at 9:04 AM Grant Edwards
>> wrote:
>>>
>>> On 2021-03-21, Chris Angelico wrote:
>>> > On Mon, Mar 22, 2021 at 2:16 AM Robert Latest via Python-list
>>> wrote:
>>> >
>>> >> I wonder if .title() properly capitalizes titles in any language.
>>> It doesn't in
>>> >> English (nor does it purport to), so it begs the question why it
>>> is there in
>>> >> the first place. German and Spanish don't have any special
>>> capitalization rules
>>> >> for titles; I don't know about any other languages.
>>> >>
>>> >
>>> > It correctly title-cases a single character, as has been pointed out
>>> > already.
>>>
>>> Not according to the docs. The doc states that .title() converts the
>>> first character characger in each "word" to _upper_ case. Is the doc
>>> wrong?
>>>
>>> If you want titlecase, then you should call str.capitalize() which
>>> (again according to the doc) converts the first character to _title_
>>> case (starting in v3.8).
>>>
>>
>> Hmm, maybe it's different in 3.10, but the docs I'm seeing look fine.
>> But maybe there's a better way to word it for both of them.
>>
> Python 3.9.2 (tags/v3.9.2:1a79785, Feb 19 2021, 13:44:55) [MSC v.1928
> 64 bit (AMD64)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
>>>> help(str.title)
> Help on method_descriptor:
>
> title(self, /)
> Return a version of the string where each word is titlecased.
>
> More specifically, words start with uppercased characters and all
> remaining
> cased characters have lower case.
>
> '\N{LATIN CAPITAL LETTER DZ}', '\N{LATIN SMALL LETTER DZ}' and
> '\N{LATIN CAPITAL LETTER D WITH SMALL LETTER Z}' are all digraphs, so
> is it correct to say that .title() uppercases the first character?
> Kind of.
I think the clarification calling them upper cased characters is close
enough considering that there are only 31 title cased characters, all
digraphs.
--
Richard Damon
--
https://mail.python.org/mailman/listinfo/python-list
Re: .title() - annoying mistake
On 3/21/21 2:39 PM, Benjamin Schollnick wrote: >> I agree with everything you say. Especially the open source part. But >> wouldn't >> you agree that .title() with all its arbitrary specificity to appear in the >> very core of a general purpose language is quite an oddity? > No, because it book ends the issue. > > Upper - Converts everything to uppercase > Lower - Converts everything to lowercase > > Title - Covers the cases in-between upper/lower. > > I’ll agree that if title was to respect language definitions, that there > would be a problem here… But it specifically states otherwise. > > And as I mentioned the sheer amount of work that would be needed would > probably cover a phd dissertation or more… It’s a huge problem set to > respect one language, let alone all languages. > > So the only answer is to not respect the languages, and leave that up to a > later implementation or for someone else to assist in adding in support. > > Heck, how do we prevent it from titlecasing abbreviations? (This is plain > text not XML…. If it was XML it would be easy!) > > - Benjamin One important thing to remember is that there ARE a few characters that are themselves 'Title case', so we can't live with just upper and lower. These all are 'digraphs', i.e. look like two letters, but this glyph does act as a single character for many purposes. One example that has been given is Dz which is different than Dz. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: .title() - annoying mistake
On 3/21/21 8:19 AM, Albert-Jan Roskam wrote:
>On 20 Mar 2021 23:47, Cameron Simpson wrote:
>
> On 20Mar2021 12:53, Sibylle Koczian wrote:
> >Am 20.03.2021 um 09:34 schrieb Alan Bawden:
> >>The real reason Python strings support a .title() method is surely
> >>because Unicode supports upper, lower, _and_ title case letters, and
> >>tells you how to map between them. [...]
> >>
> >But that's exactly what he's doing, with a result which is documented,
> >but not really satisfactory.
>
>
>This would be a good
>start:
> https://apastyle.apa.org/style-grammar-guidelines/capitalization/title-case
>It could be locale-dependent. What I also don't like about .title() is
>that it messes up abbreviations ("Oecd")
The built in title() function is basically an intentionally 80%
solution. It handles the simple cases simply, and if you might have the
more complicated cases, you have to handle that yourself because to
specify what the 'right' answer would be is basically impossible to do
in general (because there are conflicting definitions, and some things
require context beyond what just its input provides).
--
Richard Damon
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why assert is not a function?
On 3/12/21 8:58 AM, Chris Angelico wrote: > On Sat, Mar 13, 2021 at 12:11 AM Richard Damon > wrote: >> On 3/12/21 12:31 AM, Chris Angelico wrote: >>> On Fri, Mar 12, 2021 at 3:53 PM Cameron Simpson wrote: >>>> For me, try/except is for when something might reasonably "go wrong" in >>>> normal use, even niche normal use. Whereas assert is for things which >>>> should _never_ occur. Roughly, again for me, try/except if for catching >>>> misuse and assert is for catching misdesign/misimplementation. >>> Something like that, yeah. An assertion failure represents a bug *in >>> this code*, something that shouldn't ever happen. If it's possible to >>> trigger the failure with some other piece of code (calling something >>> with bad arguments, or whatever), then assert is the wrong tool for >>> the job. Similarly, if you find yourself catching AssertionError >>> anywhere outside of unit testing, something is horribly wrong >>> somewhere :) >>> >>> ChrisA >> Chris, I would disagree with that statement. An assert says that there >> is something wrong with THE code, not THIS code. It is perfectly >> reasonable, and good defensive programming, to assert on the >> per-conditions to the procedure at its beginning. >> >> Now, it may be true that a 'friendlier' procedure may be defined to >> check some of these and return an error, but that then locks that >> behavior into the API, so the cost of the check becomes an absolute >> requirement. >> > It's perfectly reasonable to put "if condition: raise Blah", but is it > really reasonable to use the assert statement, which (a) might not be > run, and (b) raises a very generic exception? Make assertions about > your own code, not other people's. > > ChrisA My issue with that is that I feel that if the program raises an exception, if SHOULD document what exceptions it raises and under what conditions. That means that the detection of bad parameters has now been moved from being an 'improper' use of the module, to being defined to be checked for, and thus now a required part of the API. Exceptions are designed for errors that might be correctable by outer layers, program errors that you catch with assert tend not to fall into that category. Asserts indicate that there is a programming error that has been detected, and the operation should be aborted. The exception generated will not be used to 'correct' the error, but might reformat the assert message and facilitate its reporting, or for an interactive program, perhaps provide a path for the user to save his work or work around the program bug. The are conceptually very different sorts of things, and should not be interchanged. Note, it is often hard to tell if the 'impossible' state you ended up in is truly a fault with your own code or the code that is calling you, so often the detecting of bad parameters is really akin to detecting your routine has gotten into a state it should not be in, the only difference is you have detected this before you have done anything, and thus help locate where the bug is. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Why assert is not a function?
On 3/12/21 12:31 AM, Chris Angelico wrote: > On Fri, Mar 12, 2021 at 3:53 PM Cameron Simpson wrote: >> For me, try/except is for when something might reasonably "go wrong" in >> normal use, even niche normal use. Whereas assert is for things which >> should _never_ occur. Roughly, again for me, try/except if for catching >> misuse and assert is for catching misdesign/misimplementation. > Something like that, yeah. An assertion failure represents a bug *in > this code*, something that shouldn't ever happen. If it's possible to > trigger the failure with some other piece of code (calling something > with bad arguments, or whatever), then assert is the wrong tool for > the job. Similarly, if you find yourself catching AssertionError > anywhere outside of unit testing, something is horribly wrong > somewhere :) > > ChrisA Chris, I would disagree with that statement. An assert says that there is something wrong with THE code, not THIS code. It is perfectly reasonable, and good defensive programming, to assert on the per-conditions to the procedure at its beginning. Now, it may be true that a 'friendlier' procedure may be defined to check some of these and return an error, but that then locks that behavior into the API, so the cost of the check becomes an absolute requirement. In langauges like C, the assert for this may be more important because the language provides more opportunity for 'undefined behavior'. It is reasonable to skip the input assert if it becomes too expensive for benefit it provides, or if something else will catch the error. This likely actually applies to a lot of Python code, so it may seem that it doesn't apply. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Button placement
On 3/9/21 6:24 AM, Bischoop wrote: > On 2021-03-09, Peter Otten <__pete...@web.de> wrote: >> On 09/03/2021 03:08, Bischoop wrote: >>> I try for a while place the top button in a a middle of column=0 with >>> span to column2 below so the button being centered to those, >> I'm not sure what you mean, do you perhaps need columnspan=3? >> >> > You were sure :-) > columnspan=3 helped, I didn't know that I can apply it to 3 when not > having column=3, was trying just with columnspan=2 but as you know it > didn't do the job. I was swearing when fighting with it with padding lol. > > -- > Thanks One thing to remember is that span is sort of like range, range(3) is [0, 1, 2] -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: How to implement logging for an imported module?
On 3/8/21 4:16 AM, Robert Latest via Python-list wrote: > Joseph L. Casale wrote: >>> I couldn't find any information on how to implement logging in a library >>> that >>> doesn't know the name of the application that uses it. How is that done? >> That's not how it works, it is the opposite. You need to know the name of its >> logger, and since you imported it, you do. > [much snipping] > >> Last word of advice, don't fight it by hacking up or patching (somehow?), it >> will simply not work right for any other case even slightly different than >> the one you somehow beat into submission. > I didn't waht to hack the logging system, it's just that I wasn't sure of its > design principles. I had hoped that if I set up a logger (including levels and > formatter) in my main app, the loggers in the imported modules would somwhow > automagically follow suit. Now I understand that for each imported module I > must import its logger, too, and decide how to deal with its messages. > > Each instance of the logger inherents from a 'parent' logger, except for the top level logger which has the name None (as in the singleton of NoneType), and unless told otherwise will inherit it properties from its parent. Thus, if you get the root logger with logging.getLogger() you can set properties there, and unless a child logger has specifical been told not to inherit or has been specifically given a different value. General convention is that modules will use their name as the name of their logger, as that is generally unique. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Tkinter long-running window freezes
On 2/24/21 6:35 AM, John O'Hagan wrote: > Hi list > > I have a 3.9 tkinter interface that displays data from an arbitrary > number of threads, each of which runs for an arbitrary period of time. > A frame opens in the root window when each thread starts and closes > when it stops. Widgets in the frame and the root window control the > thread and how the data is displayed. > > This works well for several hours, but over time the root window > becomes unresponsive and eventually freezes and goes grey. No error > messages are produced in the terminal. > > Here is some minimal, non-threaded code that reproduces the problem on > my system (Xfce4 on Debian testing): > > from tkinter import * > from random import randint > > root = Tk() > > def display(label): > label.destroy() > label = Label(text=randint(0, 9)) > label.pack() > root.after(100, display, label) > > display(Label()) > mainloop() > > This opens a tiny window that displays a random digit on a new label > every .1 second. (Obviously I could do this by updating the text rather > than recreating the label, but my real application has to destroy > widgets and create new ones). > > This works for 3-4 hours, but eventually the window freezes. > > The process uses about 26 Mb of memory at first, and this gradually > increases to around 30 or so by the time it freezes. > > Any ideas what could be causing this, or even how to approach debugging > or workarounds? > > Thanks > > -- > > John One thought is that repeatedly destroying and recreating a label might be leaking a resource. One option would be to change the code to just update the label rather than recreating it each time. Simplest is probably to link the Label to a StringVar instead of a fixed text and updating the variable to change the text. You can also (I believe) go into the Label and change the text it has with a configuration call. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 2.7 and 3.9
On 2/16/21 4:16 PM, Ethan Furman wrote: > Kevin, please reply to the list (preferably Reply-to-list, or > Reply-all), that way others can chime in with help. > > On 2/16/21 12:55 PM, Kevin M. Wilson wrote: > >> Windows 7 OS, and typically run in conjunction with testing SSD', as >> for stand alone scripts. >> Those require: python BogusFile.py. I too was expecting users to >> type: python my_Script.py! > > I'm afraid I have no experience with the above, hopefully somebody > else on the list does. > > -- > ~Ethan~ It depends a lot on how everything was installed and how the path was setup. You will at least need the version 2 and version 3 pythons to be given different names, like python3 and then start the python 3 scripts with python3 my_script.py -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: learning python building 2nd app, need advices
On 1/8/21 6:10 PM, pascal z via Python-list wrote: > any way to attach a file because I loose indentation? Don't post via googlegroups, it thinks the world is HTML, which treats spaces in a funny matter. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: tkinter: creating/attaching menubar to top level window
On 1/8/21 4:47 PM, Rich Shepard wrote: > I'm using Chapter 9 in Mark Roseman's "Modern Tkinter for Busy Python > Developers" to learn how to write a top level menu. MWE code is attached. > > Python3 tells me there's invalid syntax on line 42: > self.['menu'] = menubar # attach it to the top level window > ^ > yet that's the syntax he prints on page 84 (and has in the book's code > supplement). > > Why am I getting an invalid syntax error here? > > TIA, > > Rich Because it is the wrong syntax. It could be either: self.menu = menubar or self['menu'] = menubar -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: dayofyear is not great when going into a new year
On 1/5/21 8:02 PM, Mats Wichmann wrote:
> On 1/5/21 4:04 PM, Chris Angelico wrote:
>> On Wed, Jan 6, 2021 at 10:01 AM Eli the Bearded
>> <*@eli.users.panix.com> wrote:
>>>
>>> In comp.lang.python, Chris Angelico wrote:
>>>> There are multiple definitions for "day of year", depending on how you
>>>> want to handle certain oddities. The simplest is to identify Jan 1st
>>>> as 1, Jan 2nd as 2, etc, to Dec 31st as either 365 or 366; but some
>>>> libraries will define the year as starting with the week that contains
>>>> the Thursday, or something, and then will define days of year
>>>> accordingly.
>>>
>>> That sounds like some weird off-shoot of the ISO-8601 calendar. That
>>> document primarily concerns itself with weeks. Week 1 of a year is the
>>> first week with a Thursday in it. The last week of a year will be
>>> either
>>> 52 or 53, and you can have things like days in January belonging to the
>>> week of the previous year.
>>
>> The "weird off-shoot" part is probably a result of me misremembering
>> things, so don't read too much into the details :) I just remember
>> coming across something that numbered days within a year in a way that
>> was consistent with the way that it numbered weeks, which would indeed
>> have been based on the ISO 8601 week numbering. Not 100% sure of the
>> exact details.
>
> "workweeks" has always been fun, ISO standard or not, there's been a
> variation for ages since people don't seem to always follow ISO for
> that. I spent over a decade at a place that lived and died by their
> WorkWeek references ("due WW22" or the like would appear in every
> status report ever written, and there were zillions of those) - and it
> didn't agree with ISO on whether WW1 was the week that contained Jan 1
> or whether it was the week that followed the previous year's last
> workweek. After all, those few days can't actually belong to two
> different workweeks, now can they? :)
>
> (that was not a good memory you guys brought back :) )
I'm reminded of a video made describing 'ISO Weeks' that was put out on
Dec 30, 2019, which was the first day of the ISO week bsed 2020, and he
ended it with a comment that if 2019 wasn't going so well, you could
always just use ISO to get an early start on 2020.
Apparently a lot of people were getting this recommended a number of
months later, and people were commenting how that line just was not
aging well. And we couldn't use that te get out of 2020, as 2020 is a
long year, and ISO 2021 didn't start until Jan 4th.
--
Richard Damon
--
https://mail.python.org/mailman/listinfo/python-list
Re: A random word from one of two lists
On 1/3/21 12:38 PM, Mats Wichmann wrote: > On 1/3/21 5:30 AM, Bischoop wrote: >> On 2021-01-02, Stefan Ram wrote: >>> Bischoop writes: >>>> On 2021-01-02, Stefan Ram wrote: >>>>> Otherweise, I'd go this way without a dictionary. >>>>> import random >>>>> animal = ['koala', 'kangaroo'] >>>>> fruit = ['banana', 'apple'] >>>>> kinds = [animal,fruit] >>>>> kind = random.choice( kinds ) >>>>> result = random.choice( kind ) >>>>> print( result ) >>>> I had that solution in mind but I thought that one is not good >>>> programming style or not Pythonin :-) >>> >>> I do not see any stylistic problem when you use this approach >>> with "nested lists". List indexing by a number should even be >>> faster than indexing a dictionary. >>> >>> >> Now I know that's ok, seems I was ovethingking while solution was so >> simply. >> >> -- >> Thanks >> > > You don't really need to do this as a two-level selection: > > import random > animal = ['koala', 'kangaroo'] > fruit = ['banana', 'apple'] > result = random.choice(animal + fruit) > print(result) It depends on what distribution of results you want. Since the example had two equal length list is doesn't matter, but if, say, there were many more animals then fruit, your method would produce an animal more often than a fruit, but the two level method will make the distribution 50% fruits, 50% animals independent on the number in each category. Which is the right answer is problem specific. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: A random word from one of two lists
On 1/1/21 5:58 PM, Bischoop wrote:
> I have two lists *animal* and *fruit* and I try to get a random variable
> animal or fruit and then random word from that list.
> I thought that dictionary(*words*) could help me but no succes, the only way
> I've
> done partially what was with list *kinds* and by using two times
> random.choice. However print(kind) return me a list not a variable:
> animal or fruit so now I'm kinda confuse if I can achieve that.
>
>
>
> import random
> animal = ['koala', 'kangaroo']
> fruit = ['banana', 'apple']
> kinds = [animal,fruit]
> words = {'animals': animal, 'fruits': fruit}
>
>
> kind = random.choice(kinds)
> print(kind)
> word = random.choice(kind)
> print(word)
> #output:
> ['kolala', 'kangaroo']
> kangaroo
>
> --
> Thanks
random.choice doesn't return 'a variable' but an object. Which is the
same object that one of the variables that you used.
IF you wanted to use words, then you could have made kinds = {'animals',
'fruits'} and then looked up the list in words, but that is really just
more work (unless you want to know which list it came from)
Note that 'animals' isn't a variable, but a string value.
--
Richard Damon
--
https://mail.python.org/mailman/listinfo/python-list
Re: Which method to check if string index is queal to character.
On 12/28/20 8:02 PM, Chris Angelico wrote: > > Yes, many such regexes exist, and they are *all wrong*. Without > exception. I don't think it's actually possible for a regex to > perfectly match all (syntactically) valid email addresses and nothing > else. > > ChrisA Since Email addresses are allowed to have (comments) in them, and comments are allowed to nest, I think it takes something stronger than a regex to fully process them, but takes something that can handle a recursive grammar. I think that is the only thing that absolutely prevents using a regex (but not sure about it) but some of the rules will make things messy and need to use alternation and repetition. The one other thing that might block a regex is I think there is an upper limits to how long the address (or its parts) are allowed to be, and testing that at the same time as the other patterns is probably beyond what a regex could handle. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Which method to check if string index is queal to character.
On 12/28/20 4:52 PM, Michael Torrie wrote: > On 12/28/20 10:37 AM, Bischoop wrote: >> A valid email address consists of an email prefix and an email domain, >> both in acceptable formats. The prefix appears to the left of the @ symbol. >> The domain appears to the right of the @ symbol. >> For example, in the address exam...@mail.com, "example" is the email prefix, >> and "mail.com" is the email domain. > Seems so simple, yet at least half the web sites I try to use get it > wrong. There's an entire RFC on this topic. Drives me crazy when a web > site insists that myaddress+suf...@domain.com is not a valid address. > It certainly is! Yes, it really is fairly straight forward to do it right, but it does have details that need to be checked carefully (It is significantly harder if the email address can also contain comments or display names, but just a base email address isn't that hard). Many people do still get it wrong. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Which method to check if string index is queal to character.
On 12/28/20 3:08 PM, Mats Wichmann wrote: > On 12/28/20 10:46 AM, Marco Sulla wrote: >> On Mon, 28 Dec 2020 at 17:37, Bischoop wrote: >>> >>> I'd like to check if there's "@" in a string and wondering if any >>> method >>> is better/safer than others. I was told on one occasion that I should >>> use is than ==, so how would be on this example. >>> >>> s = 't...@mail.is' >> >> You could do simply >> >> if "@" in s: >> >> but probably what you really want is a regular expression. >> > > Will add that Yes, you should always validate your inputs, but No, the > presence of an @ sign in a text string is not sufficient to know it's > a valid email address. Unfortunately validating that is hard. > Validating that it meets the SYNTAX of an email address isn't THAT hard, but there are a number of edge cases to worry about. Validating that it is a working email address (presumably after verifying that it has a proper syntax) is much harder, and basically requires trying to send to the address, and to really confirm that it is good requires them to do something actively with a message you send them. And then nothing says the address will continue to be valid. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: tkinter global variable
On 11/13/20 12:12 PM, ChalaoAdda wrote: > On Fri, 13 Nov 2020 12:04:53 -0500, Richard Damon wrote: > >> On 11/13/20 11:42 AM, ChalaoAdda wrote: >>> On Fri, 13 Nov 2020 16:04:03 +, Stefan Ram wrote: >>> >>>> ChalaoAdda writes: >>>>> On Fri, 13 Nov 2020 15:41:20 +, Stefan Ram wrote: >>>>>> ChalaoAdda writes: >>>>>>> I am trying to read a file from askopenfilename outside the >>>>>>> function. >>>>>>> I am getting blank file name. What am I doing wrong? Here is my >>>>>>> code. >>>>>> It is possible that you try to read from "pic" before "on_openfile" >>>>>> ever was executed. >>>>> I didn't get you. I click on the menu item "Open" and then from the >>>>> filedialog select a file. And then outside that function I am trying >>>>> to read and print the file. >>>> I have added two additional statements to your source code: >>>> print( "A" ) and print( "B" ). >>>> >>>> If you now execute this new source code, you might observe that "B" >>>> is being printed before "A" is being printed. >>>> >>>> from tkinter import * >>>> from tkinter import filedialog >>>> >>>> def on_openfile(): >>>> print( "A" ) >>>> global pic pic = filedialog.askopenfilename() >>>> >>>> >>>> root = Tk() >>>> >>>> menubar = Menu(root) >>>> root.config(menu=menubar) >>>> file_menu = Menu(menubar) file_menu.add_command(label="Open", >>>> command=on_openfile) file_menu.add_command(label="Exit", >>>> command=root.destroy) >>>> menubar.add_cascade(label="File", menu=file_menu) >>>> >>>> >>>> print( "B" ) >>>> f = open(pic) >>>> print(f.read()) >>>> >>>> root.mainloop() >>> Ok. I got the point. So what do I need to do access the variable? How >>> do I return a value from that function? >>> >>> Thanks. >> The problem is that you are accessing the variable BEFORE the box has >> been put up and the user clicking on it. That doesn't happen until the >> mainloop() call. You need to delay the opening and reading of the file >> till the filedialog has been used and returned. >> >> Perhaps on_openfile could open and read the file. > Ok. Then how do I access the content of the file from outside the > function? How can I access return value? > Thanks. When you are using a menuing system like tkinter, you have to think about program structure differently. Note that YOU never called on_open in your code (at least not directly), so you can't really get to its return value. It actually gets called somewhere deep inside mainoop(), so you could access the value after that, but you won't get there until you issue the command inside tkinter to shut down the mainloop (your File / Exit), which is probably later than you want. Inside interfaces like this, you generally respond to things in the callbacks. Now, one other option is that rather than wait for the user to select the File / Open command, you could just call your on_openfile() function, which will pop up the dialog, wait for a response, and the set the answer, then you could use it, but then as I said, that question comes up before the user does the File / Open command. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: tkinter global variable
On 11/13/20 11:42 AM, ChalaoAdda wrote: > On Fri, 13 Nov 2020 16:04:03 +, Stefan Ram wrote: > >> ChalaoAdda writes: >>> On Fri, 13 Nov 2020 15:41:20 +, Stefan Ram wrote: >>>> ChalaoAdda writes: >>>>> I am trying to read a file from askopenfilename outside the function. >>>>> I am getting blank file name. What am I doing wrong? Here is my code. >>>> It is possible that you try to read from "pic" before "on_openfile" >>>> ever was executed. >>> I didn't get you. I click on the menu item "Open" and then from the >>> filedialog select a file. And then outside that function I am trying to >>> read and print the file. >> I have added two additional statements to your source code: >> print( "A" ) and print( "B" ). >> >> If you now execute this new source code, you might observe that "B" is >> being printed before "A" is being printed. >> >> from tkinter import * >> from tkinter import filedialog >> >> def on_openfile(): >> print( "A" ) >> global pic pic = filedialog.askopenfilename() >> >> >> root = Tk() >> >> menubar = Menu(root) >> root.config(menu=menubar) >> file_menu = Menu(menubar) file_menu.add_command(label="Open", >> command=on_openfile) file_menu.add_command(label="Exit", >> command=root.destroy) >> menubar.add_cascade(label="File", menu=file_menu) >> >> >> print( "B" ) >> f = open(pic) >> print(f.read()) >> >> root.mainloop() > Ok. I got the point. So what do I need to do access the variable? How do > I return a value from that function? > > Thanks. The problem is that you are accessing the variable BEFORE the box has been put up and the user clicking on it. That doesn't happen until the mainloop() call. You need to delay the opening and reading of the file till the filedialog has been used and returned. Perhaps on_openfile could open and read the file. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there a conflict of libraries here?
On 11/7/20 9:26 PM, Terry Reedy wrote: > On 11/6/2020 5:05 PM, Steve wrote: >> "Right, because the name "datetime" points to the class datetime in the >> module datetime. > > A module containing an object with the same name as the module is a > real pain, a constant mental papercut. I consider datetime.datetime > to be a design mistake*. You are the 2nd person in about a month to > post the same resulting code problem. > > * Either the class should have been 'Datetime', capitalized like > classes in modules other that builtins generally should be, or the > module should have been given a different name. I personally would > always rename the module when imported. > Which says that if you do: import datetime from datetime import datatime as Datatime you get the class in your module as the more modern capitalized name, and avoid the name conflict. It just says that in your code, to use the class you either need to use Datatime or datetime.datetime -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: What might cause my sample program to forget that already imported datetime?
On 10/12/20 7:20 AM, Chris Angelico wrote: > On Mon, Oct 12, 2020 at 9:58 PM Abdur-Rahmaan Janhangeer > wrote: >> Btw why a datetime in datetime? >> >> It causes much confusion. I dont know >> the design decision behind, if someone knows, it might be good to explain >> > There are quite a few modules that have one "most obvious" entrypoint, > and there's really no better name for either that thing or the module > it lives in. The pprint module has a pprint function, giving the same > phenomenon. > > This is yet another reason that "from MODULE import *" is a bad idea. > Instead, just import the module itself, and take whatever you need. > > ChrisA And if you don't like doing datetime.datatime all the time, you can also do from MODULE import SYMBOL and do from MODULE import SYMBOL as ALIAS when you get conflicts. The big issue is that you lose control with * as it pulls 'arbitrary' things into your name space. I do sometimes do things like the combination import MODULE from MODULE import SYMBOL if there is some name in the module I want to use a lot. I don't see much need for: import MODULE from MODULE import * as if you are bringing in ALL the names into the current module name space, when will you need to use the module.symbol notation? -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Help! I broke python 3.9 installation on macOS
On 10/8/20 7:31 PM, Elliott Roper wrote: > First problem: I can no longer say > Obfuscated@MyMac ~ % python3 pip -m list isn't that supposed to be python3 -m pip list -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Use of a variable in parent loop
On 9/27/20 4:42 PM, Christian Gollwitzer wrote:
> Am 26.09.20 um 06:43 schrieb Stephane Tougard:
>> ===PYTHON===
>> #!/usr/local/bin/python
>> if 4 == 4:
>> name = "Stephane"
>> print(name)
>> pass
>>
>> print("Out {}".format(name))
>>
>>
>> The exact same code in Python works fine, the variable name is used
>> outside of the if block even it has been declared inside.
>>
>> This does not look right to me.
>
> I'll try another way of explaining it. You seem to be confused that
> the scope of the variable assignment[*] continues after the if.
> However, look at this:
>
> def f():
> a=3
>
> f()
> a
>
> NameError
> Traceback (most recent call last)
> in ()
> > 1 a
>
> NameError: name 'a' is not defined
>
> So the "def f()" obviously introduces local scope, but control
> structures like if and while do not.
>
> Christian
>
>
> [*] In Python it's called "name binding", but it mostly works like
> variable assignment
Yes, functions and classes have a scope, control structures do not. If
control structures created a scope it would be ugly.
You do need to watch out about the difference between classical
'variables' and pythons name binding when you deal with mutable objects;
For example:
a = []
b = a
a.append(1)
print(b)
give [1] as a and b are bound to the same object, even though you want
to think of them as different variables.
--
Richard Damon
--
https://mail.python.org/mailman/listinfo/python-list
Re: Puzzling difference between lists and tuples
On 9/17/20 11:24 AM, William Pearson wrote:
> I am puzzled by the reason for this difference between lists and tuples.
>
> A list of with multiple strings can be reduced to a list with one string with
> the expected results:
>
> for n in ['first','second']:
> print n
>
> for n in ['first']:
> print n
>
> The first loop prints "first", "second", and the second prints "first".
>
>
>
> This is not true for a tuple:
>
> for n in ('first','second'):
> print n
>
> for n in ('first'):
> print n
>
>
> prints "first", "second" in the first case, but "f","i","r","s","t" in the
> second.
>
> Where is this inconsistency explained?
>
Parenthesis don't always make a tuple (and in fact aren't needed to make
them)
('first') is just the string value 'first', inside a set of parenthesis
to possible affect order of operations.
For 1 element tuples, you need a trailing comma, like ('first,) and in
many places it also could be just 'first',
just like your first example could be just for n in 'first', 'second':
--
Richard Damon
--
https://mail.python.org/mailman/listinfo/python-list
Re: Your confirmation is required to join the Python-list mailing list
On 9/10/20 12:48 PM, LZ Lian wrote: > Dear Python Team, > > I've subscribed as requested. I've attached the subscription email for your > reference too > > Now, for the issue I’ve tried to download and install the latest version > of Python software a few times. However, each time I run the application, the > window showing “Modify / Repair / uninstall” will pop out. I’ve tried all the > options on that pop-up and nothing works. I’ve tried googling for solutions > and none are really helpful. Pls assist. Thanks > > Warmest Regards, > Jovial Lian > Sounds like you keep re-running the installer rather than the installed version of python. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: PYTHON BUG. deleting elements of list.
On 9/8/20 7:06 PM, Mats Wichmann wrote: > On 9/7/20 5:01 PM, Driuma Nikita wrote: > > > _list = list(range(50)) > for i, el in enumerate(_list): > del _list[i] > print(_list) > > > Don't change the the list while you are iterating over it, it messes up > the iteration. It's not "randomly deleting", it's when next is called to > fetch the next item, the list has changed. > > One workaround is to iterate over a copy. For example here's using > slicing to create a new list to iterate over: > > for i, el in enumerate(_list[:]): > del _list[i] > The issue isn't so much that he is modifying the list that he is iterating over, but also when he deletes _list[0], all the other elements move down, so the next time when he does a del _list[1], that will delete what started as _list[2], and with your code, when he gets half way done he will hit an index error as he tries to delete _list[26] from a list with only 25 elements. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Symlinks already present
On 9/1/20 9:03 AM, Chris Angelico wrote: > On Tue, Sep 1, 2020 at 10:57 PM Richard Damon > wrote: >> On 8/31/20 6:05 PM, Chris Angelico wrote: >>> On Tue, Sep 1, 2020 at 5:08 AM Richard Damon >>> wrote: >>>> The file descriptor could remember the path used to get to it. chroot >>>> shows that .. needs to be somewhat special, as it needs to go away for >>>> anyone that . is their current root. >>> But my point is that there might not actually *be* a valid path that >>> gets you to a file descriptor. It can't remember something that >>> doesn't exist. (And it's pretty impractical to do that even if it >>> does.) >> Remember, we are talking about a hypothetical OS that handles hardlinks >> to directories, and defines that .. will point to the parent used to >> come to it, NOT just having current *NIX allowing hardlinks to >> directories with no remediation of the issues cause. > Yes. I'm assuming that you can define things any way you like. > >> One result of the definition, is that when you open a file/directory, if >> it might be a directory, the system WILL need to remember the path to it >> (so as to provide a value for ..) and that memory will provide a >> 'reference' for the directories so they can't go away (just like an >> unlinked file stays around will someone has it open). The normal way to >> get a file descriptor starts from a path, so the path had to exist in >> the first place, and since we are assuming that to get .., it keep a >> reference to that path, it can't truly go away. >> > But as I've pointed out, you don't always *have* a valid path. File > descriptors can be passed from process to process (most commonly by > being retained when you fork and not closed when you exec, but there > are other ways too, eg sockets), so even though starting with a path > is the most common, it isn't the only way, and you could easily have > an FD with no associated path, and then read it to find out what ".." > is. > > Also, even if all that could be solved, I don't like the idea that > reading the same directory from two different sources leads to > different results. Is it really the same directory if reading it in > different ways gives different results? > > ChrisA But when you pass the file descriptors to another process, the OS knows this, so the data that was pointed by the descriptor (which is where you would keep it anyway) still has it. There is no normal way that I know of from user land to get to a directory except from a path or at least an object that could have remembered a path. For a FD, that FD started with a path, so it could still remember it. Part of your issue is likely that you are used to thinking of the file system as a pure tree, and *nix likes to do that too. Once you accept hard links to directories as 'normal', suddenly the meaning of .. gets funny, as there is not a unique parent, but getting the parent as you got there could be useful for recursive file system searches (which will need protection from getting stuck in a loop). My research says that Unix System V allowed them, but restricted them to super users, to avoid the bigger problems with them. I don't know how it handle the issue of .. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Symlinks already present
On 8/31/20 6:05 PM, Chris Angelico wrote: > On Tue, Sep 1, 2020 at 5:08 AM Richard Damon wrote: >> The file descriptor could remember the path used to get to it. chroot >> shows that .. needs to be somewhat special, as it needs to go away for >> anyone that . is their current root. > But my point is that there might not actually *be* a valid path that > gets you to a file descriptor. It can't remember something that > doesn't exist. (And it's pretty impractical to do that even if it > does.) Remember, we are talking about a hypothetical OS that handles hardlinks to directories, and defines that .. will point to the parent used to come to it, NOT just having current *NIX allowing hardlinks to directories with no remediation of the issues cause. One result of the definition, is that when you open a file/directory, if it might be a directory, the system WILL need to remember the path to it (so as to provide a value for ..) and that memory will provide a 'reference' for the directories so they can't go away (just like an unlinked file stays around will someone has it open). The normal way to get a file descriptor starts from a path, so the path had to exist in the first place, and since we are assuming that to get .., it keep a reference to that path, it can't truly go away. > >> I see no problem with it being a hardlink, and in fact, executables know >> the name they were executed by, so directories knowing the path isn't >> that different. > Actually no, they don't. They are all taught, and being taught, > believe, that their first argument is their name. > >> The key differnce between a hardlink and a symlink is >> that hardlinks maintain existance, and always point to something that >> exists (things know how many hardlinks refer to them). symlinks don't >> reference the actual file object, but the symbolic path to it, which may >> or may not actually exist, and who doesn't know such a link exists. > Symlinks refer to a path, which may be relative. Hardlinks refer to an > inode (or whatever other way you choose to identify an actual file's > contents). It's entirely possible to have an open file or directory > that no longer has any actual path referring to it; in fact, things > don't know how many hardlinks refer to them, just how many references > there are. > > ChrisA -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Symlinks already present
On 8/31/20 12:49 PM, Chris Angelico wrote: > On Tue, Sep 1, 2020 at 2:40 AM Richard Damon wrote: >> On 8/31/20 9:00 AM, Chris Angelico wrote: >>> That's incompatible with the normal meaning of "..", and it also >>> implies that any time you rename any directory, you have to scan all >>> of its children (recursively) to find any parent directory references >>> that need to change. I'm still not sure how this solves the problem - >>> it just pushes it to everything else, and you still have to have ".." >>> mean multiple things somehow. >>> >>> ChrisA >> The . and .. entries in a directory don't need to be 'real' entries >> added to the directory using up directory slots in the directory, but >> pseudo entries created by the file system when reading a directory. To >> read a directory, you need to specify it (how else do you say you want >> to read it), and the meaning of . and .. can be derived from the path >> used to read the directory. > You can open a directory (same as you open a file), and then you have > an open file descriptor. You can open something relative to something > else. And you can chroot in between those two operations, which would > mean that there is no complete path that references what you are > opening. The file descriptor could remember the path used to get to it. chroot shows that .. needs to be somewhat special, as it needs to go away for anyone that . is their current root. > >> And yes, this means that a given directory, reachable by multiple paths, >> may give different values for .. (or .) based on which path you came to >> it from. > That would basically violate the concept of hardlinks, which is that > they have the same content regardless of how you access them. What > you're suggesting is far better handled by symlinks. > > ChrisA I see no problem with it being a hardlink, and in fact, executables know the name they were executed by, so directories knowing the path isn't that different. The key differnce between a hardlink and a symlink is that hardlinks maintain existance, and always point to something that exists (things know how many hardlinks refer to them). symlinks don't reference the actual file object, but the symbolic path to it, which may or may not actually exist, and who doesn't know such a link exists. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Symlinks already present
On 8/31/20 1:07 PM, Barry Scott wrote: > > I'm intrigued. > > How are you adding a second path that shows this mutating ".." ? > I tried with a symlink and that did not change the ".." inode. > Do you mean that I can do this with a bind mount? > > Barry > This is based on a hypothetical OS that allows creating hard-links to directories, just like to files. Because current *nix system don't do it this way, they don't allow hard-links to directories because it does cause this sort of issue. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Symlinks already present
On 8/31/20 9:00 AM, Chris Angelico wrote: > On Mon, Aug 31, 2020 at 9:57 PM Richard Damon > wrote: >> On 8/31/20 3:35 AM, Chris Angelico wrote: >>> On Mon, Aug 31, 2020 at 5:28 PM Cameron Simpson wrote: >>>>> Because of the ".." issue, it's not going to be as >>>>> symmetric as hardlinking files is. You can move a file by hardlinking >>>>> it and then unlinking the original name. If you do that with a >>>>> directory, at what point do you update its parent pointer? What >>>>> happens if you create TWO more hardlinks, and then unlink the original >>>>> name? Can you even *have* a single concept of a "real path" without it >>>>> basically just being symlinks in disguise? >>>> Shrug. Who says ".." is wired to the directory, and not the user's >>>> process context? Who says a wired to the directory ".." needs changing >>>> at any time except when its referring link count goes to 1? There are >>>> many choices here. Making those choices is a policy decision for the OS >>>> implementor, and they all have their costs and benefits. >>>> >>> Consider the situation I posed: start with one reference to the >>> directory, add two more, then remove the original. Where is its >>> parent? Is there any good way to handle that? And if you allow >>> hardlinking of directories at all, there's no reason to block this >>> particular sequence of operations. A naive reading of your description >>> is that the parent, in this situation, would remain unchanged - which >>> means the parent is some completely unrelated directory. Or, worse, it >>> could end up with a parent of itself, or a parent of its own child. >>> >>> Are you SURE it can be well-defined? >>> >>> ChrisA >> EVERY reference to the .. file link has to have a full path to that >> link, either explicit with the reference of implicit via the current >> working directory. That can define what is the parent. Yes, that says >> that two references to the 'same' directory (same as in same inode, but >> different paths) will find a different value for .. in it. So the >> definition of .. can be well defined, even in the presence of multiple >> parent directories. >> > That's incompatible with the normal meaning of "..", and it also > implies that any time you rename any directory, you have to scan all > of its children (recursively) to find any parent directory references > that need to change. I'm still not sure how this solves the problem - > it just pushes it to everything else, and you still have to have ".." > mean multiple things somehow. > > ChrisA The . and .. entries in a directory don't need to be 'real' entries added to the directory using up directory slots in the directory, but pseudo entries created by the file system when reading a directory. To read a directory, you need to specify it (how else do you say you want to read it), and the meaning of . and .. can be derived from the path used to read the directory. And yes, this means that a given directory, reachable by multiple paths, may give different values for .. (or .) based on which path you came to it from. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Symlinks already present
On 8/31/20 3:35 AM, Chris Angelico wrote: > On Mon, Aug 31, 2020 at 5:28 PM Cameron Simpson wrote: >>> Because of the ".." issue, it's not going to be as >>> symmetric as hardlinking files is. You can move a file by hardlinking >>> it and then unlinking the original name. If you do that with a >>> directory, at what point do you update its parent pointer? What >>> happens if you create TWO more hardlinks, and then unlink the original >>> name? Can you even *have* a single concept of a "real path" without it >>> basically just being symlinks in disguise? >> Shrug. Who says ".." is wired to the directory, and not the user's >> process context? Who says a wired to the directory ".." needs changing >> at any time except when its referring link count goes to 1? There are >> many choices here. Making those choices is a policy decision for the OS >> implementor, and they all have their costs and benefits. >> > Consider the situation I posed: start with one reference to the > directory, add two more, then remove the original. Where is its > parent? Is there any good way to handle that? And if you allow > hardlinking of directories at all, there's no reason to block this > particular sequence of operations. A naive reading of your description > is that the parent, in this situation, would remain unchanged - which > means the parent is some completely unrelated directory. Or, worse, it > could end up with a parent of itself, or a parent of its own child. > > Are you SURE it can be well-defined? > > ChrisA EVERY reference to the .. file link has to have a full path to that link, either explicit with the reference of implicit via the current working directory. That can define what is the parent. Yes, that says that two references to the 'same' directory (same as in same inode, but different paths) will find a different value for .. in it. So the definition of .. can be well defined, even in the presence of multiple parent directories. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Aw: Re: Python 3 how to convert a list of bytes objects to a list of strings?
On 8/29/20 3:31 PM, Karsten Hilbert wrote: >> However the problem appears to be that internally in Python 3 mailbox >> class there is an assumption that it's being given 'ascii'. > Do you really _need_ the mailbox class ? From what you've > written so far my understanding was that you receive data > (bytes) and want to append that to a file (which happens > to be an mbox). > > Can't you "just do that" ? > > IOW, read the bytes, open the file, dump the bytes, close the file ? > > Karsten Just appending a message as a raw file to a mailbox, doesn't properly add it as a new message. You need to add a From: line to the front, and then go through the message and alter any line that begins as "From:" (and possibly any line that begins with something like ">From:" or ">>From:" depending on which mailbox format is being used. There may be a few other small details that needs to happen to. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 how to convert a list of bytes objects to a list of strings?
On 8/29/20 11:50 AM, Chris Green wrote:
> Chris Green wrote:
>> Dennis Lee Bieber wrote:
>>> On Fri, 28 Aug 2020 12:26:07 +0100, Chris Green declaimed
>>> the
>>> following:
>>>
>>>
>>>
>>>> Maybe I shouldn't but Python 2 has been managing to do so for several
>>>> years without any issues. I know I *could* put the exceptions in a
>>>> bucket somewhere and deal with them separately but I'd really rather
>>>> not.
>>>>
>>> In Python2 "string" IS BYTE-STRING. It is never UNICODE, and ignores
>>> any encoding.
>>>
>>> So, for Python3, the SAME processing requires NOT USING "string"
>>> (which
>>> is now Unicode) and ensuring that all literals are b"stuff", and using the
>>> methods of the bytes data type.
>>>
>> Now I'm beginning to realise that *this* may well be what I need to
>> do, after going round in several convoluted circles! :-)
>>
> However the problem appears to be that internally in Python 3 mailbox
> class there is an assumption that it's being given 'ascii'. Here's
> the error (and I'm doing no processing of the message at all):-
>
> Traceback (most recent call last):
> File "/home/chris/.mutt/bin/filter.py", line 102, in
> mailLib.deliverMboxMsg(dest, msg, log)
> File "/home/chris/.mutt/bin/mailLib.py", line 52, in deliverMboxMsg
> mbx.add(msg)
> File "/usr/lib/python3.8/mailbox.py", line 603, in add
> self._toc[self._next_key] = self._append_message(message)
> File "/usr/lib/python3.8/mailbox.py", line 758, in _append_message
> offsets = self._install_message(message)
> File "/usr/lib/python3.8/mailbox.py", line 830, in _install_message
> self._dump_message(message, self._file, self._mangle_from_)
> File "/usr/lib/python3.8/mailbox.py", line 215, in _dump_message
> gen.flatten(message)
> File "/usr/lib/python3.8/email/generator.py", line 116, in flatten
> self._write(msg)
> File "/usr/lib/python3.8/email/generator.py", line 181, in _write
> self._dispatch(msg)
> File "/usr/lib/python3.8/email/generator.py", line 214, in _dispatch
> meth(msg)
> File "/usr/lib/python3.8/email/generator.py", line 432, in
> _handle_text
> super(BytesGenerator,self)._handle_text(msg)
> File "/usr/lib/python3.8/email/generator.py", line 249, in
> _handle_text
> self._write_lines(payload)
> File "/usr/lib/python3.8/email/generator.py", line 155, in
> _write_lines
> self.write(line)
> File "/usr/lib/python3.8/email/generator.py", line 406, in write
> self._fp.write(s.encode('ascii', 'surrogateescape'))
> UnicodeEncodeError: 'ascii' codec can't encode characters in position
> 0-3: ordinal not in range(128)
>
> Any message with other than ASCII in it is going to have bytes >128
> unless it's encoded some way to make it 7-bit and that's not going to
> happen in the general case.
>
When I took a quick look at the mailbox class, it said it could take a
'string', or a 'message'. It may well be that the string option assumes
ASCII. You may need to use the message parsing options of message to
convert messages with extended characters into the right format. This is
one of the cases where Python 2's non-strictness made things easier, but
also much easier to get wrong if not careful. Python 3 is basically
making you do more work to make sure you are doing it right.
--
Richard Damon
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 how to convert a list of bytes objects to a list of strings?
On 8/28/20 8:44 AM, Chris Green wrote: > Stefan Ram wrote: >> Chris Green writes: >>> Therein lies the problem, the incoming byte stream *isn't* ASCII, it's >>> an E-Mail message which may, for example, have UTF-8 or other encoded >>> characters in it. Hopefully it will have an encoding given in the >>> header but that's only if the sender is 'well behaved', one needs to >>> be able to handle almost anything and it must be done without 'manual' >>> interaction. >> I would make a difference between "scoring" and "transport": >> >> To transfer a message into an mbox it can be transferred as it is. >> Just the bytes from the POP3 server. Let mutt deal with them. >> > That's what I do at present in Python 2, the problem is that Python 3 > complains when I use the standard library to put the message into the > mbox. > > I want to transport the message into my mbox and Python 3 won't do it > without knowing how it's encoded whereas Python 2 just stuffed it in > there 'as is'. > > I want Python 3's mailbox class to juyst put what I tell it (even if > mis-formatted or mis-encoded) into the mbox. > It looks like the mailbox class has gotten 'pickier' in Python 3, and won't accept a message as a byte string, just as either a email message or a real string. My guess would be that 'simplest' path would be to convert your message into a parsed Message class, and add that. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 how to convert a list of bytes objects to a list of strings?
On 8/28/20 8:39 AM, Chris Green wrote: > Richard Damon wrote: >> On 8/28/20 7:50 AM, Karsten Hilbert wrote: >>>>> No interpreation requires, since parsing failed. Then you can start >>>>> dealing with these exceptions. _Do not_ write unparsable messages into >>>>> an mbox! >>>>> >>>> Maybe I shouldn't but Python 2 has been managing to do so for several >>>> years without any issues. >>> I am inclined to congratulate you on that sheer amount of luck. I don't >>> believe there were no issues because everything worked just right under >>> py2 but rather because py2 cared less than py3 does now. >>> >>>> Are we saying that Python 3 really can't be made to handle things >>>> 'tolerantly' like Python 2 used to? >>> It sure should be possible but it will require *explicit* en/decode()s in >>> more places than before because AFAICT there's less impliciteness as to >>> which encoding to apply (regardless of whether it applies). >>> >>> Karsten >>> >>> >>> >> This might be one of the cases where Python 2's lack handling of string >> vs bytes was an advantage. >> >> If he was just scanning the message for specific ASCII strings, then not >> getting the full message decoded write is unlikely to have been causing >> problems. >> >> Python2 handled that sort of case quite easily. Python 3 on the other >> hand, will have issue converting the byte message to a string, since >> there isn't a single encoding that you could use for all of it all the >> time. This being 'fussier' does make sure that the program is handling >> all the text 'properly', and would be helpful if some of the patterns >> being checked for contained 'extended' (non-ASCII) characters. >> >> One possible solution in Python3 is to decode the byte string using an >> encoding that allows all 256 byte values, so it won't raise any encoding >> errors, just give your possibly non-sense characters for non-ASCII text. >> > But this will simply get some things quite wrong and produce garbage > won't it? Whereas Python 2 would simply scramble the odd character. > Yes, when the message has extended characters, it will put the 'wrong' characters into the message, but if you are only looking for a fixed set of ASCII strings, especially in the headers of the message, that doesn't matter, those will still be there. It is a pragmatic short cut, something that is 'good enough' to get the job done, even if not 100% correct. As was elsewhere mentioned, you could also do at least most of the processing as bytes (this may need converting some of the strings being uses to bytes), but I don't know exactly what they are doing, so don't know if there is something that really needs a string. Basically, mail messages are complicated, and to 'properly' convert a message into a format for proper analysis would be significant work (and the result would NOT be a simple string), but it sounds like they didn't need that level of work with the messages. Particually if they only need to process the headers, and are working to try to 'whitelist' files to get them, being close and simple is likely good enough, -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Aw: Re: Python 3 how to convert a list of bytes objects to a list of strings?
On 8/28/20 7:50 AM, Karsten Hilbert wrote: >>> No interpreation requires, since parsing failed. Then you can start >>> dealing with these exceptions. _Do not_ write unparsable messages into >>> an mbox! >>> >> Maybe I shouldn't but Python 2 has been managing to do so for several >> years without any issues. > I am inclined to congratulate you on that sheer amount of luck. I don't > believe there were no issues because everything worked just right under > py2 but rather because py2 cared less than py3 does now. > >> Are we saying that Python 3 really can't be made to handle things >> 'tolerantly' like Python 2 used to? > It sure should be possible but it will require *explicit* en/decode()s in > more places than before because AFAICT there's less impliciteness as to > which encoding to apply (regardless of whether it applies). > > Karsten > > > This might be one of the cases where Python 2's lack handling of string vs bytes was an advantage. If he was just scanning the message for specific ASCII strings, then not getting the full message decoded write is unlikely to have been causing problems. Python2 handled that sort of case quite easily. Python 3 on the other hand, will have issue converting the byte message to a string, since there isn't a single encoding that you could use for all of it all the time. This being 'fussier' does make sure that the program is handling all the text 'properly', and would be helpful if some of the patterns being checked for contained 'extended' (non-ASCII) characters. One possible solution in Python3 is to decode the byte string using an encoding that allows all 256 byte values, so it won't raise any encoding errors, just give your possibly non-sense characters for non-ASCII text. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Aw: Re: Python 3 how to convert a list of bytes objects to a list of strings?
On 8/28/20 7:50 AM, Karsten Hilbert wrote: >>> No interpreation requires, since parsing failed. Then you can start >>> dealing with these exceptions. _Do not_ write unparsable messages into >>> an mbox! >>> >> Maybe I shouldn't but Python 2 has been managing to do so for several >> years without any issues. > I am inclined to congratulate you on that sheer amount of luck. I don't > believe there were no issues because everything worked just right under > py2 but rather because py2 cared less than py3 does now. > >> Are we saying that Python 3 really can't be made to handle things >> 'tolerantly' like Python 2 used to? > It sure should be possible but it will require *explicit* en/decode()s in > more places than before because AFAICT there's less impliciteness as to > which encoding to apply (regardless of whether it applies). > > Karsten > > > -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Another 2 to 3 mail encoding problem
On 8/27/20 4:31 AM, Chris Green wrote: > While an E-Mail body possibly *shouldn't* have non-ASCII characters in > it one must be able to handle them without errors. In fact haven't > the RFCs changed such that the message body should be 8-bit clean? > Anyway I think the Python 3 mail handling libraries need to be able to > pass extended characters through without errors. Email message a fully allowed to use non-ASCII characters in them as long as the headers indicate this. They can be encoded either as raw 8 bit bytes on systems that are 8-bit clean, or for systems that are not, they will need to be encoded either as base-64 or using quote-printable encoding. These characters are to interpreted in the character set defined (or presumed) in the header, or even some other binary object like and image or executable if the content type isn't text. Because of this, the Python 3 str type is not suitable to store an email message, since it insists on the string being Unicode encoded, but the Python 2 str class could hold it. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Why __hash__() does not return an UUID4?
On 8/26/20 5:13 PM, 2qdxy4rzwzuui...@potatochowder.com wrote: > On 2020-08-26 at 22:10:26 +0200, > Marco Sulla wrote: > >> As title ... > Assuming that the title appears prominently with the content of your > email. For the rest of us: > > Why __hash__() does not return an UUID4? > >> ... The reasons that came in my mind are: >> >> 1. speed >> 2. security > Correctness? > > Why would __hash__() return a random number? An important property of > hashes is that if x == y, then hash(x) == hash(y). If hash(x) and > hash(y) were random numbers, then how would this property be maintained? > > Or do UUID4 mean something else to you than a random number? Looking up which UUID type 4 is, yes it is a random number, so could only be applicable for objects that currently return id(), which could instead make id() be a UUID4 (and save it in the object, increasing its side) -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Why __hash__() does not return an UUID4?
On 8/26/20 4:10 PM, Marco Sulla wrote: > As title. The reasons that came in my mind are: > > 1. speed > 2. security My guess is that the typical use of the value for __hash__() doesn't need that level of guarantee of uniqueness, so requiring it would be unnecessarily expensive. Since the typical use of hash will be followed by a real equality test if the hashes match, we don't need the level of a UUID -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: About float/double type number in range.
On 8/25/20 10:39 PM, ADITYA wrote: >Dear Sir/Ma’am > >I am requesting you to satisfy me about float number in Range function, >because in the argument of range we can take integer but not double or >float whenever double as well as float are integer in nature but when we >use double/float in, it gives error that- “'float' object cannot be >interpreted as an integer.” If we want to increment the number by half or >quarter what can I do. > >For ex- Range(1,3,0.5) I want it gives Output as [1 1.5 2 2.5 3) > >I am requesting to change the nature of increment number nature in above >example so that we can increase the number with half or quarter any point >value. > >Your Sincerely > >Aditya Gautam >Saharsa (Bihar) >India >Postal Code- 852201 As was indicated, Range(1, 3, 0.5) if legal would generate ([1, 1.5, 2, 2.5] because range excludes the top value. This case happens to work in the sense that if Python allowed it, this is the result that would come out. On the other hand, the very similar Range(1, 3, 0.4) would be need very detailed knowledge to predict, it could return [1, 1.4, 1.8, 2.2, 2.6] as expected or [1, 1.4, 1.8, 2.2, 2.6, 3.0]. The issue is that there is no such exact number in binary floating point as 0.4, (it is like trying to write out exactly 1/3), so the actual value used for 0.4 will be either slightly higher (where you get the expected value) or slightly lower (where you would get the top 'excluded' value listed). This sort of unpredictability is part of the difficulty dealing with floating point. As was pointed out, you can scale the range, or build your own generator to get what you want. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Final statement from Steering Council on politically-charged commit messages
On 8/18/20 7:34 PM, rmli...@riseup.net wrote: > I would also caution against relying on the idea of human rights when > defending against accusations of being political, since they too are > political. Life is political. We continue to this day trying to > redefine, as a society, what human rights are, & who is considered to > deserve them. That process is politics. I will challenge STRONGLY the believe that all right are political in nature. That attitude is the path of tyranny, for if rights only come by the will of the government, then the government is in its right to take them all away. The American Deceleration of Independence states it well (Yes, I know we are not all Americans): *We hold these truths to be self-evident, that all men are created equal, that they are endowed by their Creator with certain unalienable Rights, that among these are Life, Liberty and the pursuit of Happiness.* Without an ideal like this, that the basic rights come out of something bigger than ourselves, we have no basis to decide on what is a right. In fact, if we declare that rights are purely a political decision, we have no right to complain about past abuses that were within what the then society decide was right, or at the very least if we want to say they were wrong, we have to accept just as validly their concept that WE are just as wrong. Politics may be the process to hammer out the details, but if politics does not look to the ruling of the truly higher power, it has no authority, except might, to enforce it. If we accept might as the right and power to rule, we need to accept that it was and will be the right and power, and accept what it brought and will bring. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Final statement from Steering Council on politically-charged commit messages
On 8/18/20 1:22 AM, justin walters wrote: > I for one don't want to see politics involved in PL development. However, > inclusivity isn't a political issue, it's a human rights issue. > > Do I agree with the PR, not exactly. However, I do think we as a community > should be accommodating to people > Whose use of the English language differs from the standard as long as the > meaning is clear. > > This thread reads like a bunch of old fuddy duddies complaining about > immigrants not speaking perfect English at a fast food restaurant. > > Feel free to ban me from the list if this doesn't meet your standards. > One comment on this. I think the focus on the words that have been used is very much a '1st world problem'. Most of the people actually suffering from the problems being discusses would very much LOVE to be in a position where the discussion of what words are the right way to say something was their biggest issue. The forces behind these issues very much love to see our focus go to debating our speech, as opposed to actually DOING something about the issue. This isn't an accusation that those bringing up the speech issues are part of the dark forces behind the problems, but maybe a call to them to think about what really is the important issue. This also doesn't mean that language doesn't matter. If our language makes a Human Rights issue seem to be 'normal', that is bad, and weakens our resolve against it. Sometimes though, the right use of a word can be powerful, and analogies are great teachers. For example, talking (to a techie) how in a master-slave network, the master node has very strong control over what the slave node does, and then comparing that to a person, asking how would it feel to be that 'slave node', maybe even needing to wait for your 'master' to ask before you went to the bathroom, or be considered to be 'malfunctioning'. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
A few comments come to mind about this discussion about TCO. First, TCO, Tail Call Optimization, is talking about something that is an optimization. Optimizations, are generally some OPTIONAL improvement in the method of executing the code that doesn't alter its DEFINED meaning. First big point, they are optional. Yes, some languages may define certain circumstances where where there is a promise that a given optimization will be done, but this is unusual. Some things that might seem like optimizations, really aren't but are defined behaviors, like the short cutting operators 'and' and 'or' where the fact that the second operand isn't always evaluated could be though of as an optimization. Second, optimizations are generally only allow to be performed if it doesn't change any defined behavior of the program. I am not so sure that is possible for TCO to be done in python based on that. for example, given: def foo(x): if x == 0: return 1 else return foo(x-1) def bar(x) if x == 0: return 2 else return bar(x-1) t = foo foo = bar bar = t foo(1) By the twiddling done at the end, we have changed the self tail-recursive functions into mutually tail-recursive functions. The fact we can do this says that when compiling foo and bar into byte-code, the recursive call to foo can't just automatically go to the beginning of the current function, but needs to look up the name and enter with a possibly need operation, something like a tail-call which becomes more of a jump as it doesn't create a new stack frame but somehow replaces the current frame with what will be the new frame while binding the 'new x' with the old 'x-1' Second, because Python has defined things like traceback, the presence of TCO is observable, and thus violates one of the basic guidelines of an optimization, that it shouldn't change defined behavior. In my mid, this says that for Python to proper support TCO, it may need to do something to make it an explicit request, or at least defined specifically when it will do it and when not. Perhaps it could be defined that a return statement whose top level of the expression is a function call, becomes an optimized tail call, ALWAYS (at least with that version of Python), or maybe some sort of flag needs to also be on the statement to avoid making it a backwards breaking change. -- https://mail.python.org/mailman/listinfo/python-list
Re: Including a Variable In the HTML Tags When Sending An Email
On 8/9/20 6:22 PM, sammy.jackson...@gmail.com wrote:
> On Sunday, August 9, 2020 at 1:32:30 AM UTC+1, Richard Damon wrote:
>> On 8/8/20 8:03 PM, sammy.jackson...@gmail.com wrote:
>>> If i use place holders i.e. {0} and {1} where {0} is the name and {1} is
>>> the dataframe i get an error for the following line of code:-
>>> .format((Name,Body).to_html()) which states 'tuple' object has no attribute
>>> 'to_html'.
>> I would do it as
>>
>> .format(Name, Body.to_html()) if your names really are just straight
>> letters.
>>
>> If they might have some funny characters that need html handling, you
>> could do:
>>
>> import html
>>
>>
>> .format(html.escape(Name), Body.to_html())
>>
>>
>> Note that different types need to be treated differently to get them
>> into clean html.
>>
>>
>> --
>> Richard Damon
>
> Richard I love you.
>
> The following change you recommended worked.
>
>
Now spend a bit of time understanding why that works, how it is
different from what you did, and what you can learn from it so you can
do other things than just follow a rote recipe.
--
Richard Damon
--
https://mail.python.org/mailman/listinfo/python-list
Re: Including a Variable In the HTML Tags When Sending An Email
On 8/8/20 8:03 PM, sammy.jackson...@gmail.com wrote:
> If i use place holders i.e. {0} and {1} where {0} is the name and {1} is the
> dataframe i get an error for the following line of code:-
> .format((Name,Body).to_html()) which states 'tuple' object has no attribute
> 'to_html'.
I would do it as
.format(Name, Body.to_html()) if your names really are just straight
letters.
If they might have some funny characters that need html handling, you
could do:
import html
.format(html.escape(Name), Body.to_html())
Note that different types need to be treated differently to get them
into clean html.
--
Richard Damon
--
https://mail.python.org/mailman/listinfo/python-list
Re: Including a Variable In the HTML Tags When Sending An Email
On 8/8/20 10:58 AM, sammy.jackson...@gmail.com wrote: > Thank you Richard for your response. > > I have moved all the text i want the user to see into the body of the email. > > I still cannot get my email to display the name. > > Name = "Tim" > > How would i include this variable in my HTML/Python code? > > Any ideas? > > Thank you. Since you are already using .format to insert the message body, you might as well do something similar to insert the name, adding more placeholders for the format to insert into. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
