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

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',

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

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öller

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

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] 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

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/ #

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

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. > >

[Python-ideas] Keyword only argument on function call

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 list Python-ideas

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't it

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

> 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

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

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=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

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

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

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

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

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

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

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öller wrote: >

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

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] 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] 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

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. /

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

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

Oh heh. Well there we go :) > On 4 Nov 2018, at 14:33, Steven D'Aprano wrote: > >> On Mon, Nov 05, 2018 at 12:19:49AM +1100, Steven D'Aprano wrote: >>> On Sun, Nov 04, 2018 at 02:20:31PM +0200, Tiberiu Chibici wrote: >>> Hi, >>> I would like to propose an improvement to the functions in the

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,

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

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] 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:

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] 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] 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

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

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]) >> >> 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

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

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

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

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

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] 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] 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 >>

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

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

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

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

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?

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

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

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

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

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

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

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

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 >

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,

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

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

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

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] 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

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

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

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

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

>>> 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

Re: [Python-ideas] In fact, I'm a bit worry about this literal p""

>regex = re.compile(r"...") >regex = p("...") > > is not that much different. True, but when the literal is put somewhere far from the compile() call it becomes a problem for static analysis. Conceptually a regex is not a string but an embedded foreign language. That's why I think

Re: [Python-ideas] struct.unpack should support open files

> And this is why I, personally, think augumenting struct.unpack and json.read > and a myriad of other arbitrary methods to accept both file-like things and > bytes is an open ended can of worms. > > And it is why I wrote myself my CornuCopyBuffer class (see my other post in > this thread).

Re: [Python-ideas] Add regex pattern literal p""

> We can use this literal to represent a compiled pattern, for example: > > >>> p"(?i)[a-z]".findall("a1B2c3") > ['a', 'B', 'c'] There are some other advantages to this. For me the most interesting is that we can know from code easier that something is a regex. For my mutation tester mutmut

Re: [Python-ideas] About the passing the function arguments in Keyword form.

> On 24 Dec 2018, at 11:21, 李默 wrote: > > I am having an idea on loosing the argument validity check when passing the > function arguments in keyword way. > For example: > --- > def f(x, y): > print(x, y) > def call_f(): > f(x=7, y=9, z=9) > > call_f() >

Re: [Python-ideas] About the passing the function arguments in Keyword form.

> I agree with other posters that we definitely do not want this as the default > behavior in Python. However, it's also sometimes a useful pattern. I use it > when I have a large plugin architecture that can take dozens or hundreds of > possible parameters, but any given plugin is likely to

Re: [Python-ideas] __len__() for map()

>> +1. Throwing away information is almost always a bad idea. > > "Almost always"? Let's take this seriously, and think about the > consequences if we actually believed that. If I created a series of > integers: “Almost". It’s part of my sentence. I have known about addition for many years

Re: [Python-ideas] __len__() for map()

> I just mentioned that porting effort for background. I still believe > that the actual proposal of making the arguments to a map(...) call > accessible from Python as attributes of the map object (ditto filter, > zip, etc.) is useful in its own right, rather than just having this >

Re: [Python-ideas] Possible PEP regarding the use of the continue keyword in try/except blocks

> You mean like this? > > https://docs.python.org/3/library/contextlib.html#contextlib.suppress Hah. Exactly. Maybe that is what the OP wanted in the first place? It's always surprising how much stuff is in the standard lib even after all these years! Thanks for this. / Anders

Re: [Python-ideas] AMEND PEP-8 TO DISCOURAGE ALL CAPS

> Do you not have/use syntax highlighting? If not, why not? There's a right and > wrong tool for everything. In the case of visually differentiating various > kinds of code entities, the IDE is the right tool, all caps is not. This is an argument against: - the line length limit (because the

Re: [Python-ideas] AMEND PEP-8 TO DISCOURAGE ALL CAPS

> So you're saying we should prefer a future where it's an inconsistent mess? > No. And please don't straw man. It's a very annoying argumentative tactic. I > prefer a future where all caps aren't used. I understand that the change I > propose won't magically transport us there, but I don't

Re: [Python-ideas] Possible PEP regarding the use of the continue keyword in try/except blocks

> This proposal is basically about introducing goto to the language. A bit hyperbolic but I agree that it has the same problem as goto. But the specific suggested solution is not something we should be restricted so rigidly to in this discussion. One could for example see another solution to

Re: [Python-ideas] AMEND PEP-8 TO DISCOURAGE ALL CAPS

So you're saying we should prefer a future where it's an inconsistent mess? I agree with you that the C standard is ugly but it's.more important to have a standard than what that standard is. And we do have a strong standard today. -1 from me / Anders > On 4 Jan 2019, at 20:01, Abe Dillon

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

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

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

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

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 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 functions

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] 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

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] 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

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

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

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_file

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

  1   2   3   >