Windows Tablet RealTimeStylus in Python
I have a Windows Tablet machine, running XP Tablet Edition, and I want
to access the stylus data from Python.
If anyone has done this themselves, I'd be very grateful for a
description of what worked.
Otherwise, I'd be grateful for advice. I'm in way over my head, so
what I describe below is probably full of errors.
I managed to access the stylus data successfully from C#, using a .net
object called RealTimeStylus, contained in Microsoft.Ink.dll, which
was located in
c:\program files\common files\microsoft shared\ink.
The documentation says that this .net object uses an underlying COM
object, so I hoped to be able to access the COM object from within
Python. First, I used a .net disassembler to inspect
Microsoft.Ink.dll, and I discovered that it uses this command to
create the COM object:
Guid clsid = new Guid("{DECBDC16-E824-436e-872D-14E8C7BF7D8B}");
Guid iid = new Guid("{C6C77F97-545E-4873-85F2-E0FEE550B2E9}");
string licenseKey = "{CAAD7274-4004-44e0-8A17-D6F1919C443A}";
ComObjectCreator.CreateInstanceLicense(clsid, iid, licenseKey);
I looked up this clsid in my registry, and discovered that it refers
to
C:\Program Files\Common Files\Microsoft Shared\INK\inkobj.dll
(This file also exists on my standard XP machine, which also ran my C#
program happily.)
Now, I want to somehow access this COM object from within Python. I
tried MakePy, but I didn't know what type library to specify. I found
something called "Microsoft Tablet PC Type Library, version 1.0
(1.0)", and it generated a .py file from type library 'inkobj.dll',
but this file doesn't say anything about a RealTimeStylus.
I tried looking for a Python command to CreateInstance, but I couldn't
find one where I could specify the license string. Without the license
string I ended up with the error message "Class is not licensed for
use".
I have no idea what to do next.
Damon.
--
http://mail.python.org/mailman/listinfo/python-list
Re: A little bit else I would like to discuss
On Feb 12, 8:15 pm, Philip Semanchuk wrote: > Let me know when Visual Studio tries to address building GUIs for > Windows, OS X, Gnome, and KDE. Until then, you're comparing apples to > oranges, or chalk and cheese if you're from that part of the world. Right now. Use Visual Studio to program a .net application using Windows Forms. Run it in Mono on Windows, or OS X, or Linux. You can even do it with IronPython. Or, if you prefer a native look on each application, do it with wx.net. The great thing about IronPython in .net is that you can just link in any other .net library in whatever language it's written in, without needing any sort of wrapper. Admittedly, I haven't tried this, I'm just going by the hype I read on the Mono and wx.net pages. Also, you can quibble whether it's Visual Studio that tries to address this, or the Mono effort. Damon. -- http://mail.python.org/mailman/listinfo/python-list
Re: A little bit else I would like to discuss
On Feb 12, 8:40 pm, Christian Heimes wrote: > In your opinion all third party are bad. You like to have one monolithic > block of software. That's a typical Microsoft approach. Lot's of people > from the open source community prefer small and loosely coupled pieces > of software. One of the greatest ruler of all time once said "divide et > impera" -- divide it in small pieces to make it much easier to conquer > every piece by its own. "Divide et impera" was a strategy used by the monolithic Roman empire to divide and subjugate others. I hope that's not what happens to Python! The original poster complained about needing to go off to third-party sites to hunt for software. I wonder if the Python team has ever considered following the lead of miktex or R, and setting up a centralized (mirrored) repository of packages? Let anyone who wants, submit packages. * Like R, every time there is a new version of Python, the repository should rebuild the packages, for all supported platforms, and make available all those that compile cleanly. R also forces you to write properly structured documentation for every exposed function, before the repository will accept it. * Like miktex, when the user does "import foo", the Python interpreter should (optionally) look for foo in its cached list of packages, and download the latest version if necessary. This works fine for R and miktex, and it has made my life very easy. Damon. -- http://mail.python.org/mailman/listinfo/python-list
missing python-config and building python on Windows
I am attempting to build gtk and glade using mingw/msys. It seems that some of the packages require python. I installed 2.7.3 using the installer from python.org. That worked for some of the packages but now I am trying to do one that needs python-config which I don't find in the installation directory. I tried building from source using mingw/msys but that had too many problems so I gave up on that. I thought I might try building with MSVC 2010 since it appears to be supported and I have that at work. There are a few problems with this: 1. though I have looked in a few readme files, I don't see instructions for installing what I have just built using MSVC. Where can I find the instructions for installing after building with MSVC? 2. I have searched the project directory but I don't find python-config. Is this some sort of optional thing that isn't built by default? I tried searching this list and although I find a few questions about it, I don't see an answer to where I can find it. 3. It seems that MSVC doesn't produce the .a library files needed for linking into a mingw built program. Do I have to do that fun trick to create the .a from the dll? Damon Register -- http://mail.python.org/mailman/listinfo/python-list
Re: EXTERNAL: Re: missing python-config and building python on Windows
On 7/31/2012 11:49 PM, Mark Hammond wrote: On 1/08/2012 10:48 AM, Damon Register wrote: 1. though I have looked in a few readme files, I don't see instructions for installing what I have just built using MSVC. Where can I find the instructions for installing after building with MSVC? There is no such process. In general, you can just run directly from the built tree. That is a bummer. That makes me more curious about how the Windows installer was made and how all the pieces were gathered together. I'm afraid I don't know what python-config is. It appears it might be a reflection of how Python was configured and build on *nix systems - if that is the case then it is expected that one does not exist for Windows (as it doesn't use the *nix build chain). which means, I guess, that mingw is barely supported if at all. While it may be Windows, mingw/msys is a nice way to build many programs that are unix oriented. I suppose that just for fun I should try to build python on SuSE to see how it goes. 3. It seems that MSVC doesn't produce the .a library files needed for linking into a mingw built program. Do I have to do that fun trick to create the .a from the dll? I'm surprised MSVC *can* build .a files for mingw - but AFAIK, even if MSVC could do that, I believe Python makes no attempt to build with support for linking into mingw programs. I don't know that MSVC can do this. The only process of which I am aware is a two step process using pexports and dlltool to generate the .a file from a dll. One reason I was using the python.org installer is that it already had the python27.a file. Now I am even more curious about what was used to build python and create that installer. The python.org installer provided all I needed for build most python dependent apps with mingw until I ran into one that needed python-config. I suppose that if python-config does what I suspect it does (produce cflags and ldflags as does pkg-config) then perhaps I could just fake it by replacing use of python-config with what the cflags and ldflags should be for where I have python. Damon Register -- http://mail.python.org/mailman/listinfo/python-list
Re: EXTERNAL: Re: pylagiarism -- Need help now! Please provide code...
Thanks, I needed something to start the day on the positive side. On 8/14/2012 5:32 AM, Simon Cropper wrote: Anyone willing to contribute money to help with the compilation of the code will get a portion of the profits. Just send me your account details, name and address; and I will ensure, once I have been paid, that I will send you your cut! :) You forgot about the part where you have leukemia and have only a month to live so you will leave all the profits to me. Damon Register -- http://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
On 10/4/17 11:22 PM, Steve D'Aprano wrote: The A and E in the word "are" are not vowels, since they are silent. The A is clearly not silent, unless you have some strange pronunciation. The fact that are is pronounced just like the NAME of the letter R doesn't mean it is silent. Compare the sound of the word are (which begins like the 'pirate' phrase arrgh) to me, to a word that begins with a letter R like rat or ring. There is a clear aspiration in the former that isn't in the latter. -- https://mail.python.org/mailman/listinfo/python-list
Re: django project avoid reload page where work algorithm
On 10/8/17 11:58 AM, Xristos Xristoou wrote: Τη Κυριακή, 8 Οκτωβρίου 2017 - 6:35:28 μ.μ. UTC+3, ο χρήστης MRAB έγραψε: On 2017-10-08 15:27, Xristos Xristoou wrote: Do you mean "long reload"? user can put some numbers in my html template and i take that numbers and i sue it in specific mathematical algorithm that algorithm to create result need time between 5-10 minutes in that time browser stay on reload...that i mean It sounds like the fundamental problem is that you are doing the calculation in the web page handler. This means that the browser will be stuck in the page load until the calculation finishes, and that if the user aborts the access (or loses connection) then the web page handler is aborted. What you need to do is rather than doing the calculation in the page handler, you need to kick off an independent process to do the calculation, and then immediately finish the page (maybe giving the use a link to a page they can check to see if a result is available). -- https://mail.python.org/mailman/listinfo/python-list
Re: django project avoid reload page where work algorithm
On 10/8/17 4:46 PM, Xristos Xristoou wrote: Τη Κυριακή, 8 Οκτωβρίου 2017 - 10:48:38 μ.μ. UTC+3, ο χρήστης Richard Damon έγραψε: On 10/8/17 11:58 AM, Xristos Xristoou wrote: Τη Κυριακή, 8 Οκτωβρίου 2017 - 6:35:28 μ.μ. UTC+3, ο χρήστης MRAB έγραψε: On 2017-10-08 15:27, Xristos Xristoou wrote: Do you mean "long reload"? user can put some numbers in my html template and i take that numbers and i sue it in specific mathematical algorithm that algorithm to create result need time between 5-10 minutes in that time browser stay on reload...that i mean It sounds like the fundamental problem is that you are doing the calculation in the web page handler. This means that the browser will be stuck in the page load until the calculation finishes, and that if the user aborts the access (or loses connection) then the web page handler is aborted. What you need to do is rather than doing the calculation in the page handler, you need to kick off an independent process to do the calculation, and then immediately finish the page (maybe giving the use a link to a page they can check to see if a result is available). yes this is nice can you help me to do that? I haven't done it myself, but you may want to look at the various os.spawn* methods. -- https://mail.python.org/mailman/listinfo/python-list
Re: Compression of random binary data
On 10/24/17 6:30 PM, Steve D'Aprano wrote: On Wed, 25 Oct 2017 07:09 am, Peter J. Holzer wrote: On 2017-10-23 04:21, Steve D'Aprano wrote: On Mon, 23 Oct 2017 02:29 pm, Stefan Ram wrote: If the probability of certain codes (either single codes, or sequences of codes) are non-equal, then you can take advantage of that by encoding the common cases into a short representation, and the uncommon and rare cases into a longer representation. As you say: Otherwise, if ( 0, 0 ) is much more frequent, we can encode ( 0, 0 ) by "0" and ( 0, 1 ) by "101", ( 1, 0 ) by "110", and ( 1, 1 ) by "111". And we could then use /less/ than two bits on the average. That's incorrect. On average you use 2.5 bits. (1*1 bit + 3*3 bits divide by four possible outcomes, makes 2.5 bits.) I disagree. If the distribution is not equal, then the average needs to take the different probabilities into account. I think I would call that the *weighted* average rather than the average. Regardless of what we call it, of course both you and Stefan are right in how to calculate it, and such a variable-length scheme can be used to compress the data. E.g. given the sequence 0011 which would take 8 bits in the obvious encoding, we can encode it as "000111" which takes only 6 bits. But the cost of this encoding scheme is that *some* bit sequences expand, e.g. the 8 bit sequence 1100 is encoded as "10" which requires 10 bits. The end result is that averaged over all possible bit sequences (of a certain size), this encoding scheme requires MORE space than the obvious 0/1 bits. But in practice we don't care much, because the data sequences we care about are usually not "all possible bit sequences", but a heavily restricted subset where there are lots of 00 pairs and fewer 01, 10, and 11 pairs. My understanding of the 'Random Data Comprehensibility' challenge is that is requires that the compression take ANY/ALL strings of up to N bits, and generate an output stream no longer than the input stream, and sometime less. It admits that given no-uniformly distributed data, it is possible to compress some patterns, the common ones, and expand others, the uncommon ones, to lower the net average length. What it says can't be done is to have a compression method that compresses EVERY input pattern. That is where the 'Pigeon Hole' principle comes into play which the people who claim to be able to compress random data like to ignore or just attempt to say doesn't apply. -- https://mail.python.org/mailman/listinfo/python-list
Re: Student can't get if elif final statement to print for discussion post for python
On 11/19/17 1:10 PM, Cheri Castro wrote:
I've tried several variations but haven't been able to figure out why my final
if elif statement won't print. I tried using return, I tried using 1's and 0's
rather than yes and no. Not sure what the issue is. Please, help.
#This function will print how many yes answers the user has and a message
def correctAnswers(job, house, yard, time):
if correctAnswers == 'yes':
print ("Congratulations! You should get a puppy!")
else:
return "I'm sorry, you shouldn't get a puppy."
Why does one path print and the other return, those are different actions.
--
Richard Damon
--
https://mail.python.org/mailman/listinfo/python-list
Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)
On 11/23/17 2:46 PM, Thomas Jollans wrote: On 23/11/17 19:42, Mikhail V wrote: I mean for a real practical situation - for example for an average Python programmer or someone who seeks a programmer job. And who does not have a 500-key keyboard, I don't think it's too much to ask for a programmer to have the technology and expertise necessary to type their own language in its proper alphabet. My personal feeling is that the language needs to be fully usable with just ASCII, so the - character (HYPHEN/MINUS) is the subtraction/negation operator, not an in-name hyphen. This also means the main library should use just the ASCII character set. I do also realize that it could be very useful for programmers who are programming with other languages as their native, to be able to use words in their native language for their own symbols, and thus useful to use their own character sets. Yes, doing so may add difficulty to the programmers, as they may need to be switching keyboard layouts (especially if not using a LATIN based language), but that is THEIR decision to do so. It also may make it harder for outside programmers to hep, but again, that is the teams decision to make. The Unicode Standard provides a fairly good classification of the characters, and it would make sense to define that an character that is defined as a 'Letter' or a 'Number', and some classes of Punctuation (connector and dash) be allowed in identifiers. Fully implementing may be more complicated than it is worth. An interim simple solution would be just allow ALL (or maybe most, excluding a limited number of obvious exceptions) of the characters above the ASCII set, with a warning that only those classified as above are promised to remain valid, and that other characters, while currently not generating a syntax error, may do so in the future. It should also be stated that while currently no character normalization is being done, it may be added in the future, so identifiers that differ only by code point sequences that are defined as being equivalent, might in the future not be distinct. Since my native language is English, this isn't that important to me, but I do see it as being useful to others with different native tongues. The simple implementation shouldn't be that hard, you can just allow character codes 0x80 and above as being acceptable in identifiers, with the documented warning that the current implementation allows some forms that may generate errors in the future. If enough interest is shown, adding better classification shouldn't be that hard. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)
On 11/23/17 4:31 PM, Chris Angelico wrote: On Fri, Nov 24, 2017 at 8:19 AM, Richard Damon wrote: On 11/23/17 2:46 PM, Thomas Jollans wrote: On 23/11/17 19:42, Mikhail V wrote: I mean for a real practical situation - for example for an average Python programmer or someone who seeks a programmer job. And who does not have a 500-key keyboard, I don't think it's too much to ask for a programmer to have the technology and expertise necessary to type their own language in its proper alphabet. My personal feeling is that the language needs to be fully usable with just ASCII, so the - character (HYPHEN/MINUS) is the subtraction/negation operator, not an in-name hyphen. This also means the main library should use just the ASCII character set. I do also realize that it could be very useful for programmers who are programming with other languages as their native, to be able to use words in their native language for their own symbols, and thus useful to use their own character sets. Yes, doing so may add difficulty to the programmers, as they may need to be switching keyboard layouts (especially if not using a LATIN based language), but that is THEIR decision to do so. It also may make it harder for outside programmers to hep, but again, that is the teams decision to make. The Unicode Standard provides a fairly good classification of the characters, and it would make sense to define that an character that is defined as a 'Letter' or a 'Number', and some classes of Punctuation (connector and dash) be allowed in identifiers. That's exactly how Python's identifiers are defined (modulo special handling of some of the ASCII set, for reasons of backward compatibility). Fully implementing may be more complicated than it is worth. An interim simple solution would be just allow ALL (or maybe most, excluding a limited number of obvious exceptions) of the characters above the ASCII set, with a warning that only those classified as above are promised to remain valid, and that other characters, while currently not generating a syntax error, may do so in the future. It should also be stated that while currently no character normalization is being done, it may be added in the future, so identifiers that differ only by code point sequences that are defined as being equivalent, might in the future not be distinct. No, that would be a bad idea; some of those characters are more logically operators or brackets, and some are most definitely whitespace. Also, it's easier to *expand* the valid character set than to *restrict* it, so it's better to start with only those characters that you know for sure make sense, and then add more later. If the xid_start and xid_continue classes didn't exist, it might be reasonable to use "Letter, any" and "Number, any" as substitutes; but those classes DO exist, so Python uses them. But broadly speaking, yes; it's not hard to allow a bunch of characters as part of Python source code. Actual language syntax (eg keywords) is restricted to ASCII and to those symbols that can easily be typed on most keyboards, but your identifiers are your business. ChrisA My thought is you define a legal only those Unicode characters that via the defined classification would be normally legal, but perhaps the first implementation doesn't diagnose many of the illegal combinations. If that isn't Pythonic, then yes, implementing a fuller classification would be needed. That might also say normalization questions would need to be decided too. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)
On 11/23/17 5:45 PM, Thomas Jollans wrote: On 23/11/17 23:15, Richard Damon wrote: My thought is you define a legal only those Unicode characters that via the defined classification would be normally legal, but perhaps the first implementation doesn't diagnose many of the illegal combinations. If that isn't Pythonic, then yes, implementing a fuller classification would be needed. That might also say normalization questions would need to be decided too. You do realise that Python has a perfectly good definition of what's allowed in an identifier that is thoroughly grounded in the Unicode standard and works very well, right? -- Thomas No, I wasn't aware that Python was already Unicode enabled in the source code set. Still fairly new with it, but the fact that people seemed to argue about doing it made me think it was allowed yet. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Increasing the diversity of people who write Python (was: Benefits of unicode identifiers)
On 11/24/17 11:41 AM, Skip Montanaro wrote: Because if I already can't understand the words, it will be more useful to me to be able to type them reliably at a keyboard, for replication, search, discussion with others about the code, etc. I am probably not alone in my Americo-centric world where I can't even easily type accented Latin-1 characters. I happen to be using Linux as I type this, but type at a Windows keyboard at work (ugh) and have long been a user of Macs (still have one or two at home). Might the problem be further multiplied by the number of different ways I have of entering text? Would Emacs running on Linux, but displaying on Windows be different than Chrome running directly on Linux? I will make a wild-ass guess and suggest that maybe, just maybe, those three major system types have different ways of typing accented characters. Consequently, I've never even tried to learn any of them. On the rare instance where I need to type an accented character, such as when typing Marc-André Lemburg's name properly, I ask Google for "accented e" and copy/paste an instance. That's a PITA, but worth it on the few occasions where I need it today. I suppose I would have to break down and learn how to properly enter such text should I need to Romanized text which might contain cedillas, accents and other diacritical marks... This is all not to suggest the goal isn't worth striving for, just that there exists a huge barrier - in the form of ASCII and its limiting effect on computer keyboard entry - to attaining Unicode identifier Nirvana. Perhaps for my next computer I should choose a non-ASCII keyboard option when configuring it. Skip I find it it interesting that the primary reason to want to limit the character set to ASCII is people thinking that it would make it hard for *them* to read/use the code, but no thought about how much harder it makes it on the original author/team to write code that is easily understood by THEM. Yes, code intended to be used by the broad community would be best to adhere to the community standard (and the community style guide should, if it doesn't already, have a rule about this). Code intended for internal usage is best to be as well understood by that group as possible. Some also bring up some of the issues with similar glyphs, as if we don't already have issues with things like 0 and O, 1 and l and I (depending on the font you use). This mostly comes down to self-inflicted pain, which can mostly be relieved with a style rule to avoid multi-language identifiers, perhaps checked with a special 'linter'. Since Python is white space sensitive, we already have the issue with the distinction between space and tab, which isn't normally obvious in many text editors (Though I suspect many Python programmers have their editors configured to largely avoid the issue). -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Increasing the diversity of people who write Python
On 11/24/17 12:35 PM, Skip Montanaro wrote: I find it it interesting that the primary reason to want to limit the character set to ASCII is people thinking that it would make it hard for *them* to read/use the code, but no thought about how much harder it makes it on the original author/team to write code that is easily understood by THEM. I think you misunderstood my post. For that I apologize that I wasn't clear. I was only pointing out that there is a ton of inertia based on the long dominance of ASCII (and before that EBCDIC) and its downstream effects on computer entry systems. I know that there are likely semi-reasonable ways to enter accented characters on my keyboard, but they are unknown to me, and will likely be different on the different systems I use, so I've not bothered to learn any of them. One thing which occurred to me as I was typing my earlier message, but which I failed to include... I wonder if when you go to Dell (for example) to configure a computer, you can easily specify a non-ASCII keyboard for a machine destined for delivery to the US. Maybe it's trivial, but maybe it's just enough more difficult (slows delivery, costs a few bucks more, which of the alternatives should you choose?) that people think, "Ah hell, might as well just go with the ASCII keyboard." I'm clearly in the old fart camp at this point. Perhaps American software engineers half my age aren't afflicted by my career-long biases. Skip I doubt I am 1/2 your age (are you 120 yet?). The keyboard I normally use would be very hard to use for foreign characters, but I do understand that if I wanted to, I could easily get a keyboard designed for use in any other language. Some would take some training to learn how to use (like a Chinese keyboard). The fact that I was pointing out is that the fact that people are arguing that because *THEY* would have difficulty working with a code base (that they likely would never actually need access to) is a good reason from preventing others, who already HAVE the needed hardware/training from being able to make the code more readable to them. As far as the basic ability to enter arbitrary characters, most OSes have a generic entry method (like windows ALT-numbers method) and I think most have a character selector app to add arbitrary characters to the clipboard. Yes, this may not be very convenient for a lot of use but is possible. Also, it is generally possible to select an alternate keyboard map for your keyboard to enter other characters, you then just need to know (or have printed) the new mapping of the keyboard. It helps if you do this to have learned the new mapping, and how to touch type on that keyboard. Generally you can also get Keyboard Stickers to place on your keyboard if you are a hunt and pecker typist. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)
On 11/24/17 4:04 PM, Mikhail V wrote: On Fri, Nov 24, 2017 at 9:08 PM, Chris Angelico wrote: On Sat, Nov 25, 2017 at 7:00 AM, Mikhail V wrote: I agree that one should have more choices, but people still can't really choose many things. I can't choose hyphen, I can't choose minus sign, and many tech people would probably want more operators. It counts probably not so *big* amount of people, compared to *all* people that potentially would say "oh how wonderful is it to be able to write in various scripts", still it is just a "use it at your own risk" thing at a minimum, and merely based on emotions rather than common sense. Regardless of what Unicode decides for classifications, there simply must be careful analysis how the major *Python* code actually looks in the end of all experiments. Especially true for characters in regard identifiers versus operators. And it's the "identifiers versus operators" question that is why you can't use hyphen in an identifier. Underscore is available as an ASCII joiner, and there are various non-ASCII joiners available too. Why is hyphen so important? Yes I understand this, so it is how Unicode defines joiners. Yeah, debates about the classifications can be hold forever, but one should not forget about the hyphen during these debates. Hyphen is used I think more then six hundreds years as a joiner (or probably some other classification term one prefer). And just comes so it works very well. Among Unicode joiners, middledot reminds of hyphen, but it is not used in typography for this task. So it is not good option and has issues in most fonts (too small or not aligned with lowercase). Often it is used to show up whitespace in editors, so it is kind of 'reserved'. Other joiners in unicode classification - well probably ok for a 1st April proposal. About importance, it was already covered in the proposal. Why it is SO important? It is rhetorical question. Important compared to what? Compared to the question, what one will eat and where sleep tomorrow? Then it is not so important. Mikhail Have you tried using U+2010 (HYPHEN) ‐. It is in the class XID_CONTINUE (in fact it is in XID_START) so should be available. What isn't available is U+002D (HYPHEN-MINUS) - because that is otherwise defined as the subtraction/negation operator. It may make your code harder to read, if your font doesn't make enough of a distinction between those characters -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)
On 11/24/17 5:46 PM, Ned Batchelder wrote: On 11/24/17 5:26 PM, Richard Damon wrote: Have you tried using U+2010 (HYPHEN) ‐. It is in the class XID_CONTINUE (in fact it is in XID_START) so should be available. U+2010 isn't allowed in Python 3 identifiers. The rules for identifiers are here: https://docs.python.org/3/reference/lexical_analysis.html#identifiers . U+2010 is in category Pd (http://www.fileformat.info/info/unicode/char/2010), which isn't one of the categories allowed in identifiers. Category Pc (http://www.fileformat.info/info/unicode/category/Pc/list.htm) is allowed, but it doesn't include anything that would look like a hyphen. --Ned. Looks like the site that I looked up characters in XID_CONTINUE/START was incorrect. Looks like not only is U+2010 not in any of the character classes that are put into ID_START or ID_CONTINUE but is in Pattern_Syntax which is explicitly removed from those categories. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: What is the meaning of @@?
On 12/24/17 8:33 PM, Peng Yu wrote: See for example this file. https://github.com/tensorflow/tensorflow/blob/master/tensorflow/python/ops/rnn_cell.py On Sat, Dec 23, 2017 at 12:03 AM, Steve D'Aprano wrote: On Sat, 23 Dec 2017 04:38 pm, Peng Yu wrote: Hi, I only can find the doc for @. What does @@ mean in python? I don't think that @@ means anything yet. There was a proposal to use @@ for matrix exponentiation in Numpy, as @ is used for matrix multiplication, but that was left on hold to see whether it is really needed or not. Where did you find @@ in Python? (By the way, @ for matrix multiplication only works in Python 3.5 or better.) https://www.python.org/dev/peps/pep-0465/ -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list Note, the @@ is inside a triple quoted string, so this is just part of a multi-line string. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: has sourceforge exposed the dirty little secret ?
On 1/5/18 3:11 PM, Kim of K. wrote: let me tell you... Once you're done with that school crap, you realize it was the pefect waste of time. At work or in life you need less than 2% of that school crap they funnelled into your head. My experience is that while I found little use for much of the 'facts' that I learned in school, there has been a lot of use for the basic methods that were learned while processing those facts in school. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] Re: has sourceforge exposed the dirty little secret ?
On 1/7/18 5:27 PM, Gene Heskett wrote: On Sunday 07 January 2018 16:22:57 Christian Gollwitzer wrote: Am 05.01.18 um 22:15 schrieb Michael Torrie: Please, no! We don't need emoji in this group. Fortunately the vast majority of posters use plain text (as is the etiquette) and so we don't have to worry about that kind of nonsense. It's not needed, but shouldn't pose any big problems with modern software? I'm using Thunderbird over NNTP, and this shows up as graphics to me: 🐍 💻 But here its broken and I am looking at two pairs of vertical boxes because it is not properly mime'd. If you use chars or gliphs from a non-default charset, it needs to demarcated with a mime-boundary marker followed by the new type definition. Your email/news agent did not do that. The headers say: Content-Type: text/plain; charset=UTF-8; format=flowed So it DOES declare the right character set. But it also says: Content-Transfer-Encoding: 7bit Which is incorrect, as the message is actually 8bit encoded (since the Emoji aren't in the first 127 characters, so their UTF-8 encoding isn't 7-bit. Some software might have messed up the message in transit due to that error. It came up on the mailing list correct, and the gateway converted the encoding to Base64 which should work. If you don't have a font installed that your reader can find those characters, that could be another issue. (a snake and a computer) Unless this message is blocked at the NNTP-List boundary, it should show the same on any recent mail reader. Christian Cheers, Gene Heskett -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] Re: has sourceforge exposed the dirty little secret ?
On 1/7/18 7:07 PM, Gene Heskett wrote: On Sunday 07 January 2018 18:25:52 Random832 wrote: On Sun, Jan 7, 2018, at 17:47, Richard Damon wrote: But it also says: Content-Transfer-Encoding: 7bit Which is incorrect, as the message is actually 8bit encoded (since the Emoji aren't in the first 127 characters, so their UTF-8 encoding isn't 7-bit. Some software might have messed up the message in transit due to that error. Well, the fact that the emoji survived the round-trip and showed up properly in his reply (and yours) led me to rule out the possibility that anything like that had happened. Plus, if that had happened, the result wouldn't be boxes, but a series of ASCII characters (some of which are control characters, and some of which are printable). Its just boxes here, and I just spent the better part of half an hour trying all the fonts available to kmail, without see anything but variable sizes of twin boxes. Looking at the raw message its also marked transfer content encoding = base64, which I'd assume destroys any semblance of an 8 bit encoding. Cheers, Gene Heskett If you see base64, then something converted it. The 7bit was what I got from the source comp.language.python, and it looks like the gateway saw that it wasn't 7 bit, and fixed the encoding to base64, which maintains the full 8 bit content of the message (with an encoding overhead of using 4 characters to encode 3 bytes of data, plus line overhead). If you got the message from the list, it was intact, and the lack of characters says you machine just doesn't have a full unicode font. (One of the issues with Unicode, a FULL font is huge) -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Distance between point and a line passing through other two points
On 2/7/18 6:06 AM, Dhananjay wrote: Hello all, I have 3 points with coordinates (x0,y0,z0), (x1,y1,z1) and (x2,y2,z2). I also have a line joining points (x1,y1,z1) and (x2,y2,z2). For example, p0=[5.0, 5.0, 5.0] p1=[3.0, 3.0, 3.0] p2=[4.0, 4.0, 4.0] a = np.array(p0) b = np.array(p1) c = np.array(p2) I want to write a script that can calculate shortest distance d between point (x0,y0,z0) and the line((x1,y1,z1), (x2,y2,z2)). In other words, d = distance(a, line(b,c)) Since I have information of the coordinates of these points only, I am not sure how to put it into python script to get distance d. On searching Internet, some solutions are discussed for 2D coordinates (i.e. for (x0,y0), (x1,y1) and (x2,y2) ). However, I need solution for 3D coordinates. Any direction or suggestion would be great help. Thanking you in advance, -- Joshi This sounds a lot more like a math problem then a python problem (unless python has a geometry package to use for this). The 3D solution is very close to the 2D version, if you draw the angle p0 -> p1 -> p2 and take the cross product of the vectors p1-p0 and p2-p1 the result will be a vector perpendicular to plane defined by p0, p1, p2 with a magnitude of |p1-p0| * |p2-p1| * sin(angle between line (p1,p0) and (p2,p1)) The distance you want is |p1-p0| * sin(angle between line (p1,p0) and (p2,p1)) With a bit of thought you should be able to get the answer. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: This newsgroup (comp.lang.python) may soon be blocked by Google Gro
On 2/9/18 4:12 PM, Chris Angelico wrote: On Sat, Feb 10, 2018 at 8:05 AM, wrote: On Friday, February 9, 2018 at 2:48:17 PM UTC-5, Chris Green wrote: [email protected] wrote: On Saturday, February 3, 2018 at 7:15:16 PM UTC-5, pyotr filipivich wrote: [snip] Those of us who do not use google-groups may not notice the loss of the google groupies. I use GG to read comp.lang.python because of the following combination of factors. I would definitely be happier if there was another way to do this, so that I wouldn't have to wade through lots of spam. - I read it from both home and work. - I can't install any additional software at work. - There is no newsgroup reader software available at work. - GG tracks read/unread status of every post. This is shared between work and home through my Google account. - When I (very rarely) post from work, I can't do it by email, since outgoing email is blocked. Alternative approach, what I do:- Run a text mode (but very capable and mouse aware) newsreader on my home system, read news locally using that. Use ssh (is that available at worK?) to connect from work to home and run the same newsreader in the same environment. If you can't even ssh from work then you can always use an 'ssh from the web' app from your wenb browser. The newsreader I use is tin by the way. -- Chris Green · ssh would be even a bigger problem here. As I mentioned, I can't even email from work to the outside! All web sites that provide remote connectivity tools are blocked. ... yet they're okay with you browsing newsgroups? I think you may have a Layer Eight conflict here. ChrisA If he can browse, he can get E-Mail with Gmail/Yahoo/AOL/etc, his normal mail ISP likely even supports some form of Web Mail Client. If they are blocking these, but not Google Groups, there is a major disconnect in the rules. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: This newsgroup (comp.lang.python) may soon be blocked by Google Gro
On 2/9/18 6:19 PM, [email protected] wrote: On Friday, February 9, 2018 at 5:03:45 PM UTC-5, Richard Damon wrote: On 2/9/18 4:12 PM, Chris Angelico wrote: On Sat, Feb 10, 2018 at 8:05 AM, wrote: On Friday, February 9, 2018 at 2:48:17 PM UTC-5, Chris Green wrote: [email protected] wrote: On Saturday, February 3, 2018 at 7:15:16 PM UTC-5, pyotr filipivich wrote: [snip] Those of us who do not use google-groups may not notice the loss of the google groupies. I use GG to read comp.lang.python because of the following combination of factors. I would definitely be happier if there was another way to do this, so that I wouldn't have to wade through lots of spam. - I read it from both home and work. - I can't install any additional software at work. - There is no newsgroup reader software available at work. - GG tracks read/unread status of every post. This is shared between work and home through my Google account. - When I (very rarely) post from work, I can't do it by email, since outgoing email is blocked. Alternative approach, what I do:- Run a text mode (but very capable and mouse aware) newsreader on my home system, read news locally using that. Use ssh (is that available at worK?) to connect from work to home and run the same newsreader in the same environment. If you can't even ssh from work then you can always use an 'ssh from the web' app from your wenb browser. The newsreader I use is tin by the way. -- Chris Green · ssh would be even a bigger problem here. As I mentioned, I can't even email from work to the outside! All web sites that provide remote connectivity tools are blocked. ... yet they're okay with you browsing newsgroups? I think you may have a Layer Eight conflict here. ChrisA If he can browse, he can get E-Mail with Gmail/Yahoo/AOL/etc, his normal mail ISP likely even supports some form of Web Mail Client. If they are blocking these, but not Google Groups, there is a major disconnect in the rules. -- Richard Damon Disconnect or not, I can browse GG and post replies (e.g., this one). I have no access to gmail or any other email provider. Regards, Igor. My guess then is that your access to google groups is also against your companies policies, they just haven't put an enforcement in their firewalls because it is too obscure for the IT department to have thought of. Based on the sort of broad blocking they are doing, I am a bit surprised they seem to be black listing rather than white listing the web. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Are the critiques in "All the things I hate about Python" valid?
On 2/18/18 6:55 AM, Anders Wegge Keller wrote:
På Sat, 17 Feb 2018 15:05:34 +1100
Ben Finney skrev:
boB Stepp writes:
He blithely conflates “weakly typed” (Python objects are not weakly, but
very strongly typed)
Python is more strongly typed than PHP, but that doesn't really say much.
However, compared to a language like C, there are big holes in the type
safety.
>>> alist = [1, 'two', ('three', four), 5*'#']
That list is not only weakly typed, but rather untyped. There are no
safeguards in the language, that enforce that all elements in a list or
other container are in fact of the same type. Before type annotations and
mypy, I could not enforce that other than at runtime.
So claiming Python to have very strongly typed objects is a bit of a
strecth. PHP that many of us like to be smug about is equally strongly
typed. It just comes with a metric ton of inane type coersions that have
gone too far. However, we are happy to add an integer to a float without
having to make an explicit conversion every time, so ... Thread carefull and
all that.
Note, that 'Only at Runtime' isn't a distinction between Weakly Typed or
Strongly Typed but between Statically Typed and Dynamically Typed.
Python is clearly dynamically typed, as we don't need to assign a type
to a symbol, and it will always reflect a value of that type,
Python is much stronger typed than PHP, because in PHP you can do things
like 1 + '2' and get 3, as string values will naturally convert
themselves to numbers, Python won't do this. Yes Python will freely
convert between numeric types, but I wouldn't say that Python claims to
be a language that focuses on numerics.
--
Richard Damon
--
https://mail.python.org/mailman/listinfo/python-list
Re: Are the critiques in "All the things I hate about Python" valid?
On 2/18/18 8:16 PM, Ben Finney wrote: Dennis Lee Bieber writes: On Mon, 19 Feb 2018 00:09:40 + (UTC), Steven D'Aprano declaimed the following: Or more realistically, suppose you want your type system to ensure that you don't lay off the wrong workers: "employee records where the length of employment is greater than six months but less than five years, AND the salary is greater than $100,000 or less than $40,000, AND the average number of paid sick days taken per year over the last three years is less than five, AND the number of reprimands is zero in the last year and less than two in the last five years, AND the position in the last two stack rankings was in the top fifty percent" That's not a data type -- that's an SQL query... If that isn't part of the definition of the data type, then *the type checker is not going to help* to determine whether the code lays off the wrong workers. Doesn't sound like the sort of thing that you should expect a Type Checker to find. Now, perhaps you could define a type of something like 'Layoffable_Employee' with an invariant based on the above, then the layoff module could insist that it will only that an Layoffable_Employee, and the type uses pre-/post- conditions to confirm the needed conditions. Now, somewhere in the code you probably started with an Employee, and then to pass it to the module you will need to convert the type of the object (it seems unlikely that such a type is inherent in most of the rest of the code). This is why it doesn't make sense for it to be a 'Type', but more likely an attribute/predicate of the object, that the Layoff module can confirm as a pre-condition. The data type is still "employee" I think you're agreeing with Steven. Static data types are not relevant for finding most of the bugs a program can have. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Are the critiques in "All the things I hate about Python" valid?
On 2/19/18 10:35 AM, Chris Angelico wrote:
On Tue, Feb 20, 2018 at 12:34 AM, Steven D'Aprano
wrote:
On Mon, 19 Feb 2018 20:14:32 +1100, Chris Angelico wrote:
As an integer, 3.141590 is 107853 $
Looks to me like C is perfectly happy to interpret a float as an int.
Yes, but that's not an *automatic* coercion. To count as weakly typed,
the compiler has to do it automatically, without an explicit cast or
conversion.
Fair enough. If you ignore warnings, then C does have that kind of weak typing:
$ cat demo.c
#include
int main() {
float f = 3.14159;
int *i = &f;
printf("As an integer, %f is %d\n", f, *i);
return 0;
}
$ gcc demo.c
demo.c: In function ‘main’:
demo.c:5:14: warning: initialization from incompatible pointer type
[-Wincompatible-pointer-types]
int *i = &f;
^
$
GCC was quite happy to compile that code, even though the type of "&f"
is "pointer to float", and it's being assigned to a variable of type
"pointer to int". But C is a language saddled with so much history and
backward compatibility constraints that there are some things you just
CAN'T make into errors; so in terms of "how safe is C?", I'd have to
say that warnings (especially those that are enabled by default - I
didn't need to say "-Wall" for this test), count as "disallowing",
especially if all the major compilers emit warnings on the same code.
But I do see the argument that "it compiles, so the language clearly
permits it".
ChrisA
One thing to note, that is more an issue with GCC than with C. By the
standard, that is a constraint violation, that requires a diagnostic,
and the C standard says it provides no definition of what should happen
here, which is about as strong as it gets to defining something as an
'Error', the only thing with a stronger requirement is the #error
statement which must not running the program.
GCC has decided that this diagnostic will be considered just a 'Warning'
and provides its own meaning to the statement. You really want to run
with pedantic-errors enabled to get GCC to reject code with constraint
violations.
--
Richard Damon
--
https://mail.python.org/mailman/listinfo/python-list
Re: Are the critiques in "All the things I hate about Python" valid?
> On Feb 20, 2018, at 8:58 AM, Chris Angelico wrote: > >> On Wed, Feb 21, 2018 at 12:53 AM, Antoon Pardon wrote: >> In C++ I can do something like: >> >> SomeClass MyVar; >> >> And after that the kind of possible assignments to MyVar are constraint. It >> makes the runtime throw an error when somewhere the program tries to assign >> something to MyVar that isn't allowed by SomeClass. >> >> You can't put such constraints on names in Python. >> >> In C++ I can do some like: >>Some_Class: MyVar; >> >> And after that, It will be impossible to assign a value to MyVar that >> doesn't meet the >> constraints imposed by the constructor/copy operator. You have put >> somekind of >> contract on the name MyVar, that limits the kind of things assignable to >> it. You >> can't put such constraints on a name in Python. > > Okay. Now create a constraint on a name in C++ such that it can only > accept integers representing A.D. years which, on the Gregorian > calendar, are leap years. (Using a dedicated integer-like type is > permitted.) It must accept all multiples of four, except those which > are multiples of one hundred, unless they're also multiples of four > hundred. > > That's what Steve asked for. Can you do it? Or is the C++ type system > not flexible enough for that? > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list Such a class would be fairly trivial to write in C++, or I suspect Python. In C++ you would have a constructor and possibilities an assignment operator that takes an integer, tests it for validity and throw/asserts if it is incorrect. (Depending on other requirements, you might allow or not implicit conversions) It probably also has a constructor and an assignment operator that takes a ‘LeapYear’ and just uses it. To be usable, it will need something to allow you to get the integer value out, might be implicit or explicit. The big issue with such a type, and why it doesn’t make much sense as a type, is that there is very little that can be done with such a type, as there is no interesting operation for which the type is at least mostly closed under, at best it is closed under +400*n -- https://mail.python.org/mailman/listinfo/python-list
Re: Are the critiques in "All the things I hate about Python" valid?
On 2/20/18 3:51 PM, Chris Angelico wrote:
On Wed, Feb 21, 2018 at 7:42 AM, Rick Johnson
wrote:
On Tuesday, February 20, 2018 at 2:18:31 PM UTC-6, MRAB wrote:
The point he was making is that if you store a person's age, you'd have
to update it every year. It's far better to store the date of birth and
calculate the age on demand.
*AHEM*
At the risk of being labeled a "quibbler" (which, in the
grander scheme is not really all that bad considering some
of the names that have been attributed to me), i must say
your advice is only "sound advice" in cases where the age
will not be queried frequently.
For instance, if the age is queried many times a second, it
would be a much wiser design to set-up an event that will
advance the age at the end of the last second of every year,
instead of doing the age calculation many times a second.
Heck, even if the frequency is multiple time a day, a valid
argument could be made.
Nope. Even if you need the age many times per second, it's still
better to store the date of birth, because you eliminate boundary
conditions and duplicated data. But that's assuming you're storing the
age of *a person*. If the age in question is a boundary ("motor
insurance premiums are increased if the driver is 65 years or older"),
then it's still sane to store the age.
ChrisA
I would normally expect that the persistent store would have a birth
date of the person, but within a local operation, you likely want to be
able to assume the consistency of a attribute like over 55 years old, so
you would compute the age, for that operation, but not keep it beyond
that. Otherwise, depending on the order of doing your checks you may
find that during your processing they are either both or neither of
under 55 and over 55. It is much easier to reason that your code is
correct when you can prevent (and thus ignore) such data races. This
normally means your operation grabs the value of 'now' once, and all
processing will be based on THAT point of time, not what currently is
'now'. How big this 'timestop' needs to be depends on how wide the
requirement is for temporal consistency. It might be just within a
function, it might be for the full duration of the program run, 'now'
might even be a parameter to the program, i.e. as of last (or next)
midnight, do the computation.
--
Richard Damon
--
https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
On 2/28/18 11:00 PM, ROGER GRAYDON CHRISTMAN wrote: On Wed, Feb 28, 2018, Rick Johnson wrote: > On Wednesday, February 28, 2018 at 5:02:17 PM UTC-6, Chris Angelico wrote: Here's one example: reference cycles. When do they get detected? Taking a really simple situation: class Foo: def __init__(self): self.self = self *shudders* Can you provide a real world example in which you need an object which circularly references_itself_? This looks like a highly contrived example used to (1) merely win the argument, and (2) Bump fib() up one position from it's current position as "the worst introductory example of how to write a function in the history of programming tutorials" If you want something that looks like a real world example, consider the very common doubly-linked list: [ 1 ] <---> [ 2 ] <---> [ 3 ] <--.--> [ N ] This is chock-full of reference cycles, everywhere you see a <--> Then you have a wrapper List object that has a head referencing the 1 node and a tail referencing the N node. And you decide you don't need that List any more. You could: 1) Take the time the code to carefully delete every single node in this linked list, taking the time to set all of the internal references to None, or 2) Just discard your List object, and let the GC take care of the rest. Note that removing the list alone does not clear any of the reference counts in the picture above, because those internal <--> references are all still there. You either have to manually remove all the references, or rely on the garbage collector. Oh, and for those who claim that reference counting is 'efficient', do bear in mind that every single assignment statement increases the reference count of one value and possibly reduces the reference count of another. So down in the machine or byte-code world, every assignment operation is really two arithmetic computations and three assignments, which takes 5 times as many operations as not doing any reference counting at all. So if you have a program that can get by leaving unused memory allocated, and can still terminate the program before all the memory is claimed, your reference count system is far less efficient than relying on a garbage collector that happens to not get activated before your program ends. Roger Christman Pennsylvania State University Now, of course in a language that WANT'S to make reference counting work, and allow for deterministic destruction of object happen, all you need to do is make one direction of the pointer into a 'weak reference', and the list control object have a strong pointer to the end that starts the strong chain and a weak reference to the other, and when the list control object goes away, so does all the list elements. Yes, there is a slight speed cost in keeping the reference counts, but there is also a significant cost to the processing that is needed to run the garbage collection. And that doesn't include the cost of having to explicitly manage all resources that aren't memory as you have broken the RAII concept. I will agree that many programs many programs don't need precise destruction for most of their objects, but many can be helped by it for at least a specific set of them. I am not sure how hard it would be to implement a really useful reference counting system in Python, as first you would need a concept of a weak pointer to deal with cases like your list above (which I don't think Python has anything like that concept). You would also need to keep the current garbage collection, to handle the existing cases of circular references (I disagree with the original complaint that these are always 'errors', if you know you have garbage collection, the allowance of cycles knowing they will still get cleaned up is a useful simplification if you don't need the immediate clean up). -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction (Posting On Python-List Prohibited)
On 3/3/18 9:03 AM, Ian Kelly wrote: On Fri, Mar 2, 2018 at 9:57 PM, Gregory Ewing wrote: Paul Rubin wrote: So you want the programmer to put more head scratching into figuring out which reference should be strong and which should be weak? Also, sometimes weak references don't really solve the problem, e.g. if you have a graph where you can't identify any particular node as a "root" node, and you want the graph to stay around as long as any of its nodes are referenced. I offered two possible solutions for the graph problem elsewhere in this thread. For the record I'm not in favor of the OP's proposal (although making the different Python implementations more consistent in their garbage collection semantics would not be a bad thing per se) but I am somewhat mystified as to why people seem to think that weak refs are difficult to use correctly. As I think about this, and coming from a background where I have found the ability to reliably use RAII useful in some cases, I can see some merit to the proposal. One big issue is that since Python doesn't have sub-function level lifetime scopes for locals, it is perhaps not quite as useful in some cases. One idea does come to mind though, would it be reasonable, and somewhat Pythonic, for a class to define member functions like __ref__ and __unref__ (or perhaps some other name) that if defined, would be called every time a name was bound or unbound to an object? (the assignment to a name should __ref__ the new value, then __unref__ the old to avoid possible issues with rebinding an object to the last name it was bound to). This would allow those (limited) objects that want to be destroyed as soon as possible to do so, but most other objects wouldn't have any significant overhead added (just a check for this method). Objects with these methods would still be subject to being cleaned up with garbage collection in the case they were kept alive via a cycle, having the cycle just makes it so that you don't get the immediate distruction. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
On 3/3/18 11:33 AM, Michael Torrie wrote: On 03/03/2018 09:02 AM, [email protected] wrote: I can assure you that RAII does what it says on the tin and is relied on in many critical systems to release resources robustly ... given the pre-requisite deterministic destruction. Sure but did you read what Paul Moore wrote? He said RAII works in C++ because objects are allocated on the *stack* with strict lifetimes and scopes. They won't ever have cycles and they are guaranteed to be destroyed no matter what as the stack is unwound. Python has no stack-allocated objects. In C++, Heap-allocated objects must still be managed manually, without the benefit of RAII, for much of the same reasons as people are giving here for why RAII is not a good fit for Python. There are smart pointer objects that try to give RAII semantics to heap-allocated objects, with varying degrees of success. In other words there are some limitations. Python does not have stack-allocated objects, so the same issues that prevent RAII from automatically applying in C++ to heap objects exist here. Yes, stack allocated object in C++ have a nice lifetime to allow RAII to work, but it doesn't just work with stack allocated objects. A lot of RAII objects are members of a class object that may well be allocated on the heap, and RAII makes sure that all the needed cleanup gets done when that object gets destroyed. Yes, I suspect that directly creating a RAII control object as the sole object on the heap is unusual, but that doesn't make the never appear on the heap. When the resource is memory, since one chunk of memory tends to be just as usable as another, garbage collection works great. Other resources can be quite precious, and delays in releasing them can have significant effects. With RAII and immediate destruction on end of scope, we can automate the release, without it and you need a lot of explicit code to manage these resources. Maybe the issue is that most Pythonic code doesn't need to deal with these sorts of resources where this becomes important to be dealt with automatically, either being held for the whole program so OS cleanup handles it, or the are so fine grained that the explicitness isn't an issue. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
On 3/3/18 12:43 PM, Chris Angelico wrote: On Sun, Mar 4, 2018 at 4:37 AM, Richard Damon wrote: On 3/3/18 11:33 AM, Michael Torrie wrote: On 03/03/2018 09:02 AM, [email protected] wrote: I can assure you that RAII does what it says on the tin and is relied on in many critical systems to release resources robustly ... given the pre-requisite deterministic destruction. Sure but did you read what Paul Moore wrote? He said RAII works in C++ because objects are allocated on the *stack* with strict lifetimes and scopes. They won't ever have cycles and they are guaranteed to be destroyed no matter what as the stack is unwound. Python has no stack-allocated objects. In C++, Heap-allocated objects must still be managed manually, without the benefit of RAII, for much of the same reasons as people are giving here for why RAII is not a good fit for Python. There are smart pointer objects that try to give RAII semantics to heap-allocated objects, with varying degrees of success. In other words there are some limitations. Python does not have stack-allocated objects, so the same issues that prevent RAII from automatically applying in C++ to heap objects exist here. Yes, stack allocated object in C++ have a nice lifetime to allow RAII to work, but it doesn't just work with stack allocated objects. A lot of RAII objects are members of a class object that may well be allocated on the heap, and RAII makes sure that all the needed cleanup gets done when that object gets destroyed. How do you guarantee that the heap object is properly disposed of when you're done with it? Your RAII object depends 100% on the destruction of the heap object. ChrisA Yes, the heap object 'owns' a resource, and as long as that heap object exists, the resource needs to exist, but as soon as it doesn't, you want that resource freed. That heap object might well be controlled by some other RAII object (maybe a smart pointer with a ref count) or maybe that object is being manually controlled by the program. But the key is that when it goes away, all of the resources it controls via RAII are automatically cleaned up, and you don't need all that cleanup made explicit in the owning class. If the resource is plentiful, like memory, we can simplify the life management by using something like garbage collection, so if some is used longer than needed it isn't a big issue. Other resources are much more valuable and limited, and it is important to release them when no longer needed. Without some method to make sure that happens 'automatically' as soon as possible, it requires that the programmer explicitly deal with it in full detail. Now, a lot of talk has been throw around about things like reference cycles getting in the way of this, but practically, the resources that this would be needed for, then not to get involved in those sorts of issues, but tend to live in more simple structures, so the fact that objects in a cycle might need for the garbage collector to determine they aren't used anymore isn't an issue (and the presence of garbage collection says that these more complicated structures, which only hold resources that are plentiful, don't need to be precisely managed will RAII controls). -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
On 3/3/18 1:28 PM, Chris Angelico wrote: On Sun, Mar 4, 2018 at 5:22 AM, Richard Damon wrote: On 3/3/18 12:43 PM, Chris Angelico wrote: On Sun, Mar 4, 2018 at 4:37 AM, Richard Damon wrote: On 3/3/18 11:33 AM, Michael Torrie wrote: On 03/03/2018 09:02 AM, [email protected] wrote: I can assure you that RAII does what it says on the tin and is relied on in many critical systems to release resources robustly ... given the pre-requisite deterministic destruction. Sure but did you read what Paul Moore wrote? He said RAII works in C++ because objects are allocated on the *stack* with strict lifetimes and scopes. They won't ever have cycles and they are guaranteed to be destroyed no matter what as the stack is unwound. Python has no stack-allocated objects. In C++, Heap-allocated objects must still be managed manually, without the benefit of RAII, for much of the same reasons as people are giving here for why RAII is not a good fit for Python. There are smart pointer objects that try to give RAII semantics to heap-allocated objects, with varying degrees of success. In other words there are some limitations. Python does not have stack-allocated objects, so the same issues that prevent RAII from automatically applying in C++ to heap objects exist here. Yes, stack allocated object in C++ have a nice lifetime to allow RAII to work, but it doesn't just work with stack allocated objects. A lot of RAII objects are members of a class object that may well be allocated on the heap, and RAII makes sure that all the needed cleanup gets done when that object gets destroyed. How do you guarantee that the heap object is properly disposed of when you're done with it? Your RAII object depends 100% on the destruction of the heap object. ChrisA Yes, the heap object 'owns' a resource, and as long as that heap object exists, the resource needs to exist, but as soon as it doesn't, you want that resource freed. That heap object might well be controlled by some other RAII object (maybe a smart pointer with a ref count) or maybe that object is being manually controlled by the program. But the key is that when it goes away, all of the resources it controls via RAII are automatically cleaned up, and you don't need all that cleanup made explicit in the owning class. You're trying to handwave away the *exact point* that we are all making: EVERY object in Python is a heap object. So how is your magic wand going to make any of this work? You have to do it exclusively with heap objects because there is nothing else available. ChrisA Because while every OBJECT in Python is on the heap, not every THING is, as you do have local and global names bound to those objects. This is like in C++, in C++ there is no way to directly reference an object on the heap, but need to use a stack or statically allocated object or reference (which has a name) to get to it. The fact that all objects exist on the heap actually makes some things simpler, in C++ you need to be careful with smart pointers that they only point to objects on the heap, and thus are delete-able. If you accidentally put the address of a static or stack based object into one of them (and don't add a fake reference to the count) you will run into an issue when the reference count goes to zero and you try to destroy and then free the memory for the object. In Python, that can't happen. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: cute interview problem
On 2/28/18 3:51 PM, Ian Kelly wrote: On Wed, Feb 28, 2018 at 12:55 PM, wrote: On Tuesday, 27 February 2018 00:42:02 UTC+1, Paul Rubin wrote: Ron Aaron posted the below url on comp.lang.forth. It points to what I thought was a cute problem, along with his solution in his Forth dialect 8th: https://8th-dev.com/forum/index.php/topic,1584.msg8720.html I wrote a solution in Forth and additional ones in Python and Haskell and thought people here might like trying it themselves. I'll post my Python version here in a few days if anyone wants to see it. Time limit for the problem is supposed to be 45 minutes. I spent a lot longer because I ended up writing several versions in various languages. I dont think its cute at all. how did the interview go? Yeah, seems to me this is basically just asking "have you ever heard of an interval tree (or can you invent one on the fly)". An interval tree sounds a bit more complicated than you really need (there is no need to keep the original list of intervals intact, we just need to know if a number was in ANY forbidden interval). All you really need to do is build a binary search tree of disjoint intervals, where before actually adding the next interval in the list you find the intervals it is between and merge rather than add if it overlaps (or is adjacent), and merging the two intervals (the prior and next) if it fills all the space between. The output is just a simple walking of the tree and processing the gaps between recorded forbidden intervals. You also could just build up a tree of forbidden intervals, sorted by starting value, and not consider overlaps, and in the output walk just keep track of the highest end of interval encountered so far to effectively merge them at readout time. -- https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
On 3/3/18 6:49 PM, Steven D'Aprano wrote: On Sat, 03 Mar 2018 12:37:08 -0500, Richard Damon wrote: With RAII and immediate destruction on end of scope, we can automate the release, without it and you need a lot of explicit code to manage these resources. Not so much. with resource_i_care_about() as rsrc: process(rsrc) is hardly what I call "a lot of explicit code". Yes, there's some code in the context manager, but you write that *once* (if it isn't already written for you!) and you're done. The with statement handles the C++ case of using a unique_ptr, where the resource is aquired and release within a single block scope and thus a single stack based object is ultimately responsible for the lifetime of the resource. I am not sure how it would handle a resource that gets shared for a while with something like a shared_ptr, and needs to be released when all the people who is has been shared with are done with their copy. Admittedly, this case is much less likely to be using such a critical resource, but it might. In Python, currently, you would either need to keep an explicit usage count to allow you to delete it when done, or let things wait for the collector to find it. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction (Posting On Python-List Prohibited)
On 3/3/18 6:57 PM, Steven D'Aprano wrote: On Sat, 03 Mar 2018 10:01:43 -0700, Ian Kelly wrote: On Sat, Mar 3, 2018 at 9:19 AM, Richard Damon wrote: One idea does come to mind though, would it be reasonable, and somewhat Pythonic, for a class to define member functions like __ref__ and __unref__ (or perhaps some other name) that if defined, would be called every time a name was bound or unbound to an object? (the assignment to a name should __ref__ the new value, then __unref__ the old to avoid possible issues with rebinding an object to the last name it was bound to). This would allow those (limited) objects that want to be destroyed as soon as possible to do so, but most other objects wouldn't have any significant overhead added (just a check for this method). Objects with these methods would still be subject to being cleaned up with garbage collection in the case they were kept alive via a cycle, having the cycle just makes it so that you don't get the immediate distruction. This sounds like a nightmare for performance. Ref counting is enough of a drain already when it's done in C, using macros for in-lining. Now every time the count would be incremented or decremented, we'd also need to check the class __dict__ to see if there's a corresponding Python method, build a frame object, and then call it in the interpreter. Not just the class __dict__. You would have to do a full search of the MRO looking for any superclass which defines such methods. Python code doesn't tend to go in for long inheritance hierarchies, but still, you could easily be checking four or five classes on *every* binding. Richard's assertion that this wouldn't add significant overhead isn't right. [...] It would be much more efficient to spare all that by doing the ref-counting in the interpreter and just call a method when it hits zero. Which is just what CPython already does. Indeed. I'm afraid I don't understand what Richard's proposal is actually meant to do. It sounds to me like he's just proposed adding a second, parallel, optional, *SLOW* reference counter to the CPython implementation, in order to force non-ref counter implementations to do something which they have no need to do. If checking for a method definiton is that slow, it wouldn't work. The idea was to have a way to mark that certain classes/objects request that they are reference counted so they get the __del__ called as soon as the last reference goes away, without needing to require that overhead for all objects in all implementations. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
On 3/3/18 9:10 PM, Chris Angelico wrote: On Sun, Mar 4, 2018 at 1:01 PM, Ooomzay wrote: On Saturday, 3 March 2018 17:44:08 UTC, Chris Angelico wrote: On Sun, Mar 4, 2018 at 4:37 AM, Richard Damon Yes, stack allocated object in C++ have a nice lifetime to allow RAII to work, but it doesn't just work with stack allocated objects. A lot of RAII objects are members of a class object that may well be allocated on the heap, and RAII makes sure that all the needed cleanup gets done when that object gets destroyed. How do you guarantee that the heap object is properly disposed of when you're done with it? Your RAII object depends 100% on the destruction of the heap object. Smart pointers (unique_ptr and friends) are used to manage heap object lifecycles n . These are analogous to python object references. Yep, cool. Now do that with all of your smart pointers being on the heap too. You are not allowed to use ANY stack objects. ANY. Got it? ChrisA Now write your Python without using anything not on the heap either (so no binding your objects to a name). As Chris said, the stack variables in C++ are the local names used to refer to the objects. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
On 3/4/18 8:46 AM, Chris Angelico wrote: On Mon, Mar 5, 2018 at 12:26 AM, Ooomzay wrote: Well refcounts are definitely "doable": This is how the reference python implementation, CPython, currently manages to comply with this PEP and can therefore be used for RAII. This PEP is an attempt to _guarantee_ this behaviour and make the elegance of RAII available to all pythonistas that want it. Without this guarantee python is not attractive to applications that must manage non-trivial resources reliably. Aside: I once read somewhere that must have seemed authoritative at the time, that CPython _guarantees_ to continue to behave like this - but now the subject is topical again I can find no trace of this guarantee. That's because there is no such guarantee. In fact, you can probably find places in the docs where it is specifically stated that you cannot depend on __del__ for this. You still haven't said how you're going to cope with reference cycles - or are you expecting every single decref to do a full cycle check? ChrisA My presumption of the proposal is the it does NOT expect that __del__ be called just because an object is no longer reachable but is in a cycle of isolated objects, those would still need to wait for the garbage collector to get them. The request is that when the direct reference count goes to 0, that __del__ gets called. I think that is what CPython promises (but not other versions). I am not positive if __del__ gets called for sure when the object is garbage collected (I thought it did, but I am not positive). I am pretty sure it does NOT get called on object that are still in existence when things terminate (which would be the major difference from a language like C++) What the language does not promise is that in general, __del__ be called 'immediately' on the last reference going away in the general case, because CPythons reference counting is an implementation detail. My understanding of this proposal is to ask that, I would say at least for selected objects, that all implementations perform this reference counting, allowing objects that track 'critical resources' to get disposed of in a timely manner and not wait for garbage collection. And that this is triggered only by the reference count going to zero, and not if the object happens to be in an isolated reference cycle. This does limit what you can do with this sort of object, but that normally isn't a problem. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
On 3/4/18 6:55 PM, Ned Batchelder wrote: On 3/4/18 5:25 PM, Ooomzay wrote: On Sunday, 4 March 2018 14:37:30 UTC, Ned Batchelder wrote: Are you including cyclic references in your assertion that CPython behaves as you want? Yes. Because the only behaviour required for RAII is to detect and debug such cycles in order to eliminate them. It is a design error/resource leak to create an orphan cycle containing RAII objects. def main(): gc,disable This isn't a reasonable position. Cycles exist, and the gc exists for a reason. Your proposal isn't going to go anywhere if you just naively ignore cycles. --Ned. While Ooomzay seems to want to say that all cycles are bad, I think it is fair to say that in general in Python they are unavoidable, in part because I can't see any good way to create the equivalent of a 'weak reference' (names aren't objects so don't have properties). The best I can think of is to create some sort of magical object that can refer to another object, but that reference 'doesn't count'. This seems very unPythonic. What I think can be said is that it should be possible (enforced by the programmer, not the language) to use these RAII objects in ways that don't create cycles (or maybe that the program knows of the cycles and makes the effort to break them when it is important). So perhaps it can be said that cycle that involve major resource RAII objects should exist. -- 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: 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: 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 Da
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: 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: 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: 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: 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: What should go to stdout/stderr and why Python logging write everything to stderr?
> On Jan 3, 2023, at 10:38 AM, [email protected] 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: No solution for "--verbose" (on stdout) output in Pythonds standard library?
> On Jan 4, 2023, at 8:56 AM, [email protected] 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: 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 [email protected]: 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: evaluation question
On 2/1/23 3:59 AM, [email protected] wrote: On Wed, 1 Feb 2023 11:59:25 +1300 Greg Ewing wrote: On 31/01/23 10:24 pm, [email protected] 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: 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: 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: 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: Weak Type Ability for Python
On 4/13/23 7:25 PM, [email protected] 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: 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: 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: 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: 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: 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: Button placement
On 3/9/21 6:24 AM, Bischoop wrote: > On 2021-03-09, Peter Otten <[email protected]> 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: 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: 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: .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: .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 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 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/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: 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: A 35mm film camera represented in Python object
On 4/1/21 6:41 PM, [email protected] 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: 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: 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/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, [email protected] 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/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 [email protected]. 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 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, [email protected] 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 > &g
Re: for the installation of pycharm
On 5/8/21 10:49 AM, [email protected] 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
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: 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
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: 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: 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: 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 > > > ]> > &e; > 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: 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: 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: 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 jus
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 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: 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: 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: 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: 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: 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: Entering a very large number
On 3/23/18 9:35 AM, ast wrote: Le 23/03/2018 à 14:16, Antoon Pardon a écrit : On 23-03-18 14:01, ast wrote: Le 23/03/2018 à 13:43, Rustom Mody a écrit : On Friday, March 23, 2018 at 5:46:56 PM UTC+5:30, ast wrote: What meaningful information from number can you easily retrieve from representing the number in some kind of table form that you can't from just writing the number on one line? digit n° 103 is 1 digit n° 150 is 7 ... If the value of the specific digits is meaningful, they you likely don't really have a number, but a digital representation, for which a string is probably the better way to define it, and take the cost of the conversion as part of the cost to be pretty. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Putting Unicode characters in JSON
On 3/23/18 6:35 AM, Chris Angelico wrote:
On Fri, Mar 23, 2018 at 9:29 PM, Steven D'Aprano
wrote:
On Fri, 23 Mar 2018 18:35:20 +1100, Chris Angelico wrote:
That doesn't seem to be a strictly-correct Latin-1 decoder, then. There
are a number of unassigned byte values in ISO-8859-1.
That's incorrect, but I don't blame you for getting it wrong. Who thought
that it was a good idea to distinguish between "ISO 8859-1" and
"ISO-8859-1" as two related but distinct encodings?
https://en.wikipedia.org/wiki/ISO/IEC_8859-1
The old ISO 8859-1 standard, the one with undefined values, is mostly of
historical interest. For the last twenty years or so, anyone talking
about either Latin-1 or ISO-8859-1 (with or without dashes) is almost
meaning the 1992 IANA superset version which defines all 256 characters:
"In 1992, the IANA registered the character map ISO_8859-1:1987,
more commonly known by its preferred MIME name of ISO-8859-1
(note the extra hyphen over ISO 8859-1), a superset of ISO
8859-1, for use on the Internet. This map assigns the C0 and C1
control characters to the unassigned code values thus provides
for 256 characters via every possible 8-bit value."
Either that, or they actually mean Windows-1252, but let's not go there.
Wait, whaaa...
Though in my own defense, MySQL itself seems to have a bit of a
problem with encoding names. Its "utf8" is actually "UTF-8 with a
maximum of three bytes per character", in contrast to "utf8mb4" which
is, well, UTF-8.
In any case, abusing "Latin-1" to store binary data is still wrong.
That's what BLOB is for.
ChrisA
One comment on this whole argument, the original poster asked how to get
data from a database that WAS using Latin-1 encoding into JSON (which
wants UTF-8 encoding) and was asking if something needed to be done
beyond using .decode('Latin-1'), and in particular if they need to use a
.encode('UTF-8'). The answer should be a simple Yes or No.
Instead, someone took the opportunity to advocate that a wholesale
change to the database was the only reasonable course of action.
First comment, when someone is proposing a change, it is generally put
on them the burden of proof that the change is warranted. This is
especially true when they are telling someone else they need to make
such a change.
Absolute statements are very hard to prove (but the difficulty of proof
doesn't relieve the need to provide it), and in fact are fairly easy to
disprove (one counter example disproves an absolute statement). Counter
examples to the absolute statement have been provided.
When dealing with a code base, backwards compatibility IS important, and
casually changing something that fundamental isn't the first thing that
someone should be thinking about, We weren't given any details about the
overall system this was part of, and they easily could be other code
using the database that such a change would break. One easy Python
example is to look back at the change from Python 2 to Python 3, how
many years has that gone on, and how many more will people continue to
deal with it? This was over a similar issue, that at least for today,
Unicode is the best solution for storing arbitrary text, and forcing
that change down to the fundamental level.
--
Richard Damon
--
https://mail.python.org/mailman/listinfo/python-list
Re: Entering a very large number
On 3/25/18 8:32 AM, bartc wrote: On 25/03/2018 02:47, Steven D'Aprano wrote: On Sun, 25 Mar 2018 00:05:56 +0100, Peter J. Holzer wrote: [...] yes, good idea Not if you want to avoid that string to int conversion (as you stated). That is still there, but in addition you now split the string into a list and then join the list into a different string. I'm glad I wasn't the only one who spotted that. There's something very curious about somebody worried about efficiency choosing a *less* efficient solution than what they started with. To quote W.A. Wulf: "More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason — including blind stupidity." As Donald Knuth observed: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." The Original Poster (OP) is concerned about saving, what, a tenth of a microsecond in total? Hardly seems worth the effort, especially if you're going to end up with something even slower. Using CPython on my machine, doing a string to int conversion that specific number took 200 times as long as doing a normal assignment. That conversion took 4 microseconds. Not significant if it's only done once. But it might be executed a million times. The other half of that thought is how does the 4 microseconds to create the constant compare to the operations USING that number. My guess is that for most things the usage will swamp the initialization, even if that is somewhat inefficient. One option, which in my opinion is more readable, is if you really want the efficency is to write the number on a single line, with a place guide comment above, something like # 0112233445 # 12345678901234567890123456789012345678901234567890 foo = 13452356547242573457246245673472457723245634564564 This makes it very clear what the 47th digit of the number is (run the guide numbers in the direction that makes sense for you) Yes, you will have a very long line (several in fact with the guide comment), but that 'uglyness' is worth it if the time cost turns out to be significant. After all, correctness outweighs elegance (but maybe not clarity, but the long line isn't unclear, just a bit ugly), so if the time cost make the program violate the specs to be useful, you need a bit of ugly to get it to work. (The other option would be to initialize into a global variable, which has its own type of ugly)). -- https://mail.python.org/mailman/listinfo/python-list
Re: Entering a very large number
On 3/25/18 9:37 PM, bartc wrote:
On 26/03/2018 00:27, Richard Damon wrote:
On 3/25/18 8:32 AM, bartc wrote:
Using CPython on my machine, doing a string to int conversion that
specific number took 200 times as long as doing a normal assignment.
That conversion took 4 microseconds.
Not significant if it's only done once. But it might be executed a
million times.
The other half of that thought is how does the 4 microseconds to
create the constant compare to the operations USING that number. My
guess is that for most things the usage will swamp the
initialization, even if that is somewhat inefficient.
Calling a function that sets up C using 'C = 288714...' on one line,
and that then calculates D=C+C, takes 0.12 seconds to call 100 times.
To do D=C*C, takes 2.2 seconds (I've subtracted the function call
overhead of 0.25 seconds; there might not be any function call).
If I instead initialise C using 'C = int("288712...")', then timings
increase as follows:
0.12 => 3.7 seconds
2.2 => 5.9 seconds
So the overhead /can/ be substantial, and /can/ be significant
compared with doing bignum calculations.
Of course, once initialised, C might be used a hundred times, then the
overhead is less significant. But it is not small enough to just dismiss.
And my point is that writing a program to just add or multiply once two
FIXED big long numbers (since they are in the source code, that seems
fixed), a million times seems unlikely (and even then the cost isn't
that bad, since that sounds like a run once program). And of course once
the answer has been computed, it needs to be output somehow, which
likely will add to the time significantly. The question would be do you
have a REAL PRACTICAL case where this overhead actually makes a
significant difference, or are we just talking a theoretical toy. It is
a fact that it seems the language has no notation to express such a
large number as a number in source code on mulitple lines (except as a
string). I would think it would take something more than a toy program
to persuade for something notation to do this directly (and there are
alternatives that have been mentioned that aren't that bad for this sort
of corner case).
--
Richard Damon
--
https://mail.python.org/mailman/listinfo/python-list
Re: Entering a very large number
On 3/26/18 6:45 AM, bartc wrote:
On 26/03/2018 03:35, Richard Damon wrote:
On 3/25/18 9:37 PM, bartc wrote:
So the overhead /can/ be substantial, and /can/ be significant
compared with doing bignum calculations.
Of course, once initialised, C might be used a hundred times, then
the overhead is less significant. But it is not small enough to just
dismiss.
And my point is that writing a program to just add or multiply once
two FIXED big long numbers (since they are in the source code, that
seems fixed), a million times seems unlikely (and even then the cost
isn't that bad, since that sounds like a run once program).
Similar overheads occur when you use string=>int even on small numbers:
This code:
C = int("12345")
D = C+C # or C*C; about the same results
takes 5 times as long (using my CPython 3.6.x on Windows) as:
C = 12345
D = C+C
Your arguments that this doesn't really matter would equally apply here.
Yet you don't see Python code full of 'int("43")' instead of just '43'
on the basis that the extra overhead is not significant, as the
program might be run only once.
A slightly worrying attitude in a language that has issues with
performance, but no longer a surprising one.
Strawman. The original argument was that there was sufficient clarity
grounds to want to express the big number as a string. That base
argument doesn't hold here, and in fact for small number the construct
clearly makes the code less clear, so the construct fails there. If the
numbers were formatted in a way that using a string, and doing some
manipulations on it first, and then converting made sense, you might be
able to make the argument, but then again it comes down to efficiency vs
clarity, and for that, as long as efficiency hasn't suffered enough to
start to become a correctness issue, clarity has an edge.
--
Richard Damon
--
https://mail.python.org/mailman/listinfo/python-list
Re: Entering a very large number
On 3/26/18 6:31 AM, bartc wrote:
On 26/03/2018 10:34, Steven D'Aprano wrote:
On Mon, 26 Mar 2018 02:37:44 +0100, bartc wrote:
If I instead initialise C using 'C = int("288712...")', then timings
increase as follows:
Given that the original number given had 397 digits and has a bit length
of 1318, I must admit to some curiosity as to how exactly you managed to
cast it to a C int (32 bits on most platforms).
It is too big for an int, a long (64 bits), a long-long (128 bits) or
even a long-long-long-long-long-long-long-long-long-long-long-long-long-
long-long-long (1024 bits), if such a thing even exists.
So what exactly did you do?
I'm not sure why you think the language C came into it. I did this:
def fn():
C = int(
"28871482380507712126714295971303939919776094592797"
"22700926516024197432303799152733116328983144639225"
"94197780311092934965557841894944174093380561511397"
"4215424169339729054237110027510420801349667317"
"5515285922696291677532547505856101949404200039"
"90443211677661994962953925045269871932907037356403"
"22737012784538991261203092448414947289768854060249"
"76768122077071687938121709811322297802059565867")
# C = 2887148238050771212671429... [truncated for this post]
D=C+C
for i in range(100):
fn()
The purpose was to establish how such int("...") conversions compare
in overheads with actual arithmetic with the resulting numbers.
Of course if this was done in C with a version that had builtin bignum
ints or an aggresive enough optimizer (or a Python that did a similar
level of optimizations) this function would just test the speed of
starting the program, as it actually does nothing and can be optimized
away. Yes, something like this can beused to measure the base time to do
something, but the real question should be is that time significant
compared to the other things that the program is doing, Making a 200x
improvement on code that takes 1% of the execution time saves you
0.995%, not normally worth it unless your program is currently running
at 100.004% of the allowed (or acceptable) timing, if acceptable timing
can even be defined that precisely.
--
Richard Damon
--
https://mail.python.org/mailman/listinfo/python-list
