Re: [Python-Dev] subprocess shell=True on Windows doesn't escape ^ character
On 11/06/2014 21:26, anatoly techtonik wrote: I am banned from tracker, so I post the bug here: The OP's approach to the Python community is beautifully summarised here http://bugs.python.org/issue8940 -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ 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] Pending issues
The following is a list of the 18 pending issues on the bug tracker.
All have been in this state for at least one month so I'm assuming that
they can be closed or they wouldn't have been set to pending in the
first place. Can somebody take a look at them with a view to closing
them or setting them back to open if needed.
16221tokenize.untokenize() "compat" mode misses the encoding when
using an iterator
15600expose the finder details used by the FileFinder path hook
12588test_capi.test_subinterps() failed on OpenBSD (powerpc)
7979 connect_ex returns 103 often
17668re.split loses characters matching ungrouped parts of a pattern
11204re module: strange behaviour of space inside {m, n}
14518Add bcrypt $2a$ to crypt.py
15883Add Py_errno to work around multiple CRT issue
19919SSL: test_connect_ex_error fails with EWOULDBLOCK
20026sqlite: handle correctly invalid isolation_level
18228AIX locale parsing failure
1602742 itemconfigure returns incorrect text property of text items
19954test_tk floating point exception on my gentoo box with tk 8.6.1
21084IDLE can't deal with characters above the range (U+-U+)
20997Wrong URL fragment identifier in search result
6895 locale._parse_localename fails when localename does
not contain encoding information
1669539 Improve Windows os.path.join (ntpath.join) "smart" joining
21231Issue a python 3 warning when old style classes are defined.
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
---
This email is free from viruses and malware because avast! Antivirus protection
is active.
http://www.avast.com
___
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] PEP 3121, 384 Refactoring Issues
I'm just curious as to why there are 54 open issues after both of these PEPs have been accepted and 384 is listed as finished. Did we hit some unforeseen technical problem which stalled development? For these and any other open issues if you need some Windows testing doing please feel free to put me on the nosy list and ask for a test run. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ 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] Reviving restricted mode?
On 11/08/2014 18:42, matsjoyce wrote: Yup, I read that post. However, those specific issues do not exist in my module, as there is a module whitelist, and a method whitelist. Builtins are now proxied, and all types going in to functions are checked for modification. There maybe some holes in my approach, but I can't find them. Any chance of giving us some context, or do I have to retrieve my crystal ball from the menders? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] Documenting enum types
On 14/08/2014 17:14, Ethan Furman wrote: On 08/14/2014 08:51 AM, Ben Hoyt wrote: The BDFL actually wrote:- The enemy must be documented and exported, since users will encounter them. QOTW. enum == enemy? Is that you, Raymond? ;-) ROFL! Thanks, I needed that! :D -- ~Ethan~ I'll be seeing the PSF in court, on the grounds that I've just bust a gut laughing :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] List insert at index that is well out of range - behaves like append
On 15/09/2014 23:29, Mark Shannon wrote: On 15/09/14 12:31, Tal Einat wrote: On Mon, Sep 15, 2014 at 6:18 AM, Harish Tech wrote: I had a list a = [1, 2, 3] when I did a.insert(100, 100) [1, 2, 3, 100] as list was originally of size 4 and I was trying to insert value at index 100 , it behaved like append instead of throwing any errors as I was trying to insert in an index that did not even existed . Should it not throw IndexError: list assignment index out of range exception as it throws when I attempt doing a[100] = 100 Question : 1. Any idea Why has it been designed to silently handle this instead of informing the user with an exception ? Personal Opinion : Lets see how other dynamic languages behave in such a situation : Ruby : > a = [1, 2] > a[100] = 100 > a => [1, 2, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, 100] The way ruby handles this is pretty clear and sounds meaningful (and this is how I expected to behave and it behaved as per my expectation) at least to me . So what I felt was either it should throw exception or do the way ruby handles it . Is ruby way of handling not the obvious way ? I even raised it in stackoverflow http://stackoverflow.com/questions/25840177/list-insert-at-index-that-is-well-out-of-range-behaves-like-append and got some responses . Hello Harish, The appropriate place to ask questions like this is python-list [1], or perhaps Stack Overflow. I think this is an OK forum for this question. If someone isn't sure if something is a bug or not, then why not ask here before reporting it on the bug tracker? This does seem strange behaviour, and the documentation for list.insert gives no clue as to why this behaviour was chosen. Cheers, Mark. I assume it's based on the concepts of slicing. From the docs "s.insert(i, x) - inserts x into s at the index given by i (same as s[i:i] = [x])". Although shouldn't that read s[i:i+1] = [x] ? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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-committers] [RELEASE] Python 3.4.2 is now available
On 08/10/2014 11:21, Victor Stinner wrote: 2014-10-08 10:57 GMT+02:00 Larry Hastings : You can download it here: https://www.python.org/download/releases/3.4.2 This page redirect me to https://www.python.org/download/releases/3.4.1 Maybe some web servers of the CDN don't contain the latest version. I guess that the issue will quickly disappears. Victor Further if you navigate from 3.4.1 to 3.4.2 it says "Python 3.4.2rc1 was released on October 8th, 2014.". The download itself is correct. Thanks as always to everybody who has contributed, another great piece of work. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] Status of C compilers for Python on Windows
On 10/10/2014 01:29, Victor Stinner wrote: === MinGW Some people tried to compile Python. See for example: https://bitbucket.org/puqing/python-mingw We even got some patches: http://bugs.python.org/issue3871 (rejected) There are 55 open issues on the bug tracker with mingw in the title. See also: https://stackoverflow.com/questions/15365249/build-python-with-mingw-and-gcc MinGW reuses the Microsoft C library and it is based on GCC which is very stable, actively developed, supports a lot of archiectures, etc. I guess that it should be possible to reuse third party GCC tools like the famous GDB debugger? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] Status of C compilers for Python on Windows
On 26/10/2014 00:24, R. David Murray wrote: On Sun, 26 Oct 2014 00:19:44 +0200, Antoine Pitrou wrote: On Sun, 26 Oct 2014 09:06:36 +1100 Chris Angelico wrote: On Sun, Oct 26, 2014 at 8:59 AM, Antoine Pitrou wrote: How do you know this isn't a problem, since you haven't *tested* with MSVC? Why on Earth would you want to test your PEP work with an unsupported Windows compiler and runtime, rather than with the officially supported compiler and runtime? This discussion revolved around supporting MinGW in addition to MSVC. If it had been supported when I was doing that, I could have spun myself up a Windows build and tested it. My point is that your "Windows build" would not have the same behaviour as a MSVC-produced Windows build, and so testing it with it would not certify that your code would actually be compatible with genuine MSVC builds of CPython, which we will not stop supporting. While true, I don't think that matters for Chris' point. Given only the ability to build with the MSVC toolchain, his code (which might even be pure python for the purposes of this discussion) would not get tested on Windows until committed and run by the buildbots. If he could build CPython using MinGW, he would, and would test his code on Windows. Even if there are C components and MSVC/MinGW compatibility issues are revealed when the buildbots eventually run the code, still the number of bugs present would probably be lower if he had tested it on Windows than if he hadn't. I know I for one do not generally test patches on Windows because I haven't taken the time to learn how to build CPython on it. Sure, I could test pure python changes by applying patches to an installed Python, but that's an ongoing pain and I'd rather learn to build CPython on Windows and get to use the normal hg tools. If I could use a more linux-like toolchain to build CPython on windows, I would doubtless do much more testing on windows for stuff where I think windows might behave differently (and I might look at more Windows bugs...though frankly there are plenty of bugs for me to look at without looking at Windows bugs). This is not necessarily a compelling argument for MinGW support. However, it *is* a valid argument, IMO. Note: it can be made even less compelling by making it a lot easier to build CPython on Windows without having an MSVC license (which I think means not using the GUI, for which I say *yay* :). I think Zach Ware has been working on improving the Windows build process, and I keep meaning to give it a try... --David MSVC Express Edition 2010 works perfectly for building 3.5 so no license needed. Links to older versions have been pointed out on other threads, either here or python-ideas, maybe both? Or use the command line as Antoine pointed out elsewhere. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] New Windows installer for Python 3.5
On 04/01/2015 22:56, Steve Dower wrote: Paul Moore wrote: Overall, this looks good. One question - will it be possible to install both 32-bit and 64-bit Python on the same machine? Currently, you need a custom install to do this (as the default directory doesn't include the architecture) and IIRC there's some oddness around install order. It would be nice if installing both versions were a supported option, both for the "default" install and in custom installs. Yes, the default install directories on the first page are different for 32-bit and 64-bit (either "Program Files [(x86)]" or "Python35[-32]"). The default value on the customize page is currently always C:\Python35, and so you'll need to change it if you're doing custom installs, but that's easy to add the "-32" by default. (I used a -32 suffix because it matches the py.exe option.) Also, what happens now with setting PATH? Is Python (and the scripts directory) added to PATH by default? If so, what happens when you install 2 versions of Python? Yes, and in general the later installed version will win and system-wide installs always beat per-user installs. As I mentioned above, using py.exe with a parameter or shebang line is the most reliable way to get the version you want. In case it's not clear, I'm thinking of the impact on build machines, which often have multiple versions, in both 32- and 64-bit forms, installed simultaneously (but can also be used as a "normal" development machine, and for that purpose will want a selected Python version as the default one. You should see my dev machines :) Most have 2.5, 2.6, 2.7 32-bit and 64-bit, 3.0, 3.1, 3.2, 3.3 32-bit and 64-bit, 3.4 32-bit and 64-bit, IronPython and often PyPy, Anaconda or Canopy. So I'm being fairly selfish when I try and make the multiple-versions scenario work better, but it will benefit everyone. Also, how does the launcher py.exe fit into the picture? Is it still installed into the Windows directory? What about for a user install? Are Python scripts associated with the launcher, and if so, how does it pick up the version you selected as default? py.exe is more important than ever. It's still installed into the Windows directory for all-user installs, and into the Python directory for just-for-me. It's installed in a way that will make upgrades more reliable (so if you install 3.6 and then 3.5, you'll keep the newer launcher) and all the file associations go straight to the launcher. The default Python for the launcher seems to be 2.7 if it's there and the latest version if not (though I could be wrong). Shebang lines are the best way to choose a specific version. Incidentally, whoever came up with the py.exe launcher deserves a medal. It's made dealing with multiple versions amazingly easy. If I'm reading this correctly it means that py.exe gets picked up from PATH so it could be 32 or 64 bit. Does this mean that the launcher could be or needs enhancing so 32 or 64 bit can be selected? I'm not sure if anything can be done about pyw.exe, perhaps you (plural) can throw some light on this for me. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] New Windows installer for Python 3.5
On 05/01/2015 17:09, Steve Dower wrote: Paul Moore wrote: Steve is in essence saying that it's not possible to sanely manage PATH as part of the new installer, but that py.exe makes that unnecessary. It's actually not possible to sanely manage PATH from any installer - it really needs to be handled by a user directly (though I can't ever bring myself to tell anyone to use the UI for it). The old installers were less susceptible because they didn't support per-user installs, but you'd still get the "last install Python wins" behaviour. Something that's help keep me slightly sane is the Rapid Environment Editor http://www.rapidee.com/en/about. I'm sure there are plenty of other choices but it does what I need. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] Compile Python on Windows (OpenSSL)
On 13/01/2015 22:04, Victor Stinner wrote: +* Type: PCbuild\win32\python_d.exe PCbuild\prepare_ssl.py externals\openssl-1.0.1j See also http://bugs.python.org/issue23212 "Update Windows and OS X installer copies of OpenSSL to 1.0.1k" -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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 484 syntax: NONONONONONONO!
On 01/02/2015 10:13, Benjamin wrote: The proposed syntax is abominable. It's the opposite of readable. I have no views on the subject as I won't be using it, but there is no need to shout to get your point across. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] (no subject)
On 10/02/2015 13:23, Antoine Pitrou wrote: On Tue, 10 Feb 2015 23:16:38 +1000 Nick Coghlan wrote: On 10 Feb 2015 19:24, "Terry Reedy" wrote: On 2/9/2015 7:29 PM, Neil Girdhar wrote: For some reason I can't seem to reply using Google groups, which is is telling "this is a read-only mirror" (anyone know why?) I presume spam prevention. Most spam on python-list comes from the read-write GG mirror. There were also problems with Google Groups getting the reply-to headers wrong (so if someone flipped the mirror to read-only: thank you!) With any luck, we'll have a native web gateway later this year after Mailman 3 is released, so posting through Google Groups will be less desirable. There is already a Web and NNTP gateway with Gmane: http://news.gmane.org/gmane.comp.python.devel No need to rely on Google's mediocre services. Regards Antoine. Highly recommended as effectively zero spam. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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 370 - per-user scripts directory on Windows
On 10/02/2015 20:47, Paul Moore wrote: On 10 February 2015 at 12:38, Paul Moore wrote: Comments? If this is acceptable, I would be willing to prepare a patch for Python 3.5 implementing this. See http://bugs.python.org/issue23437 As yet untested, as I just realised I need to get Visual Studio 2015 installed to be able to build Python 3.5. I'll try to get that sorted out, but I thought it would be worth putting the patch up anyway - it's pretty simple. Paul Visual Studio 2013 is fine for building 3.5. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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 370 - per-user scripts directory on Windows
On 12/02/2015 20:23, Paul Moore wrote: On 12 February 2015 at 20:11, Ethan Furman wrote: I believe you are correct; however, as the PEP for the launcher stated [1] "use as a general-purpose (aka non-python) launcher is explicitly not supported". Yes, I once used it to start Perl scripts, just because it appealed to the perverse instinct in me. Part of me wishes there had been a problem, so that I could be the one who raised a legitimate bug on bugs.python.org saying "Python encounters an error when running a Perl script" :-) Paul Get thee behind me, Satan. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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 441 - Improving Python ZIP Application Support
On 15/02/2015 18:06, Steve Dower wrote: "Go ahead, make my pep." We should make a python-dev t-shirt with this on it :) I'll buy one provided p&p isn't too high :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] Emit SyntaxWarning on unrecognized backslash escapes?
On 23/02/2015 21:27, Serhiy Storchaka wrote: On 23.02.15 21:58, Joao S. O. Bueno wrote: That happens all the time, and is this use case that should possibly be addressed here - maybe something as simple as adding a couple of paragraphs to different places in the documentation could mitigate the issue. (in contrast to make a tons of otherwise valid code to become deprecated in a couple releases). The problem is that the user don't know that he should read the documentation. It just find that his script works with "C:\sample.txt", but doesn't work with "D:\test.txt". He has no ideas what happen. Isn't this why users have help desks? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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 489: Redesigning extension module loading
On 16/03/2015 12:38, Petr Viktorin wrote: Hello, Can you use anything from the meta issue http://bugs.python.org/issue15787 for PEP 3121 and PEP 384 or will the work that you are doing render everything done previously redundant? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] Guarantee ordered dict literals in v3.7?
On 07/11/17 04:05, David Mertz wrote: I strongly opposed adding an ordered guarantee to regular dicts. If the implementation happens to keep that, great. Maybe OrderedDict can be rewritten to use the dict implementation. But the evidence that all implementations will always be fine with this restraint feels poor, and we have a perfectly good explicit OrderedDict for those who want that. If there is an ordered guarantee for regular dicts but not for dict literals, which is the subject of this thread, then haven't we got a recipe for the kind of confusion that will lead to the number of questions from newbies going off of the Richter scale? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] Guido's Python 1.0.0 Announcement from 27 Jan 1994
On 27/01/18 17:05, Oleg Broytman wrote: On Sat, Jan 27, 2018 at 08:58:54AM -0800, Senthil Kumaran wrote: Someone in HackerNews shared the Guido's Python 1.0.0 announcement from 27 Jan 1994. That is, on this day, 20 years ago. 24 years ago, no? (-: Correct so we only have one year to organise the 25th birthday party. The exact time and place for the party will obviously have to be discussed on python-ideas, or do we need a new mailing list? :-) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] Computed Goto dispatch for Python 2
On 28/05/2015 15:47, Skip Montanaro wrote: On Thu, May 28, 2015 at 9:02 AM, Brett Cannon wrote: But you could argue that "Special cases aren't special enough to break the rules" and that's what we are proposing here by claiming Python 2.7 is a special case and thus we should accept a patch that is not a one-liner change to gain some performance in a bugfix release. One can read anything he wants into the Zen. I could respond with this retort: "Although practicality beats purity," but I won't. :-) Skip That's good, otherwise you'd just be repeating what Raymond said further up this subthread two hours and one minute before you didn't say it :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] RM for 3.6?
On 01/06/2015 19:33, Benjamin Peterson wrote: On Mon, Jun 1, 2015, at 14:24, Stefan Behnel wrote: Barry Warsaw schrieb am 01.06.2015 um 20:07: On May 30, 2015, at 10:09 AM, Serhiy Storchaka wrote: Isn't it a time to assign release manager for 3.6-3.7? Indeed! Please welcome Ned Deily as RM for 3.6: https://www.python.org/dev/peps/pep-0494/ Does he know already? The suck^H^H^H^H man even volunteered! Was that "volunteered" as in RM or the Comfy Chair? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] Unable to build regex module against Python 3.5 32-bit
On 05/06/2015 01:37, MRAB wrote: Steve Dower's post has prompted me to look again at building the regex module for Python 3.5, 32-bit and 64-bit, using just Mingw64 and linking against python32.dll. It works! Earlier versions of Python, however, including Python 2.7, still seem to want libpython??.a. This http://bugs.python.org/issue24385 should interest you. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] Obtaining stack-frames from co-routine objects
On 14/06/2015 11:50, Ben Leslie wrote: Per Nick's advice I've created enhancement proposal 245340 with an attached patch. http://bugs.python.org/issue24450 as opposed to http://bugs.python.org/issue24450#msg245340 :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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 493: Redistributor guidance for Python 2.7 HTTPS
On 07/07/2015 03:10, Stephen J. Turnbull wrote: Cross-posted to redirect discussion. Replies directed to Python-Ideas. Erik Bray writes on Python-Dev: > On Mon, Jul 6, 2015 at 6:21 AM, Antoine Pitrou wrote: > > On Mon, 6 Jul 2015 14:22:46 +1000, Nick Coghlan wrote: > >> > >> The main change from the last version discussed on python-ideas > > > > Was it discussed there? That list has become totally useless, I've > > stopped following it. > > Considering that a useful discussion of a useful PEP occurred there > (not to mention other occasionally useful discussions) I'd say that > such a value judgment is not only unnecessary but also inaccurate. As you point out, the words "totally" and "useless" were unnecessary and inaccurate respectively. However, the gist of his post, that the S/N on Python-Ideas has become substantially lower in the last few months, seems accurate to me. At least two recent threads could have been continued on Python-List, where they would have benefited a lot more users, and they didn't seem profitable on Python-Ideas since it was quite evident that Those Who Know About Python were adamantly opposed to the idea as discussed in the thread, while the proponent kept pushing on that brick wall rather than seeking a way around it. I myself continue to follow Python-Ideas, Nick and other committers are posting here daily, and even Guido manages to pop up occasionally, so that may be no problem (or even a good thing if it results in educating and inviting new committers in the long run). But I think it's worth considering whether it we should cultivate a bit more discipline here. Again, discussion on Python-Ideas, please. From https://mail.python.org/mailman/listinfo/python-ideas This list is to contain discussion of speculative language ideas for Python for possible inclusion into the language. If an idea gains traction it can then be discussed and honed to the point of becoming a solid proposal to put to python-dev as appropriate. Relative to the above I believe that far too many proposals are for trivial ideas, mainly targetted at the stdlib, that would be better suited to the main python list. As for gaining traction, it's often the complete opposite, flogging a dead horse is an understatement for some threads. Gently putting the OP down with a firm but polite "it ain't gonna happen" would save a lot of time all around. Just my £0.02p worth. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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 493: Redistributor guidance for Python 2.7 HTTPS
On 07/07/2015 15:42, Antoine Pitrou wrote: Whether the time required to properly follow python-ideas is a productive involvement for the average core dev is another question. The problem I see with python-ideas is that it may select on free time more than on actual, concrete contribution... (note that python-list has a similar problem with some of its old-timers and regular ranters; the difference is that python-list has a ready alternative in StackOverflow, with perhaps higher-quality answers... it's less and less relevant in the grand scheme of things) I cannot see StackOverflow as a "ready alternative" to python-list as questions are strictly closed, nothing in the way of debate is allowed. I'd love to explain to some people what I think of their "perhaps higher-quality answers" but I don't have enough "reputation". Having said that I have to agree about python-list, there is very little of any substance on there nowadays. Perhaps that's because people are reading any of the 387 Python lists on gmane that are dedicated to their specific area of interest? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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 far to go with user-friendliness
On 14/07/2015 23:22, Robert Collins wrote: For clarity, I think we should: - remove the assret check, it is I think spurious. - add a set of functions to the mock module that should be used in preference to Mock.assert* - mark the Mock.assert* functions as PendingDeprecation - in 3.6 move the PendingDeprecation to Deprecated - in 3.7 remove the Mock.assert* functions and the check for method names beginning with assert entirely. -Rob +1 from me as not even Baldrick could do better, see https://en.wikipedia.org/wiki/Baldrick :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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 far to go with user-friendliness
On 18/07/2015 01:00, Ryan Gonzalez wrote: I am tempted to reply with a slightly sarcastic message involving a cookie... I'm not tempted, I will ask, what the hell are you on about? On July 17, 2015 6:40:21 PM CDT, Antoine Pitrou wrote: Frankly, this kind of inept discussion, where a bunch of folks get hung up about an extremely minor design decision (who cares whether "assret" is being special-cased or not? in the actual world, not the fantasy world of righteous indignation and armchair architects?), is amongst the reasons why I'm stopping contributing to CPython. Keep up the good work, you're making this place totally repulsive to participate in. Every maintainer or contributor now has an army of voluntary hair-splitters to bother about, most of whom probably aren't relying on said functionality to begin with. Regards Antoine. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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 far to go with user-friendliness
On 19/07/2015 22:06, Brett Cannon wrote: On Sun, Jul 19, 2015 at 8:58 AM Ethan Furman mailto:et...@stoneleaf.us>> wrote: On 07/19/2015 02:22 AM, s.krah wrote: > Ein Sa, 18 Jul 2015 15:35:05 + *Stephen J. Turnbull hat geschrieben >> s.krah writes: >>> Sorry, that amounts to twisting my words. >> >> Let's not play the dozens here. That just extends the thread to no point. > > Indeed. I'll just filter you from now on. You may as well filter me too, then, because you are acting like an ass and I'm saying so. Is the name calling really necessary? Couldn't you have just as easily said that you disapproved of Stephen K's attitude without calling him an ass? Same goes for Stephen K's comment where he could have stated he was simply going to ignore Stephen T and be less snippy about it. There are ways to get the point across just as strongly without resorting to this sort of stuff. This whole thread has shown two problems we have on this list. One is the occasional name calling and bad attitude that we let slide in the name of blowing off steam or something. We are all adults here and can get the point across that we disapprove of something without resorting to playground antics. Plus emails can be delayed until cooler heads prevail. It's this kind of thing that leads to the need of a CoC for this list and contributing in general so that people can feel okay saying they thought a comment was out of line without retaliation for it. The other problem is letting threads drag on needlessly. The longer a thread drags on, the greater the chance someone is going to say something they regret. It can also lead to some people like Antoine feeling like their time is being wasted and become frustrated. I think in this instance debate should have been cut sooner when no clear consensus was being reached to force a reversal of the patch and then have someone say politely that a core dev who is the listed expert on a module made a call and if someone disliked it they could produce a patch and propose it on the issue tracker to see if they could change someone's mind (I believe both Nick and Ethan have made the same point). Our niceness can be to a fault when no one is willing to step up and simply say "this thread is in a stalemate and nothing new is being added, please move it to the issue tracker if you wish to discuss further where you can propose a patch" and we just be good about telling people to move the discussion to the issue tracker if they keep replying. There is absolutely no reason we can't keep discussions cordial, friendly, and on-point on this list and prevent this sort of debacle from occurring again. +infinity -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] Status on PEP-431 Timezones
On 25/07/2015 00:06, ISAAC J SCHWABACHER wrote: I got to "Daylight Saving Time is a red herring," and stopped reading. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] Burning down the backlog.
On 26/07/2015 22:59, Paul Moore wrote: On 26 July 2015 at 16:39, Berker Peksağ wrote: I'm not actually clear what "Commit Review" status means. I did do a quick check of the dev guide, and couldn't come up with anything, https://docs.python.org/devguide/triaging.html#stage Thanks, I missed that. The patches I checked seemed to have been committed and were still at commit review, though. Doesn't the roundup robot update the stage when there's a commit? (Presumably not, and people forget to do so too). Paul I wouldn't know. I certainly believe that the more time we spend assisting Cannon, Coghlan & Co on the core workflow, the quicker, in the medium to long term, we put the backlog of issues to bed. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] Status on PEP-431 Timezones
On 27/07/2015 15:45, Nick Coghlan wrote: On 28 July 2015 at 00:27, Steve Dower wrote: Am I the only one feeling like this entire thread should be moved to python-ideas at this point? Since this is an area where the discussion of implementation details and the discussion of the developer experience can easily end up at cross purposes, I'm wondering if there may be value in actually splitting those two discussions into different venues by creating a datetime-sig, and specifically inviting the pytz and dateutil developers to participate in the SIG as well. The traffic on a similarly niche group like import-sig is only intermittent, but it means that by the time we bring suggestions to python-ideas or python-dev, we've already thrashed out the low level arcana and know that whatever we're proposing *can* be made to work, leaving the core lists to focus on the question of whether or not the change *should* be made. Whether or not to do that would be up to the folks with a specific interest in working with dates and times, though. Cheers, Nick. Would it be worth doing a straw poll to gauge how many people really need this, from my perspective anyway, level of complexity? I've used datetimes a lot, but I don't even need naive timezones, completely dumb suits me. Alternatively just go ahead, knowing that if the proposal isn't accepted into the stdlib it can at least go on pypi. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] Status on PEP-431 Timezones
On 28/07/2015 01:58, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/27/2015 06:03 PM, Tim Peters wrote: Even if days weren't a distinguished unit for timedelta, I'd still much rather write, e.g., timedelta(days=5, hours=3) than timedelta(hours=123) or timedelta(hours=5*24 + 3) etc. The intent of the first spelling is obvious at a glance. - From a human's perspective, "a day from now" is always potentially unambigous, just like "a month from now" or "a year from now", whereas "24 hours from now" is never so. In a given application, a user who doesn't care can always write a helper function to generate hours; in an applicatino whose developer who *does* care, the 'days' argument to timedelta in its current does *not* help achieve her goal: it is an attractive nuisance she will have to learn to avoid. To me a day is precisely 24 hours, no more, no less. I have no interest in messing about with daylight savings of 30 minutes, one hour, two hours or any other variant that I've not heard about. In my mission critical code, which I use to predict my cashflow, I use code such as. timedelta(days=14) Is somebody now going to tell me that this isn't actually two weeks? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] Status on PEP-431 Timezones
On 28/07/2015 03:15, Tim Peters wrote: [Mark Lawrence ] To me a day is precisely 24 hours, no more, no less. I have no interest in messing about with daylight savings of 30 minutes, one hour, two hours or any other variant that I've not heard about. In my mission critical code, which I use to predict my cashflow, I use code such as. timedelta(days=14) Is somebody now going to tell me that this isn't actually two weeks? Precisely define what "two weeks" means, and then someone can answer. One week == 7 days == 7 * 24 hours Two weeks = 2 * (one week) The timedelta in question represents precisely 14 24-hours days, and ignores the possibility that some day in there may suffer a leap second. As I've said elsewhere I've no interest in DST, at least right here, right now, let alone leap seconds. When I run my cashflow forecast the balance in my bank account one year from today isn't going to be influenced by UK clocks falling back to GMT at the end of October and on to BST at the end of next March. It remains unclear to me which of those outcomes _you_ consider to be "actually 14 days". But my bet is that you like what Python already does here (because "tz-naive arithmetic" is exactly what _I_ want in all my financial code). Correct. What I would like to know is how many people are in my position, how many people are in the situation of needing every possible combination of dates, times, daylight saving, local time zone rules and anything else you can think of under the sun, and how many are on the scale somewhere in between these two extremes. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] Status on PEP-431 Timezones
On 28/07/2015 06:21, Lennart Regebro wrote: On Tue, Jul 28, 2015 at 3:22 AM, Mark Lawrence wrote: To me a day is precisely 24 hours, no more, no less. OK. In my mission critical code, which I use to predict my cashflow, I use code such as. timedelta(days=14) Is somebody now going to tell me that this isn't actually two weeks? Yes, I'm telling you that, now. The two claims "One day is always precisely 24 hours" and "14 days is two weeks" are not both true. You have to choose one. //Lennart You can tell me, but as far as I'm concerned in my application both are true, so I don't have to choose one. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] Status on PEP-431 Timezones
On 28/07/2015 07:54, Lennart Regebro wrote: On Tue, Jul 28, 2015 at 8:11 AM, Tim Peters wrote: [Tim] timedelta objects only store days, seconds, and microseconds, [Lennart Regebro ] Except that they don't actually store days. They store 24 hour periods, Not really. A timedelta is truly an integer number of microseconds, and that's all. That's what I said. Timedeltas, internally assume that 1 day is 24 hours. Or 8640 microseconds. That's the assumption internally in the timedelta object. The problem with that being that in the real world that's not true. In my real world it is. We clearly have parallel worlds. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] Status on PEP-431 Timezones
On 28/07/2015 05:26, Tim Peters wrote: Python's datetime supports microsecond precision. Mere seconds are for wimps ;-) Microseconds are for wimps https://bugs.python.org/issue22117 :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] Status on PEP-431 Timezones
On 28/07/2015 13:35, Lennart Regebro wrote: On Tue, Jul 28, 2015 at 1:55 PM, Mark Lawrence wrote: One week == 7 days == 7 * 24 hours Two weeks = 2 * (one week) Right, and that of course is not true in actual reality. I know you are not interested in DST, but with a timezone that has DST, two times a year, the above statement is wrong. Tim asked for my definition of two weeks so I've given it. With respect to that in reality this is true, for me, with my application, making my statement above correct. For my application we could go from GMT to BST and back on successive days throughout the year and it wouldn't make any difference. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] Status on PEP-431 Timezones
On 28/07/2015 16:47, Chris Angelico wrote: On Tue, Jul 28, 2015 at 10:06 PM, Mark Lawrence wrote: On 28/07/2015 06:21, Lennart Regebro wrote: On Tue, Jul 28, 2015 at 3:22 AM, Mark Lawrence wrote: To me a day is precisely 24 hours, no more, no less. In my mission critical code, which I use to predict my cashflow, I use code such as. timedelta(days=14) Is somebody now going to tell me that this isn't actually two weeks? Yes, I'm telling you that, now. The two claims "One day is always precisely 24 hours" and "14 days is two weeks" are not both true. You have to choose one. You can tell me, but as far as I'm concerned in my application both are true, so I don't have to choose one. (and subsequently) Tim asked for my definition of two weeks so I've given it. With respect to that in reality this is true, for me, with my application, making my statement above correct. For my application we could go from GMT to BST and back on successive days throughout the year and it wouldn't make any difference. When your clocks go from winter time to summer time, there are two possibilities: 1) Your application says "days=14" and actually gets 167 or 169 hours 2) Your application says "days=14" and ends up with the time changing My cashflow forecast doesn't give two hoots how many hours there are in two weeks, which I've defined elsewhere. It doesn't care if the time changes. Neither does it care how many days there are in a month for that matter. It can even cater with plotting data with a tick on the 29th of each month when we have a leap year and February is included in the plot, thanks to the dateutils rrule. (Or equivalently if you say "days=1" or "hours=24" or whatever.) A naive declaration of "two weeks later" could conceivably mean either. When I schedule my weekly Dungeons & Dragons sessions, they are officially based on UTC [1], which means that one session starts 168 hours after the previous one. Currently, they happen when my local clock reads noon; in summer, my local clock will read 1PM. Was it still "a week later" when it was noon once and 1PM the next time? Don't know and don't care, your application is not working in the same way that mine does. Conversely, my (also weekly) Thinkful open sessions are scheduled every week at 8AM US Eastern time (America/New_York). For anyone on the Atlantic coast of the US, they will occur every Wednesday and the clock will read 08:00 every time. Sometimes, one will happen 167 hours after the previous one, or 169 hours afterwards. Is that "a week later"? Ditto my above remark. Your application has to make a choice between these two interpretations. This is a fundamental choice that MUST be made. Trying to pretend that your application doesn't care is like trying to say that Code Page 437 is good enough for all your work, and you can safely assume that one byte is one character is one byte. No. ChrisA [1] Leap seconds aren't significant, as people are often several minutes early or late, so UTC/UT1/GMT/TIA are all effectively equivalent. Precisely my point. For me hours are not significant, days are. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] Issues not responded to.
There are over 400 issues on the bug tracker that have not had a response to the initial message, roughly half of these within the last eight months alone. Is there a (relatively) simple way that we can share these out between us to sort those that are likely to need dealing with in the medium to longer term, from the simple short term ones, e.g very easy typo fixes? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] What happens of the Python 3.4 branch?
On 14/09/2015 10:49, Larry Hastings wrote: On 09/14/2015 09:29 AM, Victor Stinner wrote: Python 3.5.0 was released. What happens to the 3.4 branch in Mercurial? Does it still accept bugfixes, or is it only for security fixes now? Nothing has been announced or decided. As release manager I suppose I get some say. Here, I'll propose something: Python 3.4.4 rc1 should be released on Sunday October 4th. Python 3.4.4 final should be released on Sunday October 13th. After the tag of 3.4.4, Python 3.4 should enter security-fixes-only mode, and any future releases (3.4.5+) will be source code only. How's that? //arry/ Sorry but Sunday October 13th doesn't suit me, how about Sunday October 11th or Sunday October 18th? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] My collection of Python 3.5.0 regressions
On 18/09/2015 16:27, R. David Murray wrote: Once Steve comes back from vacation he's going to have a lot of Windows install issues to look at. IMO, we should resolve those, and then issue 3.5.1. It's really too bad more people didn't test the installation with the release candidates, and I'm very glad that those people who did so did soI know there were a significant number of issues with the new Windows installer infrastructure that were caught and fixed before final. I agree very strongly with your point here. Raising umpteen issues over installation failures when a full release comes out strikes me as below the belt when there have been multiple previous releases without a squeak. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] My collection of Python 3.5.0 regressions
On 19/09/2015 06:38, Stephen J. Turnbull wrote: Mark Lawrence writes: > I agree very strongly with your point here. Raising umpteen issues > over installation failures when a full release comes out strikes me > as below the belt when there have been multiple previous releases > without a squeak. Raising issues is always useful and appropriate. It's up to Larry Hastings to decide whether he personally needs to do more work. My point is that issues were raised after the full release was made, but no attempt was made to test for these problems in any of the previous releases, whether alpha, beta or release candidate. There was advance warning here http://stevedower.id.au/blog/the-python-3-5-installer/, which was flagged up here http://www.gossamer-threads.com/lists/python/dev/1175080. Larry doesn't need to do anything that I'm aware of, except perhaps be guided by our windows gurus. I suspect he probably will, though. I knew these changes were risky on the lead time given, even though I don't do Windows, and I'm not a core Python developer. I would hope that Steve Dower and Larry were at least as well aware of what they were getting into, and there are a lot of Windows users we *want* to support well. (*Not* "have to", and YMMV. But the Python developer community clearly has a working consensus on supporting Windows well.) I'm certain that Steve was well aware of what he was getting into, Larry, at least with respect to Windows, I'm not so sure about. Not that it really matters to me. All I know is that the build procedures have been made easier on Windows, thanks mostly to Steve and Zach Ware in recent years, building on work done by Tim Golden, Martin v. Löwis and Mark Hammond amongst others. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] VS 2010 compiler
On 29/09/2015 00:52, Nathaniel Smith wrote: On Mon, Sep 28, 2015 at 2:55 PM, Paul Moore wrote: On 28 September 2015 at 22:18, Nathaniel Smith wrote: On Sep 28, 2015 1:39 PM, "Paul Moore" wrote: On 28 September 2015 at 21:18, MRAB wrote: Same here. I compile the regex module for Python 2.5-2.7 and 3.1-3.5, both 32-bit and 64-bit, using MinGW-w64, and I haven't had a problem yet that wasn't due to a bug in the source code. Interesting. With Python 3.5, what CRT does the module use? With Python 3.4 and earlier, distutils arranged for mingw builds to link to the CRT that matched the CPython build, This doesn't sound right to me. Maybe if you're talking about the original mingw, but that's been abandoned upstream for years. Nowadays everyone uses the mingw-w64 fork, for both 32 and 64 bits. And in mingw-w64, the only way to select a non-default CRT is to hack up the toolchain's source tree and cross your fingers. It's definitely not a supported configuration upstream. (Source: we've been talking to mingw-w64 upstream and MS about how to potentially make building free software less painful on Windows.) Interesting, it's been a long time since I've done work on the mingw support, so I hadn't realised this had happened. I guess that means that nowadays all mingw-compiled extensions link to msvcrt (I assume that's still the CRT that mingw-w64 uses by default)? Right, linking to msvcrt.dll is the only standard/supported configuration for upstream mingw-w64. but I don't think that happened for 3.5 (because mingw doesn't support ucrt yet). So you'd have a CRT that doesn't match the core. Obviously this isn't causing you issues, but I'm not sure if it could (CRT problems seem to be mostly about "might cause issues" type problems...) CRT issues are indeed tricky, because they only bite in certain circumstances -- so long as you never pass a FILE* or a fileno across the dll boundary, or call malloc in one module and free in the other, or ... then it works fine. Except when it doesn't :-). Example of a subtle issue: msvc and mingw-w64 disagree about whether the x87 fpu should be configured in extended precision mode or not. So simply loading a mingw-w64-compiled dll can potentially cause math functions in other dlls to start returning incorrect results. Or maybe not -- it depends on the details of how MS implemented things, and we can't exactly check. Or whether you get correct math result in mingw-w64 compiled code can depend on which runtime was used to spawn the thread that's running the code (!!). And even if things work today, it could change without warning in any update, because no one is testing this configuration upstream. It's totally plausible that the regex module happens to avoid all these issues. But you can't assume that it's a general solution. Agreed. That was essentially what I was asking - has someone found a solution to the issue of avoiding mixed CRTs when using mingw as a compiler (or at least, found a better solution than using the original mingw -lmsvcr100 approach combined with the distutils code that supports this). Looks like the answer is that nobody has. But it's certainly (still) true that for straightforward cases things seem pretty much OK, especially if you avoid the "obvious" issues. (The non-obvious ones sound terrifying, and I'm glad I don't have to write code that encounters those!!!) It's not *quite* "nobody has". Carl Kleffner has been doing a lot of work on trying to set up Python-compatible gcc-based toolchains for Windows. (This is still pretty much the only hope for getting a usable free fortran compiler on Windows, and there's still lots of fortran down at the bottom of the scientific/numerical stack). It's still rather beta and the approach probably isn't sustainable without more funding, but right now it's probably the closest thing you can get to what you're asking about. I believe these are the latest builds: https://binstar.org/carlkl/mingwpy/files (Yes, those are .whl files that contain compiler toolchains.) (Also, if making this *actually* work reliably would make a difference to anyone, then feel free to send me heartfelt testimonials and I'll forward them on to MS. Or I guess you could just send them to Steve Dower directly ;-).) -n For anyone interested although this http://bugs.python.org/issue3871 mingw issue is closed, it points to four other issues. In total there are around 25 mingw issues open. Maybe some of the work done on them can be tied up with the work that Carl Kleffner has done? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] Should PEP 498 specify if rf'...' is valid?
On 27/10/2015 18:39, Sven R. Kunze wrote: On 26.10.2015 20:54, Ethan Furman wrote: You misunderstand -- the order of string prefixes does *not* matter, so forcing us to use one is silly. I don't think so. It's better to have less possibilities in the beginning. So later on, we can easily relax the restrictions without breaking compatibility. Best, Sven Please no. Having a memory much like a bottomless sieve I have no intention of reading the manual every time I need to use string prefixes. Would the table listing "string prefix precedence" in The Fine Docs™ be unique in the programming world? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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.exe is not a valid Win32 app"
On 01/12/2015 14:30, Alexei Belenki via Python-Dev wrote: Installed python 3.5 (from https://www.python.org/downloads/) on Windows XPsp3/32 On starting >>python.exe got the text above in the Windows message box. Any suggestions? Thanks. AB This isn't really the place to ask questions such as this. However Python 3.5 is *NOT* supported on XP. Work has been done for 3.5.1 to improve the user experience in this scenario. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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 4 musings (was Re: Deleting with setting C API functions)
On 02/12/2015 23:36, Barry Warsaw wrote: On Dec 02, 2015, at 11:26 PM, Gregory P. Smith wrote: Except that we should skip version 4 and go directly to 5 in homage to http://www.montypython.net/scripts/HG-handgrenade.php. Five is right out. https://youtu.be/QM9Bynjh2Lk?t=3m35s -Barry Can we have a PEP on this please, otherwise there's likely to be a great deal of confusion between hand grenade style counting, and the faculty rules at the University of Walamaloo. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] New poll about a macro for safe reference replacing
On 21/12/2015 21:57, Steve Dower wrote: Was Py_MOVEREF (or MOVE_REF) ever suggested? Those are valid objections, and now they're raised I remember them from last time. But I don't think they're a huge concern - setting a ref count directly doesn't seem useful anyway, and the compiler/IDE will let you know pretty quick if you put an integer vs a PyObject* there. Cheers, Steve Or Py_SAFEREF or SAFE_REF? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] Speeding up CPython 5-10%
On 01/02/2016 16:54, Yury Selivanov wrote: On 2016-01-29 11:28 PM, Steven D'Aprano wrote: On Wed, Jan 27, 2016 at 01:25:27PM -0500, Yury Selivanov wrote: Hi, tl;dr The summary is that I have a patch that improves CPython performance up to 5-10% on macro benchmarks. Benchmarks results on Macbook Pro/Mac OS X, desktop CPU/Linux, server CPU/Linux are available at [1]. There are no slowdowns that I could reproduce consistently. Have you looked at Cesare Di Mauro's wpython? As far as I know, it's now unmaintained, and the project repo on Google Code appears to be dead (I get a 404), but I understand that it was significantly faster than CPython back in the 2.6 days. https://wpython.googlecode.com/files/Beyond%20Bytecode%20-%20A%20Wordcode-based%20Python.pdf Thanks for bringing this up! IIRC wpython was about using "fat" bytecodes, i.e. using 64bits per bytecode instead of 8. That allows to minimize the number of bytecodes, thus having some performance increase. TBH, I don't think it was "significantly faster". From https://code.google.com/archive/p/wpython/ WPython is a re-implementation of (some parts of) Python, which drops support for bytecode in favour of a wordcode-based model (where a is word is 16 bits wide). It also implements an hybrid stack-register virtual machine, and adds a lot of other optimizations. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] The pysandbox project is broken
On 13/11/2013 09:33, Simon Cross wrote: Thanks for writing this email. It's well written and it takes a lot of character to stand up and say you went down the wrong road. While I'm here - thanks also for all your work on core Python. As a Python user I really appreciate it. Schiavo Simon Big +1s from me to Victor Stinner for his original email and to Simon Cross for this response. -- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer Mark Lawrence ___ 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 428 - pathlib - ready for approval
On 20/11/2013 22:01, Antoine Pitrou wrote: pathlib imports many modules at startup, so for scripts for which startup time is critical using os.path may still be the best option. Will there be or is there a note to this effect in the docs? -- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer Mark Lawrence ___ 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 process entry point and ill fated initiatives
On 29/11/2013 15:25, Kristján Valur Jónsson wrote: I know that Anatoly himself is a subject of long history here, but I myself have felt lessening affinity to the dev community in recent years. It feels like it is increasingly shutting itself in. I entirely agree, the development community is getting to the stage where it stinks. Consider Issue 19755. It was a low priority admittedly, but it took them 17 minutes and 47 seconds to action it, what is the world coming to? :) -- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer Mark Lawrence ___ 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 process entry point and ill fated initiatives
7;re actually trying to get stuff done. Regards, Nick. FWIW I agree entirely with your sentiments. Several times recently I've seen him in action on the bug tracker. I've been sorely tempted to wear my XXXL size Asperger hat and state what I really think of his behaviour, but somehow managed to control myself and say nothing. Thankfully with your words above this seems to have paid off as nobody has been sidetracked any further. And yes I'm aware that at times I'm no angel, although I believe I can at least offer mitigating circumstances. -- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer Mark Lawrence ___ 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] General Q&A regarding Python 3, adoption etc.
On 06/01/2014 23:16, Nick Coghlan wrote: For anyone that isn't already aware, I wrote a Q & A about Python 3 last year (in response to an article about how we should have fixed the GIL instead of Unicode), and I've updated it extensively over the past several days due to Alex's misunderstanding of the objectives for Python 3.4 as well as Armin's latest piece on the increased difficulties in writing wire protocol handling code. The two main additions I currently have planned are a question specifically about the state of the WSGI protocol (it works, but it an error prone way), as well as one on what I'd like to see as the next steps in encouraging Python 3 adoption now that we're within 18 months of the planned date for 2.7 to enter security fix only mode (which involve encouraging community workshops to switch to teaching Python 3.4 initially, with Python 2.7 as an optional follow up, helping Ubuntu & Fedora with their transitions to Py3 by default, bringing 3.5 closer to parity with Python 2 for wire protocol development, and, on the Red Hat/Fedora side, helping to encourage the adoption of software collections as a mechanism for decoupling the runtime for Python applications from the system Python on RHEL 6 and its derivatives. I thought I mentioned it on this list last year when I first wrote it, but some messages I've seen recently suggest many folks haven't seen it before. Cheers, Nick. Is it on the back of a fag packet or is there a link somewhere? :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] Changing Clinic's output
On 07/01/2014 19:53, Antoine Pitrou wrote: Hello, Several core developers a bit unhappy with the way Argument Clinic currently scatters generated code into hand-written C modules. The opinion is that it makes C files more confusing and annoying to navigate through. Several solutions have been proposed: - move all generated code to separate C files, which would then be #included'd into the main module file - gather all generated code to a single place in the C module file, for example near the end (Larry's "accumulator" idea) - prefix all Clinic-generated lines with a recognizable marker, e.g. "/* AC */" What do you think? Regards Antoine. Maybe overkill but why not follow 3 with 2 at the end of the file, the marker to be a very clear /* Generated by Argument Clinic - DO NOT EDIT BELOW THIS LINE */ or whatever wording is appropriate in this case. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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
On 07/01/2014 22:11, Skip Montanaro wrote: On Tue, Jan 7, 2014 at 2:46 PM, Barry Warsaw wrote: I think we should be willing to entertain breaking feature freeze for getting this in Python 3.4. Maybe you could revert 3.4 to alpha status and give it a cycle or two there to get this done before returning to beta status. Skip When I first saw the suggestion from Georg I had visions of men in white coats gragging him off :) Having giving the idea more thought I think there's any opportunity here and now to make a very profound long term impact for Python 3. Skip's idea seems to me a clean way to do this. Short term pain, long term gain? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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"
On 09/01/2014 00:21, MRAB wrote: "I need a new battery." "What kind of battery?" "I don't care!" A neat summary of the draft requirements specification for Python 2.8. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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" (was RFC: PEP 460: Add bytes...)
On 09/01/2014 00:12, Kristján Valur Jónsson wrote: Just to avoid confusion, let me state up front that I am very well aware of encodings and all that, having internationalized one largish app in python 2.x. I know the problems that 2.x had with tracking down the source of errors and understand the beautiful concept of encodings on the boundary. However: For a lot of data processing and tools, encoding isn't an issue. Either you assume ascii, or you're working with something like latin1. A single byte encoding. This is because you're working with a text file that _you_ wrote. And you're not assigning any semantics to the characters. If there is actual "text" in there it is just english, not Norwegian or Turkish. A byte read at code 0xfa doesn't mean anything special. It's just that, a byte with that value. The file system doesn't have any default encoding. A file on disk is just a file on disk consisting of bytes. There can never be any wrong encoding, no mojibake. With python 2, you can read that file into a string object. You can scan for your field delimiter, e.g. a comma, split up your string, interpolate some binary data, spit it out again. All without ever thinking about encodings. Even though the file is conceptually encoded in something, if you insist on attaching a particular semantic meaning to every ordinal value, whatever that meaning is is in many cases irrelevant to the program. I understand that surrogateescape allows you to do this. But it is an awkward extra step and forces an extra layer of needles semantics on to that guy that just wants to read a file. Sure, vegetarians and alergics like to read the list of ingredients on everything that they eat. But others are just omnivores and want to be able to eat whatever is on the table, and not worry about what it is made of. And yes, you can read the file in binary mode but then you end up with those bytes objects that we have just found that are tedious to work with. All I can say is that I've been using python 3 for years and wouldn't know what a surrogateescape was if you were to hit me around the head with it. I open my files, I process them, and Python kindly closes them for me via a context manager. So if you're not bothered about encoding, where has the "awkward extra step and forces an extra layer of needles semantics" bit come from? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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"
On 09/01/2014 06:50, Lennart Regebro wrote: On Thu, Jan 9, 2014 at 1:07 AM, Ben Finney wrote: Kristján Valur Jónsson writes: Believe it or not, sometimes you really don't care about encodings. Sometimes you just want to parse text files. Files don't contain text, they contain bytes. Bytes only become text when filtered through the correct encoding. To be honest, you can define text as "A stream of bytes that are split up in lines separated by a linefeed", and do some basic text processing like that. Just very *basic*, but still. Replacing characters. Extracting certain lines etc. This is harder in Python 3, as bytes does not have all the functionality strings has, like formatting. This can probably be fixed in Python 3.5, if the relevant PEP gets finished. For the battery analogy, that's like saying: "I want a battery." "What kind?" "It doesn't matter, as long as it's over 5V." //Lennart "That Python 3 battery you sold me blew up when I tried using it". "We've been telling you for years that could happen". "I didn't think you actually meant it". -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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
On 06/01/2014 13:24, Victor Stinner wrote: Hi, bytes % args and bytes.format(args) are requested by Mercurial and Twisted projects. The issue #3982 was stuck because nobody proposed a complete definition of the "new" features. Here is a try as a PEP. Apologies if this has already been said, but Terry Reedy attached a proof of concept to issue 3982 which might be worth taking a look at if you haven't yet done so. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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"
On 10/01/2014 22:06, Chris Barker wrote: On Fri, Jan 10, 2014 at 6:05 AM, Paul Moore mailto:p.f.mo...@gmail.com>> 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. Agreed. The latin-1 suggestion is purely for people who object to learning how to handle the encodings in their data more accurately. I'm not so sure -- it could be used (abused?) for that, but I'm suggesting it be used for mixed ascii-binary data. I don't know that there IS a "right" way to do that -- at least not an efficient or easy to read and write one. -Chris The correct way is to read the interface specification which tells you what should be in the data. Or do people not use interface specifications these days, preferring to guess what they've got instead? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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 460: allowing %d and %f and mojibake
On 12/01/2014 17:06, Mark Shannon wrote: On 12/01/14 16:52, Kristján Valur Jónsson wrote: Now you're just splitting hairs, Nick. An explicit operator, %s, _defined_ to be "encode a string object using strict ascii", I don't like this because '%s' reads to me as "insert *string* here". I think '%a' which reads as "encode as ASCII and insert here" would be better. I entirely agree. This would also parallel the conversion flags given here http://docs.python.org/3/library/string.html#format-string-syntax, I quote "Three conversion flags are currently supported: '!s' which calls str() on the value, '!r' which calls repr() and '!a' which calls ascii()". -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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 460: allowing %d and %f and mojibake
On 12/01/2014 21:06, Greg Ewing wrote: Paul Moore wrote: I could easily argue at this point that this is the type of bug that having %-formatting operations on bytes would encourage - %s means "format a string" (from years of C and Python (text) experience) so I automatically supply a string argument when using %s in a bytes formatting context. So don't call it %s -- call it something else such as %b. Sorry but you can't use %b as that'll confuse people who're used to it meaning "Month as locale’s abbreviated name." :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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 460: allowing %d and %f and mojibake
On 12/01/2014 17:03, Ethan Furman wrote: On 01/12/2014 08:21 AM, Ethan Furman wrote: On 01/12/2014 08:09 AM, Nick Coghlan wrote: On 13 Jan 2014 01:22, "Kristján Valur Jónsson" wrote: Imho, this is not equivalent to re-introducing automatic type conversion between binary/unicode, it is adding a specific convenience function for explicitly asking for ASCII encoding. It is not explicit, it is implicit - whether or not the resulting string assumes ASCII compatibility or not depends on whether you pass a binary value (no assumption) or a string value (assumes ASCII compatibility). Nick, I don't understand what you are saying here. Are you saying that the result of b'%s' % var may be either a bytes object or a str object? Because that would be wrong -- it would always be a bytes object. Okay, I just went and took a closer look at the asciistr type [1]. For what it's worth I don't think this is Antoine's understanding of what we [2] are asking for, nor is it what we are asking for (I'm sure Antoine will correct me if I'm wrong. ;) We know full well the difference between unicode and bytes, and we know full well that numbers and much of the text we need has an ASCII (bytes!) representation. When we do a b'Content Length: %d' % len(binary_data) we are expecting to get back a bytes object, /not/ a unicode object. Your asciistr, which sometimes returns bytes and sometimes returns text, is absolutely *not* what we want. I've just tried asciistr using your test code (having corrected the typo, it's assertIsInstance, not assertIsinstance :) and it looks like a very good starting point. Have you, or anyone else for that matter, actually tried asciistr out? -- ~Ethan~ [1] https://github.com/jeamland/asciicompat [2] the dbf and pdf folks, at least -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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 460 reboot and a bitter fight
On 13/01/2014 07:59, Ethan Furman wrote: On 01/12/2014 11:15 PM, Guido van Rossum wrote: The proponents (myself, you, Stufft, Eric Smith, et al*) are arguing that bytes already has an ASCII bias, already has ASCII string methods, that it isn't the same as the Py2 world because if you combine a bytes object with a str object outside of interpolation (such as b'hello' + 'world') it doesn't work, that only bytes would ever be returned, etc, etc. -- ~Ethan~ "ASCII bias" seems to me an understatement. From http://docs.python.org/3/library/stdtypes.html#bytes-and-bytearray-operations "Due to the common use of ASCII text as the basis for binary protocols, bytes and bytearray objects provide almost all methods found on text strings". Can you get any clearer than that, or have I been completely swamped by the massive tsunami that these PEP 460 threads are? Note that I'm *NOT* taking sides here, I'd just like to see a peaceful settlement without any bloodshed :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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 460 reboot
On 13/01/2014 21:01, Paul Moore wrote: I think this should be for 3.5, and should not involve an accelerated release of 3.5 - we should get it into the 3.5 code early and let people thrash out the details during the 3.5 release cycle. I disagree, it should be on pypi now so people can start trying it out, or as others have suggested incorporate it into the six module. Surely that'd make the job of getting it into 3.5 far easier? Paul. PS For all the heated arguments and occasional frayed tempers, this has been an impressively civil debate. I think that's one of the best things about python-dev, that discussions like these never degenerate into flamewars. Kudos to all concerned! +1 -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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 460 reboot
On 14/01/2014 20:54, Guido van Rossum wrote: On Tue, Jan 14, 2014 at 12:13 PM, Ethan Furman wrote: In Py2, because '%15s' can actually take 17 characters, I have to use '%15s' % data_value[:15] everywhere. Wow. I thought there would be some combination using %.15s but I can't get that to work. :-( I believe you wanted this. >>> a='01234567890123456' >>> len(a) 17 >>> b = '%15.15s' % a >>> b;len(b) '012345678901234' 15 -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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 461 - Adding % and {} formatting to bytes
On 14/01/2014 19:55, Ethan Furman wrote: This PEP goes a but further than PEP 460 does, and hopefully spells things out in enough detail so there is no confusion as to what is meant. -- ~Ethan~ Out of plain old curiosity do we have to consider PEP 292 string templates in any way, shape or form, or regarding this debate have they been safely booted into touch? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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 461 - Adding % and {} formatting to bytes
On 14/01/2014 19:56, Ethan Furman wrote: Duh. Here's the text, as well. ;) %s, because it is the most general, has the most convoluted resolution: - input type is bytes? pass it straight through - input type is numeric? use its __xxx__ [1] [2] method and ascii-encode it (strictly) - input type is something else? use its __bytes__ method; if there isn't one, raise an exception [3] Examples: >>> b'%s' % b'abc' b'abc' >>> b'%s' % 3.14 b'3.14' >>> b'%s' % 'hello world!' Traceback (most recent call last): ... TypeError: 'hello world' has no __bytes__ method, perhaps you need to encode it? For completeness I believe %r and %a should be included here as well. FTR %a appears to have been introduced in 3.2, but I couldn't find anything in the What's New and there's no note in the docs http://docs.python.org/3/library/stdtypes.html#printf-style-string-formatting to indicate when it first came into play. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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 461 - Adding % and {} formatting to bytes
On 15/01/2014 22:22, Brett Cannon wrote: On Wed, Jan 15, 2014 at 5:00 PM, Steven D'Aprano mailto:st...@pearwood.info>> wrote: On Thu, Jan 16, 2014 at 10:55:31AM +1300, Greg Ewing wrote: > Neil Schemenauer wrote: > >Objects that implement __str__ can also implement __bytes__ if they > >can guarantee that ASCII characters are always returned, > > I think __ascii_ would be a better name. I'd expect > a method called __bytes__ on an int to return some > version of its binary value. +1 If we are going the route of a new magic method then __ascii__ or __bytes_format__ get my vote as long as they only return bytes (I see no need to abbreviate to __bformat__ or __formatb__ when we have method names as long as __text_signature__ now). __bytes_format__ gets my vote as it's blatantly obvious what it does. I'm against __ascii__ as I'd automatically associate that with ascii in the same way that I associate str with __str__ and repr with __repr__. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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 461 - Adding % and {} formatting to bytes
On 17/01/2014 14:50, Eric V. Smith wrote: On 01/17/2014 07:34 AM, Eric V. Smith wrote: On 1/17/2014 6:42 AM, Nick Coghlan wrote: On 17 Jan 2014 18:03, "Eric Snow" mailto:ericsnowcurren...@gmail.com>> wrote: On Thu, Jan 16, 2014 at 11:30 AM, Eric V. Smith <mailto:e...@trueblade.com>> wrote: For the first iteration of bytes.format(), I think we should just support the exact types of int, float, and bytes. It will call the type's__format__ (with the object as "self") and encode the result to ASCII. For the stated use case of 2.x compatibility, I suspect this will cover > 90% of the uses in real code. If we find there are cases where real code needs additional types supported, we can consider adding __format_ascii__ (or whatever name we cook up). +1 Please don't make me learn the limitations of a new mini language without a really good reason. For the sake of argument, assume we have a Python 3.5 with bytes.__mod__ restored roughly as described in PEP 461. *Given* that feature set, what is the rationale for *adding* bytes.format? What new capabilities will it provide that aren't already covered by printf-style interpolation directly to bytes or text formatting followed by encoding the result? The only reason to add any of this, in my mind, is to ease porting of 2.x code. If my proposal covers most of the cases of b''.format() that exist in 2.x code that wants to move to 3.5, then I think it's worth doing. Is there any such code that's blocked from porting by the lack of b''.format() that supports bytes, int, and float? I don't know. I concede that it's unlikely. IF this were a feature that we were going to add to 3.5 on its own merits, I think we add __format_ascii__ and make the whole thing extensible. Is there any new code that's blocked from being written by missing b"".format()? I don't know that, either. Following up, I think this leaves us with 3 choices: 1. Do not implement bytes.format(). We tell any 2.x code that's written to use str.format() to switch to %-formatting for their common code base. 2. Add the simplistic version of bytes.format() that I describe above, restricted to accepting bytes, int, and float (and no subclasses). Some 2.x code will work, some will need to change to %-formatting. 3. Add bytes.format() and the __format_ascii__ protocol. We might want to also add a format_ascii() builtin, to match __format__ and format(). This would require the least change to 2.x code that uses str.format() and wants to move to bytes.format(), but would require some work on the 3.x side. I'd advocate 1 or 2. Eric. For both options 1 and 2 surely you cannot be suggesting that after people have written 2.x code to use format() as %f formatting is to be deprecated, they now have to change the code back to the way they may well have written it in the first place? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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 461 - Adding % and {} formatting to bytes
On 17/01/2014 15:41, Ethan Furman wrote: On 01/17/2014 07:15 AM, Mark Lawrence wrote: For both options 1 and 2 surely you cannot be suggesting that after people have written 2.x code to use format() as %f formatting is to be deprecated %f formatting is not deprecated, and will not be in 3.x's lifetime. -- ~Ethan~ I'm sorry, I got the above wrong, I should have said "was to be deprecated" :( -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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 461 Final?
On 17/01/2014 17:46, Neil Schemenauer wrote: I think we should use %b instead of %s. In that case, I'm fine with %b not accepting numbers. Using %b clearly indicates we are inserting arbitrary bytes. It also proves a useful code review step when translating from Python 2.x. Using %b could cause problems in the future as b is used in new style formatting to mean output numbers in binary, so %B seems to me the obvious choice as it's also unused. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] str.rreplace
On 24/01/2014 16:32, Ram Rachum wrote: Question: Why is there no str.rreplace in Python? It's not needed. Is this *REALLY* relevant to this list? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] str.rreplace
On 24/01/2014 17:19, Ram Rachum wrote: Hmm, on one hand I understand the need for the separation between python-dev and python-list, but on the other hand I don't think python-list is a good place to discuss Python, the language. I now looked at the 17 most recent python-list threads. Out of them: - 58% are about third-party packages. - 17% are off-topic (not even programming related) - 11% are 2-vs-3 discussions - 5% are job offers. - 5% (which is just one thread out of 17) is about Python the language. I'm extremely impressed by your knowledge of statistics, it must have taken you many man years of effort to analyse all 17 threads in such detail. So can you understand why someone would be reluctant to start a discussion in python-list about Python the language there? Especially if this is the same place where beginners might ask newbies questions about Python? (So not only are actual Python questions just 5% of the content, non-newbie questions are just a subset of that 5%.) it's full of people asking about third-party Python packages, or asking newbie questions. How terrible, fancy having the audacity to ask about third party packages or newbie questions on the *MAIN* Python mailing list. There's yet another reason to bring back the death penalty in the UK. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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 3 marketing document?
On 24/01/2014 16:37, Jesse Noller wrote: fwiw, I'm offering the keys/account/etc for getpython3.com to whomever has the time to keep it fresh and up to date. If I've ever heard of this I've forgotten about it. How do we make it more prominent? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] str.rreplace
On 24/01/2014 22:44, Brian Curtin wrote: On Fri, Jan 24, 2014 at 11:40 AM, Mark Lawrence wrote: On 24/01/2014 17:19, Ram Rachum wrote: Hmm, on one hand I understand the need for the separation between python-dev and python-list, but on the other hand I don't think python-list is a good place to discuss Python, the language. I now looked at the 17 most recent python-list threads. Out of them: - 58% are about third-party packages. - 17% are off-topic (not even programming related) - 11% are 2-vs-3 discussions - 5% are job offers. - 5% (which is just one thread out of 17) is about Python the language. I'm extremely impressed by your knowledge of statistics, it must have taken you many man years of effort to analyse all 17 threads in such detail. So can you understand why someone would be reluctant to start a discussion in python-list about Python the language there? Especially if this is the same place where beginners might ask newbies questions about Python? (So not only are actual Python questions just 5% of the content, non-newbie questions are just a subset of that 5%.) it's full of people asking about third-party Python packages, or asking newbie questions. How terrible, fancy having the audacity to ask about third party packages or newbie questions on the *MAIN* Python mailing list. There's yet another reason to bring back the death penalty in the UK. Please adjust the tone of your messages if you are going to use this mailing list. I'm sorry but I do not understand, please explain what is wrong with an extremely heavy dose of sarcasm. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] str.rreplace
On 24/01/2014 22:56, Brian Curtin wrote: On Fri, Jan 24, 2014 at 4:50 PM, Mark Lawrence wrote: On 24/01/2014 22:44, Brian Curtin wrote: On Fri, Jan 24, 2014 at 11:40 AM, Mark Lawrence wrote: On 24/01/2014 17:19, Ram Rachum wrote: Hmm, on one hand I understand the need for the separation between python-dev and python-list, but on the other hand I don't think python-list is a good place to discuss Python, the language. I now looked at the 17 most recent python-list threads. Out of them: - 58% are about third-party packages. - 17% are off-topic (not even programming related) - 11% are 2-vs-3 discussions - 5% are job offers. - 5% (which is just one thread out of 17) is about Python the language. I'm extremely impressed by your knowledge of statistics, it must have taken you many man years of effort to analyse all 17 threads in such detail. So can you understand why someone would be reluctant to start a discussion in python-list about Python the language there? Especially if this is the same place where beginners might ask newbies questions about Python? (So not only are actual Python questions just 5% of the content, non-newbie questions are just a subset of that 5%.) it's full of people asking about third-party Python packages, or asking newbie questions. How terrible, fancy having the audacity to ask about third party packages or newbie questions on the *MAIN* Python mailing list. There's yet another reason to bring back the death penalty in the UK. Please adjust the tone of your messages if you are going to use this mailing list. I'm sorry but I do not understand, please explain what is wrong with an extremely heavy dose of sarcasm. There's a real discussion going on and you're just responding to throw around sarcasm. People aren't going to come to this list if you're just going to give them snarky replies. It's not helping. Okay, I'll leave the snarky comments to the people who are authorised to be snarky. How do you get on this list? Is it any core dev, or are there more severe restrictions than that, for example do you have to be a member of the PSF, in which case I'd guess you can be very snarky without having a word said against you? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)
On 27/01/2014 01:52, Nick Coghlan wrote: In 3.5, that will be passing None, rather than -1. For those proposing to change the maintenance releases, how should a user relying on this misbehaviour update their code to handle it? I'm -1 on using None. The code currently rejects anything except an int. The docs don't say anything about using None, except in the "equivalent to" section, which is also the only place where it looks as if times can be a keyword argument. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)
On 27/01/2014 12:56, Steven D'Aprano wrote: As it stands now, the documentation is internally contradictory. In one part of the documentation, it gives a clear indication that "times is None" should select the repeat forever behaviour. In another part of the documentation, it fails to mention that None is an acceptable value to select the repeat forever behaviour. None is not currently an acceptable value, ValueError is raised if you provide anything other than an int in both Python 2.7 and 3.3. That's why I'm against using it to say "run forever" in Python 3.5. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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 3 niggle: None < 1 raises TypeError
On 18/02/2014 15:45, Terry Reedy wrote: On 2/18/2014 12:11 AM, Greg Ewing wrote: Nobody is asking for a return to the arbitrary-but- [in]consistent mess of Python 2, only to bring back *one* special case, i.e. None comparing less than everything else. For a < None, that is only the fallback rule if a does not handle the comparison. The result is a mess, including a possible inconsistency between direct comparison and cmp. See my previous posts. 'Bringing back' what was or an improved version would be a semantic change that could break code and would require a two-version deprecation period. Sorry if this has already been suggested, but why not introduce a new singleton to make the database people happier if not happy? To avoid confusion call it dbnull? A reasonable compromise or complete cobblers? :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ 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 461: Adding % formatting to bytes and bytearray -- Final, Take 2
On 23/02/2014 02:30, Ethan Furman wrote: +be any more of a nuisance than the already existing methdods. Typo "methdods". -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ 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 461: Adding % formatting to bytes and bytearray -- Final, Take 2
On 24/02/2014 18:40, Ethan Furman wrote: Okay, types corrected, most comments taken into account. %b is right out, %a is still suffering scrutiny. The arguments seem to boil down to: We don't need it. vs Somebody might, and it's better than having them inappropriately add a __bytes__ method if we don't have it. "We don't need it" doesn't really need any further explanation. Does anybody have any examples where %a could be useful? Considering the work-arounds are either wrong or painful, it wouldn't take much to sway me towards keeping it, but at the moment it seems to be a YAGNI, plus we could always add it later if it turns out to be useful. (For that matter, we could implement the main portion of the PEP now, and maybe a %a use-case will show up before 3.5 is released and we could add it then.) So, any last thoughts about %a? I placed it under your nose https://mail.python.org/pipermail/python-dev/2014-January/131636.html but personally I wouldn't lose any sleep whether it stays or goes. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ 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] Cherry-pick between Python 3.4 RC2 and final?
On 03/03/2014 21:38, Nick Coghlan wrote: On 4 Mar 2014 07:32, "Larry Hastings" mailto:la...@hastings.org>> wrote: > > On 03/03/2014 05:05 AM, Victor Stinner wrote: >> >> 2014-03-03 13:13 GMT+01:00 Larry Hastings mailto:la...@hastings.org>>: >>> >>> I would like to know if the cherry-picking rule still applies for >>> Python 3.4 final? Can I open an issue if I want to see a changeset in >>> the final version? >>> >>> Sadly, yes. >> >> Ok, I created: >> http://bugs.python.org/issue20843 >> >> Why do you say "sadly"? It's up to you to decide if a change can wait >> Python 3.4.1 or not. Feel free to close my cherry-pick issue as >> wontfix. > > > It was intended as gentle comedy. Related question - have you decided yet whether or not to do an rc3? I ask, as I believe it would be good to give the folks like Mike Bayer and Armin Ronacher (who picked up test coverage gaps in rc2 via the Alembic and Flask test suites respectively) a chance to rerun their tests before we declare 3.4 final. Cheers, Nick. Will this impact on the decision http://bugs.python.org/issue20846 ? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ 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 4: don't remove anything, don't break backward compatibility
On 10/03/2014 13:55, Victor Stinner wrote: So can we please try to stop scheduling another major Python version breaking almost all modules and all applications just to be pendantic? I've missed the announcement about this, can we have a link please? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ 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 4: don't remove anything, don't break backward compatibility
On 10/03/2014 19:28, Ethan Furman wrote: On 03/10/2014 11:21 AM, MRAB wrote: What does "irregardless" mean? The same thing as "regardless", with an extra syllable just for fun. -- ~Ethan~ Is this the UK, US, Australian or some other "regardless"? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ 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 4: don't remove anything, don't break backward compatibility
On 10/03/2014 22:28, Greg Ewing wrote: Chris Angelico wrote: Terrible idea. Would wreak havoc with comparisons. No. Python 3 is all about Unicode, so the right way to proceed is 3.8, 3.9, 3.:, 3.;, 3.<, 3.=, 3.>, 3.?, 3.@, 3.A. And we have all of UCS-4 to play with, so for all practical purposes the 3.x line can live forever! The downside is that we'll get endless complaints from jmfauth about the Flexible Version Number Representation. :-( Drat, drat and double drat, you beat me to it :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ 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] OP_NO_COMPRESSION
On 23/03/2014 15:46, Antoine Pitrou wrote: On Sun, 23 Mar 2014 11:37:25 -0400 Donald Stufft wrote: I already did open an issue and write a patch :) There’s someone on that issue saying that flipping that without a way to flip it back would break their application. You're right, I had forgotten about that :-) I'd be surprised if disabling compression could altogether break an application. It may make it less efficient, though, if it relied on TLS to compress data for it (which doesn't sound like a good thing to rely on, anyway). Regards Antoine. I've looked at the issue and can't find any such comment. The closest is from http://bugs.python.org/issue20994#msg214246 "Also some users will absolutely want to manually re-enable compression, please don't disable it entirely." Chinese whispers? :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ 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] issue with itertools leads the crash
On 08/04/2014 17:30, MRAB wrote: On 2014-04-08 16:31, Brett Cannon wrote: Something for Python 3.5, maybe? :-) It's not going to happen in Python 2.7; that's the end of the Python 2 series, and it's getting security fixes only. According to http://legacy.python.org/dev/peps/pep-0373/ the final release of 2.7 is scheduled to be 2.7.9 in May 2015. Did you mean to say that 2.7 isn't getting new features? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ 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 "2migr8"
On 14/04/2014 22:17, Chris Barker wrote: On Mon, Apr 14, 2014 at 1:26 PM, Guido van Rossum mailto:gu...@python.org>> wrote: >> - I'd prefer a name that plays on 2 and 3, not 2 and 8. :-) How about mirg2**3 (pronounced "migrate") ? ;-) -Chris I agree with the grate part. Failing that, how about a play on 2 + 8 = ache? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ 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] Mercurial sluggishness (was: this is what happens if you freeze all the modules required for startup)
On 15/04/2014 18:32, Daniel Holth wrote: On Tue, Apr 15, 2014 at 1:29 PM, Antoine Pitrou wrote: Le 15/04/2014 19:09, Daniel Holth a écrit : In case you were wondering, I'm using Ubuntu's "2.7.5+" and "3.3.2+". My feeling has long been that the speed of getting at the "--help" option or any initial user feedback from Mercurial or git is a big driver in perceived speed as opposed to how long the entire operation might take. But for me any initial speed improvements from git are fully offset by the feeling of irritation afterwards. /troll For me Python's startup time (warm) takes about 1/4 of the hg startup time in the worst case. I expect to both notice and appreciate any speedups and encourage all optimizers to optimize. Well, if we optimize 11% out of that 1/4, I don't expect you to notice the speedup at all ;-) Regards Antoine. No one expects the Spanish Inquisition. Except those who expect Python 2.8? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ 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 469: Restoring the iterkeys/values/items() methods
On 20/04/2014 06:31, Ethan Furman wrote: Thank you for taking the time to write this up, Nick. However, I am -1 on it. One of the allures of Python 3 is the increase in simplicity and elegance. Restoring cruft does not help with that. Python 2 idioms that get restored to Python 3 must have real value: unicode literals, wire-protocol interpolations -- I don't feel that this comes any where close to meeting that bar. -- ~Ethan~ +1 for this summary which echoes my sentiments entirely. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ 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] Language Summit Follow-Up
On 30/05/2014 18:40, Mark Roberts wrote: What I'd really like to see is a Python 2.8 that makes sufficient changes to Python 2 that writing libraries which cross the boundary between 2 and 3 is relatively easy instead of a painful nightmarish chore. Because when push comes to shove, Python 2 support is still infinitely more important than Python 3. -Mark What is the point of flogging a horse that's been dead for so long that it's already down to a skeleton? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ 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] Internal representation of strings and Micropython
On 04/06/2014 11:53, Paul Sokolovsky wrote: Hello, On Tue, 3 Jun 2014 22:23:07 -0700 Guido van Rossum wrote: [] Never mind disabling assertions -- even with enabled assertions you'd have to expect most Python programs to fail with non-ASCII input. Then again the UTF-8 option would be pretty devastating too for anything manipulating strings (especially since many Python APIs are defined using indexes, e.g. the re module). If the Unicode is slow (*), then obvious choice is not using Unicode when not needed. Too bad that's a bit hard in Python3, as it enforces Unicode everywhere, and dealing with efficient strings requires prefixing them with funny characters like "b", etc. * If Unicode if slow because it causes heap to bloat and go swap, the choice is still the same. Where is your evidence that (presumably) CPython unicode is slow? What is your response to this message http://bugs.python.org/issue16061#msg171413 from the bug tracker? Why not support variable-width strings like CPython 3.4? Because, like good deal of community, we hope that Python4 will get back to reality, and strings will be efficient (both for processing and storage) by default, and niche and marginal "Unicode string" type will be used explicitly (using funny prefixes, etc.), only when really needed. Where is your evidence that supports the above claim? Ah, all these not so funny geek jokes about internals of language implementation, hope they didn't make somebody's day dull! -- --Guido van Rossum (python.org/~guido) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ 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] Internal representation of strings and Micropython
On 04/06/2014 16:32, Steve Dower wrote:
If copying into a separate list is a problem (memory-wise), re.finditer('\\S+',
string) also provides the same behaviour and gives me the sliced string, so
there's no need to index for anything.
Out of idle curiosity is there anything that stops MicroPython, or any
other implementation for that matter, from providing views of a string
rather than copying every time? IIRC memoryviews in CPython rely on the
buffer protocol at the C API level, so since strings don't support this
protocol you can't take a memoryview of them. Could this actually be
implemented in the future, is the underlying C code just too
complicated, or what?
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
---
This email is free from viruses and malware because avast! Antivirus protection
is active.
http://www.avast.com
___
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] Internal representation of strings and Micropython
On 04/06/2014 16:52, Mark Lawrence wrote:
On 04/06/2014 16:32, Steve Dower wrote:
If copying into a separate list is a problem (memory-wise),
re.finditer('\\S+', string) also provides the same behaviour and gives
me the sliced string, so there's no need to index for anything.
Out of idle curiosity is there anything that stops MicroPython, or any
other implementation for that matter, from providing views of a string
rather than copying every time? IIRC memoryviews in CPython rely on the
buffer protocol at the C API level, so since strings don't support this
protocol you can't take a memoryview of them. Could this actually be
implemented in the future, is the underlying C code just too
complicated, or what?
Anybody?
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
---
This email is free from viruses and malware because avast! Antivirus protection
is active.
http://www.avast.com
___
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] Internal representation of strings and Micropython
On 06/06/2014 09:53, Hrvoje Niksic wrote:
On 06/04/2014 05:52 PM, Mark Lawrence wrote:
On 04/06/2014 16:32, Steve Dower wrote:
If copying into a separate list is a problem (memory-wise),
re.finditer('\\S+', string) also provides the same behaviour and
gives me the sliced string, so there's no need to index for anything.
Out of idle curiosity is there anything that stops MicroPython, or any
other implementation for that matter, from providing views of a string
rather than copying every time? IIRC memoryviews in CPython rely on the
buffer protocol at the C API level, so since strings don't support this
protocol you can't take a memoryview of them. Could this actually be
implemented in the future, is the underlying C code just too
complicated, or what?
Memory view of Unicode strings is controversial for two reasons:
1. It exposes the internal representation of the string. If memoryviews
of strings were supported in Python 3, PEP 393 would not have been
possible (without breaking that feature).
2. Even if it were OK to expose the internal representation, it might
not be what the users expect. For example, memoryview("Hrvoje") would
return a view of a 6-byte buffer, while memoryview("Nikšić") would
return a view of a 12-byte UCS-2 buffer. The user of a memory view might
expect to get UCS-2 (or UCS-4, or even UTF-8) in all cases.
An implementation that decided to export strings as memory views might
be forced to make a decision about internal representation of strings,
and then stick to it.
The byte objects don't have these issues, which is why in Python 2.7
memoryview("foo") works just fine, as does memoryview(b"foo") in Python 3.
Thanks for the explanation :)
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
---
This email is free from viruses and malware because avast! Antivirus protection
is active.
http://www.avast.com
___
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] Moving Python 3.5 on Windows to a new compiler
On 07/06/2014 02:13, Donald Stufft wrote: On Jun 6, 2014, at 9:05 PM, Terry Reedy wrote: On 6/6/2014 6:47 PM, Nathaniel Smith wrote: On Fri, Jun 6, 2014 at 11:43 PM, Sturla Molden wrote: Brett Cannon wrote: Nope. A new minor release of Python is a massive undertaking which is why we have saved ourselves the hassle of doing a Python 2.8 or not giving a clear signal as to when Python 2.x will end as a language. Why not just define Python 2.8 as Python 2.7 except with a newer compiler? I cannot see why that would be massive undertaking, if changing compiler for 2.7 is neccesary anyway. This would require recompiling all packages on OS X and Linux, even though nothing had changed. If you are suggesting that a Windows compiler change should be invisible to non-Windows users, I agree. Let us assume that /pcbuild remains for those who have vc2008 and that /pcbuild14 is added (and everything else remains as is). Then the only other thing that would change is the Windows installer released on Python.org. Call than 2.7.9W or whatever on the download site and interactive startup message to signal that something is different. -- Terry Jan Reedy ___ 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/donald%40stufft.io How are packaging tools supposed to cope with this? AFAIK there is nothing in most of them to deal with a X.Y.Z release suddenly dealing with a different compiler. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA Potentially completely stupid suggestion to get people thinking (or die laughing :) , but would it be possible to use hex digits, such that 2.7.A was the first release on Windows with the different compiler? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ 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] Windows XP, Python 3.5 and PEP 11
On 17/06/2014 08:03, Victor Stinner wrote: 2014-06-17 7:01 GMT+02:00 Tim Golden : On 17/06/2014 04:08, Zachary Ware wrote: This was recently discussed in the "Moving Python 3.5 on Windows to a new compiler" thread, where Martin declared XP support to be ended [1]. I believe Tim Golden is the only resident Windows dev from whom I haven't seen at least implicit agreement that XP doesn't need further support, so I'd say our support for XP is well and truly dead :) In any case, surely anyone stuck with XP can be happy with Python 3.4. I'm perfectly fine with 3.2 on Win2k! I think we're justified in dropping XP support, for all the reasons others have given. Would you be ok to make this official by adding Windows XP explicitly to the PEP 11? (I can do the change, I'm just asking for a confirmation.) From PEP 11 the entire "Microsoft Windows" section. Please see the third paragraph. "Microsoft has established a policy called product support lifecycle [1]. Each product's lifecycle has a mainstream support phase, where the product is generally commercially available, and an extended support phase, where paid support is still available, and certain bug fixes are released (in particular security fixes). Python's Windows support now follows this lifecycle. A new feature release X.Y.0 will support all Windows releases whose extended support phase is not yet expired. Subsequent bug fix releases will support the same Windows releases as the original feature release (even if the extended support phase has ended). Because of this policy, no further Windows releases need to be listed in this PEP. Each feature release is built by a specific version of Microsoft Visual Studio. That version should have mainstream support when the release is made. Developers of extension modules will generally need to use the same Visual Studio release; they are concerned both with the availability of the versions they need to use, and with keeping the zoo of versions small. The Python source tree will keep unmaintained build files for older Visual Studio releases, for which patches will be accepted. Such build files will be removed from the source tree 3 years after the extended support for the compiler has ended (but continue to remain available in revision control)." -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ 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
