Re: [Python-Dev] Requesting pronouncement on PEP 463: Exception-catching expressions

On Thu, Mar 13, 2014 at 8:37 AM, Tres Seaver wrote: > On 03/12/2014 04:49 PM, Chris Angelico wrote: >> You can use hasattr() in place of AttributeError > > I use: > > getattr(subject, attrname, default)? > > *all the time*. Umm, yeah, that one. Why did I think hasa

Re: [Python-Dev] Requesting pronouncement on PEP 463: Exception-catching expressions

On Thu, Mar 13, 2014 at 8:15 PM, Victor Stinner wrote: > Even if a PEP is rejected, it becomes the best reference if someone > requests the same or a similar feature some months or years later. > Rejected PEPs explain almost how the Python language was designed. > > For thanks Chris, and I hope th

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On Sun, Mar 23, 2014 at 10:33 AM, Antoine Pitrou wrote: > On Sat, 22 Mar 2014 19:07:51 -0400 > Donald Stufft wrote: >> As someone who is deeply biased towards improving the packaging tool chain >> and getting people to use it I think that most people will simply use the >> Stdlib even if a more

Re: [Python-Dev] PEP 466 (round 2): Network security enhancements for Python 2.7

On Sun, Mar 23, 2014 at 6:07 PM, Nick Coghlan wrote: > And that's just three of the highest profile open source projects that > make heavy use of Python. Given the likely existence of large amounts of > legacy code that lacks the kind of automated regression test suite needed > to help support a m

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On Mon, Mar 24, 2014 at 11:03 AM, Barry Warsaw wrote: > Python 2.7.x will always be the "standard stdlib". We would never release a > specific Python 2.7 + "security stdlib" release, but downstream developers > would be able to overlay this forked stdlib on top of the standard one. > Volunteers o

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On Mon, Mar 24, 2014 at 1:34 PM, Donald Stufft wrote: > Right now users have a singular method for determining what the runtime > environment looks like for Python, the version. There are processes around > selecting different Python versions for things, upgrading etc. This isn’t > a new thing for

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On Mon, Mar 24, 2014 at 7:44 PM, Nick Coghlan wrote: > > On 24 Mar 2014 15:25, "Chris Angelico" wrote: > >> As has already been pointed out, this can already happen, but in an >> ad-hoc way. Making it official or semi-official would mean that a >> scrip

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On Mon, Mar 24, 2014 at 8:28 PM, Cory Benfield wrote: > On 24 March 2014 08:44, Nick Coghlan wrote: >> The position I am coming to is that the "enhanced security" release should >> be the default one that we publish binary installers for, but we should also >> ensure that downstream redistributor

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On Tue, Mar 25, 2014 at 7:12 PM, Cory Benfield wrote: > On 24 March 2014 19:37, Chris Angelico wrote: >> The opting in could be done at the distro level. Red Hat could ship a >> thing called /usr/bin/python that runs SEPython, and that package >> could be identified and n

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On Tue, Mar 25, 2014 at 7:37 PM, Cory Benfield wrote: > On 25 March 2014 08:26, Chris Angelico wrote: >> Exactly the same. If someone wants to distribute SEPython (that >> someone might be python.org itself, or ActiveState, or anyone else who >> has an interest in it), the

Re: [Python-Dev] SSLSocket.send() for non-blocking sockets

On Wed, Mar 26, 2014 at 11:54 AM, Nikolaus Rath wrote: > 2. Change the behavior immediately, potentially breaking some >applications that worked around it, but unbreaking others that relied >on the documented behavior. If it's a functionality change that's likely to break code, would it b

Re: [Python-Dev] collections.sortedtree

On Thu, Mar 27, 2014 at 8:58 PM, Nick Coghlan wrote: >On 27 March 2014 19:10, Maciej Fijalkowski wrote: >> I just find "my company is stupid so let's work around it by putting >> stuff to python standard library" unacceptable argument for python-dev >> and all the python community. > > Due dilige

Re: [Python-Dev] collections.sortedtree

On Thu, Mar 27, 2014 at 10:10 PM, Nick Coghlan wrote: > Extending our trust to include a new component isn't to be done > lightly, but it *does* genuinely save work in the long run for a whole > lot of other people whenever we choose to do so, and that is the point > Stephen was making. Exactly s

Re: [Python-Dev] collections.sortedtree

On Fri, Mar 28, 2014 at 3:26 PM, Stephen J. Turnbull wrote: > This is at least some convenience for *all* > users, and a near necessity for some strictly controlled environments. > In the latter, the "gatekeeper" is all too likely to say "PyPI? Bring > us a CTO signoff that 'this module is essent

Re: [Python-Dev] Python 4?

On Fri, Apr 4, 2014 at 1:02 AM, Skip Montanaro wrote: > On Thu, Apr 3, 2014 at 8:59 AM, Brett Cannon wrote: >> >> Who the heck knows what the person specifically means, although it sounds >> like he did mean Python 3.4 which would explain why he know has a Python3 >> directory. > > Thanks. I'll

Re: [Python-Dev] Python-Dev Digest, Vol 129, Issue 6

On Mon, Apr 7, 2014 at 5:15 PM, Kells Pablo wrote: > HELLO... > > !thank you for all the cooperation and emails send. i would like that you > now stop sending them.. > > thank you in advance > > On Fri, Apr 4, 2014 at 4:22 PM, wrote: >> >> Send Python-Dev mailing list submissions to >> py

Re: [Python-Dev] PEP 465: A dedicated infix operator for matrix multiplication

On Tue, Apr 8, 2014 at 12:02 PM, Steven D'Aprano wrote: >> You can't be serious. > > I can't? Would it help if I sprinkle smileys and *winks* throughout my > post? You can be serious, Steven, but it's more likely to happen if you *don't* use smileys... *not very serious* ChrisA

Re: [Python-Dev] issue with itertools leads the crash

On Wed, Apr 9, 2014 at 2:40 AM, Eric Snow wrote: > On Apr 8, 2014 10:31 AM, "MRAB" wrote: >> If the RHS yields too few, e.g. 3, you'll get: >> >> ValueError: attempt to assign sequence of size 3 to extended slice of size 4 >> >> If it yields too many, e.g. 10, you'll get: >> >> ValueError: attemp

Re: [Python-Dev] PEP 465: A dedicated infix operator for matrix multiplication

On Wed, Apr 9, 2014 at 2:49 AM, Antoine Pitrou wrote: > Le 08/04/2014 04:02, Steven D'Aprano a écrit : > >> >> Many, many more people take part in the CPython core developer culture >> than just the core developers themselves. Look at the readership of this >> mailing list, which is open to the pu

Re: [Python-Dev] issue with itertools leads the crash

On Wed, Apr 9, 2014 at 3:30 AM, Larry Hastings wrote: > On 04/08/2014 12:50 PM, Chris Angelico wrote: > > It would be nice to have a simple notation that fetches what it needs > and ignores any extras. > > a, b, c, * = x.split("-") > > Bomb if there aren't

Re: [Python-Dev] death to 2.7; long live 2.7

On Thu, Apr 10, 2014 at 11:22 AM, Benjamin Peterson wrote: > Planning-on-making-2.7-releases-'til-the-cows-come-home-ly yours, Past 2.7.9, will you make 2.7.10 etc, or does that violate other policies? What will a lack of provided installers do to Windows support? It's easy enough on Linux to sa

Re: [Python-Dev] Python "2migr8"

On Tue, Apr 15, 2014 at 1:32 AM, Steve Dower wrote: > My best idea so far would be to have a magic comment (to ensure 2.7 > compatibility better than a "from __future__ ...") near the top of the file > that marks that file as "must straddle 2.7 and 3.3". Adding this comment > causes (for exampl

Re: [Python-Dev] Python "2migr8"

On Tue, Apr 15, 2014 at 7:17 AM, Chris Barker wrote: > On Mon, Apr 14, 2014 at 1:26 PM, Guido van Rossum wrote: > >> >> >> - I'd prefer a name that plays on 2 and 3, not 2 and 8. :-) > > How about mirg2**3 (pronounced "migrate") ? > > ;-) > Just read this, and laughed so loudly and suddenly that

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

On Tue, Apr 15, 2014 at 8:21 AM, Brett Cannon wrote: >> In my work environment (Python 2.7.2, all the heavy lifting done in >> C++), startup costs are dominated by dynamic linking of all our C++ >> libraries and their Boost wrappers: > > > Sure, but not everyone uses Boost or has long running proc

Re: [Python-Dev] Mercurial sluggishness (was: this is what happens if you freeze all the modules required for startup)

On Wed, Apr 16, 2014 at 1:34 AM, Skip Montanaro wrote: > I find it hard to believe > that freezing the stdlib is going to lower the barrier enough for the > Mercurial folks, if, in fact, import slowness is their main reason for > not moving to 3.x. I've no idea whether that's the case or not. All

Re: [Python-Dev] Mercurial sluggishness (was: this is what happens if you freeze all the modules required for startup)

On Wed, Apr 16, 2014 at 1:56 AM, Skip Montanaro wrote: > On Tue, Apr 15, 2014 at 10:42 AM, Daniel Holth wrote: >> I wish it was less >> than 50 milliseconds (0.05 seconds) including running hg, which is the >> common threshold for "instant". > > "Instant" for me is "the blink of an eye," which Wi

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

On Wed, Apr 16, 2014 at 2:40 AM, Antoine Pitrou wrote: > Le 15/04/2014 09:45, Chris Angelico a écrit : > >> >> Specific use-case that I can see: Mercurial. In a git vs hg shoot-out, >> git will usually win on performance, and hg is using Py2; > > > Keep in mind

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

On Wed, Apr 16, 2014 at 4:54 AM, Guido van Rossum wrote: > Can we please stop the argument about Hg vs. Git? My apologies. All I was saying was that hg is a use case where startup performance really does matter, as opposed to the ones presented earlier in the thread where a process stays in memor

Re: [Python-Dev] List vs Tuple / Homogeneous vs Heterogeneous / Mutable vs Immutable

On Thu, Apr 24, 2014 at 1:59 PM, Łukasz Langa wrote: > On Apr 17, 2014, at 11:49 AM, Brett Cannon wrote: > >> Think of tuples like a struct in C, lists like an array. > > > I generally agree but it’s a bit more complex, for instance when you have a > homogenous sequence but want it to be hashable

Re: [Python-Dev] pep8 reasoning

On Thu, Apr 24, 2014 at 11:59 PM, Barry Warsaw wrote: > I will say this: the original preference for underscore_names in PEP 8 was > spurred by user studies some of our early non-native English speaking users > conducted many years ago. We learned that it was more difficult for many of > them to

Re: [Python-Dev] pep8 reasoning

On Fri, Apr 25, 2014 at 11:40 AM, Allen Li wrote: > 2) If you're starting a new project, follow PEP8 (or the standards for >the language you're using) to preserve CONSISTENCY. Don't forget that PEP 8 is not the standard for the Python language, only the Python stdlib. Particularly, there's no

Re: [Python-Dev] pep8 reasoning

On Fri, Apr 25, 2014 at 1:28 PM, Guido van Rossum wrote: > On Apr 24, 2014 7:01 PM, "Chris Angelico" wrote: >> >> On Fri, Apr 25, 2014 at 11:40 AM, Allen Li wrote: >> > 2) If you're starting a new project, follow PEP8 (or the standards for >>

Re: [Python-Dev] Help with changes in stack from 2.7 to 3.x

On Sat, Apr 26, 2014 at 1:11 PM, Andrew Konstantaras wrote: > Can anyone point me in the direction to find this information? Any help is > appreciated. I'd recommend python-list rather than python-dev (the latter is for the development *of* Python, rather than development *with* Python). But to

Re: [Python-Dev] Clarification on MRO when inheriting from builtin type.

On Mon, Apr 28, 2014 at 12:59 PM, Paul Sokolovsky wrote: > From the output, "User" class as expected does not override > list.append(), but does override list.__str__(). Is this behavior > documented somewhere (complete arrangement)? What's the rationale > behind it? In Python 3.4 (don't know abo

Re: [Python-Dev] Clarification on MRO when inheriting from builtin type.

On Mon, Apr 28, 2014 at 1:25 PM, Paul Sokolovsky wrote: > > Thanks for quick response! I see that list.__repr__ exists, and test > using it works "as expected". Hopefully, such stuff can be treated as > implementation-specific details... The language defines method lookups and the MRO and such, a

Re: [Python-Dev] pip: cdecimal an externally hosted file and may be unreliable [sic]

On Thu, May 8, 2014 at 11:39 PM, M.-A. Lemburg wrote: > I agree with Stefan that the warning message wording is less > than ideal. You'd normally call such blanket statements FUD, > esp. since there are plenty external hosting services which > are reliable and safe to use. No, it's not FUD. Every

Re: [Python-Dev] cpython: Minor clean-ups for heapq.

On Tue, May 27, 2014 at 6:58 PM, Serhiy Storchaka wrote: > 26.05.14 10:59, raymond.hettinger написав(ла): >> >> +result = [(elem, i) for i, elem in zip(range(n), it)] > > > Perhaps it is worth to add simple comment explaining why this is not > equivalent to just list(zip(it, range(n))). Ot

Re: [Python-Dev] Download Counts (was: Language Summit notes)

On Thu, May 29, 2014 at 7:27 AM, Victor Stinner wrote: > 2014-05-28 22:05 GMT+02:00 Eli Bendersky : >> Most Linux installs go through package managers which don't count here, no? > > For Debian, there is the "popcorn" project which provides some statistics: > > http://qa.debian.org/popcon.php?pack

Re: [Python-Dev] Download Counts (was: Language Summit notes)

On Thu, May 29, 2014 at 9:05 AM, Barry Warsaw wrote: > On May 29, 2014, at 07:37 AM, Chris Angelico wrote: > >>Debian Testing (Jessie) ships both 3.3 and 3.4, with the 'python3' >>package pulling in 3.3. That may change before Jessie becomes stable, >>I don

Re: [Python-Dev] Language Summit Follow-Up

On Sat, May 31, 2014 at 3:40 AM, 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

[Python-Dev] %x formatting of floats - behaviour change since 3.4

I'm helping out with the micropython project and am finding that one of their tests fails on CPython 3.5 (fresh build from Mercurial this morning). It comes down to this: Python 3.4.1rc1 (default, May 5 2014, 14:28:34) [GCC 4.8.2] on linux Type "help", "copyright", "credits" or "license" for more

Re: [Python-Dev] %x formatting of floats - behaviour change since 3.4

On Wed, Jun 4, 2014 at 8:03 AM, Victor Stinner wrote: > 2014-06-03 23:38 GMT+02:00 Chris Angelico : >> Is this an intentional change? And if so, is it formally documented >> somewhere? I don't recall seeing anything about it, but my >> recollection doesn't mean

Re: [Python-Dev] %x formatting of floats - behaviour change since 3.4

On Wed, Jun 4, 2014 at 8:26 AM, Glenn Linderman wrote: > On 6/3/2014 3:05 PM, Chris Angelico wrote: > > On Wed, Jun 4, 2014 at 8:03 AM, Victor Stinner > wrote: > > 2014-06-03 23:38 GMT+02:00 Chris Angelico : > > Is this an intentional change? And if so, is it formally d

Re: [Python-Dev] Internal representation of strings and Micropython

On Wed, Jun 4, 2014 at 11:17 AM, Steven D'Aprano wrote: > * Having a build-time option to restrict all strings to ASCII-only. > > (I think what they mean by that is that strings will be like Python 2 > strings, ASCII-plus-arbitrary-bytes, not actually ASCII.) What I was actually suggesting al

Re: [Python-Dev] Internal representation of strings and Micropython

On Wed, Jun 4, 2014 at 3:17 PM, Nick Coghlan wrote: > On 4 June 2014 11:17, Steven D'Aprano wrote: >> My own feeling is that O(1) string indexing operations are a quality of >> implementation issue, not a deal breaker to call it a Python. > > If string indexing & iteration is still presented to t

Re: [Python-Dev] Internal representation of strings and Micropython

On Wed, Jun 4, 2014 at 3:23 PM, Guido van Rossum wrote: > On Tue, Jun 3, 2014 at 7:32 PM, Chris Angelico wrote: >> >> On Wed, Jun 4, 2014 at 11:17 AM, Steven D'Aprano >> wrote: >> > * Having a build-time option to restrict all strings to ASCII-only. >>

Re: [Python-Dev] Internal representation of strings and Micropython

On Wed, Jun 4, 2014 at 5:02 PM, wrote: > There are more things to consider for the internal implementation, > in particular how the string length is implemented. Several alternatives > exist: > 1. store the UTF-8 length (i.e. memory size) > 2. store the number of code points (i.e. Python len()) >

Re: [Python-Dev] Internal representation of strings and Micropython

On Wed, Jun 4, 2014 at 8:38 PM, Paul Sokolovsky wrote: > That's another reason why people don't like Unicode enforced upon them > - all the talk about supporting all languages and scripts is demagogy > and hypocrisy, given a choice, Unicode zealots would rather limit > people to Latin script then

Re: [Python-Dev] Internal representation of strings and Micropython

On Wed, Jun 4, 2014 at 8:38 PM, Paul Sokolovsky wrote: > And I'm saying that not to discourage Unicode addition to MicroPython, > but to hint that "force-force" approach implemented by CPython3 and > causing rage and split in the community is not appreciated. FWIW, it's Python 3 (the language) an

Re: [Python-Dev] Internal representation of strings and Micropython

On Wed, Jun 4, 2014 at 9:12 PM, Paul Sokolovsky wrote: > An alternative view is that the discussion on the tracker showed Python > developers' mind-fixation on implementing something the way CPython does > it. And I didn't yet go to that argument, but in the end, MicroPython > does not try to rewr

Re: [Python-Dev] Internal representation of strings and Micropython

On Thu, Jun 5, 2014 at 12:17 AM, Serhiy Storchaka wrote: > 04.06.14 10:03, Chris Angelico написав(ла): > >> Right, which is why I don't like the idea. But you don't need >> non-ASCII characters to blink an LED or turn a servo, and there is >> significant resista

Re: [Python-Dev] Internal representation of strings and Micropython

On Thu, Jun 5, 2014 at 12:49 AM, Paul Sokolovsky wrote: >> > But you need non-ASCII characters to display a title of MP3 track. > > Yes, but to display a title, you don't need to do codepoint access at > random - you need to either take a block of memory (length in bytes) and > do something with i

Re: [Python-Dev] Internal representation of strings and Micropython

On Thu, Jun 5, 2014 at 6:50 AM, Glenn Linderman wrote: > 8) (Content specific variable size caches) Index each codepoint that is a > different byte size than the previous codepoint, allowing indexing to be > used in the intervals. Worst case size is like 2, best case size is a single > entry for

Re: [Python-Dev] Internal representation of strings and Micropython

On Thu, Jun 5, 2014 at 8:52 AM, Paul Sokolovsky wrote: > "Well" is subjective (or should be defined formally based on the > requirements). With my MicroPython hat on, an implementation which > receives a string, transcodes it, leading to bigger size, just to > immediately transcode back and send o

Re: [Python-Dev] Internal representation of strings and Micropython

On Thu, Jun 5, 2014 at 10:03 AM, Greg Ewing wrote: > StringPositions could support the following operations: > >StringPosition + int --> StringPosition >StringPosition - int --> StringPosition >StringPosition - StringPosition --> int > > These would be computed by counting characters f

Re: [Python-Dev] [numpy wishlist] Interpreter support for temporary elision in third-party classes

On Fri, Jun 6, 2014 at 11:47 AM, Nathaniel Smith wrote: > Unfortunately we don't actually know whether Cython is the only culprit > (such code *could* be written by hand), and even if we fixed Cython it would > take some unknowable amount of time before all downstream users upgraded > their Cython

Re: [Python-Dev] Internal representation of strings and Micropython

On Fri, Jun 6, 2014 at 8:15 PM, Paul Sokolovsky wrote: > I'm sorry if I was somehow related to that, my > bringing in the formal language spec was more a rhetorical figure, a > response to people claiming O(1) requirement. This was exactly why this whole discussion came up, though. We were debati

Re: [Python-Dev] Moving Python 3.5 on Windows to a new compiler

On Sat, Jun 7, 2014 at 1:41 AM, Steve Dower wrote: > What this means for Python is that C extensions for Python 3.5 and later can > be built using any version of MSVC from 14.0 and later. Oh, if only this had been available for 2.7!! Actually... this means that 14.0 would be a good target for a

Re: [Python-Dev] Moving Python 3.5 on Windows to a new compiler

On Sat, Jun 7, 2014 at 4:12 AM, Steve Dower wrote: > Chris Angelico wrote: >> On Sat, Jun 7, 2014 at 1:41 AM, Steve Dower >> wrote: >>> What this means for Python is that C extensions for Python 3.5 and later >>> can be built using any version of MSVC from

Re: [Python-Dev] Moving Python 3.5 on Windows to a new compiler

On Sat, Jun 7, 2014 at 5:11 AM, Donald Stufft wrote: > Is it really any difference in maintenance if you just stop applying updates > to > 2.7 and switch to 2.8? If 2.8 is really just 2.7 with a new compiler then > there > should be no functional difference between doing that and doing a 2.7.wha

Re: [Python-Dev] Moving Python 3.5 on Windows to a new compiler

On Sat, Jun 7, 2014 at 5:36 AM, Donald Stufft wrote: > Well it’d contain bug fixes and whatever other sorts of things you’d put > into a 2.7.whatever release. So they’d still want to upgrade to 2.8 since > that’ll have bug fixes. But it's not a potentially-breaking change. For example, on Debian

Re: [Python-Dev] Moving Python 3.5 on Windows to a new compiler

On Sat, Jun 7, 2014 at 5:42 AM, wrote: > Perhaps a final alternative is simply continuing > the 2.7 series with a stale compiler, as a kind of carrot on a stick to > encourage users to upgrade? More likely, what would happen is that there'd be an alternate distribution of Python 2.7 (eg ActiveSt

Re: [Python-Dev] subprocess shell=True on Windows doesn't escape ^ character

On Thu, Jun 12, 2014 at 7:58 AM, Ryan wrote: > In all seriousness, to me this is obvious. When you pass a command to the > shell, naturally, certain details are shell-specific. > > -1. Bad idea. Very bad idea. If you want the ^ to be escaped, do it > yourself. Or better yet, don't pass shell=T

Re: [Python-Dev] subprocess shell=True on Windows doesn't escape ^ character

On Thu, Jun 12, 2014 at 10:00 AM, anatoly techtonik wrote: > I thought exactly about that. Usually separate arguments are used to avoid > problems with escaping of quotes and other stuff. > > I'd deprecate subprocess and split it into separate modules. One is about > shell execution and another on

Re: [Python-Dev] subprocess shell=True on Windows doesn't escape ^ character

On Thu, Jun 12, 2014 at 12:07 PM, Chris Angelico wrote: > ISTM what you want is not shell=True, but a separate function that > follows the system policy for translating a command name into a > path-to-binary. That's something that, AFAIK, doesn't currently exist > in th

Re: [Python-Dev] subprocess shell=True on Windows doesn't escape ^ character

On Fri, Jun 13, 2014 at 12:11 PM, Nikolaus Rath wrote: > Can someone describe an use case where shell=True actually makes sense > at all? > > It seems to me that whenever you need a shell, the argument's that you > pass to it will be shell specific. So instead of e.g. > > Popen('for i in `seq 42`;

Re: [Python-Dev] Python 2.7 patch levels turning two digit

On Sun, Jun 22, 2014 at 2:57 AM, M.-A. Lemburg wrote: > On 21.06.2014 12:51, Nick Coghlan wrote: >> Such code has an easy fix available, though, as sys.version_info has >> existed since 2.0, and handles two digit micro releases just fine. The >> docs for sys.version also have this explicit disclai

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Thu, Jun 28, 2018 at 11:29 AM, Ivan Pozdeev via Python-Dev wrote: > On 28.06.2018 2:44, Greg Ewing wrote: >> >> Ivan Pozdeev via Python-Dev wrote: >>> >>> for me, the primary use case for an assignment expression is to be able >>> to "catch" a value into a variable in places where I can't put a

Re: [Python-Dev] Examples for PEP 572

On Wed, Jul 4, 2018 at 7:37 AM, Serhiy Storchaka wrote: > I believe most Python users are not > professional programmers -- they are sysadmins, scientists, hobbyists and > kids -- [citation needed] > In particularly mutating and > non-mutating operations are separated. The assignment expression

Re: [Python-Dev] Examples for PEP 572

On Wed, Jul 4, 2018 at 4:07 PM, Serhiy Storchaka wrote: > 04.07.18 00:51, Chris Angelico пише: >> >> On Wed, Jul 4, 2018 at 7:37 AM, Serhiy Storchaka >> wrote: >>> >>> I believe most Python users are not >>> professional programmers -- they a

Re: [Python-Dev] Examples for PEP 572

On Wed, Jul 4, 2018 at 7:59 PM, Stéfane Fermigier wrote: > > > On Tue, Jul 3, 2018 at 11:52 PM Chris Angelico wrote: >> >> On Wed, Jul 4, 2018 at 7:37 AM, Serhiy Storchaka >> wrote: >> > I believe most Python users are not >> > professional

Re: [Python-Dev] Examples for PEP 572

On Wed, Jul 4, 2018 at 11:52 PM, David Mertz wrote: > On Wed, Jul 4, 2018 at 3:02 AM Chris Angelico wrote: >> >> "Assignment is a statement" -- that's exactly the point under discussion. >> "del is a statement" -- yes, granted >> "func

Re: [Python-Dev] Assignment expression and coding style: the while True case

On Thu, Jul 5, 2018 at 10:03 AM, Victor Stinner wrote: > On the 3360 for loops of the stdlib (*), I only found 2 loops which > would benefit of assignment expressions. > > It's not easy to find loops which: > - build a list, > - are simple enough to be expressed as list comprehension, > - use a co

Re: [Python-Dev] PEP 572, VF/B, and "Shark Jumping"

On Thu, Jul 5, 2018 at 9:52 AM, Mike Miller wrote: > Compromise: > > Fortunately there is a compromise design that is chosen often these days in > new languages---restricting these assignments to if/while (potentially > comp/gen) statements. We can also reuse the existing "EXPR as NAME" syntax >

Re: [Python-Dev] PEP 572 semantics

On Thu, Jul 5, 2018 at 10:20 AM, Steve Dower wrote: > On 04Jul2018 1518, Tim Peters wrote: >> The only new thing is specifying the scope of `a`, where "local to f" >> means exactly the same thing as for any other name local to a function >> today. So far as the PEP semantics go, it doesn't even m

Re: [Python-Dev] Assignment expression and coding style: the while True case

On Thu, Jul 5, 2018 at 10:33 AM, Victor Stinner wrote: > 2018-07-05 2:15 GMT+02:00 Chris Angelico : >> On Thu, Jul 5, 2018 at 10:03 AM, Victor Stinner wrote: >>> On the 3360 for loops of the stdlib (*), I only found 2 loops which >>> would benefit of assignment express

Re: [Python-Dev] PEP 572 semantics: all capabilities of the assignment statement

On Thu, Jul 5, 2018 at 1:28 PM, Ivan Pozdeev via Python-Dev wrote: > Victor Stinner in "Assignment expression and coding style: the while True > case" and others have brought to attention > > that the AE as currently written doesn't support all the capabilities of the > assignment statement, namel

Re: [Python-Dev] PEP 572 semantics: all capabilities of the assignment statement

On Thu, Jul 5, 2018 at 3:15 PM, Guido van Rossum wrote: > Let me be slightly contrarian. :-) > > On Wed, Jul 4, 2018 at 9:12 PM Chris Angelico wrote: >> 2) Is the result of the expression the modified value or the original? > > Someone (sadly I forget who) showed, convin

Re: [Python-Dev] PEP 572: intended scope of assignment expression

On Thu, Jul 5, 2018 at 11:14 PM, Gustavo Carneiro wrote: > On Thu, 5 Jul 2018 at 13:43, Victor Stinner wrote: >> >> Hi, >> >> My work (*) in the "Assignment expression and coding style: the while >> True case" thread helped me to understand something about the >> *intended* scope. >> >> While tec

Re: [Python-Dev] PEP 572 semantics

On Fri, Jul 6, 2018 at 10:17 AM, Guido van Rossum wrote: >> I'm still wondering if it might make sense to define a new >> "TargetScopeError" subclass of SyntaxError for that last case, since it >> isn't the assignment expression syntax itself that's the problem: it's where >> that expression is lo

[Python-Dev] Symmetric vs asymmetric symbols (was PEP 572: Do we really need a ":" in ":="?)

On Fri, Jul 6, 2018 at 12:48 PM, Alexander Belopolsky wrote: > > Python really has a strong C legacy and this is the area where I agree that > C designers made a mistake by picking a symmetric symbol (=) for an > asymmetric operation. On top of that, they picked an asymmetric digraph (!=) > for a

Re: [Python-Dev] Call for prudence about PEP-572

On Sat, Jul 7, 2018 at 11:09 PM, Giampaolo Rodola' wrote: > To me this looks like the perfect example of where this functionality can be > abused. Also, I'm not clear what PEP-572 intend to do about "all other > places". E.g. should these cases be allowed? (IMO no) > > >>> yield x := 3 > >

Re: [Python-Dev] Call for prudence about PEP-572

On Mon, Jul 9, 2018 at 3:14 AM, Giampaolo Rodola' wrote: > > > On Sun, Jul 8, 2018 at 6:45 PM Steve Holden wrote: >> >> On Sun, Jul 8, 2018 at 10:41 AM, Giampaolo Rodola' >> wrote: >>> >>> [...] >>> I find that (space between the parentheses of a function call statement) >>> too unnatural as a p

Re: [Python-Dev] Call for prudence about PEP-572

On Mon, Jul 9, 2018 at 3:55 AM, Eric V. Smith wrote: > I agree with Chris in this case. That said, there is at least one place > where the grammar does forbid you from doing something that would otherwise > make be allowable: decorators. > @lookup[0] > File "", line 1 > @lookup[0] >

Re: [Python-Dev] Call for prudence about PEP-572

On Mon, Jul 9, 2018 at 7:27 AM, Giampaolo Rodola' wrote: > 5) It has no keyword argument correspondence. If foo(x := 1) is > allowed then why this one is not? > >>> foo(x=(x := 1)) > (I don't think it should BTW: it's not pretty) Actually it is. Nothing wrong with that. It assigns to 'x' in t

Re: [Python-Dev] Call for prudence about PEP-572

On Tue, Jul 10, 2018 at 2:20 AM, Paddy McCarthy wrote: > > > On Sat, 7 Jul 2018 at 16:50, Guido van Rossum wrote: >> >> This seems more suitable for a style guide. > > > Which would be good enough, if the automatic checkers were improved to flag > such poor use of ':='.. > > Would that be possib

Re: [Python-Dev] Accepting PEP 572, Assignment Expressions

On Fri, Jul 13, 2018 at 11:36 PM, Random832 wrote: > On Wed, Jul 11, 2018, at 20:10, Guido van Rossum wrote: >> As anticippated, after a final round of feedback I am hereby accepting PEP >> 572, Assignment Expressions: https://www.python.org/dev/peps/pep-0572/ > > I know everyone else is probably

Re: [Python-Dev] PEP 572 and assert

On Tue, Jul 17, 2018 at 6:50 PM, Serhiy Storchaka wrote: > Recently Barry shown an example: > > assert len(subdirs := list(path.iterdir())) == 0, subdirs > > It looks awful to me. It looks even worse than using asserts for validating > the user input. The assert has a side effect, and it depen

Re: [Python-Dev] PEP 572 and assert

On Wed, Jul 18, 2018 at 2:24 AM, Serhiy Storchaka wrote: > 17.07.18 18:48, Guido van Rossum пише: >> >> On Tue, Jul 17, 2018 at 8:28 AM, Serhiy Storchaka > > wrote: >> Should not the assert statement introduce an implicit lexical scope >> for preventing leaking

Re: [Python-Dev] Const access to CPython objects outside of GIL?

On Wed, Jul 18, 2018 at 8:18 PM, Radim Řehůřek wrote: > Thanks for your feedback everyone. Given the overwhelmingly negative > response, we'll drop this line of investigation. > > If more people bring up the same request in the future (unlikely), feel free > to reach out to us for some extra set o

[Python-Dev] Finding Guido's replacement

Guido's term as Benevolent Dictator For Life has been a long one, but in the wake of his resignation, we have an opportunity to correct some fundamental flaws in the system. Among them: * Guido lacks patience, as evidenced by the brevity of his acceptance posts. See https://mail.python.org/piperm

Re: [Python-Dev] Finding Guido's replacement

On Mon, Jul 23, 2018 at 7:07 PM, Oleg Broytman wrote: > Hi! > > On Mon, Jul 23, 2018 at 11:47:25AM +0300, Yury Selivanov > wrote: >> On Sun, Jul 22, 2018 at 11:18 PM Chris Angelico wrote: >> >> > >> > * Lately, all Guido's actions have be

Re: [Python-Dev] Let's change to C API!

On Mon, Jul 30, 2018 at 10:46 AM, Victor Stinner wrote: > 2018-07-29 23:41 GMT+02:00 Jeroen Demeyer : >> For example, you mention that you want to make Py_INCREF() a function call >> instead of a macro. But since Py_INCREF is very common, I would guess that >> this would make performance worse (no

Re: [Python-Dev] Confused on git commit tree about Lib/datetime.py

On Wed, Aug 1, 2018 at 1:16 PM, Jeffrey Zhang wrote: > I found a interesting issue when checking the Lib/datetime.py implementation > in python3 > > This patch is introduced by cf86e368ebd17e10f68306ebad314eea31daaa1e [0]. > But if you > check the github page[0], or using git tag --contains, you w

Re: [Python-Dev] Finding Guido's replacement

On Mon, Jul 23, 2018 at 6:12 AM, Chris Angelico wrote: > Guido's term as Benevolent Dictator For Life has been a long one, but > in the wake of his resignation, we have an opportunity to correct some > fundamental flaws in the system. Among them: > > * Guido lacks patience,

Re: [Python-Dev] Finding Guido's replacement

On Mon, Jul 23, 2018 at 6:12 AM, Chris Angelico wrote: > Guido's term as Benevolent Dictator For Life has been a long one, but > in the wake of his resignation, we have an opportunity to correct some > fundamental flaws in the system. Among them: > > * Guido lacks patience,

Re: [Python-Dev] Python REPL doesn't work on Windows over remote powershell session (winrm)

On Sun, Aug 26, 2018 at 9:09 AM, ZHU Xiang wrote: > But for the remote Windows powershell session the REPL doesn’t work, when I > type ‘’python” on the remote session, there’s nothing happened. > > # 1/ pre-install python on server1 (server 1 is a windows os) > # 2/ from a powershell console on se

Re: [Python-Dev] Change in Python 3's "round" behavior

On Sun, Sep 30, 2018 at 10:18 PM Steven D'Aprano wrote: > > On Sat, Sep 29, 2018 at 09:40:03PM -0400, Alex Walters wrote: > > My experience and that of many users of > > the python irc channel on freenode is that round-half-to-even is not the > > intuitive, or even desired, behavior - round-half-u

Re: [Python-Dev] Change in Python 3's "round" behavior

On Mon, Oct 1, 2018 at 8:17 AM Greg Ewing wrote: > > Chris Angelico wrote: > > ]That > > means that any representable number actually has to indicate a range > > of values centered on that value. > > That's not always true -- it depends on the source of the &g

Re: [Python-Dev] Change in Python 3's "round" behavior

On Mon, Oct 1, 2018 at 9:36 AM Steven D'Aprano wrote: > Then we can add a keyword only argument to round: > > round(number, ndigits=0, *, mode=ROUND_HALF_EVEN) > > To use it, you can import the rounding mode you want from math: > > from math import ROUND_CEILING > round(x, 3, mode=ROUN

<    1   2   3   4   5   6   7   8   9   10   >