Re: How make your module substitute a python stdlib module.
Op 27/12/2022 om 16:49 schreef Thomas Passin: On 12/27/2022 8:25 AM, Antoon Pardon wrote: Op 27/12/2022 om 13:46 schreef Chris Angelico: On Tue, 27 Dec 2022 at 23:28, Antoon Pardon wrote: At the moment I am happy with a solution that once the programmer has imported from QYZlib.threaders that module will used as the threading module. Oh! If that's all you need, then yes, a simple patch of sys.modules will work. You'll have to make sure you get your module imported before anything else pulls up the vanilla one, though. Otherwise, your only option is to keep the existing module object and monkeypatch it with whatever changes you need. But a simple "sys.modules['threading'] = QYZlib.threaders" will work. Of course, how *well* this works depends also on how well that module manages to masquerade as the threading module, but I'm sure you've figured that part out :) Well it is what will work for the moment. Thanks for the confirmation this will indeed work. What you **should not** do is to make other modules use your code when they think they are using the standard library. Raymond Chen in The Old New Thing blog often writes about users who want to do a basically similar thing. He always asks "What if some other program wants to do the same thing?" One case was when a developer wanted his program's icon to force itself to be at the top position in the Windows task bar. "What if another program tried this too?" The two would keep trying to displace each other at the top position. If you set the PYTHONPATH environmental variable, you can put any directory you like to be at the start of the module search path after the current directory. Perhaps this would be enough for your use case? But if I put a threading.py file in that directory, it would make other modules use my code when they "think" they are using the standard library. The problem is that the logging module uses threading, but doesn't allow you to specify which threading module to use. So if you want to use an alternative, you either have to do things like this, or copy the logging packages into your project and adapt it to use your alternative. -- https://mail.python.org/mailman/listinfo/python-list
Re: How make your module substitute a python stdlib module.
On 12/28/2022 5:39 AM, Antoon Pardon wrote: Op 27/12/2022 om 16:49 schreef Thomas Passin: On 12/27/2022 8:25 AM, Antoon Pardon wrote: Op 27/12/2022 om 13:46 schreef Chris Angelico: On Tue, 27 Dec 2022 at 23:28, Antoon Pardon wrote: At the moment I am happy with a solution that once the programmer has imported from QYZlib.threaders that module will used as the threading module. Oh! If that's all you need, then yes, a simple patch of sys.modules will work. You'll have to make sure you get your module imported before anything else pulls up the vanilla one, though. Otherwise, your only option is to keep the existing module object and monkeypatch it with whatever changes you need. But a simple "sys.modules['threading'] = QYZlib.threaders" will work. Of course, how *well* this works depends also on how well that module manages to masquerade as the threading module, but I'm sure you've figured that part out :) Well it is what will work for the moment. Thanks for the confirmation this will indeed work. What you **should not** do is to make other modules use your code when they think they are using the standard library. Raymond Chen in The Old New Thing blog often writes about users who want to do a basically similar thing. He always asks "What if some other program wants to do the same thing?" One case was when a developer wanted his program's icon to force itself to be at the top position in the Windows task bar. "What if another program tried this too?" The two would keep trying to displace each other at the top position. If you set the PYTHONPATH environmental variable, you can put any directory you like to be at the start of the module search path after the current directory. Perhaps this would be enough for your use case? But if I put a threading.py file in that directory, it would make other modules use my code when they "think" they are using the standard library. The problem is that the logging module uses threading, but doesn't allow you to specify which threading module to use. So if you want to use an alternative, you either have to do things like this, or copy the logging packages into your project and adapt it to use your alternative. In that case, I think your best bet would be to write wrappers for the threading classes or functions you want to use. Your wrappers would import from the threading module and could then produce the behavior you want. -- https://mail.python.org/mailman/listinfo/python-list
Possible re bug when using ".*"
In a couple recent versions of Python (including 3.8 and 3.10), the
following code:
import re
print(re.sub(".*", "replacement", "pattern"))
yields the output "replacementreplacement".
This behavior does not occur in 3.6.
Which behavior is the desired one? Perhaps relatedly, I noticed that even
in 3.6, the code
print(re.findall(".*","pattern"))
yields ['pattern',''] which is not what I was expecting.
Thanks,
Alex Richert
--
Alexander Richert, PhD
*RedLine Performance Systems*
--
https://mail.python.org/mailman/listinfo/python-list
Re: Possible re bug when using ".*"
Alexander Richert - NOAA Affiliate via Python-list schreef op 28/12/2022
om 19:42:
In a couple recent versions of Python (including 3.8 and 3.10), the
following code:
import re
print(re.sub(".*", "replacement", "pattern"))
yields the output "replacementreplacement".
This behavior does not occur in 3.6.
Which behavior is the desired one? Perhaps relatedly, I noticed that even
in 3.6, the code
print(re.findall(".*","pattern"))
yields ['pattern',''] which is not what I was expecting.
The documentation for re.sub() and re.findall() has these notes:
"Changed in version 3.7: Empty matches for the pattern are replaced when
adjacent to a previous non-empty match." and "Changed in version 3.7:
Non-empty matches can now start just after a previous empty match."
That's probably describes the behavior you're seeing. ".*" first matches
"pattern", which is a non-empty match; then it matches the empty string
at the end, which is an empty match but is replaced because it is
adjacent to a non-empty match.
Seems somewhat counter-intuitive to me, but AFAICS it's the intended
behavior.
--
"Programming today is a race between software engineers striving to build bigger
and better idiot-proof programs, and the Universe trying to produce bigger and
better idiots. So far, the Universe is winning."
-- Douglas Adams
--
https://mail.python.org/mailman/listinfo/python-list
Re: Possible re bug when using ".*"
Roel Schroeven schreef op 28/12/2022 om 19:59:
Alexander Richert - NOAA Affiliate via Python-list schreef op
28/12/2022 om 19:42:
In a couple recent versions of Python (including 3.8 and 3.10), the
following code:
import re
print(re.sub(".*", "replacement", "pattern"))
yields the output "replacementreplacement".
This behavior does not occur in 3.6.
Which behavior is the desired one? Perhaps relatedly, I noticed that even
in 3.6, the code
print(re.findall(".*","pattern"))
yields ['pattern',''] which is not what I was expecting.
The documentation for re.sub() and re.findall() has these notes:
"Changed in version 3.7: Empty matches for the pattern are replaced
when adjacent to a previous non-empty match." and "Changed in version
3.7: Non-empty matches can now start just after a previous empty match."
That's probably describes the behavior you're seeing. ".*" first
matches "pattern", which is a non-empty match; then it matches the
empty string at the end, which is an empty match but is replaced
because it is adjacent to a non-empty match.
Seems somewhat counter-intuitive to me, but AFAICS it's the intended
behavior.
For what it's worth, there's some discussion about this in this Github
issue: https://github.com/python/cpython/issues/76489
--
"Je ne suis pas d’accord avec ce que vous dites, mais je me battrai jusqu’à
la mort pour que vous ayez le droit de le dire."
-- Attribué à Voltaire
"I disapprove of what you say, but I will defend to the death your right to
say it."
-- Attributed to Voltaire
"Ik ben het niet eens met wat je zegt, maar ik zal je recht om het te zeggen
tot de dood toe verdedigen"
-- Toegeschreven aan Voltaire
--
https://mail.python.org/mailman/listinfo/python-list
Re: Possible re bug when using ".*"
On 2022-12-28 18:42, Alexander Richert - NOAA Affiliate via Python-list
wrote:
In a couple recent versions of Python (including 3.8 and 3.10), the
following code:
import re
print(re.sub(".*", "replacement", "pattern"))
yields the output "replacementreplacement".
This behavior does not occur in 3.6.
Which behavior is the desired one? Perhaps relatedly, I noticed that even
in 3.6, the code
print(re.findall(".*","pattern"))
yields ['pattern',''] which is not what I was expecting.
It's not a bug, it's a change in behaviour to bring it more into line
with other regex implementations in other languages.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Possible re bug when using ".*"
On 12/28/22 11:07, MRAB wrote:
On 2022-12-28 18:42, Alexander Richert - NOAA Affiliate via Python-list wrote:
In a couple recent versions of Python (including 3.8 and 3.10), the
following code:
import re
print(re.sub(".*", "replacement", "pattern"))
yields the output "replacementreplacement".
This behavior does not occur in 3.6.
Which behavior is the desired one? Perhaps relatedly, I noticed that even
in 3.6, the code
print(re.findall(".*","pattern"))
yields ['pattern',''] which is not what I was expecting.
It's not a bug, it's a change in behaviour to bring it more into line with
other regex implementations in other languages.
The new behavior makes no sense to me, but better to be consistent with the other regex engines than not -- I still get
thrown off by vim's regex.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
