Re: [Python-Dev] Critique of PEP 502 (String Interpolation Redux)
That could be helpful and done without too much work, adding in the best practices and PEP8 guidelines that have been asked for in other threads. Are people interested in a "rationale and best practices" for string interpolation pep? -Mike On 09/04/2015 08:15 PM, Guido van Rossum wrote: The text of the PEP has too much on motivation and rationale: maybe that would be suitable for an informative PEP. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Critique of PEP 502 (String Interpolation Redux)
I think that would be a better use of your time than continuing to refine the spec of your competing proposal. On Mon, Sep 7, 2015 at 12:40 PM, Mike Miller wrote: > That could be helpful and done without too much work, adding in the best > practices and PEP8 guidelines that have been asked for in other threads. > > Are people interested in a "rationale and best practices" for string > interpolation pep? > > -Mike > > > On 09/04/2015 08:15 PM, Guido van Rossum wrote: > >> The text of the PEP has too much on motivation and rationale: maybe that >> would >> be suitable for an informative PEP. >> > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [RELEASED] Python 3.5.0rc3 is now available
On behalf of the Python development community and the Python 3.5 release team, I'm relieved to announce the availability of Python 3.5.0rc3, also known as Python 3.5.0 Release Candidate 3. The next release of Python 3.5 will be Python 3.5.0 final. There should be few (or no) changes to Python 3.5 between rc3 and final. This is a preview release, and its use is not recommended for production settings. You can find Python 3.5.0rc3 here: https://www.python.org/downloads/release/python-350rc3/ Windows and Mac users: please read the important platform-specific "Notes on this release" section near the end of that page. Happy hacking, //arry/ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 495: What's left to resolve
The good news that other than a few editorial changes there is only one issue which keeps me from declaring PEP 495 complete. The bad news is that the remaining issue is subtle and while several solutions have been proposed, neither stands out as an obviously right. The Problem --- PEP 495 requires that the value of the fold attribute is ignored when two aware datetime objects that share tzinfo are compared. This is motivated by the reasons of backward compatibility: we want the value of fold to only matter in conversions from one zone to another and not in arithmetic within a single timezone. As Tim pointed out, this rule is in conflict with the only requirement that a hash function must satisfy: if two objects compare as equal, their hashes should be equal as well. Let t0 and t1 be two times in the fold that differ only by the value of their fold attribute: t0.fold == 0, t1.fold == 1. Let u0 = t0.astimezone(utc) and u1 = t1.astimezone(t1). PEP 495 requires that u0 < u1. (In fact, this is the main purpose of the PEP to disambiguate between t0 and t1 so that conversion to UTC is well defined.) However, by the current PEP 495 rules, t0 == t1 is True, by the pre-PEP rule (and the PEP rule that fold is ignored in comparisons) we also have t0 == u0 and t1 == u1. So, we have (a) a violation of the transitivity of ==: u0 == t0 == t1 == u1 does not imply u0 == u1 which is bad enough by itself, and (b) since hash(u0) can be equal to hash(u1) only by a lucky coincidence, the rule "equality of objects implies equality of hashes" leads to contradiction because applying it to the chain u0 == t0 == t1 == u1, we get hash(u0) == hash(t0) == hash(t1) == hash(u1) which is now a chain of equalities of integers and on integers == is transitive, so we have hash(u0) == hash(u1) which as we said can only happen by a lucky coincidence. The Root of the Problem --- The rules of arithmetic on aware datetime objects already cause some basic mathematical identities to break. The problem described above is avoided by not having a way to represent u1 in the timezone where u0 and u1 map to the same local time. We still have a surprising u0 < u1, but u0.astimezone(local) == u1.astimezone(local), but it does not rise to the level of a hash invariant violation because u0.astimezone(local) and u1.astimezone(local) are not only equal: they are identical in all other ways and if we convert them back to UTC - they both convert to u0. The root of the hash problem is not in the t0 == t1 is True rule. It is in u0 == t0. The later equality is just too fragile: if you add timedelta(hour=1) to both sides to this equation, then (assuming an ordinary 1 hour fall-back fold), you will get two datetime objects that are no longer equal. (Indeed, local to utc equality t == u is defined as t - t.utcoffset() == u.replace(tzinfo=t.tzinfo), but when you add 1 hour to t0, utcoffset() changes so the equality that held for t0 and u0 will no longer hold for t0 + timedelta(hour=1) and u0 + timedelta(hour=1).) PEP 495 gives us a way to break the u0 == t0 equality by replacing t0 with an "equal" object t1 and simultaneously have u0 == t0, t0 == t1 and t1 != u0. The Solutions - Tim suggested several solutions to this problem, but by his own admission neither is more than "grudgingly acceptable." For completeness, I will also present my "non-solution." Solution 0: Ignore the problem. Since PEP 495 does not by itself introduce any tzinfo implementations with variable utcoffset(), it does not create a hash invariant violation. I call this a non-solution because it would once again punt an unsolvable problem to tzinfo implementors. It is unsolvable for *them* because without some variant of the rejected PEP 500, they will have no control over datetime comparisons or hashing. Solution 1: Make t1 > t0. Solution 2: Leave t1 == t0, but make t1 != u1. Request for Comments I will not discuss pros and cons on the two solutions because my goal here was only to state the problem, identify the root case and indicate the possible solutions. Those interested in details can read Tim's excellent explanations in the "Another round on error-checking" [1] and "Another approach to 495's glitches" [2] threads. I "bcc" python-dev in a hope that someone in the expanded forum will either say "of course solution N is the right one and here is why" or "here is an obviously right solution - how could you guys miss it." [1]: https://mail.python.org/pipermail/datetime-sig/2015-September/000622.html [2]: https://mail.python.org/pipermail/datetime-sig/2015-September/000716.html ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Comparison operators (> < >= <=) for collections.Counter
I noticed that collections.Counter, unlike set, doesn't support the ordered comparison operators (> < >= <=). I'd like to propose implementing these operators in an analogous fashion to set: counter1 >= counter2 if counter1 contains at least as many of every key as counter2 does. Cases where counter1 doesn't have a key and counter2 has a negative amount of that key would still count as >=. counter1 > counter2 when counter1 >= counter2 and counter1 != counter2. Does this sound reasonable? If so I'll write up and submit a patch. - Kerrick ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Comparison operators (> < >= <=) for collections.Counter
On 08.09.15 05:06, Kerrick Staley wrote: I noticed that collections.Counter, unlike set, doesn't support the ordered comparison operators (> < >= <=). I'd like to propose implementing these operators in an analogous fashion to set: counter1 >= counter2 if counter1 contains at least as many of every key as counter2 does. Cases where counter1 doesn't have a key and counter2 has a negative amount of that key would still count as >=. counter1 > counter2 when counter1 >= counter2 and counter1 != counter2. Does this sound reasonable? If so I'll write up and submit a patch. This idea already was rejected. http://bugs.python.org/issue22515 ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Can't install Python 3.5rc3
I've been unable to install Python 3.5rc3. It progresses to installing Tcl/tk, then reports that a newer version of 3.5 is already installed, then it rolls back (slowly). I don't know where it's finding this "newer version"; I've uninstalled the previous releases of Python 3.5. I'm on Windows 10. Here's the contents of the log file: [0A40:1CC8][2015-09-08T04:29:45]i001: Burn v3.10.0.1823, Windows v10.0 (Build 10240: Service Pack 0), path: C:\Users\MRAB\Downloads\Python\python-3.5.0rc3.exe [0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 'ActionLikeInstalling' to value 'Installing' [0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 'ActionLikeInstallation' to value 'Setup' [0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 'ShortVersion' to value '3.5' [0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 'ShortVersionNoDot' to value '35' [0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 'InstallAllUsers' to value '0' [0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 'InstallLauncherAllUsers' to value '1' [0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 'TargetDir' to value '' [0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 'DefaultAllUsersTargetDir' to value '[ProgramFilesFolder]Python [ShortVersion]' [0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 'TargetPlatform' to value 'x86' [0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 'DefaultJustForMeTargetDir' to value '[LocalAppDataFolder]Programs\Python\Python[ShortVersionNoDot]-32' [0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 'OptionalFeaturesRegistryKey' to value 'Software\Python\PythonCore\[ShortVersion]-32\InstalledFeatures' [0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 'TargetDirRegistryKey' to value 'Software\Python\PythonCore\[ShortVersion]-32\InstallPath' [0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 'DefaultCustomTargetDir' to value '' [0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 'InstallAllUsersState' to value 'enabled' [0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 'InstallLauncherAllUsersState' to value 'enabled' [0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 'CustomInstallLauncherAllUsersState' to value '[InstallLauncherAllUsersState]' [0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 'TargetDirState' to value 'enabled' [0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 'CustomBrowseButtonState' to value 'enabled' [0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 'Include_core' to value '1' [0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 'Include_exe' to value '1' [0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 'Include_dev' to value '1' [0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 'Include_lib' to value '1' [0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 'Include_test' to value '1' [0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 'Include_doc' to value '1' [0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 'Include_tools' to value '1' [0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 'Include_tcltk' to value '1' [0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 'Include_pip' to value '1' [0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 'Include_launcher' to value '1' [0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 'Include_symbols' to value '0' [0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 'Include_debug' to value '0' [0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 'LauncherOnly' to value '0' [0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 'AssociateFiles' to value '1' [0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 'Shortcuts' to value '1' [0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 'PrependPath' to value '0' [0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 'CompileAll' to value '0' [0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 'SimpleInstall' to value '0' [0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 'SimpleInstallDescription' to value '' [0A40:1CC8][2015-09-08T04:29:45]i009: Command Line: '' [0A40:1CC8][2015-09-08T04:29:45]i000: Setting string variable 'WixBundleLog' to value 'C:\Users\MRAB\AppData\Local\Temp\Python 3.5.0rc3 (32-bit)_20150908042945.log' [0A40:1CC8][2015-09-08T04:29:45]i000: Setting string variable 'WixBundleOriginalSource' to value 'C:\Users\MRAB\Downloads\Python\python-3.5.0rc3.exe' [0A40:1CC8][2015-09-08T04:29:45]i000: Setting string variable 'WixBundleOriginalSourceFo
