Re: python documentation
On Sat, Mar 27, 2021 at 5:01 PM Dan Stromberg wrote: > > On Fri, Mar 26, 2021 at 10:37 PM Chris Angelico wrote: >> >> On Sat, Mar 27, 2021 at 4:20 PM wrote: >> > By the way, some months ago I started trying to migrate to Python 3 and >> > gave up in favor of creating said compilation. Compatibility of Python >> > and its Packages decreased with V3 significantly. A whole lot of minor >> > and major incompatibilities between your subversions and belonging >> > packages. This was one reason, why Java took the route to its own death. >> >> FUD. Lots and lots of FUD. More reasons to not promote your >> distribution. Use it if you will, but it doesn't merit any further >> visibility. > > Chris, not everything you dislike is anti-Python FUD. > Do we have proof of any of the above? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: python documentation
Hi Dan, thank you very much for your kind hints - quite interesting idea to have a more detailed look into this direction! By the way, your response was the very first here, which I consider to have a constructive notion; at least I did not felt very welcome here by Chris until yet... In the last project I developed the frontend on said C# - WinForms basis (C# and .NET is quite awesome! Most of it meanwhile has even become crossplatform! By the way, as Spyder also has this "just 3" notion, I already switched to VSCodium and never regretted that - VSCodium is the best free IDE for Python as well as C# yet, if you ask me:) and just parts of the backend with IronPython (which also is nice, although it just has access to a limited set of libraries). It worked fine, but I do not like mixing languages if not necessary as I deem that to be a software design weakness and it naturally comes with some overhead. Imagine, if another person one day should continue this work, he must be fluent in Python AND C#, not so easy to find someone free who is on the market I guess... Blythooon solves the current issues well, so at the moment, there is no pressing reason for me to become frantic. But considering the long term, those thoughts are naturally real. The obvious trend to force people to switch to Python 3 might lead to people even eliminating the access to the old packages Blythooon is using. This sword of Damocles is a heavy burden. If anybody thinks that is a little too much seeing on the black side, then they should attentively follow what at the very moment is happening with the current Qt version... May I ask, do you have any knowledge or even experience about if resp. how good Tauthon and Pypy2 works together with Qt 4.8? From my experience the limitating factor during frontend development is nearly always the GUI part. Kivy seems to be nice, but scientific plotters alike PyQtGraph are Qt based and cannot easily be integrated in Kivy yet. Have a nice day, Best Regards Dominik On 2021-03-27 07:01, Dan Stromberg wrote: On Fri, Mar 26, 2021 at 10:37 PM Chris Angelico wrote: On Sat, Mar 27, 2021 at 4:20 PM wrote: > By the way, some months ago I started trying to migrate to Python 3 and > gave up in favor of creating said compilation. Compatibility of Python > and its Packages decreased with V3 significantly. A whole lot of minor > and major incompatibilities between your subversions and belonging > packages. This was one reason, why Java took the route to its own death. FUD. Lots and lots of FUD. More reasons to not promote your distribution. Use it if you will, but it doesn't merit any further visibility. Chris, not everything you dislike is anti-Python FUD. Dominik, if you want something like Python 2.7, you likely should try Tauthon or Pypy2. Don't expect pip to work well on Tauthon; last I heard that was not happening. Also Pypy2 has some issues with C extension modules, and I'm not confident it'll pip well either. It's very worthwhile to move to 3.x, but CPython has a rather sad compatibility story when it comes to C extension modules; hopefully CFFI is going to fix that in the long term. If you're avoiding porting pure Python code, then that feels to me a bit like foot dragging, as the pure Python changes are not that big and are pretty much limited to the 2.7 -> 3.0 transition. I like to build versions of Python from 0.9 to 3.10alpha, for the sake of quickly ascertaining what features were introduced in what versions of CPython. IOW, there are good reasons to keep around old Pythons. Python history is interesting. -- https://mail.python.org/mailman/listinfo/python-list
Re: python documentation
You write, that "Everyone claims that it's easier to move to some other language rather than to migrate to Python 3". Thank you for sharing this remarkable information! On 2021-03-27 06:36, Chris Angelico wrote: On Sat, Mar 27, 2021 at 4:20 PM wrote: Chris, you seem to imply, that I have compiled said versions without reason and that the same would be possible on basis of Python 3 - which is simply not true. Maybe you are not enough acquainted with Qt and belonging libraries alike PyQtGraph. Maybe you are just not willing to see / accept these arguments. By the way, some months ago I started trying to migrate to Python 3 and gave up in favor of creating said compilation. Compatibility of Python and its Packages decreased with V3 significantly. A whole lot of minor and major incompatibilities between your subversions and belonging packages. This was one reason, why Java took the route to its own death. FUD. Lots and lots of FUD. More reasons to not promote your distribution. Use it if you will, but it doesn't merit any further visibility. With a view to the mid and long term future, this discussion even gives me cause to ponder about whether it doesn't make more sense to rely more on C# and WinForms for professional projects from now on. I am fluent in both too and it always makes sense to bet on the right horse at an early stage. If you prefer, go for it. Everyone claims that it's easier to move to rather than to migrate to Python 3, and I'm calling people's bluffs now. Go ahead and move to another language if it's easier - it's no skin off my nose. Or maybe it isn't easier, and that's just an empty argument. Funny how it keeps coming up. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: python documentation
On Sat, Mar 27, 2021 at 9:56 AM wrote: > May I ask, do you have any knowledge or even experience about if resp. > how good Tauthon and Pypy2 works together with Qt 4.8? > I've never used Qt. I do my GUI's with PyGOBject. I've moved all of my personal code that I care about from Python 2.x to 3.x. One of my former employers was forced to remain on 2.x though, because they were using Nupic (for Hierarchical Temporal Memory, AKA HTM), which will likely never be ported to 3.x because it digs around in CPython's C API in less-than-well-behaved ways, and the vendor that created Nupic is moving on to new techniques. -- https://mail.python.org/mailman/listinfo/python-list
Re: python documentation
On Sun, Mar 28, 2021 at 4:03 AM wrote: > > You write, that "Everyone claims that it's easier to move to some other > language rather than to migrate to Python 3". > > Thank you for sharing this remarkable information! > Yep. Plenty of people have claimed that. And guess what? They mostly end up deciding to move to Python 3 instead, because, what a surprise, it's actually a lot easier than completely rewriting your code in a different language. That's why I no longer try to argue people around. Go ahead and change languages - it's entirely up to you what you do. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: python documentation
On 2021-03-27 17:03, pyt...@blackward.eu wrote: You write, that "Everyone claims that it's easier to move to some other language rather than to migrate to Python 3". Thank you for sharing this remarkable information! You've quoted him partially and incorrectly. He said "Everyone claims that it's easier to move to rather than to migrate to Python 3, and I'm calling people's bluffs now." The point is that there are those who use Python 2 and don't want to move to Python 3, claiming that it's easier to switch from Python 2 to some other language than from Python 2 to Python 3. That's what seems questionable. On 2021-03-27 06:36, Chris Angelico wrote: On Sat, Mar 27, 2021 at 4:20 PM wrote: Chris, you seem to imply, that I have compiled said versions without reason and that the same would be possible on basis of Python 3 - which is simply not true. Maybe you are not enough acquainted with Qt and belonging libraries alike PyQtGraph. Maybe you are just not willing to see / accept these arguments. By the way, some months ago I started trying to migrate to Python 3 and gave up in favor of creating said compilation. Compatibility of Python and its Packages decreased with V3 significantly. A whole lot of minor and major incompatibilities between your subversions and belonging packages. This was one reason, why Java took the route to its own death. FUD. Lots and lots of FUD. More reasons to not promote your distribution. Use it if you will, but it doesn't merit any further visibility. With a view to the mid and long term future, this discussion even gives me cause to ponder about whether it doesn't make more sense to rely more on C# and WinForms for professional projects from now on. I am fluent in both too and it always makes sense to bet on the right horse at an early stage. If you prefer, go for it. Everyone claims that it's easier to move to rather than to migrate to Python 3, and I'm calling people's bluffs now. Go ahead and move to another language if it's easier - it's no skin off my nose. Or maybe it isn't easier, and that's just an empty argument. Funny how it keeps coming up. -- https://mail.python.org/mailman/listinfo/python-list
Re: XML RPC changes between 3.7 and 3.9 yield 401 http error
Following our previous discussion:
https://www.talkend.net/post/287193.html
I finally took time (thanks to Florian R.) to get a reproducible example
of my problem, as asked previously by ChrisA.
The following code is implementing a webserver with Flask, and a client
with the XMLRPC client:
import sys
from xmlrpc import server, client
from urllib.parse import urlencode
from flask import Flask, request
PORT = 23456
USER, PASSWD = 'user', 'password'
URL = '127.0.0.1:' + str(PORT)
if len(sys.argv) > 1 and sys.argv[1] == 'server':
app = Flask(__name__)
@app.route('/', methods=['POST'])
@app.route('/RPC2', methods=['POST'])
def login():
print('REQUEST:', request.args)
return 'ok'
app.run(debug=True, host='localhost', port=PORT)
else:
url = 'http://' + URL + '?' + urlencode({'u': USER, 'p': PASSWD})
print(url)
proxy = client.ServerProxy(url)
print(proxy, dir(proxy))
print(proxy.add(2, 3))
You can run the client with `python3 p.py`, and the server with `python3
p.py server`.
On debian, Python 3.7, i got:
lucas@debianserver:~$ python3.7 p.py server
* Serving Flask app "p" (lazy loading)
* Environment: production
WARNING: This is a development server. Do not use it in a
production deployment.
Use a production WSGI server instead.
* Debug mode: on
* Running on http://localhost:23456/ (Press CTRL+C to quit)
* Restarting with stat
* Debugger is active!
* Debugger PIN: 249-992-288
127.0.0.1 - - [27/Mar/2021 18:31:13] "POST /?u=user&p=password
HTTP/1.1" 404 -
On Arch, python 3.9, i got:
aluriak@arch❯ python3.9 p.py server
* Serving Flask app "p" (lazy loading)
* Environment: production
WARNING: This is a development server. Do not use it in a
production deployment.
Use a production WSGI server instead.
* Debug mode: on
* Running on http://localhost:23456/ (Press CTRL+C to quit)
* Restarting with stat
* Debugger is active!
* Debugger PIN: 821-276-100
127.0.0.1 - - [27/Mar/2021 18:35:45] "POST /RPC2 HTTP/1.1" 200 -
Both systems return the same output on command `pip3 freeze | grep
Flask`, which is `Flask==1.1.2`.
Note that the two outputs differs in two ways:
127.0.0.1 - - [27/Mar/2021 18:31:13] "POST /?u=user&p=password
HTTP/1.1" 404 -
127.0.0.1 - - [27/Mar/2021 18:35:45] "POST /RPC2 HTTP/1.1" 200 -
The first contains the arguments, and the second contains the path.
Sounds like there is something wrong with both modules.
This should be a reproducible example ; plus i'm not the only one to
encounter that problem:
https://github.com/kynan/dokuwikixmlrpc/issues/8#issuecomment-808755244
Best regards,
--lucas
--
https://mail.python.org/mailman/listinfo/python-list
Re: XML RPC changes between 3.7 and 3.9 yield 401 http error
And, in my outputs, a key part is missing: the received arguments as
parsed by Flask:
Python 3.7:
REQUEST: ImmutableMultiDict([('u', 'user'), ('p', 'password')])
Python 3.9:
REQUEST: ImmutableMultiDict([])
Have a good day everyone,
--lucas
On 27/03/2021 18:53, lucas wrote:
Following our previous discussion:
https://www.talkend.net/post/287193.html
I finally took time (thanks to Florian R.) to get a reproducible example
of my problem, as asked previously by ChrisA.
The following code is implementing a webserver with Flask, and a client
with the XMLRPC client:
import sys
from xmlrpc import server, client
from urllib.parse import urlencode
from flask import Flask, request
PORT = 23456
USER, PASSWD = 'user', 'password'
URL = '127.0.0.1:' + str(PORT)
if len(sys.argv) > 1 and sys.argv[1] == 'server':
app = Flask(__name__)
@app.route('/', methods=['POST'])
@app.route('/RPC2', methods=['POST'])
def login():
print('REQUEST:', request.args)
return 'ok'
app.run(debug=True, host='localhost', port=PORT)
else:
url = 'http://' + URL + '?' + urlencode({'u': USER, 'p': PASSWD})
print(url)
proxy = client.ServerProxy(url)
print(proxy, dir(proxy))
print(proxy.add(2, 3))
You can run the client with `python3 p.py`, and the server with `python3
p.py server`.
On debian, Python 3.7, i got:
lucas@debianserver:~$ python3.7 p.py server
* Serving Flask app "p" (lazy loading)
* Environment: production
WARNING: This is a development server. Do not use it in a
production deployment.
Use a production WSGI server instead.
* Debug mode: on
* Running on http://localhost:23456/ (Press CTRL+C to quit)
* Restarting with stat
* Debugger is active!
* Debugger PIN: 249-992-288
127.0.0.1 - - [27/Mar/2021 18:31:13] "POST /?u=user&p=password
HTTP/1.1" 404 -
On Arch, python 3.9, i got:
aluriak@arch❯ python3.9 p.py server
* Serving Flask app "p" (lazy loading)
* Environment: production
WARNING: This is a development server. Do not use it in a
production deployment.
Use a production WSGI server instead.
* Debug mode: on
* Running on http://localhost:23456/ (Press CTRL+C to quit)
* Restarting with stat
* Debugger is active!
* Debugger PIN: 821-276-100
127.0.0.1 - - [27/Mar/2021 18:35:45] "POST /RPC2 HTTP/1.1" 200 -
Both systems return the same output on command `pip3 freeze | grep
Flask`, which is `Flask==1.1.2`.
Note that the two outputs differs in two ways:
127.0.0.1 - - [27/Mar/2021 18:31:13] "POST /?u=user&p=password
HTTP/1.1" 404 -
127.0.0.1 - - [27/Mar/2021 18:35:45] "POST /RPC2 HTTP/1.1" 200 -
The first contains the arguments, and the second contains the path.
Sounds like there is something wrong with both modules.
This should be a reproducible example ; plus i'm not the only one to
encounter that problem:
https://github.com/kynan/dokuwikixmlrpc/issues/8#issuecomment-808755244
Best regards,
--lucas
--
https://mail.python.org/mailman/listinfo/python-list
Re: python documentation
You say: "The point is that there are those who use Python 2 and don't want to move to Python 3, claiming that it's easier to switch from Python 2 to some other language than from Python 2 to Python 3. That's what seems questionable." And I say, forcing people to do things they do not want to do is a little more questionable. There are reasons, why people "don't want to move to Python 3". Maybe you should concentrate more on developing Python 3 a little more attractive then in burning witches? But for my part, this discussion is ended, it does not lead to anything. At least in this point I agree with Chris. Cheers, have a good time Dominik On 2021-03-27 18:53, MRAB wrote: On 2021-03-27 17:03, pyt...@blackward.eu wrote: You write, that "Everyone claims that it's easier to move to some other language rather than to migrate to Python 3". Thank you for sharing this remarkable information! You've quoted him partially and incorrectly. He said "Everyone claims that it's easier to move to rather than to migrate to Python 3, and I'm calling people's bluffs now." The point is that there are those who use Python 2 and don't want to move to Python 3, claiming that it's easier to switch from Python 2 to some other language than from Python 2 to Python 3. That's what seems questionable. On 2021-03-27 06:36, Chris Angelico wrote: On Sat, Mar 27, 2021 at 4:20 PM wrote: Chris, you seem to imply, that I have compiled said versions without reason and that the same would be possible on basis of Python 3 - which is simply not true. Maybe you are not enough acquainted with Qt and belonging libraries alike PyQtGraph. Maybe you are just not willing to see / accept these arguments. By the way, some months ago I started trying to migrate to Python 3 and gave up in favor of creating said compilation. Compatibility of Python and its Packages decreased with V3 significantly. A whole lot of minor and major incompatibilities between your subversions and belonging packages. This was one reason, why Java took the route to its own death. FUD. Lots and lots of FUD. More reasons to not promote your distribution. Use it if you will, but it doesn't merit any further visibility. With a view to the mid and long term future, this discussion even gives me cause to ponder about whether it doesn't make more sense to rely more on C# and WinForms for professional projects from now on. I am fluent in both too and it always makes sense to bet on the right horse at an early stage. If you prefer, go for it. Everyone claims that it's easier to move to rather than to migrate to Python 3, and I'm calling people's bluffs now. Go ahead and move to another language if it's easier - it's no skin off my nose. Or maybe it isn't easier, and that's just an empty argument. Funny how it keeps coming up. -- https://mail.python.org/mailman/listinfo/python-list
Re: python documentation
On 2021-03-27 19:02, pyt...@blackward.eu wrote: You say: "The point is that there are those who use Python 2 and don't want to move to Python 3, claiming that it's easier to switch from Python 2 to some other language than from Python 2 to Python 3. That's what seems questionable." And I say, forcing people to do things they do not want to do is a little more questionable. There are reasons, why people "don't want to move to Python 3". Maybe you should concentrate more on developing Python 3 a little more attractive then in burning witches? At no point did I say that people should be forced to switch. The "regex" module, for example, still supports Python 2.7, but only just, and that won't last forever. But for my part, this discussion is ended, it does not lead to anything. At least in this point I agree with Chris. Cheers, have a good time Dominik [snip] -- https://mail.python.org/mailman/listinfo/python-list
RE: convert script awk in python
Many thanks for the link to that document. Most helpful. Peter > -Original Message- > From: Michael Torrie > Sent: Friday, March 26, 2021 8:32 PM > To: python-list@python.org > Subject: Re: convert script awk in python > > On 3/25/21 1:14 AM, Loris Bennett wrote: > > Does any one have a better approach? > > Not as such. Running a command and parsing its output is a relatively > common task. Years ago I wrote my own simple python wrapper function > that would make it easier to run a program with arguments, and capture > its output. I ended up using that wrapper many times, which saved a lot > of time. > > When it comes to converting a bash pipeline process to Python, it's > worth considering that most of pipelines seem to involve parsing using > sed or awk (as yours do), which is way easier to do from python without > that kind of pipelining. However there is a fantastic article I read > years ago about how generators are python's equivalent to a pipe. > Anyone wanting to replace a bash script with python should read this: > > https://www.dabeaz.com/generators/Generators.pdf > > Also there's an interesting shell scripting language based on Python > called xonsh which makes it much easier to interact with processes like > bash does, but still leveraging Python to process the output. > https://xon.sh/ . -- -- https://mail.python.org/mailman/listinfo/python-list
RE: python documentation
What are the odds, Chris, that rewriting an existing project written in an older version of a language like python FROM SCRATCH into any other existing language, would be easier than updating it to the same language which made fairly specific changes and has some guidelines how to update? True, if you have programmers already knowing the other language handy, fine. But as I study other languages, I keep finding things they often do invisibly in the compiler or interpreter that make me wonder why anyone thinks they can write one program that reads them all as if with a magic ring. Some features make translations far from straightforward, not that they cannot be done, but some thought is needed and maybe a change is aspects of how the darn thing is built. What you are expressing is the fact that the longer we encourage people to keep using the old, the more painful it is to move forward with the new. At some point, so many changes may accumulate, that catching up may not be worth doing. Any nontrivial program that uses many packages and modules will not find identical things in a new target language, for example. Some nice concise ways some things are done may work differently elsewhere and need to be redesigned completely or lead to lots of errors. Now if the case was being made to switch to a more recent advanced language, maybe. But the languages he suggested strike me as fairly ancient, even if they too have been evolving. As you note, he is free to do what he wishes but not free to force others to help him when it is not in their interest. -Original Message- From: Python-list On Behalf Of Chris Angelico Sent: Saturday, March 27, 2021 1:37 AM To: Python Subject: Re: python documentation On Sat, Mar 27, 2021 at 4:20 PM wrote: > > Chris, > > you seem to imply, that I have compiled said versions without reason > and that the same would be possible on basis of Python 3 - which is > simply not true. Maybe you are not enough acquainted with Qt and > belonging libraries alike PyQtGraph. Maybe you are just not willing to > see / accept these arguments. > > By the way, some months ago I started trying to migrate to Python 3 > and gave up in favor of creating said compilation. Compatibility of > Python and its Packages decreased with V3 significantly. A whole lot > of minor and major incompatibilities between your subversions and > belonging packages. This was one reason, why Java took the route to its own death. FUD. Lots and lots of FUD. More reasons to not promote your distribution. Use it if you will, but it doesn't merit any further visibility. > With a view to the mid and long term future, this discussion even > gives me cause to ponder about whether it doesn't make more sense to > rely more on C# and WinForms for professional projects from now on. I > am fluent in both too and it always makes sense to bet on the right > horse at an early stage. If you prefer, go for it. Everyone claims that it's easier to move to rather than to migrate to Python 3, and I'm calling people's bluffs now. Go ahead and move to another language if it's easier - it's no skin off my nose. Or maybe it isn't easier, and that's just an empty argument. Funny how it keeps coming up. ChrisA -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: python documentation
On Sun, Mar 28, 2021 at 7:46 AM Avi Gross via Python-list wrote: > > What are the odds, Chris, that rewriting an existing project written in an > older version of a language like python FROM SCRATCH into any other existing > language, would be easier than updating it to the same language which made > fairly specific changes and has some guidelines how to update? > Exactly. Yet people keep saying, oh, Python 3 is so hard, I can't possibly migrate from Python 2 to Python 3, it'll be easier to rewrite it all in ... I've completely stopped believing any such claims. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: python documentation
I answered your actual question, in your original post, separately. But by posting here, and continuing to respond, you implicitly invited extended discussion with questions and opinions. On 3/26/2021 11:15 PM, pyt...@blackward.eu wrote: in response to Chris Angelico, a long-time python-list discussant who has some strong opinions, especially with regard to 2.x versus 3.x: No, I am not encouraging, I am just offering the possibility. By only offering 2.7, you could be construed to be encouraging. You must know that you are stepping into a long-term debate. Your other comments suggests that you are not neutral. ... It might be a good thing to recommend people to switch to Python 3.*, it might be a bad idea to FORCE people to do so by taking away the possibility to install Python 2.7.*; The there is *obviously* no intention to take away that possibility. The download pages have everything available, all the way back to the original 0.9 sources. The latter was recently added. So suggesting that the website might 'censor' 2.7 is a kind unfair. If I am right, This implies doubt. the Python 2.7.* installers still are provided on the python.org website. Along with Windows installers back to 1.5.2. So long as this is done, I cannot see a reason not to list a 'distribution' using Python 2.7.* in said list, right? Would you say the same for a 'distribution' using 2.0.1, or 1.5.2? But, in the end, this naturally is not my decision. AFAIK, none of the website maintainers post on this list. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: python documentation
I would like to suggest adding "Blythooon" to the list under "Other parties have re-packaged CPython" listed here: https://www.python.org/download/alternatives/ Your title is misleading because you are proposing a change to a python.org website page, not the 'Python documentation'. That term, as often used, refers to the official docs at python.org/doc. See the list of "Documentation" links at the bottom of the page for a broader interpretation, which still excludes the page you are interested in. Note: the 'core developers' control the contents of .../downloads, .../doc, and some of .../dev. The rest of the website is done by a different PSF group. Blythooon can be found here: https://pypi.org/project/blythooon/ and the belonging installation step-by-step-guide video here: https://www.youtube.com/channel/UCOE8xqYS_2azFsFjBVEwVMg I don't know if the unknown to me page author(s) would consider this a 'packaging' at they intend the term to mean. May I ask - how can I do that best? Thanks in advance and At the bottom of the page is "Submit Website Bug" linked to https://github.com/python/pythondotorg/issues -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: python documentation
On 2021-03-27, MRAB wrote: > On 2021-03-27 17:03, pyt...@blackward.eu wrote: >> You write, that "Everyone claims that it's easier to move to some other >> language rather than to migrate to Python 3". >> >> Thank you for sharing this remarkable information! > > You've quoted him partially and incorrectly. He said "Everyone > claims that it's easier to move to rather than > to migrate to Python 3, and I'm calling people's bluffs now." > > The point is that there are those who use Python 2 and don't want to > move to Python 3, claiming that it's easier to switch from Python 2 > to some other language than from Python 2 to Python 3. That's what > seems questionable. That questionable to the point of being laughable. I've ported a fair number of apps from Python2 to Python3. Many of them played pretty fast and loose with py2 strings vs. raw bytes vs. Unicode. That causes as many 2->3 porting problems as anything can, and it was still far, far easier to port from py2->py3 than it would have been to port from py2 to any of the couple dozen other langauges I've used in my career. Though I still somtimes pine for the fixed length integer types that were lost in the py1.5->py2 transition... -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: python documentation
On 3/27/2021 1:20 AM, pyt...@blackward.eu wrote: By the way, some months ago I started trying to migrate to Python 3 and gave up in favor of creating said compilation. Why? What was biggest roadblock? Compatibility of Python and its Packages decreased with V3 significantly. I don't believe this without a clear explanation as to what you mean and strong evidence. Are you claiming that you cannot put together a combination of modern python + numpy + scipy + qt + ... that work together? (Many people including my daughter seem to manage just fine.) If there are particular problems, it would be worth discussing and trying to solve them. And what would 'compatibility have to do with '3.x'? (With respect to unicode, compatibility has been improved in one important respect since 3.3.) A whole lot of minor and major incompatibilities > between your subversions and belonging packages. I don't understand 'subversions' and 'belonging packages'? I understand 'incompatibities' in general but not what you mean specifically. I don't know of any evidence that there are increased within, say, 3.8 or 3.9 packages versus 2.7 packages. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Access to python37_d.lib
When matplotlib-cpp from GitHub is used to add graphics to a Visual Studio C++ Console application the following error is obtained: Cannot open python37_d.lib. The error was not resolved by re-installing python, including debug files. Any assistance would be much appreciated. JIMK -- https://mail.python.org/mailman/listinfo/python-list
Re: python documentation
On 27/03/2021 06:20, pyt...@blackward.eu wrote: Chris, you seem to imply, that I have compiled said versions without reason and that the same would be possible on basis of Python 3 - which is simply not true. Maybe you are not enough acquainted with Qt and belonging libraries alike PyQtGraph. Maybe you are just not willing to see / accept these arguments. By the way, some months ago I started trying to migrate to Python 3 and gave up in favor of creating said compilation. Compatibility of Python and its Packages decreased with V3 significantly. A whole lot of minor and major incompatibilities between your subversions and belonging packages. This was one reason, why Java took the route to its own death. *rolls eyes* I know PyQtGraph reasonably well and this is the first time I've ever heard of anybody using it on Python 2. I mean, I imagine it once worked on Python 2 and probably still does, but all of these package have had perfectly good Python 3 support for many, many years. - Thomas -- https://mail.python.org/mailman/listinfo/python-list
Re: XML RPC changes between 3.7 and 3.9 yield 401 http error
On Sun, Mar 28, 2021 at 5:00 AM lucas wrote:
> I finally took time (thanks to Florian R.) to get a reproducible example
> of my problem, as asked previously by ChrisA.
Thanks! With this in hand, I can play around with it.
> On debian, Python 3.7, i got:
>
> 127.0.0.1 - - [27/Mar/2021 18:31:13] "POST /?u=user&p=password
> HTTP/1.1" 404 -
>
> On Arch, python 3.9, i got:
>
> aluriak@arch❯ python3.9 p.py server
> 127.0.0.1 - - [27/Mar/2021 18:35:45] "POST /RPC2 HTTP/1.1" 200 -
On Debian, with both versions having been built from source, the same
occurs. Furthermore, Python 3.8 behaves as 3.7 does. This definitely
changed in 3.9.
> Note that the two outputs differs in two ways:
>
> 127.0.0.1 - - [27/Mar/2021 18:31:13] "POST /?u=user&p=password
> HTTP/1.1" 404 -
> 127.0.0.1 - - [27/Mar/2021 18:35:45] "POST /RPC2 HTTP/1.1" 200 -
>
> The first contains the arguments, and the second contains the path.
> Sounds like there is something wrong with both modules.
One point of note is that the request as given actually doesn't have a
slash. I think that's technically wrong, but a lot of systems will
just implicitly add the slash. That, coupled with commit 9c4c45, is
why you're seeing "/RPC2" in there. That distinction vanishes if you
change your client thusly:
url = 'http://' + URL + '/?' + urlencode({'u': USER, 'p': PASSWD})
Actually, it looks like all the changes came in with that commit. The
old way used some internal functions from urllib.parse, and the new
way uses the public function urllib.parse.urlparse(), and there are
some subtle differences. For one thing, the old way would implicitly
readd the missing slash, thus hiding the above issue; the new way
leaves the path empty (thus triggering the "/RPC2" replacement). But
perhaps more significantly, the old way left query parameters in the
"path" portion, where the new way has a separate "query" portion that
is being lost. Here's the relevant BPO:
https://bugs.python.org/issue38038
It seems to have been intended as a pure refactor, so I'd call this a
regression. Fortunately, it's not difficult to fix; but I'm not sure
if there are any other subtle changes.
The regression's already been reported so I'm adding to this issue:
https://bugs.python.org/issue43433
Hopefully that solves the problem!
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: XML RPC changes between 3.7 and 3.9 yield 401 http error
Thank you ChrisA !
I hope it will solve it too. Do i need to do anything ?
Thank you for your time and help.
Best wishes,
--lucas
On 27/03/2021 22:49, Chris Angelico wrote:
On Sun, Mar 28, 2021 at 5:00 AM lucas wrote:
I finally took time (thanks to Florian R.) to get a reproducible example
of my problem, as asked previously by ChrisA.
Thanks! With this in hand, I can play around with it.
On debian, Python 3.7, i got:
127.0.0.1 - - [27/Mar/2021 18:31:13] "POST /?u=user&p=password
HTTP/1.1" 404 -
On Arch, python 3.9, i got:
aluriak@arch❯ python3.9 p.py server
127.0.0.1 - - [27/Mar/2021 18:35:45] "POST /RPC2 HTTP/1.1" 200 -
On Debian, with both versions having been built from source, the same
occurs. Furthermore, Python 3.8 behaves as 3.7 does. This definitely
changed in 3.9.
Note that the two outputs differs in two ways:
127.0.0.1 - - [27/Mar/2021 18:31:13] "POST /?u=user&p=password
HTTP/1.1" 404 -
127.0.0.1 - - [27/Mar/2021 18:35:45] "POST /RPC2 HTTP/1.1" 200 -
The first contains the arguments, and the second contains the path.
Sounds like there is something wrong with both modules.
One point of note is that the request as given actually doesn't have a
slash. I think that's technically wrong, but a lot of systems will
just implicitly add the slash. That, coupled with commit 9c4c45, is
why you're seeing "/RPC2" in there. That distinction vanishes if you
change your client thusly:
url = 'http://' + URL + '/?' + urlencode({'u': USER, 'p': PASSWD})
Actually, it looks like all the changes came in with that commit. The
old way used some internal functions from urllib.parse, and the new
way uses the public function urllib.parse.urlparse(), and there are
some subtle differences. For one thing, the old way would implicitly
readd the missing slash, thus hiding the above issue; the new way
leaves the path empty (thus triggering the "/RPC2" replacement). But
perhaps more significantly, the old way left query parameters in the
"path" portion, where the new way has a separate "query" portion that
is being lost. Here's the relevant BPO:
https://bugs.python.org/issue38038
It seems to have been intended as a pure refactor, so I'd call this a
regression. Fortunately, it's not difficult to fix; but I'm not sure
if there are any other subtle changes.
The regression's already been reported so I'm adding to this issue:
https://bugs.python.org/issue43433
Hopefully that solves the problem!
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Access to python37_d.lib
On 3/27/2021 11:34 AM, Kathleen Kennedy wrote: When matplotlib-cpp from GitHub is used to add graphics to a Visual Studio C++ Console application the following error is obtained: Cannot open python37_d.lib. The error was not resolved by re-installing python, including debug files. Any assistance would be much appreciated. JIMK For me, current python3.x installed on Windows with the PSF installer has /libs/ containing 3 .lib files: _tkinter/python3/python3x.lib My repository debug builds result in /PCbuild/win32 with lots of files, including python3_d.lib and python3x_d.lib. I don't know if including 'debug files' includes these or not. You can check in your /lib. Is matplotlib-cpp possibly installed with its own debug build of python37? Or using some other installed python on your system? -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: XML RPC changes between 3.7 and 3.9 yield 401 http error
On 3/27/2021 5:49 PM, Chris Angelico wrote: https://bugs.python.org/issue38038 It seems to have been intended as a pure refactor, so I'd call this a regression. Fortunately, it's not difficult to fix; but I'm not sure if there are any other subtle changes. The regression's already been reported so I'm adding to this issue: https://bugs.python.org/issue43433 You added a PR, which is great, but useless unless a currently active coredev reviews and merges. I requested such from the author and merger of the apparently offending commit. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
