Re: [Python-ideas] shutil.symlink to allow non-race replacement of existing link targets

> On 13 May 2019, at 19:38, Steven D'Aprano wrote: > >> On Mon, May 13, 2019 at 12:31:08PM +0200, Anders Hovmöller wrote: >> >> >>> On 13 May 2019, at 11:38, Tom Hale wrote: >>> >>> * os.symlink() - the new link name is expected to

Re: [Python-ideas] shutil.symlink to allow non-race replacement of existing link targets

> On 13 May 2019, at 11:38, Tom Hale wrote: > > * os.symlink() - the new link name is expected to NOT exist > * shutil.symlink() - the new symlink replaces an existing file This seems error prone to me. There is nothing about those names that hint at the difference in behavior. An optional

Re: [Python-ideas] Idea: Allow multiple levels of tracers

> On 26 Apr 2019, at 05:47, Ram Rachum wrote: > > Ah, I thought about it now and Ned is right. This would require modifications > to ceval.c and others. Pity! > The question is... Does anyone else think it's a good idea? I do. It seems to me that coverage is a very useful tool that

Re: [Python-ideas] Proposal: "?" Documentation Operator and easy reference to argument types/defaults/docstrings

> On 26 Apr 2019, at 00:41, Peter O'Connor wrote: > > - Defaults are defined in multiple places, which very easily leads to bugs > (I'm aware of **kwargs but it obfuscates function interfaces and usually does > more harm than good) > - Types are defined in multiple places > - Documentation

Re: [Python-ideas] Idea: Allow multiple levels of tracers

done without the original >> tracer implementing it, right? >> >>> On Thu, Apr 25, 2019 at 6:16 PM Ram Rachum wrote: >>> Oh wow, I didn't even consider that. I think you're right, I'll >>> do more thinking about this. Thanks Anders

Re: [Python-ideas] Idea: Allow multiple levels of tracers

Can't this be implemented today by a simple monkey patch of sys.settrace? > On 25 Apr 2019, at 16:51, Ram Rachum wrote: > > Hi, > > Here's something I want in Python: Multiple levels of tracers working on top > of each other, instead of just one. > > I'm talking about the tracer that one

Re: [Python-ideas] Logical tracebacks

> On 15 Apr 2019, at 22:07, Antoine Pitrou wrote: > > However, there are many contexts where implementation details would > benefit from being hidden from tracebacks (the classical example being > the internals of framework or middleware code, such as Django, Dask, > etc.). We would

Re: [Python-ideas] Syntax for allowing extra keys when unpacking a dict as keyword arguments

> On 12 Apr 2019, at 19:16, Eric V. Smith wrote: > > I don't want to speak for the OP, but I have a similar use case (which is why > I wrote calllib). My use case is: I have number of callables that I don't > control. I also have a dict of parameters that the callables might take as >

Re: [Python-ideas] Starap function exists but it seems there's not such thing as "doublestarmap"

> On 10 Apr 2019, at 11:55, Krokosh Nikita wrote: > > I need smth like starstarmap('{a} / {b}/ {c}'.format, [{a:1, b:2, c:3}, {a:4, > b:5, c:6}, ...]) Seems overly specific. Why not merge the dicts then call formal like normal? >> On 4/10/19 7:48 PM, Anders Hovmöller

Re: [Python-ideas] Starap function exists but it seems there's not such thing as "doublestarmap"

I don't really understand. You can do: '{a} {b}'.format(**{'a': 1}, **{'b': 2}) Is that what you want? > On 10 Apr 2019, at 11:09, Krokosh Nikita wrote: > > Hello. I have a following question: How come there's no such thing in Python > like starmap but which unpacks dicts as kwargs for

Re: [Python-ideas] New explicit methods to trim strings

> On 2 Apr 2019, at 13:23, Paul Moore wrote: > > It would be really helpful if someone could go through the various use > cases presented in this thread and classify them - filename > manipulation, natural language uses, and "other". We could then focus > on the "other" category to get a

Re: [Python-ideas] Backward-incompatible changes for Python 4

Please let's all agree that April 1 is the worst day of the year. > On 1 Apr 2019, at 16:27, Antoine Pietri wrote: > > While the switch to Python 3 did an excellent job in removing some of > the old inconsistencies we had in the language, pretty much everyone > agrees that some other

Re: [Python-ideas] New explicit methods to trim strings

> On 1 Apr 2019, at 04:58, David Mertz wrote: > > >> Lacking a good set of semantics for removing multiple affixes at once, we >> shouldn't rush to guess what people want. You don't even know what behaviour >> YOU want, let alone what the community as a whole needs. > > > This is both

Re: [Python-ideas] New explicit methods to trim strings

> On 1 Apr 2019, at 02:23, David Mertz wrote: > >> On Sun, Mar 31, 2019, 8:11 PM Steven D'Aprano wrote: >> Regarding later proposals to add support for multiple affixes, to >> recursively delete the affix repeatedly, and to take an additional >> argument to limit how many affixes will be

Re: [Python-ideas] New explicit methods to trim strings

> On 31 Mar 2019, at 21:32, Christopher Barker wrote: > > > without_prefix > without_suffix > > They're a little longer, but IMO "without" helps > reenforce the immutability of the underlying string. None > of these functions actually remove part of the original > string, but rather they

Re: [Python-ideas] New explicit methods to trim strings

> Steven D'Aprano: > > Stephen J. Turnbull: > >> And the bikeshedding isn't hard. In the list above, cutprefix/ >> cutsuffix are far and away the best. > > Well I'm glad we agree on that, even if nothing else :-) I prefer “strip_prefix” because of the analogy to strip() which doesn’t do

Re: [Python-ideas] New explicit methods to trim strings

> On 30 Mar 2019, at 11:21, Paul Moore > > Note that the proposed name (trim) is IMO "poorly named", because a > number of languages in my experience use that name for what Python > calls "strip", so there would be continual confusion (for me at least) > over which name meant which behaviour..

Re: [Python-ideas] New explicit methods to trim strings

>>> All of this would be well served by a 3rd party library on PyPI. Strings >>> already have plenty of methods (probably too many). Having `stringtools` >>> would be nice to import a bunch of simple functions from. >> >> I respectfully disagree. This isn't javascript where we are OK with

Re: [Python-ideas] New explicit methods to trim strings

> And this really is simple enough that I don't want to reach for regex's for > it. That is, I'd write it by hand rather than mess with that. > > Well, with re.escape it's not messy at all : > > import re > def trim_mailto(s): > regex = re.compile("^" + re.escape("mailto:;)) > return

Re: [Python-ideas] New explicit methods to trim strings

> All of this would be well served by a 3rd party library on PyPI. Strings > already have plenty of methods (probably too many). Having `stringtools` > would be nice to import a bunch of simple functions from. I respectfully disagree. This isn't javascript where we are OK with millions of

Re: [Python-ideas] New explicit methods to trim strings

> Earlier, Anders wrote: > I propose naming them strip_prefix() and strip_suffix() and just skip the one > that does both sides since it makes no sense to me. > > This is good, except I prefer subtract_prefix(a, b), truncate_suffix etc. And > for the two step process prefix_subtractor(a)(b)

Re: [Python-ideas] New explicit methods to trim strings

I think this is a terrible idea. I also think it's a mistake that python uses + for string concatenation and * for string repeat. You end up with type errors far from the first place you could have had the crash! That ship has obviously sailed buy we shouldn't make even more mistakes in the

Re: [Python-ideas] Improve os.times() resolution

Have you checked how much overhead the two functions have? That seems like an obvious way this proposal could go south. > On 24 Mar 2019, at 13:15, Giampaolo Rodola' wrote: > > It turns out we could use resource.getrusage() which provides micro > seconds (tested on Linux and macOS): > >

Re: [Python-ideas] New explicit methods to trim strings

I don't see what trim() is good for but I know I've written ltrim() hundreds of times easy. I propose naming them strip_prefix() and strip_suffix() and just skip the one that does both sides since it makes no sense to me. Trim is generally a bad name because what is called strip() in python

Re: [Python-ideas] The @update operator for dictionaries

Why are you continuing to insist on using the symbol "@" after all these problems have been pointed out I wonder? Just suggest $ or something else that is a syntax error today and we can move on with discussing the merits of the underlying idea itself? / Anders > On 9 Mar 2019, at 20:03,

Re: [Python-ideas] The @update operator for dictionaries

> Thus, 'b' would be unchanged, and 'a' would be the same dictionary as > before, but updated with 'b'. > > I hope this helps. It didn't. I feel just as confused as before. What does "iat" mean? Is "update" an arbitrary symbol (if so then you could have used "foo" instead of "update" to make

Re: [Python-ideas] The @update operator for dictionaries

I don't understand what you mean. Can you provide examples that show the state of the dicts before and after and what the syntax would be the equivalent of in current python? > On 9 Mar 2019, at 16:33, Jonathan Fine wrote: > > I've been thinking that it might be easier, in the long term, to

Re: [Python-ideas] PEP: Dict addition and subtraction

> I'd like to remove all doubt: {**d1} needs to work regardless of the key > type, as long as it's hashable (d1 could be some mapping implemented without > hashing, e.g. using a balanced tree, so that it could support unhashable > keys). > > If there's doubt about this anywhere, we could

Re: [Python-ideas] Dict joining using + and +=

> Adding the + operator for dictionaries feels like it would be a mistake in > that it offers at most sugar-y benefits, but introduces the significant > drawback of making it easier to introduced unintended errors. I disagree. This argument only really applies to the case "a = a + b", not "a

Re: [Python-ideas] Dict joining using + and +=

I dislike the asymmetry with sets: > {1} | {2} {1, 2} To me it makes sense that if + works for dict then it should for set too. / Anders > On 27 Feb 2019, at 17:25, João Matos wrote: > > Hello, > > I would like to propose that instead of using this (applies to Py3.5 and > upwards) >

Re: [Python-ideas] PEP 8 update on line length

>> Maybe you know some grep magic I don't? Is there a way to do multi line grep >> that knows that open paren means to ignore new lines until the matching >> close paren? I'd love to hear about it! > > I probably don't know any more grep magic than you, I've just never had cause > to grep

Re: [Python-ideas] PEP 8 update on line length

> On 19 Feb 2019, at 17:36, Rhodri James wrote: > > On 19/02/2019 16:26, Anders Hovmöller wrote: >>> If it were me, I'd probably write (or would have re-written when I added >>> the type hints) that as follows: >>

Re: [Python-ideas] PEP 8 update on line length

> If it were me, I'd probably write (or would have re-written when I added > the type hints) that as follows: > >def resolve_annotations( >*, >raw_annotations: Dict[str, Type[Any]], >module_name: Optional[str] >) -> Dict[str, Type[Any]]: I would

Re: [Python-ideas] add fluent operator to everything

I would suggest a small improvement: allow a trailing :: which is useful for when the last function does not return anything. So for example this [1,2,3].append(4)::sort() will evaluate to None, but [1,2,3].append(4)::sort():: would evaluate to the list. > On 19 Feb 2019, at 15:13, Jimmy

Re: [Python-ideas] PEP 8 update on line length

> On 19 Feb 2019, at 05:48, David Mertz wrote: > > You either have much better eyes to read tiny fonts than I do, or maybe a > much larger monitor (it's hard for me to fit a 30"" monitor in my laptop bag). > > But that's not even the real issue. If the characters were in giant letters > on

Re: [Python-ideas] Consistency in naming [was Re: ...ALL CAPS]

As I said before, this is what I've implemented at work and to us this annoying paper cut has simply gone away. / Anders > On 3 Feb 2019, at 05:56, James Lu wrote: > > > > Sent from my iPhone > >>> On Feb 2, 2019, at 3:41 AM, Steven D'Aprano wrote: >>>

Re: [Python-ideas] Consistency in naming [was Re: ...ALL CAPS]

> Python has been around not quite 30 years now, so we can expect that it > will probably last another 30 years. But chances are not good that it > will be around in 300 years. With that attitude the odds go up *wink* / Anders ___ Python-ideas

Re: [Python-ideas] Consistency in naming [was Re: ...ALL CAPS]

> - the status quo means "no change", so there is no hassle there; Not quite true. There is a constant hassle of "do I need to write datetime.datetime.now() or datetime.now()?" I solved this at work by changing all imports to follow the "from datetime import datetime" pattern and hard

Re: [Python-ideas] Consistency in naming [was Re: ...ALL CAPS]

> The only exception to that is that I wish that ``object`` would be > renamed to Object. That would distinguish between Object, the base class > of all types, and object, an instance of some class. In my personal > opinion, being more clear about that distinction would be worth the pain >

Re: [Python-ideas] Stack traces ought to flag when a module has been changed on disk

I've been bitten by this and it always costs me several minutes of confusion. +1 > On 30 Jan 2019, at 11:17, Steven D'Aprano wrote: > > This thought is motivated by this bug report: > > https://bugs.python.org/issue35857 > > If you import a module, then edit the .py file that goes with it,

Re: [Python-ideas] Add list.join() please

Just by the title I thought you meant >>> [1].join([2, 3, 4]) [2, 1, 3, 1, 4] This is what I'd expect on the list class. So -1 for your suggestion but +1 for what I thought you meant before I read the complete mail :) > On 29 Jan 2019, at 02:40, Jamesie Pic wrote: > > Hello, > > During

Re: [Python-ideas] kwargs for return

> I don't see anything here that can't be done by returning a dict, a > namedtuple (possibly with optional fields), or some other object with > named fields. They can be optional, they can have defaults, and you can > extend the object by adding new fields without breaking backwards >

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] 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? > 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] 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? 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] 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] 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] 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] 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] 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] __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] 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] 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] 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] 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] 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] 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] 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] 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. 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

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

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

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

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

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

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

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

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

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

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

<    1   2   3   >