Re: [Python-ideas] Null coalescing operator

On 10/15/16, Nick Coghlan wrote: > * None-coalescing operator: x ?or y > * None-severing operator: x ?and y > * None-coalescing augmented assignment: x ?= y > * None-severing attribute access: x?.attr > * None-severing subscript lookup: x?[expr] Please don't be too harsh to me for my next words!

Re: [Python-ideas] Null coalescing operator

On 10/31/16, Guido van Rossum wrote: > For "everything to the right" it would seem we have some freedom: e.g. if > we have "foo.bar?.baz(bletch)" is the call included? The answer is yes -- > the concept we're after here is named "trailer" in the Grammar file in the > source code ( > https://githu

Re: [Python-ideas] PEP 532: A circuit breaking operator and protocol

On 11/12/16, Mark E. Haase wrote: > 1. It is easier to Google a name. E.g., Google "c# ??" and you'll get > nothing related to null coalescing in c#". ("C# question marks" does find > the right content, however.) python has nice (*) help system and would have help('??')... (where we could get be

Re: [Python-ideas] How to respond to trolling

On 1/11/17, Steven D'Aprano wrote: > On Tue, Jan 10, 2017 at 07:29:12AM -0800, Guido van Rossum wrote: >> Was it really necessary for all the usual folks on this list to engage >> with >> the "Python review" threads? I think a much more effective response would >> have been a resounding silence. >

Re: [Python-ideas] Things that won't change (proposed PEP)

On 1/12/17, Steven D'Aprano wrote: > This shouldn't need saying, but Python 3 will not be abandoned. Except Python 4 would come. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduc

Re: [Python-ideas] Things that won't change (proposed PEP)

On 1/12/17, Todd wrote: > 5. "and" and "or" are short-circuiting operations that return one of the > two values given. They will never be non-short-circuiting and they will > never coerce returned values to boolean. This one bring question how deep this PEP could be because we could show what

Re: [Python-ideas] Python dependancies

On 1/15/17, Steven D'Aprano wrote: > On Sun, Jan 15, 2017 at 12:24:29AM -0500, Mathieu TORTUYAUX wrote: >> And each time Python project is run developer will be aware if >> dependancies >> are up to date. > > That would be awful. It would be pure noise. If I'm running an old > version of somethin

Re: [Python-ideas] Is it Python 3 yet?

On 2/7/17, Mike Miller wrote: > Hmm, agreed. BTW, I think the current download page is *way* too > complicated > for new comers. > > There should be a giant button for the latest 3.x/64 (platform sniffed), > and below it a more subtle button for the "LTS" 2.X/32. I am afraid that "LTS" could con

Re: [Python-ideas] More classical for-loop

On 2/17/17, Mikhail V wrote: > Rationale > --- > > Removing the brackets will help concentrate on other > parts of code [...] Do you think that for i in steps * 10: for i in steps * 1-10: for i in steps * 1-10 ^ 2: are better than for i in range(10):

Re: [Python-ideas] Delayed Execution via Keyword

On 2/17/17, Chris Angelico wrote: > Do delayed-expressions have identities or only values? For example: > > rand = delayed: random.randrange(10) > otherrand = rand > assert rand is otherrand # legal? > randid = id(rand) # legal? > print(rand) # force to concrete value > assert any(rand is x for x

Re: [Python-ideas] Delayed Execution via Keyword

On 2/18/17, Steven D'Aprano wrote: Sorry Steve that I use your words probably too much out of context! I just want to reuse your examples to analyze if proposed "delayed execution" is really necessary. Thanks for them! :) > print("Start") > result = delayed: get_nth_prime(10**6) # I dislike th

Re: [Python-ideas] String Format Callable Flag (Was: Efficient Debug Logging)

On 2/19/17, Eric V. Smith wrote: > On 2/18/2017 2:25 AM, Steven D'Aprano wrote: >> I see three problems: >> >> (1) It will be a bug magnet. People will accidently write >> >> logging.debug('%03d %C03d', 1, expensive()) >> >> >> and then not only will their code still be slow, but they'll have

Re: [Python-ideas] Delayed Execution via Keyword

On 2/19/17, David Mertz wrote: > On Sun, Feb 19, 2017 at 10:13 AM, Joseph Hackman > wrote: >> >> My honest preference would be that the [] is evaluated fresh each time >> the >> function is called. >> def stuff(arg=delayed f()): >> would result in f() being called every time stuff() is. This seem

Re: [Python-ideas] Delayed Execution via Keyword

On 2/19/17, Michel Desmoulin wrote: > Evnetually we also may need to allow this: > > a = lazy stuff > if a is not lazy: > print(a) > > But then lazy can't be used a var name to help with the transition. What about this? if not inspect.islazy(a): print(a) Next idea is probably obvious:

Re: [Python-ideas] add __contains__ into the "type" object

On 3/1/17, Steven D'Aprano wrote: > On Wed, Mar 01, 2017 at 07:02:23AM +0800, 语言破碎处 wrote: >> >> where we use types? >> almost: >> isinstance(obj, T); >> # issubclass(S, T); >> >> Note that TYPE is SET; > > What does that mean? I don't understand. Maybe she/he wants to say tha

Re: [Python-ideas] for/except/else

On 3/1/17, Wolfgang Maier wrote: > - as explained by Nick, the existence of "except break" would strengthen > the analogy with try/except/else and help people understand what the > existing else clause after a loop is good for. I was thinking bout this analogy: 1. try/else (without except) is S

Re: [Python-ideas] add __contains__ into the "type" object

On 3/2/17, Stephan Houben wrote: > A crucial difference between a set and a type is that you cannot > explicitly iterate over the elements of a type, so while we could implement > > x in int > > to do something useful, we cannot make > > for x in int: >print(x) > > Because if we could, we coul

Re: [Python-ideas] Exploiting type-homogeneity in list.sort() (again!)

On 3/6/17, Tim Peters wrote: > One subtle thing to look at: thread safety. One other subtle: Is it gilectomy neutral? ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://p

Re: [Python-ideas] Proposal: Query language extension to Python (PythonQL)

On 3/27/17, Chris Angelico wrote: > On Mon, Mar 27, 2017 at 12:26 PM, Terry Reedy wrote: >> It might be possible (or not!) to make the clause-heading words like >> 'where' >> or 'groupby' (this would have to be one word) recognized as special only >> in >> the context of starting a new comprehens

Re: [Python-ideas] Way to repeat other than "for _ in range(x)"

On 3/30/17, Nick Coghlan wrote: > On 30 March 2017 at 19:18, Markus Meskanen > wrote: >> Hi Pythonistas, >> >> yet again today I ended up writing: >> >> d = [[0] * 5 for _ in range(10)] d = [[0]*5]*10 # what about this? >> And wondered, why don't we have a way to repeat other than looping

Re: [Python-ideas] Way to repeat other than "for _ in range(x)"

On 3/30/17, Nick Coghlan wrote: > On 31 March 2017 at 00:23, Pavol Lisy wrote: >> Just for curiosity - if PEP-501 will be accepted then how many times >> could be fnc called in next code? >> >> eval(i'{fnc()}, ' *3) > > Once (the same as f-stri

Re: [Python-ideas] Way to repeat other than "for _ in range(x)"

On 3/30/17, Joshua Morton wrote: >def repeat_for(func, iters): > return func() for _ in range(iters) > > does what you want without any required syntax changes. I've got a "SyntaxError: invalid syntax" PL. ___ Python-ideas mailing list Pyt

Re: [Python-ideas] Way to repeat other than "for _ in range(x)"

On 3/31/17, Steven D'Aprano wrote: > On Thu, Mar 30, 2017 at 04:23:05PM +0200, Pavol Lisy wrote: >> On 3/30/17, Nick Coghlan wrote: >> > On 30 March 2017 at 19:18, Markus Meskanen >> > wrote: >> >> Hi Pythonistas, >> >> >> >> y

Re: [Python-ideas] Construct a matrix from a list: matrix multiplication

On 4/1/17, Franklin? Lee wrote: > On Fri, Mar 31, 2017 at 3:58 AM, Chris Angelico wrote: >> This keeps on coming up in one form or another - either someone >> multiplies a list of lists and ends up surprised that they're all the >> same, or is frustrated with the verbosity of the alternatives. >

Re: [Python-ideas] Tighten up the formal grammar and parsing a bit?

Something broken like this? import inspect def cond(): if 'not cond' in inspect.stack()[1].code_context[0]: return False return True if cond(): print('yes') else: print('no') if not cond(): print('no') else: print('yes') On 5/15/17, Ryan Gonzalez wrote: > I gues

Re: [Python-ideas] fnmatch.filter_false

On 5/20/17, Steven D'Aprano wrote: > On Wed, May 17, 2017 at 12:14:05PM -0400, Alex Walters wrote: >> Fnmath.filter works great. To remind people what it does, it takes an >> iterable of strings and a pattern and returns a list of the strings that >> match the pattern. And that is wonderful >> >

Re: [Python-ideas] fnmatch.filter_false

On 5/21/17, Steven D'Aprano wrote: > On Sun, May 21, 2017 at 08:04:04AM +0200, Pavol Lisy wrote: > >> If fnmatch.filter was written to solve performance, isn't calling >> _filtered step back? > > It adds overhead of *one* function call regardless of how many &g

Re: [Python-ideas] π = math.pi

Sorry for probably stupid question! Is something like -> class A: def __oper__(self, '⊞', other): return something(self.value, other) a = A() a ⊞ 3 thinkable? On 6/3/17, Guido van Rossum wrote: > OK, I think this discussion is pretty much dead then. We definitel

Re: [Python-ideas] π = math.pi

On 6/1/17, Serhiy Storchaka wrote: > What you are think about adding Unicode aliases for some mathematic > names in the math module? ;-) > > math.π = math.pi > math.τ = math.tau > math.Γ = math.gamma > math.ℯ = math.e > > Unfortunately we can't use ∞, ∑ and √ as identifiers. :-( My humble opinion

Re: [Python-ideas] π = math.pi

On 6/3/17, Chris Angelico wrote: > On Sat, Jun 3, 2017 at 3:42 PM, Pavol Lisy wrote: >> Sorry for probably stupid question! Is something like -> >> >> class A: >> def __oper__(self, '⊞', other): >> return something(sel

Re: [Python-ideas] Security: remove "." from sys.path?

On 6/5/17, Chris Barker wrote: > On Mon, Jun 5, 2017 at 3:55 AM, Victor Stinner > wrote: > >> A minimum change would be to add the (empty string) at the end of >> sys.path >> in Python 3.7 rather than adding it at the start. >> >> It would increase Python usability since it avoids the "random has

Re: [Python-ideas] Idea : for smarter assignment?

On 7/25/17, MRAB wrote: > On 2017-07-25 18:02, Nick Timkovich wrote: >> On Fri, Jul 21, 2017 at 12:59 PM, David Mertz > > wrote: >> >> But you've left out quite a few binding operations. I might forget >> some, but here are several: >> >> >> Ned Batchelder had a go

Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple]

On 7/26/17, Steven D'Aprano wrote: [...] > But this has a hidden landmine. If *any* module happens to use ntuple > with the same field names as you, but in a different order, you will > have mysterious bugs: > > x, y, z = spam > > You expect x=2, y=1, z=0 because that's the way you defined the f

Re: [Python-ideas] PEP draft: context variables

On 9/4/17, Koos Zevenhoven wrote: > Core concept > > > A context-local variable is represented by a single instance of > ``contextvars.Var``, say ``cvar``. Any code that has access to the ``cvar`` > object can ask for its value with respect to the current context. In the > high-level

[Python-ideas] Fwd: A PEP to define basical metric which allows to guarantee minimal code quality

On 9/20/17, alexandre.gal...@gmail.com wrote: [...] > But i think, as wee need to avoid to talk about any tool name in the PEP, > we need to avoid to give a code example. The aim of this proposal is to > have a guideline on minimal metrics to have minimal quality. Michel Foucault wrote book (ht

Re: [Python-ideas] SI scale factors in Python

On 8/25/16, Ken Kundert wrote: [...] > Just allowing the units to be present, even it not > > retained, is a big advantage because it can bring a great deal of clarity to > the > meaning of the number. For example, even if the language does not flag an > error > when a user writes: > > vdiff

Re: [Python-ideas] SI scale factors alone, without units or dimensional analysis

On 8/26/16, Steven D'Aprano wrote: [...] > from scaling import * > int_value = 8*M > float_value = 8.0*M > fraction_value = Fraction(1, 8)*M > decimal_value = Decimal("1.2345")*M [...] > Disadvantages: none I can think of. Really interesting idea, but from my POV a little disadvantage is "import