On 2018-04-18 02:13, Chris Angelico wrote:
> I'm much happier promoting a full-featured assignment expression than
> something that can only be used in a limited set of situations. Is
> there reason to believe that extensions to the := operator might take
> it in a different direction? If not, there's very little to lose by
> permitting any assignment target, and then letting style guides frown
> on it if they like.
This is a very good argument: why artificially restrict the operator?
This reminds me of the artificial restriction of decorator syntax (why
is @foo()() not legal?). There was never a rationale given for that and
now we are stuck with it.
Please feel free to reply to
python-dev(a)python.org rather than me personally to take this back to
On Tue, Apr 17, 2018 at 1:20 PM, Martin Gainty <mgainty(a)hotmail.com> wrote:
> I'll need a few specifics before i wandering into "dll hell"
> .NetFramework version?
> RT Library version? ....in the old days we used to call this msvcrt.dll
> msvc or mingw compiler?
> if msvc which version msvc?
> if mingw which version msvc ?
Have a look at https://devguide.python.org/ to get started
Python Developer’s Guide — Python Developer's Guide<https://devguide.python.org/>
Contributing¶. We encourage everyone to contribute to Python and that’s why we have put up this developer’s guide. If you still have questions after reviewing the material in this guide, then the Core Python Mentorship group is available to help guide new contributors through the process.
contributing to CPython, and in particular
https://devguide.python.org/setup/#windows for getting set up on
To answer your questions in brief, though: we use the latest MSVC
compiler available with Visual Studio 2017, which links to the
"universal CRT" and avoids most of the old headaches of
incompatibilities between the runtimes used by different compiler
You may also be interested in the core-mentorship mailing list,
details about which can be found at
Excuse me if this was discussed before, but in French and Japanese
translations, all the sample programs seem to have identifiers in
English still. According to "PEP 545 -- Python Documentation
Translations", as I understand .po files are used for translations. May
I ask if there's technical restrictions causing translations being only
applied to the text parts?
For example, here's the first sample program in 4.2:
>>># Measure some strings:
... words = ['cat', 'window', 'defenestrate']
>>>for w in words:
... print(w, len(w))
Here's a possible translation in Chinese:
>>> # 丈量一些字符串
... 词表 = ['猫', '窗户', '丢出窗户']
>>> for 词 in 词表:
... print(词, len(词))
As you may notice the strings differ in size if they are translated
directly. Obviously that does add extra burden to review the new sample
programs to assure effectiveness and readability.
Any suggestion or comments are welcome.
On 04/17/2018 06:55 AM, Steve Dower wrote:
> Agree with Paul. The PEP is well thought out and well presented, but I
> really don’t think we need this in Python (and I say this as someone
> who uses it regularly in C/C#).
> -1 on the idea; no disrespect intended toward to people who did a lot
> of work on it.
Well put! I feel the same, and yes that includes being -1 on the proposal.
On 2018-04-16 02:32, Raymond Hettinger wrote:
> I don't think that confidence is warranted. The world of Python is very large. When public APIs (such as that in the venerable types module) get changed, is virtually assured that some code will break.
Yes, *some* code will break, I never denied that. I just think that
there is not much existing code which needs to distinguish between
different kinds of methods, such that not much code will break. And if
existing code does need to make that distinction, the reason for it
might go away after PEP 575 (this is what Nick Coghlan also alluded to).
The hard question is whether the expected breakage is bad enough to
reject this PEP. This is my first PEP, so I honestly don't have a good
idea how high the bar for backwards compatibility is.
On 2018-04-14 23:14, Guido van Rossum wrote:
> That actually sounds like a pretty big problem. I'm sure there is lots
> of code that doesn't *just* duck-type nor calls inspect but uses
> isinstance() to decide how to extract the desired information.
In the CPython standard library, the *only* fixes that are needed
because of this are in:
- inspect (obviously)
- doctest (to figure out the __module__ of an arbitrary object)
- multiprocessing.reduction (something to do with pickling)
- xml.etree.ElementTree (to determine whether a certain method was
- GDB support
I've been told that there might also be a problem with
Random._randbelow, even though it doesn't cause test failures.
The fact that there is so little breakage in the standard library makes
me confident that the problem is not so bad. And in the cases where it
does break, it's usually pretty easy to fix.
Finally: changing the classes of certain objects is exactly the point of
this PEP, so it's impossible to achieve 100% backwards compatibility.
I'm pleased to announce the immediate availability of Python 2.7.15 release candidate 1. Python 2.7.15rc1 is a preview release of the next bug fix release in the Python 2.7.x series.
Python 2.7.15rc1 may be downloaded in source and binary forms from
Please consider testing this release with your applications and libraries and reporting bugs to
A final release is expected in 2 weeks time.
2.7.15 includes some noteworthy changes to the macOS installers: All python.org macOS installers now ship with a built-in copy of OpenSSL. Additionally, there is a new additional installer variant for macOS 10.9+ that includes a built-in version of Tcl/Tk 8.6. See the installer README for more information.
(on behalf of 2.7's release team and contributors)
On 2018-04-13 15:23, Nick Coghlan wrote:
> There's also a section in the rationale which refers to METH_USRx
> flags, which I'm guessing from context are an idea you were
> considering proposing, but eventually dropped from the rest of the
No, I actually still want to propose it. In my latest update of the PEP,
I hope to have made it more clear.