Re: [Python-ideas] Looking for input to help with the pip situation

Hi everyone, I just discovered this thread and thought I this is a good chance I do some advertisement. I was helping a friend doing Python tutorial and face a somewhat similar situation with beginners using Windows. It is not particularly difficult to teach them to use py, but with the vast ma

Re: [Python-ideas] Proposal: allow length_hint to specify infinite iterators

29.11.17 03:34, Steven D'Aprano пише: This wastes the opportunity to fail fast on operations which cannot possibly succeed, e.g. list(count()) must eventually fail with MemoryError. Or worse: if the OS starts thrashing trying to meet the memory requests, you can lock up the computer. I propose t

Re: [Python-ideas] [Python-Dev] What's the status of PEP 505: None-aware operators?

29.11.17 08:08, Steven D'Aprano пише: Perl is hardly the only language with null-coalescing operators -- we might better describe ?? as being familiar to C#, PHP, Swift and Dart. That's two mature, well-known languages and two up-and-coming languages. What is the syntax of the ternary operator

Re: [Python-ideas] [Python-Dev] What's the status of PEP 505: None-aware operators?

Strong -1 still from me. Too special case for syntax. Just write a function 'first_non_none()' that can perfectly will handle the need. On Nov 28, 2017 10:09 PM, "Steven D'Aprano" wrote: > On Tue, Nov 28, 2017 at 12:31:06PM -0800, Raymond Hettinger wrote: > > > > > I also cc python-dev to see if

Re: [Python-ideas] [Python-Dev] What's the status of PEP 505: None-aware operators?

On Tue, Nov 28, 2017 at 12:31:06PM -0800, Raymond Hettinger wrote: > > > I also cc python-dev to see if anybody here is strongly in favor or against > > this inclusion. > > Put me down for a strong -1. The proposal would occasionally save a > few keystokes but comes at the expense of giving Py

Re: [Python-ideas] Logging Levels

On 29 November 2017 at 06:46, Mike Miller wrote: > Hi, the reason I use note is that I want it to be output by default. So it > must be above warning, or perhaps the default level changed. If the message to be displayed is part of the actual UX of a command line tool, our advice is "You don't wa

Re: [Python-ideas] Repurpose `assert' into a general-purpose check

On 29 November 2017 at 02:03, Ivan Pozdeev via Python-ideas wrote: > On 28.11.2017 16:36, Nick Coghlan wrote: >> I'll make the same observation I usually do each time one of these >> threads comes up: >> >> * I'm opposed to making assert substantially different from the way it >> works now >> * I'

Re: [Python-ideas] generator vs iterator etc. (was: How assignment should work with generators?)

On Tue, Nov 28, 2017 at 04:25:23PM +, Rob Cliffe wrote: > Given that we have this kind of arcane discussion fairly regularly (not > just in this thread), and it always makes my head spin, and it seems I'm > not the only one who gets confused: > > How about having a module that provides func

[Python-ideas] Proposal: allow length_hint to specify infinite iterators

PEP 424 allows iterators to optionally offer a hint as to how long they will be: https://www.python.org/dev/peps/pep-0424/ Unfortunately, there's no good way for an iterator to report that it is infinitely long. Consequently, even those which are known to be infinite report finite lengths: p

Re: [Python-ideas] How assignment should work with generators?

On Tue, Nov 28, 2017 at 06:46:18PM +, Alon Snir wrote: > I would like to mention that the issue of assignment to a target list, > is also relevant to the case of elementwise assignment to a mutable > sequence (e.g. lists and arrays). Here as well, the rhs of the > assignment statement state

Re: [Python-ideas] Logging Levels

I think the resistance to trace is that it splits an existing level into two, supporting "level inflation." The current level name of critical is similar, describing not just an error, but a really big error! Note (as described here), handles an additional use case. I don't consider it leve

Re: [Python-ideas] Logging Levels

Hi, the reason I use note is that I want it to be output by default. So it must be above warning, or perhaps the default level changed. (i.e. There is no need for note if it has the same effect as info. We already have info.) -Mike On 2017-11-28 12:31, Guido van Rossum wrote: OK, that's a

Re: [Python-ideas] Repurpose `assert' into a general-purpose check

28.11.17 15:36, Nick Coghlan пише: * I'm opposed to making assert substantially different from the way it works now If sometimes we will change assert I would prefer to make it more similar to assert in pytest. Output values of the final and intermediate expressions. The hardest problem -- th

Re: [Python-ideas] Logging Levels

On Tue, Nov 28, 2017 at 12:17 PM, Serhiy Storchaka wrote: > 28.11.17 21:45, Guido van Rossum пише: > >> These look like good improvements. I think you should make an issue on >> bugs.python.org describing your proposal and if >> you can submit a PR that implements it. >>

Re: [Python-ideas] Logging Levels

28.11.17 21:45, Guido van Rossum пише: These look like good improvements. I think you should make an issue on bugs.python.org describing your proposal and if you can submit a PR that implements it. See https://bugs.python.org/issue31732 It was discussed and rejected.

Re: [Python-ideas] How assignment should work with generators?

2017-11-28 22:50 GMT+03:00 Guido van Rossum : > On Tue, Nov 28, 2017 at 11:44 AM, Kirill Balunov > wrote: > >> Although I have never used Python 2, the idea to distinguish fixed-sized >> and something lazy, even for Python 4, reminds me of the transition from >> str-unicode to the present state o

Re: [Python-ideas] Logging Levels

Thanks, will do, after some time for folks to comment further. One question was how will the level integer id affect custom levels defined by applications? If a clash could cause an issue, perhaps adding it above the last one at 100(?) makes more sense. -Mike On 2017-11-28 11:45, Guido van

Re: [Python-ideas] Logging Levels

Yep, I personally prefer fatal so I'd be totally in for it. But as you said I can see an issue on the tools that work around the logs produced (typical alerting/monitoring around an app) and all the logs parsing stacks. On 28 November 2017 at 19:59, Guido van Rossum wrote: > On Tue, Nov 28, 2017

Re: [Python-ideas] Logging Levels

On Tue, Nov 28, 2017 at 11:56 AM, Mike Miller wrote: > Yes, I remember now. However, it still outputs with the level name of > critical: > > >>> logging.fatal('hello') > > CRITICAL:root:hello > Ah, that makes it slightly more complicated -- changing that to print FATAL is surely going to break

Re: [Python-ideas] Logging Levels

On Tue, Nov 28, 2017 at 11:52 AM, Mario Corchero wrote: > Not sure if that is what you meant, but here is already "FATAL" which is > indeed an alias of CRITICAL: > > >>> logging.FATAL > 50 > >>> logging.fatal > > Maybe it should just go the other way around, making critical an alias for fatal,

Re: [Python-ideas] Logging Levels

Yes, I remember now. However, it still outputs with the level name of critical: >>> logging.fatal('hello') CRITICAL:root:hello On 2017-11-28 11:52, Mario Corchero wrote: Not sure if that is what you meant, but here is already "FATAL" which is indeed an alias of CRITICAL: >>> logging.FATA

Re: [Python-ideas] Logging Levels

Not sure if that is what you meant, but here is already "FATAL" which is indeed an alias of CRITICAL: >>> logging.FATAL 50 >>> logging.fatal On 28 November 2017 at 19:45, Guido van Rossum wrote: > These look like good improvements. I think you should make an issue on > bugs.python.org describi

Re: [Python-ideas] How assignment should work with generators?

On Tue, Nov 28, 2017 at 11:44 AM, Kirill Balunov wrote: > Although I have never used Python 2, the idea to distinguish fixed-sized > and something lazy, even for Python 4, reminds me of the transition from > str-unicode to the present state of affairs, but with much higher impact.To > be honest,

Re: [Python-ideas] How assignment should work with generators?

On 28/11/17 18:46, Alon Snir wrote: I would like to mention that the issue of assignment to a target list, is also relevant to the case of elementwise assignment to a mutable sequence (e.g. lists and arrays). Here as well, the rhs of the assignment statement states the number of elements to be

Re: [Python-ideas] Logging Levels

These look like good improvements. I think you should make an issue on bugs.python.org describing your proposal and if you can submit a PR that implements it. On Tue, Nov 28, 2017 at 11:25 AM, Mike Miller wrote: > Hi, > > I use the logging module extensively for even the simplest scripts, one of

Re: [Python-ideas] How assignment should work with generators?

2017-11-28 10:06 GMT+03:00 C Anthony Risinger : > > If not already considered, what if the RHS had to be explicitly unpacked? > > Something like: > > a, b, c = *iterator > > Which would essentially be: > > a, b, c = (*iterator,) > > This enables lazy assignment by default but `*` can force complet

[Python-ideas] Logging Levels

Hi, I use the logging module extensively for even the simplest scripts, one of the reasons there's been less difficulty moving to Python 3 at work. One of the "nano features" I've often added to its config is the addition of a custom log level. Never mentioned it before because of its trivia

Re: [Python-ideas] How assignment should work with generators?

On Wed, Nov 29, 2017 at 5:46 AM, Alon Snir wrote: > I would like to mention that the issue of assignment to a target list, is > also relevant to the case of elementwise assignment to a mutable sequence > (e.g. lists and arrays). Here as well, the rhs of the assignment statement > states the num

Re: [Python-ideas] How assignment should work with generators?

I would like to mention that the issue of assignment to a target list, is also relevant to the case of elementwise assignment to a mutable sequence (e.g. lists and arrays). Here as well, the rhs of the assignment statement states the number of elements to be assigned. Consequently, the following

Re: [Python-ideas] raise in lambda

On Wed, Nov 29, 2017 at 6:03 AM, Soni L. wrote: > Would be useful to pass exception-raising lambdas around. > > ensure(cond, lambda: raise TypeError()) > > I guess one could instead use (and raise in ensure()) > > ensure(cond, lambda: TypeError()) > > But I think exception-raising lambdas would be

[Python-ideas] raise in lambda

Would be useful to pass exception-raising lambdas around. ensure(cond, lambda: raise TypeError()) I guess one could instead use (and raise in ensure()) ensure(cond, lambda: TypeError()) But I think exception-raising lambdas would be nicer. ___ Python

Re: [Python-ideas] Repurpose `assert' into a general-purpose check

On 2017-11-28 04:27 PM, Ivan Pozdeev via Python-ideas wrote: On 28.11.2017 20:23, Ethan Furman wrote On 11/28/2017 08:03 AM, Ivan Pozdeev via Python-ideas wrote: On 28.11.2017 16:36, Nick Coghlan wrote:    it doesn't need to be a statement any more > Another benefit of a statement vs fun

Re: [Python-ideas] Repurpose `assert' into a general-purpose check

On 28.11.2017 20:23, Ethan Furman wrote On 11/28/2017 08:03 AM, Ivan Pozdeev via Python-ideas wrote: On 28.11.2017 16:36, Nick Coghlan wrote:    it doesn't need to be a statement any more > Another benefit of a statement vs function is only evaluating the error-related arguments when there

Re: [Python-ideas] Repurpose `assert' into a general-purpose check

On 11/28/2017 08:03 AM, Ivan Pozdeev via Python-ideas wrote: On 28.11.2017 16:36, Nick Coghlan wrote: it doesn't need to be a statement any more > Another benefit of a statement vs function is only evaluating the error-related arguments when there's an error The bulk of any processing

Re: [Python-ideas] generator vs iterator etc. (was: How assignment should work with generators?)

Given that we have this kind of arcane discussion fairly regularly (not just in this thread), and it always makes my head spin, and it seems I'm not the only one who gets confused: How about having a module that provides functions such as     isgenerator  isiterator  isiterable  etc. or alter

Re: [Python-ideas] Repurpose `assert' into a general-purpose check

On Tue, Nov 28, 2017 at 10:11:46AM +0300, Ivan Pozdeev via Python-ideas wrote: > I invite you to show me a single use case for those "assertions" because > after ~20 years of experience in coding (that included fairly large > projects), I've yet to see one. I already mentioned not one but multi

Re: [Python-ideas] Repurpose `assert' into a general-purpose check

On Tue, Nov 28, 2017 at 6:08 PM Ivan Pozdeev via Python-ideas < python-ideas@python.org> wrote: > On 28.11.2017 16:36, Nick Coghlan wrote: > > > On 28 November 2017 at 15:41, Steven D'Aprano > wrote: > >> On Tue, Nov 28, 2017 at 05:12:36AM +0300, Ivan Pozdeev via Python-ideas > wrote: > >>> Unlik

Re: [Python-ideas] Repurpose `assert' into a general-purpose check

On 28.11.2017 16:36, Nick Coghlan wrote: On 28 November 2017 at 15:41, Steven D'Aprano wrote: On Tue, Nov 28, 2017 at 05:12:36AM +0300, Ivan Pozdeev via Python-ideas wrote: Unlike C, Python does the aforementioned checks all the time, i.e. it's effectively always in "debug mode". Apart from

Re: [Python-ideas] Repurpose `assert' into a general-purpose check

I've used Python for 20 years, and programming in general for about 40 now. I think almost EVERY large code base I've seen used asserts in their intended way. I frequently use them myself in a way differentiated (subtly) from 'if cond: raise SomeException'. I honestly don't know how Ivan has avoid

Re: [Python-ideas] Repurpose `assert' into a general-purpose check

On 11/28/2017 03:30 AM, Steven D'Aprano wrote: On Tue, Nov 28, 2017 at 05:54:12PM +0900, Stephen J. Turnbull wrote: I understand the point made elsewhere about scientists' thinking about "assert", but as a scientist myself, I disagree. It is very useful to me to distinguish between validating

Re: [Python-ideas] Repurpose `assert' into a general-purpose check

On 2017-11-28 11:36 AM, Nick Coghlan wrote: On 28 November 2017 at 15:41, Steven D'Aprano wrote: On Tue, Nov 28, 2017 at 05:12:36AM +0300, Ivan Pozdeev via Python-ideas wrote: Unlike C, Python does the aforementioned checks all the time, i.e. it's effectively always in "debug mode". Apart f

Re: [Python-ideas] Repurpose `assert' into a general-purpose check

On 28 November 2017 at 13:36, Nick Coghlan wrote: > On 28 November 2017 at 15:41, Steven D'Aprano wrote: >> On Tue, Nov 28, 2017 at 05:12:36AM +0300, Ivan Pozdeev via Python-ideas >> wrote: >>> Unlike C, Python does the aforementioned checks all the time, i.e. it's >>> effectively always in "deb

Re: [Python-ideas] Repurpose `assert' into a general-purpose check

On 28 November 2017 at 15:41, Steven D'Aprano wrote: > On Tue, Nov 28, 2017 at 05:12:36AM +0300, Ivan Pozdeev via Python-ideas wrote: >> Unlike C, Python does the aforementioned checks all the time, i.e. it's >> effectively always in "debug mode". > > Apart from -O which disables assertions. But i

Re: [Python-ideas] Using an appropriate tone in emails (was: Adding a thin wrapper class around the functions in stdlib.heapq)

On 28 November 2017 at 13:22, bunslow wrote: > My first submission to this list was predicated on what I'd read in PEPs -- > and many of those, since they recommend major-enough changes to require a > PEP, have sections (often lengthy) dedicated to "what's wrong with the > status quo". My attempt

Re: [Python-ideas] generator vs iterator etc. (was: How assignment should work with generators?)

On 28 November 2017 at 16:11, Stephen J. Turnbull wrote: > Steven D'Aprano writes: > > > The subset of iterators which are created as generators are *also* > > called generators, > > As long as we're being precise, I don't think that is precisely correct: > > >>> (x for x in range(1)) >

Re: [Python-ideas] Repurpose `assert' into a general-purpose check

On Tue, Nov 28, 2017 at 05:54:12PM +0900, Stephen J. Turnbull wrote: > I understand the point made elsewhere about scientists' thinking about > "assert", but as a scientist myself, I disagree. It is very useful to > me to distinguish between validating data and validating algorithms. > "assert" i

[Python-ideas] Repurpose `assert' into a general-purpose check

Ivan Pozdeev via Python-ideas writes: > The `assert' statment was created the same as in previous languages like > C/C++: a check to only do in debug mode, when you can't yet trust your > code to manage and pass around internal data correctly. Examples are > array bounds and object state in

[Python-ideas] Advocating your ideas [was: Using an appropriate tone in emails]

This discussion started on Python-Ideas (q.v.), and is also somewhat applicable to Python-Dev. I think further discussion belongs on Core-Mentorship, though. Cc'd and reply-to set. bunslow writes: > My first submission to this list was predicated on what I'd read in > PEPs -- and many of thos

Re: [Python-ideas] Repurpose `assert' into a general-purpose check

On 28.11.2017 03:28, Ivan Pozdeev via Python-ideas wrote: > On 28.11.2017 5:19, Chris Angelico wrote: > >> Actually, Python does have a way of disabling assertions (the -O >> flag), so they should be treated the same way they are in C. >> Assertions should not be used as shorthands for "if cond: r

Re: [Python-ideas] Using an appropriate tone in emails (was: Adding a thin wrapper class around the functions in stdlib.heapq)

I certainly didn't take away the right lesson! And lesson well learned, hopefully. On Tue, Nov 28, 2017 at 12:55 AM, Nathaniel Smith wrote: > On Mon, Nov 27, 2017 at 7:22 PM, bunslow wrote: > > My first submission to this list was predicated on what I'd read in PEPs > -- > > and many of those,

Re: [Python-ideas] Repurpose `assert' into a general-purpose check

On 28.11.2017 10:22, Elazar wrote: Just a note : in typechecked code (such as mypy's source code) assert is used to guide the checker: assert isinstance(x, CallableType) return x.args  # checker knows it's valid So the assert becomes a kind of type annotation. The runtime check helps during