[Python-Dev] Re: PEP: Modify the C API to hide implementation details
On 2020-04-14, 12:35 GMT, Stefan Behnel wrote: >> A good way to test that promise (or other implications like performance) >> might >> also be to rewrite the standard library extensions in Cython and see where >> it >> leads. > > Not sure I understand what you're saying here. stdlib extension modules are > currently written in C, with a bit of code generation. How is that different? When you are saying that writing C extensions is unnecessary, because everything can be easily written in Cython, start persuading me by rewriting all C extensions included in CPython into Cython. If you are not willing to do it, why I should I start rewriting my 7k lines of SWIG code to Cython, just because you hope that somebody finally finally (please!) notices existence of PyPy and hopefully starts to care about it. No, they won’t. Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Never, never, never believe any war will be smooth and easy, or that anyone who embarks on the strange voyage can measure the tides and hurricanes he will encounter. The statesman who yields to war fever must realise that once the signal is given, he is no longer the master of policy but the slave of unforeseeable and uncontrollable events. -- Winston Churchill, 1930 ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/FXUBENCEONTRFTAKR2SNIJ5OOEE22FBY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP: Modify the C API to hide implementation details
On 2020-04-13, 17:39 GMT, Eric Fahlgren wrote: > Ok, so put that in a Pros/Cons list that provides guidance as to what > interface and tools to choose when writing a new extension module. > Personally, I'd put Cython (and other "big" packages, numpy, requests and > such) on par with CPython itself with respect to "likely to implode and > become unusable." Time for the unplesant questions: what is the bus factor of Cython? Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 To love another person Is to see the face of God. -- yes, incredibly cheesy verse from the screenplay of the movie Les Miserables (2012) ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/RT4HSRZF37KYED2ZREDMF37EAYYFNR4R/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10
On 2020-02-04, 01:00 GMT, Brett Cannon wrote: > I think people also forget that prior to worrying about > maintaining backwards-compatibility with Python 2 we > deprecated for a release and then we removed (so an 18 month > deprecation period). But then you mustn’t filter out deprecation warnings. And yes, we have to relearn that deprecation warning means the incoming doom, not something to ignore. Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Thou shalt not nede to be afrayed for any bugges by night. -- Coverdale's 1535 translation of Psalm 91 (or Christopher Higley's 1972 thesis explaining why programmers' are nocturnal beasts) ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/JM6X6A4E5YEYSZWSVM5CMNDSUOAHJ2A5/ Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-Dev] "if __name__ == '__main__'" at the bottom of python unittest files
On 2019-05-01, 06:46 GMT, Serhiy Storchaka wrote: > These lines were added for purpose. They are needed for > running tests in separate file as a script. > > $ ./python Lib/unittest/test/testmock/testcallable.py -v > test_attributes (__main__.TestCallable) ... ok Isn't the standard way how to run one module just? $ ./python -mtest -v testmock.testcallable Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 As long as we are thinking of natural values we must say that the sun looks down on nothing half so good as a household laughing together over a meal, or two friends talking over a pint of beer, or a man alone reading a book that interests him; and that all economies, politics, laws, armies, and institutions, save insofar as they prolong and multiply such scenes, are a mere ploughing the sand and sowing the ocean, a meaningless vanity and vexation of the spirit. Collective activities are, of course, necessary, but this is the end to which they are necessary. -- C.S. Lewis, “Membership” in “The Weight of Glory” ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Another update for PEP 394 -- The "python" Command on Unix-Like Systems
On 2019-02-13, 23:33 GMT, Barry Warsaw wrote: > Perhaps. I just don’t think Python 4 is anything but distant > vaporware. There’s a cost to freaking everyone out that > Python 4 is coming and will be as disruptive as Python 3. > Calling Python 3.9+1 Python 4 feeds into that FUD for no > reason that I can tell except for an aversion to two digit > minor version numbers. Is this relevant to the discussion at hand? We are talking about the binary /usr/bin/python3 which will be surely be provided even by Python 4, won't it? Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Reading after a certain age diverts the mind too much from its creative pursuits. Any man who reads too much and uses his own brain too little falls into lazy habits of thinking, just as the man who spends too much time in the theater is tempted to be content with living vicariously instead of living his own life. -- Albert Einstein to The Saturday Evening Post, October 1929 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Missing functions [Was: Re: Experiment an opt-in new C API for Python? (leave current API unchanged)]
On 2018-11-22, 10:13 GMT, Petr Viktorin wrote: > Yes, AFAIK that is the least bad solution. > I did something very similar here: > https://github.com/encukou/py3c/blob/master/include/py3c/fileshim.h Thank you. Matěj ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Missing functions [Was: Re: Experiment an opt-in new C API for Python? (leave current API unchanged)]
On 2018-11-21, 14:54 GMT, Benjamin Peterson wrote: > In Python 3, there is no underlying FILE* because the io > module is implemented using fds directly rather than C stdio. OK, so the proper solution is to kill all functions which expect FILE, and if you are anal retentive about stability of API, then you have to fake it by creating FILE structure around the underlying fd handler as I did in M2Crypto, right? Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 If you have a problem and you think awk(1) is the solution, then you have two problems. -- David Tilbrook (at least 1989, source of the later famous jwz rant on regular expressions). ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Missing functions [Was: Re: Experiment an opt-in new C API for Python? (leave current API unchanged)]
On 2018-11-19, 11:59 GMT, Stefan Krah wrote: > In practice people desperately *have* to use whatever is > there, including functions with underscores that are not even > officially in the C-API. Yes, there are some functions which evaporated and I have never heard a reason why and how I am supposed to overcome their removal. E.g., when porting M2Crypto to Python3 I had to reimplement my own (bad) version of `FILE* PyFile_AsFile(PyObject *pyfile)` function (https://is.gd/tgQGDw). I think it is obvious why it is necessary for C bindings, and I have never found a way how to get the underlying FILE handle from the Python File object properly. Just my €0.02. Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 All of us could take a lesson from the weather. It pays no attention to criticism. -- somewhere on the Intenret ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Use of Cython
On 2018-08-08, 11:30 GMT, Antoine Pitrou wrote: > I'm not sure why anyone would want to use swig nowadays. Legacy reasons, 47k lines of Python code (and 7k lines of swig *.i files). Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Do not long for the night, when people vanish in their place. Be careful, do not turn to evil; for you have preferred this to affliction. -- Job 36:20f (NASB) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Use of Cython
On 2018-08-06, 15:13 GMT, Stefan Behnel wrote: > Not sure I understand this correctly, but I think we're on the > same page here: writing test code in C is cumbersome, writing > test code in a mix of C and Python across different files is > aweful. And making it difficult to write or even just review > test code simply means that people will either waste their > precious contribution time on it, or try to get around it. I was thinking about the same when porting M2Crypto to py3k (M2Crypto is currently swig-based mix of C-code and Python). Is it even possible to make a mix of Cython, swig-based C, and Python? In the end I rather stayed with plain C, because the combination seems unimaginably awful. (Also, is Cython the best of all of them? What about cffi or Nuitka?) Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 There is no reason to suppose that most human beings are engaged in maximizing anything unless it be unhappiness, and even this with incomplete success. -- Ronald Coase Introduction to “The Firm, the Market, and the Law” ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Use of Cython
On 2018-08-07, 17:34 GMT, Yury Selivanov wrote: > Speaking of which, Dropbox is working on a new compiler they > call "mypyc". How does it compare with Nuitka? Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 If in desperation, read the documentation! -- Brian D. Ripley, on R-help list ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Time for 3.4.9 and 3.5.6
On 2018-07-08, 22:32 GMT, Larry Hastings wrote: > More importantly, 3.4 is in security-fixes-only mode, which > means that changes that aren't security fixes won't be > accepted. So, why isn’t https://bugs.python.org/issue31623 closed as WONTFIX (or whatever is the equivalent in b.p.o)? If we don't close our bugs, we surely will drown in them even more. Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Give your heartache to him. (1Pt 5,7; Mt 11:28-30) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Call for prudence about PEP-572
On 2018-07-07, 15:48 GMT, Guido van Rossum wrote: > if validate(name := re.search(pattern, line).group(1)): > return name Except there is no error handling for situations when re.search() returns None, so one shouldn't use it anyway (most of the time). Which seems to me like another nice example why one should stay away from this style as much as possible. I am too lazy to be tempted into this nice-example-terrible-production-code world. Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin, Historical Review of Pennsylvania, 1759. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Failing tests (on a Linux distro)
On Wed, 2018-07-04 at 22:05 +1000, Nick Coghlan wrote: > Running the following locally fails for me: > > $ SOURCE_DATE_EPOCH=`date` ./python -m test test_py_compile > test_compileall Just if this is taken literally, it is wrong. According to https: //reproducible-builds.org/specs/source-date-epoch/ it should be $ SOURCE_DATE_EPOCH=`date +%s` ./python -m test test_py_compile \ test_compileall Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 And religious texts are a bit like software standards, the interpretation is always the tricky and complicated bit. -- Alan Cox signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Failing tests (on a Linux distro)
On Mon, 2018-07-02 at 14:13 +0200, Victor Stinner wrote: > 2018-07-02 9:38 GMT+02:00 Petr Viktorin : > > Fedora* has been building python37 since the alphas, so the > > final update to > > rc/stable was smoother. > > (...) > > * Thanks to Miro Hrončok for most of the work in Fedora > > This work is super useful to prepare third party modules for > Python 3.7, but also to spot regressions and bugs in Python > 3.7. Fedora also helped to detect issues with the latest glibc > for example. I hope to do this as well with openSUSE, but I am just getting into the position, and it is still a lot of struggle. Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Be pitiful, for every man is fighting a hard battle. -- Ian MacLaren, at least 1898 signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Failing tests [Was: Re: Python 3.7.0 is now available! (and so is 3.6.6)]
On 2018-06-28, 00:58 GMT, Ned Deily wrote: > On behalf of the Python development community and the Python 3.7 release > team, we are pleased to announce the availability of Python 3.7.0. I am working on updating openSUSE packages to python 3.7, but I have hit quite large number of failing tests (the testsuite obviously passed with 3.6), see https://build.opensuse.org/package/show/home:mcepl:work/python3 (click on the red "failed" label to get logs). I fell into a bout of depression, only to discover that we are not alone in this problem ... Debian doesn't seem to do much better https://is.gd/HKBU4j. Surprisingly, Fedora seems to pass the testsuite https://is.gd/E0KA53; interesting, I will have to investigate which of their many patches did the trick. Anybody has any idea, what's going on, please? Did anybody on the python.org side run test suites on Linux? Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 The difference between death and taxes is death doesn't get worse every time Congress meets -- Will Rogers ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Microsoft to acquire GitHub for $7.5 billion
On 2018-06-05, 15:03 GMT, Nick Coghlan wrote: > I was actually looking into this recently to see if the > repository import feature could be used to run a regularly > updated repository mirror that included all issues and PR > comments in addition to the code, Good, thank you very much. I didn’t, so I just worked out of the PR materials and documentation on their side. I am glad somebody did. > I'm more confident in my ability to predict Microsoft's > business incentives based on the prevailing technology > landscape than I am in my ability to predict the actions of > a VC firm like Andreesen Horowitz :) Perhaps. I still would be more comfortable, if we were thinking from time to time about alternatives in case Microsoft (or somebody else) returns to The Bad Old Ways. I hope it won't happen, but it might. Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 May integrity and uprightness preserve me, for I wait for you. -- Psalm 25:21 ESV ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Microsoft to acquire GitHub for $7.5 billion
On 2018-06-04, 23:38 GMT, Steven D'Aprano wrote: > No, but Guido is right: neither is anyone else. > > In that regard, Microsoft is probably *more* likely to keep pumping > money into a failing business if it gives them a strategic advantage, > compared to other investors with no long-term strategy other than "get > aquired by Google/Microsoft/Oracle/Apple". Let me just to say here, that gitlab.com has export of repository together with all metadata. Just saying. Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Oh, to be young, and to feel love’s keen sting. -- Albus Dumbledore ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Microsoft to acquire GitHub for $7.5 billion
On 2018-06-04, 16:06 GMT, Guido van Rossum wrote: > I don't see how this *increases* the uncertainty. Surely if > GitHub had remained independent there would have been be > similar concerns about how it would make enough money to stay > in business. Beacuse Microsoft is known to keep a money loosing venture around forever? Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 To err is human, to purr feline. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Drop/deprecate Tkinter?
On 2018-05-03, 15:56 GMT, Tim Peters wrote: > IDLE isn't just for eager beginners, but also for those so old > & senile they're incapable of learning anything new ever again. As > proof, IDLE is still _my_ primary Python development environment, used > multiple times every day, and I'm so old & out-of-it that I'm +1 on > the binding expressions PEP ;-) Glad to find that such person exists! I thought that you are just a mythical legend, I am glad to be shown otherwise. Best, Matěj Cepl -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 To err is human, to purr feline. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Drop/deprecate Tkinter?
On 2018-05-02, 21:41 GMT, Guido van Rossum wrote: > So what do *you* think. Do you agree with the OP that Tkinter (and hence > IDLE) should be scrapped? It absolutely impossible to remove Tkinter IMHO (it has been part of stdlib since like forever and people expect it there; its removal would be betrayal on the level of switching = to :=), I have my doubts about IDLE though. I know, the same argument applies, but really, does anybody use IDLE for development for long time, what is its real value for the community? Although, even this argument is questionable, because Python has some affinity with the learning, and IDLE is a nice for first steps nibbling into Python. Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Only two of my personalities are schizophrenic, but one of them is paranoid and the other one is out to get him. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3
On 2018-04-28, 01:33 GMT, Greg Ewing wrote: >> In my opinion, the largest failure of Python 3 is that we >> failed to provide a smooth and *slow* transition from Python >> 2 and Python 3. > > Although for some things, such as handling of non-ascii text, it's > hard to see how a smooth transition *could* have been achieved. > Is it a failure if we don't succeed in doing the impossible? +1 My experience told me that by far the biggest problem in porting M2Crypto was dealiing with complete mess which was whole string/bytes confusioin in py2k. I don't see how it could be overcame gradually. Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 In those days spirits were brave, the stakes were high, men were real men, women were real women and small furry creatures from Alpha Centauri were real small furry creatures from Alpha Centauri. -- Douglas Adams ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 394: Allow the `python` command to not be installed (and other minor edits)
On 2018-04-28, 01:23 GMT, Nick Coghlan wrote: > That isn't currently *my* desired future, as I don't want to > see a python3 to python4 naming transition at any point, > I want a transition from python3 back to an unqualified name > to accurately reflect the change in version management > philosophy resulting from the extended Python 3 migration. > (And then "python3" would linger solely as a backwards > compatibility remnant, even if it referred to python 4+, or > a switch to some kind of CalVer based versioning scheme) +1 Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 We can tell our level of faith in what God wants to do for us by our level of enthusiasm for what we want God to do for other. -- Dave Schmelzer ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 572: Assignment Expressions
On 2018-04-23, 21:34 GMT, Sven R. Kunze wrote: > Is it just me or since when has the following Python code > fallen out of favor? It isn’t just you. Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 … one of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs. -- Robert Firth ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 572: Assignment Expressions
On 2018-04-21, 07:46 GMT, Chris Angelico wrote: > doubled_items = [x for x in (items := get_items()) if x * 2 in > items] Aside from other concerns expressed elsewhere by other people, do you really like this? I know and agree that “readability” is a subjective term, but it is my firm persuasion that whenever I need to think about what particular list comprehension means, it is the moment I should write a separate function or normal cycle. I think we should encourage writing simple (I didn’t use the r* word here, you see!) code than something which has potential to slide us towards Perl. Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 A day without sunshine is like night. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Soliciting comments on the future of the cmd module (bpo-33233)
On 2018-04-07, 00:13 GMT, Steven D'Aprano wrote: > Just in the last week, I've been reminded twice that many > people using Python do so where they cannot just arbitarily > pip install , and if a library isn't in the std lib, > they can't use it without a lot of pain: 100% agree + one of the great advantages of Python is that the batteries actually are included and we are not forcing users to download one of twenty competing unstable versions somewhere on GitHub (I won't name any competing languages here). Also, I don't see a problem with having one more mature, slower version of library in the standard library, while the more alive version is still being developed from time to time rebasing the stdlib version (I thought, unittest was one such example.) Also, considering requests, I am still dreaming about somebody writing some requests-like API over the standard library. Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 My opinions may have changed, but not the fact that I am right. --Ashleigh Brilliant ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.7 -- bugfix or security before EOL?
On 2018-03-12, 13:13 GMT, Nick Coghlan wrote: > +1 from me, as even if commercial redistributors do decide > they want to collaborate on a post-2020 Python 2.7 maintenance > branch, there's no technical reason that that needs to live > under the "python" GitHub organisation, and some solid > logistical reasons for it to live somewhere more explicitly > vendor managed. It would be good to have some email list of the commercial redistributors (Linux distro maintainers + people from Anaconda etc.). Could python.org host it? Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 ..every Man has a Property in his own Person. This no Body has any Right to but himself. The Labour of his Body, and the Work of his Hands, we may say, are properly his. The great and chief end therefore, of Mens uniting into Commonwealths, and putting themselves under Government, is the Preservation of their Property. -- John Locke, "A Treatise Concerning Civil Government" ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Git hub : CLA Not Signed label
On 2018-03-11, 03:45 GMT, Terry Reedy wrote: > When processed properly, a day to a week, usually, a * will > appear after your name on any tracker (bpo) post. So, I got my start after the name, where is the list of maintainers of individual packages, so I could know whom to bother to take a look at my PR https://github.com/python/cpython/pull/5999 (damn, just one number too small!). Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. -- C. A. R. Hoare ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any way to only receive emails for threads that I am participating in?
On 2018-03-03, 02:15 GMT, Elias Zamaria wrote: > It seems like I can either subscribe and get emails for all of > the threads, or unsubscribe and not get any emails, making me > unable to reply to the threads I want to reply to. Go to https://mail.python.org/mailman/listinfo/python-dev in the last input box fill in your email, and click on [Unsubscribe or edit options]. On the next page fill-in your password (you get it every month in email), and on the settings page switch “Mail delivery” to “Disabled”. You will not get any message from the list, but you will be still subscribed, so you can post to the list. Then open your NNTP newsreader (https://en.wikipedia.org/wiki/Newsreader_(Usenet)) (you use one, right? It is the only sensible way how to deal with the large community lists) and subscribe to nntp://news.gmane.org/gmane.comp.python.devel . You will have all advantages of newsreader (killfile, easy ignoring whole threads at once) in the comfort of your computer, perhaps even in the offline state. If you don’t want to go all that length, just use email program which can kill threads (e.g., Thunderbird https://support.mozilla.org/en-US/kb/ignore-threads ) Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Of all tyrannies, a tyranny exercised for the good of its victims may be the most oppressive. It may be better to live under robber barons than under omnipotent moral busybodies. The robber baron's cruelty may sometimes sleep, his cupidity may at some point be satiated; but those who torment us for our own good will torment us without end, for they do so with the approval of their consciences. -- C. S. Lewis ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How is the GitHub workflow working for people?
On 2018-02-21, 21:49 GMT, Chris Angelico wrote: > Said PEP may also need to mention the possibility of exporting > the history of GitHub issues, in case CPython ever migrates away from > GitHub; I remember that concern being raised when the original > migration was discussed. There are tools for it (e.g., I wrote https://github.com/mcepl/github-issues-export to move issues to Bugzilla, yes I am weird) and it is not that difficult to write something just to get data from GitHub’s all embracing arms. Of course, I am not sure how it would work on really large number of bugs, and it would be necessary to do some postprocessing (changing issue numbers etc.). Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 God is not worried about my financial situation. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecate `from __future__ import unicode_literals`?
On 2016-12-16, 23:59 GMT, Guido van Rossum wrote: > No need to get all bent out of shape. My proposal is to simply > add a note to the docs recommending against using this. > I wouldn't change any code, not even a silent deprecation > warning. (Also, read the rest of the thread to learn why this > is not the best practice for writing Python 2/3 straddling > code.) Oh, that sounds a way better. Thank you. Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 If Patrick Henry thought that taxation without representation was bad, he should see how bad it is with representation. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecate `from __future__ import unicode_literals`?
On 2016-12-16, 19:24 GMT, Guido van Rossum wrote: > I am beginning to think that `from __future__ import unicode_literals` does > more harm than good. I don't recall exactly why we introduced it, but with > the restoration of u"" literals in Python 3.3 we have a much better story > for writing straddling code that is unicode-correct. ??? There has been absolute fanaticism about not changing anything in Python 2.* because of supposed stability of API, even in situations when I don’t think API was really in danger (http://bugs.python.org/issue19494). And now you would remove a feature which zillions of lines of code depend on, or at least could depend on? And yes, I do use it in my current porting efforts of M2Crypto to be py2/3k compatible. I don’t understand. Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Never, never, never believe any war will be smooth and easy, or that anyone who embarks on the strange voyage can measure the tides and hurricanes he will encounter. The statesman who yields to war fever must realise that once the signal is given, he is no longer the master of policy but the slave of unforeseeable and uncontrollable events. -- Winston Churchill, 1930 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition
On 2014-12-11, 14:47 GMT, Giampaolo Rodola' wrote: I still think the only *real* obstacle remains the lack of important packages such as twisted, gevent and pika which haven't been ported yet. And unwise decisions of some vendors (like, unfortunately my belvoed employer with RHEL-7) not to ship python3. Oh well. Matěj ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On 2014-11-30, 11:18 GMT, Ben Finney wrote: Donald Stufft don...@stufft.io writes: I think there is a big difference here between using a closed source VCS or compiler and using a closed source code host. Namely in that the protocol is defined by git so switching from one host to another is easy. GitHub deliberately encourages proprietary features that create valuable data that cannot be exported — the proprietary GitHub-specific pull requests being a prime example. What I really don’t understand is why this discussion is hg v. GitHub, when it should be hg v. git. Particular hosting is a secondary issue and it could be GitHub or git.python.org (with some FLOSS git hosting package ... cgit/gitolite, gitorious, gitlab, etc.) or python.gitorious.org (I believe Gitorious people might be happy to host you) or whatever else. Best, Matěj ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On 2014-12-01, 02:12 GMT, Pierre-Yves David wrote: Migrating the DVCS content is usually easy. This is lovely mantra, but do you speak from your own experience? I did move rope from Bitbucket to https://github.com/python-rope and it was A LOT of work (particularly issues, existing pull requests, and other related stuff like many websites the projects holds). And rope is particularly simple (and almost dead so inactive) project. Best, Matěj ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On 2014-12-01, 00:50 GMT, Donald Stufft wrote: The only thing that is true is that git users are more likely to use the ability to rewrite history than Mercurial users are, but you’ll typically find that people generally don’t do this on public branches, only on private branches. And I would add that any reasonable git repository manager (why we are talking only about GitHub as if there was no cgit, gitorious, gitlab, gitblit, etc.?) can forbid forced-push so the history could be as sacrosanct as with Mercurial. Matěj ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On 2014-12-01, 07:43 GMT, Donald Stufft wrote: I do not choose tools simply because they are written in Python -- I choose them because, being written in Python, I I can work on them if I need to: I can enhance them, I can fix them, I can learn from them. Git uses the idea of small individual commands that do small things, so you can write your own commands that work on text streams to extend git and you can even write those in Python. I really really dislike this Mercurial propaganda for two reasons: a) obviously you are right ... git is a complete tool box for building your own tools in the best UNIX™ traditions. Each of has a ton of third-party (or our own) tools using git plumbing. (Is there a Mercurial equivalent of git-filter-branch? Can http://mercurial.selenic.com/wiki/ConvertExtension do the same as git-filter-branch?) b) it completely ignores existence of three (3) independent implementations of git format/protocol (also jgit and libgit2). How does VisualStudio/Eclipse/NetBeans/etc. support for hg works? Does it use a library or just runs hg binary in a subprocess (a thing which by the hg authors is Mercurial not designed to do)? Best, Matěj ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing 2.7.x
On 2014-10-06, 20:03 GMT, Victor Stinner wrote: I started a list of Python 2 bugs that will not be fixed: http://haypo-notes.readthedocs.org/python.html\ #bugs-that-won-t-be-fixed-in-python-2-anymore It *is* possible to fix all bugs, but it requires a large amount of work, and we decided to focus our energy on Python 3. What about bugs which have patch already devleoped for both py3k and py2k. Hint: I would love to have some movement on http://bugs.python.org/issue19494 :) Best, Matěj ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Critical bash vulnerability CVE-2014-6271 may affect Python on *n*x and OSX
On 2014-09-25, 23:14 GMT, Cameron Simpson wrote: Fortunately, Python's subprocess has its `shell` argument default to False. However, `os.system` invokes the shell implicitly and is therefore a possible attack vector. Only if /bin/sh is bash :-) Not always the case, fortunately. Where does your faith that other /bin/sh implementations (dash, busybox, etc.) are less buggy comes from? On the contrary, bash being the most used, beaten, patched, and studied of them all has plenty of arguments to claim to be the most secure /bin/sh implementation around. You just don't know about those other guys bugs. No reason to believe hackers don't know about them either. Matěj ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Bug 19494 ... urllib2.HTTPBasicAuthHandler for GitHub et al.
Hi,
now when the vacations even in Europe are over could I ask for
some movement on http://bugs.python.org/issue19494? Demanding
a half-megabyte amount of packages from PIP ('just use requests'
mentioned by some comments in the thread) or for that matter any
package from PIP (including mine
https://pypi.python.org/pypi/urllib2_prior_auth/) for something
which is essentially a ten-lines patch seems to me rather crazy.
What happened to all those batteries which were supposed to be
included?
Best,
Matěj
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [PATCH] Add an authorization header to the initial request.
Many websites (e.g. GitHub API) on the Internet are intentionally not following RFC with regards to the Basic Authorization and require Authorization header in the initial request and they never return 401 error. Therefore it is not possible to authorize with such websites just using urllib2.py HTTPBasicAuthHandler as described in documentation. However, RFC 2617, end of section 2 allows pre-authorization in the initial request: A client MAY preemptively send the corresponding Authorization header with requests for resources in that space without receipt of another challenge from the server. (RFC also suggests preauthorization of proxy requests, but that is not part of this patch, however it could be trivially added) Also, generating HTTP BasicAuth header has been refactored into special method of AbstractBasicAuthHandler. Suggested fix for bug# 19494 This is my first attempt to contribute to Python itself, so please be gentle with me. Yes, I know that I miss unit tests and port to other branches of Python (this is against 2.7), but I would like first some feedback to see what I am missing (aside from the mentioned). Matěj Cepl --- Lib/urllib2.py | 35 +++ 1 file changed, 27 insertions(+), 8 deletions(-) diff --git a/Lib/urllib2.py b/Lib/urllib2.py index aadeb73..a5feb03 100644 --- a/Lib/urllib2.py +++ b/Lib/urllib2.py @@ -848,6 +848,18 @@ class AbstractBasicAuthHandler: def reset_retry_count(self): self.retried = 0 +def generate_auth_header(self, host, req, realm): +user, pw = self.passwd.find_user_password(realm, host) +if pw is not None: +raw = %s:%s % (user, pw) +auth = 'Basic %s' % base64.b64encode(raw).strip() +if req.headers.get(self.auth_header, None) == auth: +return None +req.add_unredirected_header(self.auth_header, auth) +return req +else: +return None + def http_error_auth_reqed(self, authreq, host, req, headers): # host may be an authority (without userinfo) or a URL with an # authority @@ -875,14 +887,10 @@ class AbstractBasicAuthHandler: return response def retry_http_basic_auth(self, host, req, realm): -user, pw = self.passwd.find_user_password(realm, host) -if pw is not None: -raw = %s:%s % (user, pw) -auth = 'Basic %s' % base64.b64encode(raw).strip() -if req.headers.get(self.auth_header, None) == auth: -return None -req.add_unredirected_header(self.auth_header, auth) -return self.parent.open(req, timeout=req.timeout) +req = self.generate_auth_header(host, req, realm) + +if req is not None: +self.parent.open(req, timeout=req.timeout) else: return None @@ -898,6 +906,17 @@ class HTTPBasicAuthHandler(AbstractBasicAuthHandler, BaseHandler): self.reset_retry_count() return response +def http_request(self, req): +host = req.get_host() + +new_req = self.generate_auth_header(host, req, None) +if new_req is not None: +req = new_req + +return req + +https_request = http_request + class ProxyBasicAuthHandler(AbstractBasicAuthHandler, BaseHandler): -- 1.8.5.2.192.g7794a68 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PATCH] Add an authorization header to the initial request.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2014-02-11, 12:27 GMT, you wrote: This is my first attempt to contribute to Python itself, so please be gentle with me. Yes, I know that I miss unit tests and port to other branches of Python (this is against 2.7), but I would like first some feedback to see what I am missing (aside from the mentioned). Please upload your patch to the issue. If it gets ignored there for a month, join the mentorship list and request a review. It is there (http://bugs.python.org/file34031/0001-Add-an-authorization-header-to-the-initial-request.patch), but given I am the only on Nose list of the bug, I thought it necessary to make a noise here. Matěj -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iD8DBQFS+h/14J/vJdlkhKwRAoOAAJ9nbR2LI+OPC6B/6LkpFvOnF5B2OwCdFgMg dhTv8f3u9d+Qmmukpmo2b9Y= =lj/m -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python3 complexity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2014-01-10, 17:34 GMT, you wrote: From my experience, the concept of a default locale is deeply flawed. What if I log into a (Linux) machine using an old latin-1 putty from the Windows XP era, have most file names and contents in UTF-8 encoding, except for one directory where people from eastern Europe upload files via FTP in whatever encoding they choose. What should the default encoding be now? I know this stuff is really hard and only because I had to fight with it for a years (being Czech, so not blessed by Latin-1 covering my language … actually no living encoding does support it completely, but that’s mostly theoretical issue … Latin-2 used to work for us, and now everybody with civilized OS uses UTF-8 of course, not sure what’s the current state of MS Windows). It seems to me that you have some fundamental principles muddled together. a) Locale should be always set for the particular system. I.e., in your example above you have two variables only: locale of your Windows XP and locale of the Linux box. b) I know for fact that exactly putty (even on Windows XP) CAN translate from UTF-8 on the server to whatever Windows have to offer. So, there is no such thing as “latin-1 putty”. c) Responsibility for filenames on the system stands on whatever actually saves the file. So, in this testcase it is a matter of correct setting up of the FTP server (I see for example http://rhn.redhat.com/errata/RHBA-2012-0187.html and https://bugzilla.redhat.com/show_bug.cgi?id=638873 which seem to indicate that vsftpd, and what else you would use?, should support UTF-8 on filenames). If the server locale supports Eastern European filenames and vsftpd supports translation to this encoding (hint, hint: UTF-8 does), then you are all set. That's why I make it a principle to always unset all LC_* and LANG variables, except when working locally, which happens rather rarely. That’s a bad idea. Those variables have ALWAYS some value set (perhaps default, which tends to be something like en_US.ASCII, which is not what you want, fortunately on most Unices these days it would be en_US.UTF8, command locale(1) always gives some result). Matěj -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iD8DBQFS0TsM4J/vJdlkhKwRAg9+AJ9wuCEnPqbUr6imA2L9ak17svSP3ACePVRp 5MKkSVUQ9G7A+fZVhDGiEC8= =MXgT -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2014-01-11, 10:56 GMT, you wrote: I don't know what the fuss is about. I just cannot resist: When you are calm while everybody else is in the state of panic, you haven’t understood the problem. -- one of many collections of Murphy’s Laws Matěj -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iD8DBQFS0UBf4J/vJdlkhKwRAtc3AJ9c1ElUhLjvHX+Jw4/NvvmGABNbTQCfe9Zm rD65ozDhpj/Fu3ydM8Oipco= =TDQP -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2014-01-11, 18:09 GMT, you wrote: We are NOT going back to the confusing incoherent mess that is the Python 2 model of bolting Unicode onto the side of POSIX . . . We are not asking for that. Yes, you do. Maybe not you personally, but number of people here on this list (for F...k sake, this is for DEVELOPERS of the langauge, not some bloody users!) for whom the current suggestion is just the way how to avoid Unicode and keep all those broken script which barfs at me all the time alive is quit non-zero I am afraid. Best, Matěj -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iD8DBQFS0ev24J/vJdlkhKwRAoHOAJ9crimnp+TtXCxmZLvTUSFVFSESAwCeNrby Yjwk6Ydzc/REezfHP046C5Y= =c2vl -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python3 complexity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2014-01-10, 12:19 GMT, you wrote: Using the 'latin-1' to mean unknown encoding can easily result in Mojibake (unreadable text) entering your application with dangerous effects on your other text data. E.g. Marc-André read using 'latin-1' if the string itself is encoded as UTF-8 will give you Marc-André in your application. (Yes, I see that a lot in applications and websites I use ;-)) I am afraid that for most 'latin-1' is just another attempt to make Unicode complexity go away and the way how to ignore it. Matěj -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iD8DBQFS0AOG4J/vJdlkhKwRAgffAKCHn8uMnpZDVSwa2Oat+QI2h32o2wCeJdUN ZXTbDtiJtJrrhnRPzbgc3dc= =Pr1X -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] urllib2.HTTPBasicAuthHandler doesn't work with GitHub API
Hi,
GitHub API v3 is intentionally broken (see
http://developer.github.com/v3/auth/):
The main difference is that the RFC requires unauthenticated requests
to be answered with 401 Unauthorized responses. In many places, this
would disclose the existence of user data. Instead, the GitHub API
responds with 404 Not Found. This may cause problems for HTTP
libraries that assume a 401 Unauthorized response. The solution is to
manually craft the Authorization header.
Unfortunately, urllib2.HTTPBasicAuthHandler relies on the
standard-conformant behavior. So a naive programmer (like me) who wants
to program against GitHub API using urllib2 (and foolishly ignores this
comment about the API non-conformance, because he thinks GitHub wouldn't
be that stupid and break all Python applications) writes something like
the attached script, spends couple of hours hitting this issue, until he
tries python-requests (which work) and his (mistaken) conclusion is that
urllib2 is a piece of crap which should never be used again.
I am not sure how widespread is this breaking of RFC, but it seems to me
that quite a lot (e.g., http://stackoverflow.com/a/9698319/164233 which
just en passant expects urllib2 authentication stuff to be useless), and
the question is whether it shouldn't be documented somehow and/or
urllib2.HTTPBasicAuthHandler shouldn't be modified to try add
Authenticate header first.
Any suggestions?
Best,
Matěj
--
http://www.ceplovi.cz/matej/, Jabber: mc...@ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC
For a successful technology, reality must take precedence over
public relations, for nature cannot be fooled.
-- R. P. Feynman's concluding sentence
in his appendix to the Challenger Report
import urllib.request
import base64
import json
import os
import logging
from configparser import SafeConfigParser
logging.basicConfig(format='%(levelname)s:%(funcName)s:%(message)s',
level=logging.DEBUG)
class HTTPBrokenBasicAuthHandler(urllib.request.AbstractHTTPHandler,
urllib.request.AbstractBasicAuthHandler):
auth_header = 'Authorization'
def __init__(self, *args, **kwargs):
urllib.request.AbstractHTTPHandler.__init__(self,
*args, **kwargs)
self.set_http_debuglevel(2)
def do_open(self, http_class, req, **http_conn_args):
user, password = self.passwd.find_user_password(None, req.full_url)
b64str = base64.standard_b64encode(
'{}:{}'.format(user, password)).decode('ascii')
req.add_header(self.auth_header, 'Basic {}'.format(b64str))
urllib.request.AbstractHTTPHandler(self,
http_class, req, http_conn_args)
def http_error_401(self, req, fp, code, msg, headers):
url = req.full_url
response = self.http_error_auth_reqed('www-authenticate',
url, req, headers)
self.reset_retry_count()
return response
cp = SafeConfigParser()
cp.read(os.path.expanduser('~/.githubrc'))
# That configuration file should look something like
# [github]
# user=mylogin
# password=myveryverysecretpassword
gh_user = cp.get('github', 'user')
gh_passw = cp.get('github', 'password')
repo = 'odt2rst'
pwd_manager = urllib.request.HTTPPasswordMgrWithDefaultRealm()
pwd_manager.add_password(None, uri='https://api.github.com', user=gh_user,
passwd=gh_passw)
auth_handler = HTTPBrokenBasicAuthHandler(pwd_manager)
opener = urllib.request.build_opener(auth_handler)
urllib.request.install_opener(opener)
API_URL = https://api.github.com/repos/{0}/{1}/issues/;
gh_url = API_URL.format(gh_user, repo, 1)
logging.debug(gh_url = {0}.format(gh_url))
req = urllib.request.Request(gh_url)
create_data = {
'title': 'Testing bug summary',
'body': '''This is a testing bug. I am writing here this stuff,
just to have some text for body.''',
'labels': ['BEbug']
}
handler = urllib.request.urlopen(req,
json.dumps(create_data).encode('utf8'))
print(handler.getcode())
print(handler)
signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Difference in RE between 3.2 and 3.3 (or Aaron Swartz memorial)
On 2013-02-26, 16:25 GMT, Terry Reedy wrote: On 2/21/2013 4:22 PM, Matej Cepl wrote: as my method to commemorate Aaron Swartz, I have decided to port his html2text to work fully with the latest python 3.3. After some time dealing with various bugs, I have now in my repo https://github.com/mcepl/html2text (branch python3) working solution which works all the way to python 3.2 (inclusive; https://travis-ci.org/mcepl/html2text). However, the last problem remains. This liRun this command: prels -l *.html/pre/li li?/li should lead to * Run this command: ls -l *.html * ? but it doesn’t. It leads to this (with python 3.3 only) * Run this command: ls -l *.html * ? Does anybody know about something which changed in modules re or http://docs.python.org/3.3/whatsnew/changelog.html between 3.2 and 3.3, which could influence this script? Search the changelob or 3.3 misc/News for items affecting those two modules. There are at least 4. http://docs.python.org/3.3/whatsnew/changelog.html It is faintly possible that the switch from narrow/wide builds to unified builds somehow affected that. Have you tested with 2.7/3.2 on both narrow and wide unicode builds? So, in the end, I have went the long way and bisected cpython to find the commit which broke my tests, and it seems that the culprit is http://hg.python.org/cpython/rev/123f2dc08b3e so it is clearly something Unicode related. Unfortunately, it really doesn't tell me what exactly is broken (is it a known regression) and if there is known workaround. Could anybody suggest a way how to find bugs on http://bugs.python.org related to some particular commit (plain search for 123f2dc0 didn’t find anything). Any thoughts? Matěj P.S.: Crossposting to python-devel in hope there would be somebody understanding more about that particular commit. For that I have also intentionally not trim the original messages to preserve context. -- http://www.ceplovi.cz/matej/, Jabber: mceplatceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC When you're happy that cut and paste actually works I think it's a sign you've been using X-Windows for too long. -- from /. discussion on poor integration between KDE and GNOME signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .{git,bzr}ignore in cpython HG repo
On 2.4.2012 00:52, Guido van Rossum wrote: Please file a bug to get this reviewed and checked in. OK, I don't agree with the reasoning, but I willingly submit to BDFL ;) http://bugs.python.org/issue14472 Matěj ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] .{git,bzr}ignore in cpython HG repo
Why does HG cpython repo contains .{bzr,git}ignore at all?
IMHO, all .*ignore files should be strictly repository dependent and
they should not be mixed together.
It is even worse, that (understandingly) .{bzr,git}ignore are apparently
poorly maintained, so in order to get an equivalent of .hgignore in
.gitignore, one has to apply the attached patch.
Best,
Matěj
--
http://www.ceplovi.cz/matej/, Jabber: mceplatceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC
We understand our competition isn't with Caldera or SuSE--our
competition is with Microsoft.
-- Bob Young of Red Hat
http://www.linuxjournal.com/article/3553
--- _gitignore.orig 2012-03-30 16:49:38.388685137 +0200
+++ _gitignore.fixed2012-03-30 16:57:21.634708179 +0200
@@ -5,14 +5,18 @@
*.pyd
*.pyo
*.rej
+*.swp
*~
+.gdb_history
Doc/build/
Doc/tools/docutils/
+Doc/tools/jinja/
Doc/tools/jinja2/
Doc/tools/pygments/
Doc/tools/sphinx/
Lib/lib2to3/*.pickle
Lib/_sysconfigdata.py
+Lib/plat-mac/errors.rsrc.df.rsrc
Makefile
Makefile.pre
Misc/python.pc
@@ -31,20 +35,35 @@
PCbuild/*.o
PCbuild/*.pdb
PCbuild/Win32-temp-*
+PCbuild/amd64/
+.purify
Parser/pgen
Parser/pgen.stamp
__pycache__
autom4te.cache
build/
+buildno
+config.cache
+config.log
+config.status
+config.status.lineno
+core
+db_home
config.log
config.status
libpython*.a
libpython*.so*
+platform
pybuilddir.txt
pyconfig.h
python
+python.exe
python-gdb.py
+python.exe-gdb.py
+reflog.txt
+.svn/
tags
+TAGS
.coverage
coverage/
htmlcov/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .{git,bzr}ignore in cpython HG repo
On 1.4.2012 23:46, Brian Curtin wrote: For what reason? Are the git or bzr files causing issues on HG? No, but wrong .gitignore causes issues with git repo obtained via hg-fast-import. If it is meant as an intentional sabotage of using git (and bzr) for cpython, then that's the only explanation I can understand, otherwise it doesn't make sense to me why these files are in HG repository at all. Matěj -- http://www.ceplovi.cz/matej/, Jabber: mceplatceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC Somewhere at the edge of the Bell curve was the girl for me. -- Based on http://xkcd.com/314/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
