[Python-ideas] Keyword only argument on function call

s). The results show that ~30% of all arguments would benefit from this syntax. Me and my colleague Johan Lübcke have also written an implementation that is available at: https://github.com/boxed/cpython / Anders Hovmöller ___ Python-ideas mailing li

Re: [Python-ideas] Keyword only argument on function call

On Thursday, September 6, 2018 at 3:11:46 PM UTC+2, Steven D'Aprano wrote: > > On Thu, Sep 06, 2018 at 12:15:46PM +0200, Anders Hovmöller wrote: > > > I have a working implementation for a new syntax which would make > > using keyword arguments a lot nicer. Wouldn&

Re: [Python-ideas] Keyword only argument on function call

On Thursday, September 6, 2018 at 4:13:45 PM UTC+2, David Mertz wrote: > > Steven's point is the same as my impression. It's not terribly uncommon in > code I write or read to use the same name for a formal parameter (whether > keyword or positional) in the calling scope. But it's also far fro

Re: [Python-ideas] Keyword only argument on function call

> > > For comparison, my reaction did indeed involve awe. It was full of it, > in fact :-p Sorry, but that syntax looks at best highly misleading -- > how many parameters are we passing? I don't like it at all. > (nitpick: we're passing arguments, not parameters) I don't see how this could

Re: [Python-ideas] Keyword only argument on function call

On Thursday, September 6, 2018 at 6:51:12 PM UTC+2, Ethan Furman wrote: > > On 09/06/2018 07:05 AM, Anders Hovmöller wrote: > > On Thursday, September 6, 2018 at 3:11:46 PM UTC+2, Steven D'Aprano > wrote: > >> On Thu, Sep 06, 2018 at 12:15:46PM +0200, Anders Hovmöll

Re: [Python-ideas] Keyword only argument on function call

> For calling, we can use > https://docs.python.org/3/library/functions.html#locals > > >>> lcls = locals() > > >>> a = 'apple' > >>> b = 'banana' > >>> c = 'cherry' > > >>> dict((k, lcls[k]) for k in ('a', 'b', 'c')) > {'b': 'banana', 'c': 'cherry', 'a'

Re: [Python-ideas] Keyword only argument on function call

> Maybe something like this would be better: > > f(=a, =b, =c) > Haha. Look at my PEP, it's under "rejected alternative syntax", because of the super angry replies I got on this very mailing list when I suggested this syntax a few years ago :P I think that syntax is pretty nice persona

Re: [Python-ideas] Positional-only parameters

I think it makes more sense to remove the concept of positional only parameters by slowly fixing the standard library. I've discussed the existence of positional only with a few people and their response falls in to some basic categories: - disgust - disbelief - bargaining (it's not very common

Re: [Python-ideas] Keyword only argument on function call

> I must say I like the idea of being able to write it the way you propose. > Sometimes we make a function only to be called once at a specific location, > more because of factoring out some functions for clarity. Been doing that > myself lately for scripting, and I think it'd increase clarity

Re: [Python-ideas] Python dialect that compiles into python

Many features on this list propose different syntax to python, producing > different python "dialects" that can statically be transformed to python : > > - a,b += f(x) → _t = f(x); a += _t; b += _t; (augmented assignement > unpacking) > - a = 2x + 1 → a = 2*x + 1 (juxtaposition is product) >

Re: [Python-ideas] Keyword only argument on function call

> > I counted commas. I came up with the wrong number. Simple. > > For what it's worth, I don't like the keyword-only marker or the > proposed positional-only marker for exactly the same reason. > There's also potentially trailing commas to confuse you further :P I'm not a big fan of the key

Re: [Python-ideas] Keyword only argument on function call

Do you want to change my PEP suggestion to be about forcing stuff? Because otherwise I don’t see why you keep being that up. We’ve explained to you two times (three counting the original mail) that no one is saying anything about forcing anything. ___

Re: [Python-ideas] Keyword only argument on function call

> *At* two arguments? As in this example? > >map(len, sequence) > > > I'll admit that I struggle to remember the calling order of list.insert, > I never know which of these I ought to write: > >mylist.insert(0, 1) >mylist.insert(1, 0) > > but *in general* I don't think two posit

Re: [Python-ideas] Improving fn(arg=arg, name=name, wibble=wibble) code

p() >cb = partial(sync_open, file, mode=mode, buffering=buffering, > encoding=encoding, errors=errors, newline=newline, > closefd=closefd, opener=opener) >f = yield from loop.run_in_executor(executor, cb) > >return wrap(f, loop=loop, executor=

Re: [Python-ideas] Keyword only argument on function call

> To me, the "30% of all arguments" deserves more careful examination. > Does the proposal significant improve the reading and writing of this > code? And are there other, perhaps better, ways of improving this > code? Maybe my tool should be expanded to produce more nuanced data? Like how many of

Re: [Python-ideas] Keyword only argument on function call

> A finer grained analysis tool would be helpful. I'm -0 on the idea because I > believe it would discourage more expressive names in calling contexts in > order to enable the proposed syntax. But I also see a big difference between > cases where all keywords match calling names and cases wher

Re: [Python-ideas] Improving fn(arg=arg, name=name, wibble=wibble) code

>get_permissions(item, request, obj) > > and then simply write > >** get_permissions(item, request, obj) > > in the function call, to pass the permissions to the called function. > By the way, for ease of use this is relying on > >https://www.python.org/dev/peps/pep-0448/ # Addit

Re: [Python-ideas] Keyword only argument on function call

> You have carefully avoided explicitly accusing me of making a straw man > argument while nevertheless making a completely irrelevant mention of > it, associating me with the fallacy. I read that as him accusing you very directly. > That is not part of an honest or open discussion. > > Ande

Re: [Python-ideas] Keyword only argument on function call

> I see it all the time in JavaScript, where ES2015 introduced a new > syntax {name} equivalent to {"name":name} - people will deliberately > change their variable names to match the desired object keys. So > saying "forcing" is an exaggeration, but a very slight one. Do you have an opinion or f

Re: [Python-ideas] Keyword only argument on function call

I just realized I have another question for you: If you had to chose which one would you prefer: f(*, a b, c) or: f(=a, =b, =c) ? I know you’re clearly against the entire idea but it seems we should prefer the least disliked alternative in such a scenario. __

Re: [Python-ideas] Keyword only argument on function call

> On 8 Sep 2018, at 14:23, Anders Hovmöller wrote: > >> To me, the "30% of all arguments" deserves more careful examination. >> Does the proposal significant improve the reading and writing of this >> code? And are there other, perhaps better, ways of improvin

Re: [Python-ideas] PTPython REPL in IDLE

>> Have y’all seen ptpython’s autocomplete and syntax highlighting >> features? > > No. Do you have a link? What specific features have excited you? IPython autocomplete is now powered by ptpython and Jedi. So if you’ve used it recently you’re already familiar with it. In the context of ID

Re: [Python-ideas] Improving fn(arg=arg, name=name, wibble=wibble) code

> Summary: Michael Selik has produced a nice refactoring of an example. > I suggest further refactoring, to create a function decorator that > does the job. This might be useful if the example is an instance of a > common use pattern. It seems to me this discussion has drifted away from the orig

Re: [Python-ideas] Retire or reword the "Beautiful is better than ugly" Zen clause

> If I were to change anything, I'd drop the reference to "Zen". That wasn't > part of the original, and was added by someone else. If, e.g., a Zen > Buddhist objected that this use trivializes their beliefs, I'd have real > sympathy with _that_. But I'd be greatly surprised if a Zen Buddhis

Re: [Python-ideas] Improving fn(arg=arg, name=name, wibble=wibble) code

> Using keyword arguments is not painful. It's ugly in some unusual cases, such > as creating helper functions with nearly the same signature. It’s more painful than positional. To me the fact that everyone who works on code bases that are of non-trivial size see positional arguments being used

Re: [Python-ideas] Improving fn(arg=arg, name=name, wibble=wibble) code

>> I’ll repeat myself: what about .format()? If you localize you can’t use >> f-strings. What about templates in web apps? Obviously f-strings won’t do. >> What about json blobs in REST APIs? Again no help from f-strings. What about >> functions with more than 3 arguments generally? > > For f-stri

Re: [Python-ideas] Improving fn(arg=arg, name=name, wibble=wibble) code

> On 13 Sep 2018, at 21:34, Michael Selik wrote: > > On Thu, Sep 13, 2018 at 11:35 AM Anders Hovmöller <mailto:bo...@killingar.net>> wrote: >> Using keyword arguments is not painful. It's ugly in some unusual cases, >> such as creating helper funct

Re: [Python-ideas] Retire or reword the "Beautiful is better than ugly" Zen clause

> "Ugly" is very obviously a slur. It carries a dark meaning *and* it's still > being actively used towards people. Honestly, I can't imagine someone > cheering up when they see that word, especially if they're self-conscious > about their appearance or were told they were "ugly" at some point

Re: [Python-ideas] Improving fn(arg=arg, name=name, wibble=wibble) code

> On 14 Sep 2018, at 03:35, Michael Selik wrote: > > On Thu, Sep 13, 2018 at 5:34 PM Anders Hovmöller <mailto:bo...@killingar.net>> wrote: > I wrote a script so you can get a list of [good use cases] in big code bases > without looking through the code randomly. &

Re: [Python-ideas] Deprecation utilities for the warnings module

> I'd like to propose an extension for the warnings module > to address this problem. I like all of that. The only issue I have with it is that the warnings module is designed to namespace depredations so you can turn them on per library and this code doesn’t seem to handle that. We really want

Re: [Python-ideas] Improving fn(arg=arg, name=name, wibble=wibble) code

> It's a bit too large for me to make sense of it quickly. My apologies for not > offering a holistic refactor. My tool will print plenty of other examples. You can pick anyone really... > > That’s positional because keyword is more painful. > > Why would keyword arguments be more painful her

Re: [Python-ideas] Improving fn(arg=arg, name=name, wibble=wibble) code

>> In that case, you should be able to link to a compelling example. If you go >> to the trouble of finding one, I'll take time to try to refactor it. > > https://github.com/django/django/blob/master/django/db/models/sql/compiler.py#L707 > >

Re: [Python-ideas] Improving fn(arg=arg, name=name, wibble=wibble) code

> it reads fine precisely because the variables names match with the signature > of new_file(). But if new_file() is changed they won't match up anymore and > it will still read fine and look ok, but now the parameters don't line up and > it's broken in potentially very subtle ways. For example

Re: [Python-ideas] Improving fn(arg=arg, name=name, wibble=wibble) code

> Maybe our difference of opinion stems from tooling and the way others > refactor the code we work on. Maybe. Or the code we have to refactor that others have written. Or both. > I enjoy using keywords to explain the values I'm passing. If I already have a > well-named variable, I'm less ke

Re: [Python-ideas] Improving fn(arg=arg, name=name, wibble=wibble) code

> On 14 Sep 2018, at 09:26, Michael Selik wrote: > > > > On Fri, Sep 14, 2018, 12:17 AM Anders Hovmöller <mailto:bo...@killingar.net>> wrote: > > That's a bit of a dodge. There is a huge difference in verbosity between > > handler.new

Re: [Python-ideas] Improving fn(arg=arg, name=name, wibble=wibble) code

> I don't think it's off-topic. The ugliness of the line you're talking about > stems in large part from that it's in a heavily indented complex section. The > distinction between positional and keyword args in this case is superficial. Indenting 4 levels (32 spaces) is a problem, but adding a

Re: [Python-ideas] Deprecation utilities for the warnings module

> If correctly understood your concern, it's about usage of stdlib's *Warning > classes directly > that makes all warnings coming from different libraries indistinguishable. That was my concern yes. > I think that's not the case, since warnings.filterwarnings allows > to specify custom filte

Re: [Python-ideas] Retire or reword the "Beautiful is better than ugly" Zen clause

> It’s been almost a week since this “discussion” first started. Can we please > stop this in the name of productive work on python-ideas? A better use of time might be to discuss moving to a better forum system where moderation is easier/possible. Email somehow has a shape that makes those t

Re: [Python-ideas] Combine f-strings with i18n - How about using PEP 501?

>> See also PEP 501, which could be used for i18n. > > I don't see how this immediately helps the OP, who wants a *literal* > expression that automatically invokes the translation machinery as > well as the interpolation machinery. Another way forward could be a preprocessor. All this can be d

Re: [Python-ideas] Moving to another forum system where moderation is possible

> But there's no evidence that such tools would help. Software > enforcement powers are only necessary if verbal enforcement isn't > enough. We need the current moderators (or just Brett) to say whether > they feel it isn't enough. These systems work radically differently. You don’t get notificat

Re: [Python-ideas] Combine f-strings with i18n - How about using PEP 501?

> How about this: Have a script that runs over your code, looking for > "translatable f-strings": > > _(f'Hi {user}') > > and replaces them with actually-translatable strings: > > _('Hi %s') % (user,) > _('Hi {user}').format(user=user) > > Take your pick of which way you want to spell it. Eit

Re: [Python-ideas] Combine f-strings with i18n - How about using PEP 501?

>> I'd suggest using parso to do it. It's a really great library to write such >> transformations. > > Ah. It wasn't clear what your destination was, so I thought you were > talking about doing the translation itself using parso. But yeah, grab > one of these sorts of parsing libraries, do the t

Re: [Python-ideas] Moving to another forum system where

> Even so, there are mitigations to the firehose effect, including, but not > limited to digests I accidentally signed up with divest turned on for this list first. I got five digests in so many hours and I couldn’t figure out how to respond to individual threads. It’s a terrible choice and I

Re: [Python-ideas] Moving to another forum system where moderation is possible

+1 to everything James said. This otherwise pointless mail is further evidence he’s right. On 20 Sep 2018, at 17:08, James Lu wrote: >> It's absence is a big advantage. We're not a social network with >> "likes". We don't need a bunch of argumentless "voting". > > Up/ down voting indicates ho

Re: [Python-ideas] Moving to another forum system where

>> That's because completion of discussion has never been a requirement >> for writing a PEP. > > Not for drafting, but for submitting. Can you quote pep1? I think you’re wrong. In general pep1 is frustratingly vague. Terms like “community consensus” without defining community or what number

Re: [Python-ideas] Moving to another forum system where

> The firehose of python-ideas is a barrier to entry to suggesting major > changes to the language. This is a GOOD thing. Major changes need dedicated > advocates - if they are unwilling to endure the flood of mail, they are not > dedicated enough to the change, and that is an indication of h

Re: [Python-ideas] Moving to another forum system where

>>> Not for drafting, but for submitting. >> >> Can you quote pep1? I think you’re wrong. > > I can't remember if I pulled this quote previously (that's one of the > troubles with emails): "Following a discussion on python-ideas, the > proposal should be submitted as a draft PEP ..." > > Could

Re: [Python-ideas] PEPs: Theory of operation [was: Moving to another forum system ...]

> If one doesn't know who the senior developers are yet, she should think > twice about whether she's ready to PEP anything. That's not a litmus > test; some PEPs have eventually succeeded though the proponent was new > to the project development process.[2] But it's a lot less painful if > you

Re: [Python-ideas] PEPs: Theory of operation [was: Moving to another forum system ...]

>>> >>> I think that entire paragraph made it sound even worse than what I wrote >>> originally. It reads to an outsider as “if you don’t know what’s wrong I’m >>> not going to tell you”. > > More like, if you're not sufficiently familiar with the community or > the language, And now you mad

Re: [Python-ideas] Proposal for an inplace else (?=) operator

> If Python were going to address this problem, I think it better to do > something like: > > def teleport(from, to, hitchiker => Fly(), accessory => > Towel(hitchhiker)): > etc. > > Where => specifies an expression thst is evaluated inside the function and Is > approx

Re: [Python-ideas] PEPs: Theory of operation [was: Moving to another forum system ...]

>> And now you made it sound even worse by insinuating that I don’t know the >> language and maybe I’m not a part of the community. > > Anders, I'm sorry you feel that everyone is piling onto you. Well a bit, but mostly I was just pointing out that the text I replied to wasn’t thought out an

Re: [Python-ideas] PEPs: Theory of operation

>>> If one doesn't know who the senior developers are yet, she should >>> think twice about whether she's ready to PEP anything. That's >>> not a litmus test; some PEPs have eventually succeeded though the >>> proponent was new to the project development process.[2] But it's >>> a lot less pain

Re: [Python-ideas] Keyword only argument on function call

Hi, I'd like to reopen this discussion if anyone is interested. Some things have changed since I wrote my original proposal so I'll first summarize: 1. People seem to prefer the syntax `foo(=a)` over the syntax I suggested. I believe this is even more trivial to implement in CPython than my or

Re: [Python-ideas] Fwd: Keyword only argument on function call

> I'm still not sure why all this focus on new syntax or convoluted IDE > enhancements. I presented a very simple utility function that accomplishes > exactly the started goal of DRY in keyword arguments. And I’ve already stated my reasons for rejecting this specific solution, but I’ll repeat

Re: [Python-ideas] Fwd: Keyword only argument on function call

David, I saw now that I missed the biggest problem with your proposal: yet again you deliberately throw away errors. I'm talking about making Python code _less_ error prone, while you seem to want to make it _more_. Anyway, I'll modify your reach() to not have the if in it that has this error h

Re: [Python-ideas] Fwd: Keyword only argument on function call

> I saw now that I missed the biggest problem with your proposal: yet again you > deliberately throw away errors. I'm talking about making Python code _less_ > error prone, while you seem to want to make it _more_. > > Beyond the belligerent tone, is there an actual POINT here? Yes, there is

Re: [Python-ideas] Fwd: Keyword only argument on function call

> Oh, I see that you indeed implemented a macropy version at > https://github.com/boxed/macro-kwargs/blob/master/test.py > . > Other than use() vs grab() as the function name, it's the same thing. Well, except that it's import time, and

Re: [Python-ideas] Add .= as a method return value assignment operator

>>> Think about a more complex assignment: >>> >>> text .= encode(spam) + str(eggs) >> >> I think the only sane thing would be to disallow that, and >> require the RHS to have the form of a function call, which is >> always interpreted as a method of the LHS. > > > You obviously have a diff

Re: [Python-ideas] Suggestion: Extend integers to include iNaN

>> I am roughing out such a class and some test cases which will hopefully >> include some cases where the hoped for advantages can be realised. >> >> My thinking on bitwise operations is to do the same as arithmetic >> operations, i.e. (anything op iNaN) = iNaN and likewise for shift >> oper

Re: [Python-ideas] f-string "debug" conversion

> This would be used in debugging print statements, that currently end up > looking like: > > print(f'value={value!r}') > > and would now be: > > print(f'{value!d}') It seems to me that a short form for keyword arguments would improve this situation too. So instead of your suggestion one cou

Re: [Python-ideas] f-string "debug" conversion

>> debug(=value, =another) > > What if it's not a simple name, though? The OP gave this (somewhat > simplistic, but indicative) example: > > print(f'next: {value+1!d}') debug(next=value+1) Still shorter than the proposed syntax and much more readable. If you do this a lot you’d probably call

Re: [Python-ideas] f-string "debug" conversion

>> Here’s the idea: for f-strings, we add a !d conversion operator, which >> is superficially similar to !s, !r, and !a. The meaning of !d is: >> produce the text of the expression (not its value!), > > I SO WANT THIS AS A GENERAL FEATURE, not just for f-strings, it hurts. > > Actually what I

Re: [Python-ideas] f-string "debug" conversion

>> and much more readable. > > So you say. > > To me that looks like a regular function call, which calls an ordinary > function "debug" and takes a simple keyword argument next with value > "value+1". That was what it was. That was not intended to be about magic, that was the normal case w

Re: [Python-ideas] f-string "debug" conversion

>> I don't really think accidents of implementation are different from hard >> requirements in Python, as it applies to alternative implementations. In >> practice if it deviates from CPython then it's broken. There is no language >> spec, there is only CPython. This has been the experience an

Re: [Python-ideas] f-string "debug" conversion

> The present discussion thread is spreading into other areas, such as > what constitutes the Python language specification. I let myself get side tracked. This will be my last mail discussing that off topic thread. Sorry about that. > I'd like to > contribute to a broader discussion, of how w

Re: [Python-ideas] Debugging: some problems and possible solutions

TITLE: output debug information easily and quickly POSSIBLE SOLUTION Short form of keyword arguments where foo(=a, =1+bar) Is expanded at compile time to foo(**{'a': a, '1+bar': 1+bar}) Then we can just create a normal debug function: def debug_print(**vars): for k, v in vars.items():

Re: [Python-ideas] Debugging: some problems and possible solutions

>> foo(=a, =1+bar) > > Unfortunately, that won't help with Jonathan's inital example > expression "big_array[5:20]" as it's not a valid keyword. I didn't understand that. The example you are referring to is print('big_array[5:20] =', big_array[5:20]) Right? Nothing is a keyword in that exampl

Re: [Python-ideas] Debugging: some problems and possible solutions

foo(=a, =1+bar) >> >>> Unfortunately, that won't help with Jonathan's inital example >>> expression "big_array[5:20]" as it's not a valid keyword. >> >> I didn't understand that. The example you are referring to is >> print('big_array[5:20] =', big_array[5:20]) >> >> Nothing is a keyword

Re: [Python-ideas] Debugging: some problems and possible solutions

>> It's a very simple textual transformation. >> > > That is not guaranteed to work. In another thread it was pointed out > that this is merely a CPython implementation detail, NOT a language > feature. Pedantry. Ok. Let's be pedantic: it's a simple textual transformation AND a promotion of a

Re: [Python-ideas] Debugging: some problems and possible solutions

> So how about extending Python so that, for example, >{=(1 + bar), } > is equivalent to >{'1 + bar': 1 + bar, } > > The basic idea is Anders's, recast to avoid Chris's problem. Chris' problem isn't an actual problem though. Its just a few sentences in a PEP. It might be a problem for

Re: [Python-ideas] Debugging: some problems and possible solutions

>> Then I'm strongly -1 on it. Happy? :) > > And In case it's not clear why I said that, btw: It's not mere > pedantry. Good to see you understood yourself why that mail wasn't so good. > By restating your proposal in those terms, you make it far > broader than a simple textual transformatio

Re: [Python-ideas] Debugging: some problems and possible solutions

>> Imagine if I said something other totally irrelevant and that is bigger >> change indeed. But I didn't. I suggested not a change of CPython or PyPy or >> IronPython but a few sentences in a PEP. I also didn't suggest that it be >> snuck into the same PEP as my proposed syntax changes. I agr

Re: [Python-ideas] Debugging: some problems and possible solutions

> Ah, yes. Thank you. So it works in CPython 2.7. But I'm curious, does it work > in very old versions? My bet is still on. I take paypay. I will not accept python 1 let's say. It's just easier that way. If **kwargs exists they take strings. > I'm not saying that this is important, because l

Re: [Python-ideas] Better error messages for missing optional stdlib packages

>> Also, maybe add a little note in the docs, stating that despite being >> part of stdlib this module might not be available on all systems. > > That should be uncontroversial. Raise an issue on the bug tracker for > that, or a patch on Github. I believe a PR that is more complex than a spel

Re: [Python-ideas] Dictionary initialization to capture syntax and value (was Re: Debugging: some problems and possible solutions)

>>>{=(1 + bar), } >>> is equivalent to >>>{'1 + bar': 1 + bar, } > > What is so special about dicts that this only works there? > > If we're going to have syntax to capture the source (and AST) of an > expression, it ought to work everywhere. And it ought to be callable, > without hav

Re: [Python-ideas] Debugging: some problems and possible solutions

>> That is not guaranteed to work. In another thread it was pointed out >> that this is merely a CPython implementation detail, NOT a language >> feature. > > I'm curious where this is written down. Can you point to the relevant > part of the language spec or pronouncement or whatever it was? I

Re: [Python-ideas] Debugging: some problems and possible solutions

> Ah, yes. Thank you. So it works in CPython 2.7. But I'm curious, does it work > in very old versions? > I'm not saying that this is important, because language changes always are > for new versions. However, Anders' claim that this not a language change > seemed too broad to me. > It may be t

Re: [Python-ideas] Debugging: some problems and possible solutions

>> Ah, yes. Thank you. So it works in CPython 2.7. But I'm curious, does it >> work in very old versions? >> I'm not saying that this is important, because language changes always are >> for new versions. However, Anders' claim that this not a language change >> seemed too broad to me. >> It m

Re: [Python-ideas] Debugging: some problems and possible solutions

> [I think >> = ChrisA] >>> However, it doesn't matter. >> Of course it matters. It's the difference between changing the spec and >> changing the spec AND some implementation. There is a difference between >> those two things. You might not care but that's another topic. > > In terms of defi

Re: [Python-ideas] support toml for pyproject support

>> He's referring to PEPs 518 and 517 [1], which indeed standardize on >> TOML as a file format for Python package build metadata. >> >> I think moving anything into the stdlib would be premature though – >> TOML libraries are under active development, and the general trend in >> the packaging sp

Re: [Python-ideas] Support parsing stream with `re`

>> However, another possibility is the the regexp is consuming lots of memory. >> >> The regexp seems simple enough (b'.'), so I doubt it is leaking memory like >> mad; I'm guessing you're just seeing the OS page in as much of the file as it >> can. > > Yup. Windows will aggressively fill up you

Re: [Python-ideas] add a time decorator to timeit.py

> On 7 Oct 2018, at 22:44, Guido van Rossum wrote: > > So someone ought to submit a PR that adds (brief) documentation for this, > with reference to this thread. I was trying to write this documentation when I noticed that the docs already mention this! "The stmt and setup parameters can als

Re: [Python-ideas] Revisiting Immutable Mappings

In tri.struct we have a class Frozen https://github.com/TriOptima/tri.struct/blob/master/lib/tri/struct/__init__.py that can be used to freeze stuff. I think something like this would be even better in the standard library, especially now with data classes! If we had this frozendict would just

Re: [Python-ideas] Revisiting Immutable Mappings

>> Even though, it would be the same as issubclass() (though I'd like an AND >> relationship with the tuple of ABCs..) > > When "hasinterface" ANDs the tuple, it's already different, isn't it? > If it's AND, shouldn't it be "hasinterfaces" (notice the s!)? One could also imagine that isinstan

Re: [Python-ideas] Revisiting Immutable Mappings

> Does AND even make sense for isinstance/issubclass? Why wouldn't it? Python supports multiple inheritance. / Anders ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://

Re: [Python-ideas] TypeHinting: From variable name to type

> On 19 Oct 2018, at 09:18, Thomas Güttler wrote: > > Imaging you are developing in the django context. > > Everytime you use a variable named "request" or "response" your human brains > knows that this is a subclass of django.http.HttpRequest and > django.http.HttpResponse. > > How to give

Re: [Python-ideas] TypeHinting: From variable name to type

> On 19 Oct 2018, at 12:15, Steven D'Aprano wrote: > > On Fri, Oct 19, 2018 at 09:18:02AM +0200, Thomas Güttler wrote: > >> Imaging you are developing in the django context. >> >> Everytime you use a variable named "request" or "response" your human brains >> knows that this is a subclass of

Re: [Python-ideas] Multi Statement Lambdas

> A powerful general purpose language should not limit itself to one statement > in a closure. Nitpick on language: It doesn't. Lambdas are not the only way to do a closure. It's important to be precise when discussing these things. > Lets add mutli-statement lambdas to python either with

Re: [Python-ideas] Multi Statement Lambdas

> Wheres a lambda expression can be passed anonymously to any other function as > an argument. > > map(lambda x: x**2, array) > > vs > > def powers2(x) >x**2 > map(powers2, array) > > Coming up with a name here is not needed, as the operation is expressive > enough. Sure, but there is

Re: [Python-ideas] TypeHinting: From variable name to type

> But the critical point here is that we should not add a language feature > to make up for the limitations of a single IDE. If the free version of > PyCharm is underpowered, perhaps you ought to try the paid version, or > another IDE, or submit a feature request to PyCharm, *before* turning t

Re: [Python-ideas] TypeHinting: From variable name to type. Yes: no change to language, just convetion

>> This is certainly not something that requires language support. It can >> easily be purely a convention, as long as different IDEs, linters, type >> checkers, etc. agree on what the convention is. Maybe at some point in the >> future, if the convention becomes adopted, there might be some

Re: [Python-ideas] TypeHinting: From variable name to type

have consistent names, it was before my time but keeping this consistency isn't much work, we certainly don't go back and change code to enforce conventions. > On 23 Oct 2018, at 01:02, Steven D'Aprano wrote: > > On Fri, Oct 19, 2018 at 01:14:39PM +0200, Anders Hovmöl

Re: [Python-ideas] Python 3.7 dataclasses attribute order

Well that seems super unfortunate. You can opt out of the auto generate constructor and do it yourself: @dataclass(init=False) class Foo: foo: str bar: str = None baz: str def __init__(self, *, foo, bar = None, baz): self.foo = foo self.bar = bar

Re: [Python-ideas] Contracts in python -- a report & next steps

> Roadblocks > During the development, the following roadblocks were encountered: > > * We wanted to include the contracts in the output of help(). Unfortunately, > help() renders the __doc__ of the class and not of the instance. For > functions, this is the class "function" which you can not i

Re: [Python-ideas] Return for assignment blocks

> The point is not saving a line or typing, but saving a thought. Expressing > the intent of the factory function more clearly. Could you give some other usage examples? To me it seems like a nicer and less confusing way to create decorators is warranted but could then be more specialized an

Re: [Python-ideas] Implementing a set of operation (+, /, - *) on dict consistent with linearAlgebrae

> What are your opinions ? > I don't actually see a lot of use case except it was funny to build. But > maybe it can be of use. This list is for suggesting additions and changes to python. Broad usefulness is a prerequisite. So please build your lib but this seems off topic on this list. / A

Re: [Python-ideas] Add "default" kwarg to list.pop()

> So far, I count 12 people who responded to the original post by > Giampaolo. By my count, I see: > > * five people in favour; > * three people against, or see no need for it; > * four people I can't tell if they are for or against, > (possibly neutral?) [1] For the little it's worth I'm +1

Re: [Python-ideas] dict.setdefault_call(), or API variations thereupon

Just a little improvement: you don't need the l local variable, you can just call append: d.setdefault(foo, []).append(bar) And correspondingly: d[foo].append(bar) > On 2 Nov 2018, at 17:52, Chris Barker via Python-ideas > wrote: > >> On Thu, Nov 1, 2018 at 8:34 PM, Steven D'Aprano wrote: >

Re: [Python-ideas] dict.setdefault_call(), or API variations thereupon

> defaultdict: >- takes a zero-argument factory function which is > unconditionally called when the key is missing. > > Did I miss any? > > What we don't have is a version of setdefault where the default is > evaluated only on need. That would be a great use-case for Call-By-Name >

Re: [Python-ideas] Proposal to add a key field to the bisect library

That link has Guido and Raymond Hettinger ending +1 and looking to either add it or writing a simple copy paste:able recipe to the docs. I mean, that's how I read it, did you read that and come to a different impression? > On 4 Nov 2018, at 14:19, Steven D'Aprano wrote: > >> On Sun, Nov 04, 2

  1   2   3   >