[Python-ideas] Re: Function call in (kw)args

> On 10 Feb 2020, at 04:18, Soni L. wrote: > > Traits are composition tho. I think you missed something I said. In that case I think we all missed it and then isn't that on you? Remember it is you who are trying to convince the list so any information missed or misunderstood is your

[Python-ideas] Re: Function call in (kw)args

> On 9 Feb 2020, at 14:01, Soni L. wrote: > > > into this: > > [snip] > > def my_fn(@MyTrait x): > x.x() Can't you look at typing info or something instead? That is a lot of boilerplate and ceremony even after your proposed addition. So: @traits def my_fn(x: MyTrait): x.x() /

[Python-ideas] Re: `raise as` to raise with current exception as cause

> On 7 Feb 2020, at 16:59, Ethan Furman wrote: > > On 02/07/2020 07:44 AM, Anders Hovmöller wrote: > >> If the only difference is the text between the stack traces, why aren't you >> suggesting to change that text? > > Because the text is important in what it

[Python-ideas] Re: `raise as` to raise with current exception as cause

If the only difference is the text between the stack traces, why aren't you suggesting to change that text? > On 7 Feb 2020, at 15:30, Ram Rachum wrote: > >  > Hi, > > I'd like to suggest an idea, that builds on PEPs 3134 and 409. > > This idea came up when discussing a problem on the

[Python-ideas] Re: addition of "nameof" operator

> On 2 Feb 2020, at 01:00, Christopher Barker wrote: > > And no one answered my questions about what it would do in all the, very > common cases where an object doesn't ahve a name, opr more than one. This question has been answered multiple times. It's not about the object, it's about the

[Python-ideas] Re: addition of "nameof" operator

> On 22 Jan 2020, at 14:39, Alex Hall wrote: > >  > You can achieve this now with my executing library: > https://github.com/alexmojaki/executing > > ``` > import ast > import inspect > > import executing > > > def nameof(_): > frame = inspect.currentframe().f_back > call =

[Python-ideas] Re: addition of "nameof" operator

> On 22 Jan 2020, at 13:23, Rhodri James wrote: > > On 22/01/2020 12:03, Anders Hovmöller wrote: >> He was pretty clear in saying he wanted the same thing as in C#. That no one >> in this thread seems to have looked that up is really not his fault in my >> opinion

[Python-ideas] Re: addition of "nameof" operator

> On 22 Jan 2020, at 11:50, Steven D'Aprano wrote: > > But what should these things do? > >x = y = z = 1 >nameof(1) Syntax error. >nameof(z) "z" >nameof("Gumby") Syntax error. >nameof(mysequence[0]) Syntax error. > It isn't clear what precisely counts as the name

[Python-ideas] Re: addition of "nameof" operator

> On 21 Jan 2020, at 22:50, Andrew Barnert via Python-ideas > wrote: > > But it seems like nameof(self.age) always has to be just “age”, which you > already have to type inside the nameof if you want it to be findable, so > it’ll never be useful. Anywhere you could write

[Python-ideas] Re: Allow metaclass to override __subclasscheck__ for metaclass relations

> > > class D(metaclass=N): > pass > > > class E(C, D, metaclass=N): > pass > > > def main(): > assert type(E) is N and issubclass(E, C) > > > main() > >> On 2019-12-31 3:16 p.m., Anders Hovmöller wrote: >> You forgot

[Python-ideas] Re: Allow metaclass to override __subclasscheck__ for metaclass relations

You forgot something in that example I think because it doesn't actually do anything that can "not work". > On 31 Dec 2019, at 18:41, Soni L. wrote: > > I would like this code to work, but currently python ignores > __subclasscheck__ in many places where it checks for subclasses: > > class

[Python-ideas] Re: Total_order

> On 30 Dec 2019, at 05:55, Tim Peters wrote: > > [David] >> Has anyone actually ever used those available bits for the zillions of NaNs >> for >> anything good? > > Yes: in Python, many sample programs I've posted cleverly use NaN > bits to hide ASCII encodings of delightful puns ;-) > >

[Python-ideas] Re: "and if" and "or if" for trailing if statements - including explicit fallthrough

Could you give an example of some real code that would be improved by this construct? > On 21 Dec 2019, at 17:42, Soni L. wrote: > > I'd like to see the ability to do: > > if x: > 1 > and if y: > 2 > or if z: > 3 > > The truth table for these would be: > > x | y | z | result > 0 | _

[Python-ideas] Re: Add "elif" to "for_stmt" and "while_stmt"

In my opinion this doesn't make sense. For else is already unreadable and confusing so adding to it would be more so. > On 15 Dec 2019, at 00:16, komissar.off.and...@gmail.com wrote: > > Hello! > I think it will be useful in Python syntax if we can use "elif" in "for" and > "while" statements

[Python-ideas] Re: Segmentation of string

What are the practical uses for this? I don't recall having done this in my soon 20 years career. > On 14 Dec 2019, at 15:42, smfiles <1668151...@qq.com> wrote: > > I think it's necessary to add a segment() method to str type or string > module. This method is used to split a string into m

[Python-ideas] Re: Argumenting in favor of first()

> On 8 Dec 2019, at 20:11, Guido van Rossum wrote: > >  >> On Sun, Dec 8, 2019 at 11:03 AM Anders Hovmöller wrote: >> >> >> > On 8 Dec 2019, at 19:40, Guido van Rossum wrote: >> > >> > def first(it, /, default=None): >>

[Python-ideas] Re: Argumenting in favor of first()

> On 8 Dec 2019, at 19:40, Guido van Rossum wrote: > >  > We're not changing next(). It's too fundamental to change even subtly. > > We might add itertools.first(), but not builtins.first(). This kind of > functionality is not fundamental but it's easy to get slightly wrong (witness > many

[Python-ideas] Re: Suggestion for language addition

> On 4 Dec 2019, at 21:28, Soni L. wrote: > >  > >> On 2019-12-04 5:12 p.m., Mike Miller wrote: >> >>> On 2019-12-04 11:05, David Mertz wrote: >>> I've often wanted named loops. I know approaches to this have been proposed >>> many times, and they all have their own warts. E.g. an ad hoc

[Python-ideas] Re: Access to member name/names via context during Enum instance initialization

Maybe the right way to think about Enum is as only for the most trivial use cases. At work we almost never use Enum because it's too limited and we instead reach for our own tri.declarative which scales up to very complex use cases. Adding a lot of features to Enum would make it less of an

[Python-ideas] Re: Update pep8 for stressing type hinted long parameter in functions

Black is a bit weird in some other ways. Like preferring " over '. He has an agenda, he's not trying to codify the de facto style :( > On 27 Nov 2019, at 15:56, Ivan Levkivskyi wrote: > >  > IIRC, black actually uses the first style you mention, so maybe you should > rather discuss it there

[Python-ideas] Re: COMBINE operator

This is way too late to change now. I agree that plus isn't great but & is also quite bad since it means bitwise and. A totally separate operator for concatenation would have been preferable but this is as I said way too late to change now. > On 18 Nov 2019, at 15:02, tonycst...@gmail.com

[Python-ideas] Re: Python should take a lesson from APL: Walrus operator not needed

> On 11 Nov 2019, at 17:05, Richard Damon wrote: > > On 11/11/19 10:10 AM, Random832 wrote: >>> On Mon, Nov 11, 2019, at 03:22, Greg Ewing wrote: >>> On 11/11/19, 12:41 PM, Richard Damon wrote: it was DESIGNED to be inefficient (that was one of its design goals, to slow typesetters

[Python-ideas] Re: Guidelines on ZWSP

> On 10 Nov 2019, at 02:22, Artemis wrote: > > What should one do when one wants to put a zero width space or other > invisible character in code? > These are often not displayed in editors, which can lead to confusion. I see > two solutions: > - include it but add a comment noting it > -

[Python-ideas] Re: Suggest having a mechanism to distinguish import sources

> On 8 Nov 2019, at 18:57, Dan Sommers <2qdxy4rzwzuui...@potatochowder.com> > wrote: > > On 11/8/19 11:28 AM, Anders Hovmöller wrote: > > >> On 8 Nov 2019, at 18:06, Dan Sommers <2qdxy4rzwzuui...@potatochowder.com> > >> wrote: > > >&

[Python-ideas] Re: Suggest having a mechanism to distinguish import sources

> On 8 Nov 2019, at 18:06, Dan Sommers <2qdxy4rzwzuui...@potatochowder.com> > wrote: > > On 11/8/19 10:40 AM, Jonathan Fine wrote: >> Hi All >> I think we can learn from Unix/Linux here. Like python, it has a PATH >> variable for finding executables. It also has a command 'which'. > > Python

[Python-ideas] Re: Suggest having a mechanism to distinguish import sources

> On 8 Nov 2019, at 07:52, Steve Barnes wrote: > >  > Hi, > > I hope that his hasn’t been discussed to death in the past but I quite often > encounter cases where developers have unwittingly created a file or directory > that has a name clash with either a system import or a pip installed

[Python-ideas] Re: Allow Path object instances in subprocess.Popen

> On 3 Nov 2019, at 16:50, Andrew Barnert wrote: > >  >> >>> On Nov 3, 2019, at 16:07, Anders Hovmöller wrote: >>> >>>> On 3 Nov 2019, at 13:31, Andrew Barnert wrote: >>> >>> On Nov 3, 2019, at 13:01, Anders Hovmöller wrote

[Python-ideas] Re: Allow Path object instances in subprocess.Popen

> On 3 Nov 2019, at 13:31, Andrew Barnert wrote: > > On Nov 3, 2019, at 13:01, Anders Hovmöller wrote: >> >> Well, the last part requires that print can coerce bytes to str, not >> strictly that it must do so via str(). repr() should return b'foo' but st

[Python-ideas] Re: Allow Path object instances in subprocess.Popen

> On 3 Nov 2019, at 11:39, Chris Angelico wrote: > > On Sun, Nov 3, 2019 at 9:34 PM Anders Hovmöller wrote: >> >> >> >>>> On 3 Nov 2019, at 10:28, Steven D'Aprano wrote: >>> >>> On Sun, Nov 03, 2019 at 12:23:02AM -0700, Brendan

[Python-ideas] Re: Allow Path object instances in subprocess.Popen

> On 3 Nov 2019, at 12:17, Steven D'Aprano wrote: > > On Sun, Nov 03, 2019 at 11:31:22AM +0100, Anders Hovmöller wrote: > >>> Given: >>> values = ["Hello", b"World"] >>> would you expect ' '.join(values) to return >>&

[Python-ideas] Re: Allow Path object instances in subprocess.Popen

> On 3 Nov 2019, at 10:28, Steven D'Aprano wrote: > > On Sun, Nov 03, 2019 at 12:23:02AM -0700, Brendan Barnwell wrote: > >>For the record, I have always thought that str.join should call str >>on all its arguments. The fact that it doesn't is really annoying. > > Given: > >

[Python-ideas] Re: Ability to customize how Enum interprets values with access to names

I do agree that this is a worthwhile feature-ish, but it's marred by the tuples-for-values assumption. We've build very much the same thing in tri.token (https://github.com/TriOptima/tri.token) but tri.token is much more scalable to many arguments because it uses keyword arguments and not

[Python-ideas] Re: foo.setParseAction(lambda a, b, c: raise FuckPython(":("))

There's also the workaround: def raise_(t, *a,*kw): raise t(*a,**kw) > On 27 Oct 2019, at 14:57, Soni L. wrote: > > foo.setParseAction(lambda a, b, c: raise FuckPython(":(")) is invalid > syntax, which makes pyparsing useless. > ___ >

[Python-ideas] Re: foo.setParseAction(lambda a, b, c: raise FuckPython(":("))

Just define a function. And don't be a dick. > On 27 Oct 2019, at 14:57, Soni L. wrote: > > foo.setParseAction(lambda a, b, c: raise FuckPython(":(")) is invalid > syntax, which makes pyparsing useless. > ___ > Python-ideas mailing list --

[Python-ideas] Re: Ability to specify function for auto-test in Enum and pass the given value as an argument to _generate_next_value_

A short example would help. I read all that and I'm still not sure what you meant. > On 26 Oct 2019, at 13:13, Steve Jorgensen wrote: > > After messing around with `Enum` for a while, there's one small thing that > I'd like to see improved. It seems limiting to me that the only way to >

[Python-ideas] Re: Python 4000: Have stringlike objects provide sequence views rather than being sequences

> On 24 Oct 2019, at 01:02, Christopher Barker wrote: > >  >> On Sun, Oct 13, 2019 at 12:52 PM Andrew Barnert via Python-ideas >> wrote: > >> The main problem is that a str is a sequence of single-character str, each >> of which is a one-element sequence of itself, etc. forever. If you

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

> On 21 Oct 2019, at 00:08, Guido van Rossum wrote: > >  > So the choice is really only three way. > > 1) Add d1 + d2 and d1 += d2 (using similarity with list + and +=) > 2) Add d1 | d2 and d1 |= d2 (similar to set | and |=) > 3) Do nothing Isn't there 4) add .merged()? / Anders

[Python-ideas] Re: Ability to set precedence of classdict (returned from __prepare__) for a metaclass type

> On 20 Oct 2019, at 12:41, Steve Jorgensen wrote: > > Anders Hovmöller wrote: >> We try to do the same thing in various libraries. We've settled on using >> existing >> python and end up with syntax like: >> class MyForm(Form): >>field = Fie

[Python-ideas] Re: Ability to set precedence of classdict (returned from __prepare__) for a metaclass type

We try to do the same thing in various libraries. We've settled on using existing python and end up with syntax like: class MyForm(Form): field = Field() or in your case class Colors(TokenContainer): red = Token() green = Token() blue = Token() (this is using

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

> On 18 Oct 2019, at 15:58, Brandt Bucher wrote: > > Paul Moore wrote: >> All of the above is just my subjective opinion. Objective information is >> likely to only be available by someone looking at a body of real world code >> and demonstrating what difference the proposed operator would

[Python-ideas] Re: Add kwdefaults parameter to function constructor

Just thinking aloud here but when you say "positional" parameters you mean normal parameters and not positional only parameters as introduced in 3.8 right? And how would those fit into this picture? > On 18 Oct 2019, at 15:31, Gus Wiedey wrote: > >  > I was recently playing around with

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

> On 17 Oct 2019, at 22:44, Steven D'Aprano wrote: > > On Thu, Oct 17, 2019 at 01:42:54PM +0200, Anders Hovmöller wrote: > >> The multiply a list/string thing is a big mistake imo. You almost >> never use it so the cost of not having it is almost nothing while the

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

> On 17 Oct 2019, at 20:37, Chris Angelico wrote: > > On Fri, Oct 18, 2019 at 5:25 AM Anders Hovmöller wrote: >> >> >> >>>> On 17 Oct 2019, at 17:07, Andrew Barnert wrote: >>> >>> On Oct 17, 2019, at 05:08, Anders Hovmöl

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

> On 17 Oct 2019, at 17:07, Andrew Barnert wrote: > > On Oct 17, 2019, at 05:08, Anders Hovmöller wrote: >> >> Well obviously never with literals. But most cases of multiplication aren't >> with literals. So how can you get a type error when doing >> &

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

> On 17 Oct 2019, at 14:26, Chris Angelico wrote: > > On Thu, Oct 17, 2019 at 11:08 PM Anders Hovmöller > wrote: >> >> So how can you get a type error when doing >> >> a*b >> >> is the real question. And the answer is now obvious: any ti

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

> On 17 Oct 2019, at 13:46, Chris Angelico wrote: > > On Thu, Oct 17, 2019 at 10:42 PM Anders Hovmöller > wrote: >> >>>> On 17 Oct 2019, at 13:26, Chris Angelico wrote: >>> >>> Equally subjective, of course, but I prefer to be able to use

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

> On 17 Oct 2019, at 13:26, Chris Angelico wrote: > > On Thu, Oct 17, 2019 at 8:54 PM Inada Naoki wrote: >> >> I think this PEP is very relating to language design philosophy. >> >> (a) Overload operator heavily for convenience. >> >> (b) Prefer methods over operators. Set a high bar for

[Python-ideas] Re: Resolve append/add API inconsistency between set and list

I've many times been saved from bugs by an early crash because of this inconsistency. So it's not at all clear to me why this would be a good thing. > On 13 Oct 2019, at 15:22, Steve Jorgensen wrote: > > Currently, it is not possible to use a single method name to add an item to > a

[Python-ideas] Re: Allow with block (context manager) to return a value (e.g. to use as a builder)

Could you supply some real life examples of the proposed feature? A thing to consider here is that the with block in python doesn't introduce a scope so after: with foo() as bar: a = 2 b = 3 now bar, a and b are all available in the scope. > On 13 Oct 2019, at 15:23, Steve Jorgensen

[Python-ideas] Re: Allow kwargs in __{get|set|del|}item__

> On 8 Oct 2019, at 20:49, Todd wrote: > >  >> On Tue, Oct 8, 2019 at 2:18 PM Anders Hovmöller wrote: >> >> >>>> On 8 Oct 2019, at 20:07, Todd wrote: >>>> >>>  >>> >>>> On Tue, Oct 8, 2019 at 1:30 PM

[Python-ideas] Re: Allow kwargs in __{get|set|del|}item__

> On 8 Oct 2019, at 20:07, Todd wrote: > >  > >> On Tue, Oct 8, 2019 at 1:30 PM Anders Hovmöller wrote: >> >> >>>> On 8 Oct 2019, at 19:19, Caleb Donovick wrote: >>>> >>>  >>>> Beca

[Python-ideas] Re: Allow kwargs in __{get|set|del|}item__

> > Now slices are allowed in keyword arguments. I wasn't making an argument, I was wondering what exactly we are even discussing. It seems like people are inventing new syntax willy nilly in this thread and I am getting very confused :) / Anders > -- Caleb Donovick >

[Python-ideas] Re: Allow kwargs in __{get|set|del|}item__

> On 8 Oct 2019, at 18:59, Todd wrote: > >  > > >> On Tue, Oct 8, 2019, 12:46 Anders Hovmöller wrote: >> >> >>> On 8 Oct 2019, at 18:35, Todd wrote: >>> >>>> On Tue, Oct 8, 2019 at 12:22 PM Andrew Barnert via Python-id

[Python-ideas] Re: Allow kwargs in __{get|set|del|}item__

> On 8 Oct 2019, at 18:35, Todd wrote: > > On Tue, Oct 8, 2019 at 12:22 PM Andrew Barnert via Python-ideas > mailto:python-ideas@python.org>> wrote: > On Oct 7, 2019, at 21:21, Caleb Donovick > wrote: > > > > > But what if you wanted to take both positional

[Python-ideas] Re: Allow kwargs in __{get|set|del|}item__

> On 8 Oct 2019, at 18:27, Todd wrote: > > > On Mon, Oct 7, 2019 at 11:19 AM Anders Hovmöller <mailto:bo...@killingar.net>> wrote: > > >> On 7 Oct 2019, at 16:36, Batuhan Taskaya > <mailto:isidenti...@gmail.com>> wrote: >> >>

[Python-ideas] Re: Allow kwargs in __{get|set|del|}item__

> On 7 Oct 2019, at 16:36, Batuhan Taskaya wrote: > >  > In fact, that would be a cool feature for ORMs. IMHO instead of ugly call > chain with filters, slicing is a better option (on `__class_getattr__`). As > said there are some disadvantages but i think this proposal deserves a PEP. I

[Python-ideas] Re: Cache an entire import object graph

ker. > > - Jeethu > > [1]: https://www.youtube.com/watch?v=KRqv2Bm1J18 > [2]: https://bugs.python.org/issue34690 > > ‐‐‐ Original Message ‐‐‐ >> On Monday, September 16, 2019 12:19 PM, Anders Hovmöller >> wrote: >> >> Hi, >> >&g

[Python-ideas] Re: Cache an entire import object graph

; > [1]: https://www.youtube.com/watch?v=KRqv2Bm1J18 > [2]: https://bugs.python.org/issue34690 > > ‐‐‐ Original Message ‐‐‐ >> On Monday, September 16, 2019 12:19 PM, Anders Hovmöller >> wrote: >> >> Hi, >> >> I would like some feedback on

[Python-ideas] Cache an entire import object graph

Hi, I would like some feedback on the feasibility of an idea I've had: caching an entire import graph to speed up interactive apps. The idea is that tools like pytest, pip, hg, etc would be able to save and restore an import graph to cut down on initial startup time. As I think of it, this

[Python-ideas] Re: Simpler syntax for async generators

I don't get it. You show one example then another unrelated example? That doesn't make anything clear to me at least. > On 14 Sep 2019, at 17:24, George Fischhof wrote: > > Hi All, > > While I was reading the documentation of asyn generators, > which shows the following example: > > async

[Python-ideas] Re: PEP-603: Adding a frozenmap type to collections

> On 13 Sep 2019, at 00:38, Greg Ewing wrote: > > Yury Selivanov wrote: >> A *persistent data structure* is defined as a data structure that >> preserves the previous version of the data when the data is modified. >> Such data structures are effectively *immutable*, as operations on >> them

[Python-ideas] Re: PEP-603: Adding a frozenmap type to collections

> On 12 Sep 2019, at 13:46, Yury Selivanov wrote: > > Hi! > > I've just published a PEP to add a frozenmap type to Python; it should > be online shortly. > > Read it here: > https://discuss.python.org/t/pep-603-adding-a-frozenmap-type-to-collections/2318 My two cents: the motivation for

[Python-ideas] Re: Automatic translation of Python to assembly language

This isn't the place for ads for commercial products. > On 7 Sep 2019, at 22:19, Mark @pysoniq wrote: > > Hello to the list, > > I have an idea for Python that is non-traditional in that it doesn’t extend > or modify existing Python language structure. > > The idea uses Python to

[Python-ideas] Re: Add a "block" option to Executor.submit

> On 4 Sep 2019, at 22:58, Andrew Barnert wrote: > >> On Sep 4, 2019, at 10:17, Anders Hovmöller wrote: >> >>> . >> >> Doesn't all that imply that it'd be good if you could just pass it the queue >> object you want? > > Pass it a queue o

[Python-ideas] Re: Add a "block" option to Executor.submit

> On 4 Sep 2019, at 18:31, Andrew Barnert via Python-ideas > wrote: > > On Sep 4, 2019, at 04:21, Chris Simmons wrote: > > I have seen deployed servers that wrap an Executor with a Semaphore to add > this functionality (which is mildly silly, but not when the “better” > alternative is to

[Python-ideas] Re: Add a `dig` method to dictionaries supporting the retrieval of nested keys

> On 3 Sep 2019, at 14:56, Paul Moore wrote: > > On Tue, 3 Sep 2019 at 13:38, None via Python-ideas > wrote: > >> I really believe that a nested key retrieval mechanism should be a >> first-class offering of the standard library. It is extremely common in the >> Python ecosystem to find

[Python-ideas] Re: Custom string prefixes

> On 28 Aug 2019, at 14:09, Piotr Duda wrote: > > śr., 28 sie 2019 o 13:18 Steven D'Aprano napisał(a): >> >>> On Tue, Aug 27, 2019 at 05:13:41PM -, stpa...@gmail.com wrote: >>> >>> The difference between `x'...'` and `x('...')`, other than visual noise, is >>> the >>> following: >>>

[Python-ideas] Re: Extend ast with types for * instead of using raw lists

th Parso. In fact it's built in and way better because it keeps the formatting and comments! > Further, it is highly desirable for me to be able to turn the AST back into a > string (as astor allows) so that I can generate reasonable error messages and > debug. Then you really should loo

[Python-ideas] Re: Extend ast with types for * instead of using raw lists

Just to make sure we're on the same page: what are you using the ast module for? Maybe moving to another lib like parso actually helps your real problem more... > On 15 Aug 2019, at 22:02, Caleb Donovick wrote: > > When walking an ast it impossible to know the type of an empty list without

[Python-ideas] Re: For-expression/throwaway comprehension

> On 3 Aug 2019, at 12:18, Dan Sommers <2qdxy4rzwzuui...@potatochowder.com> > wrote: > > Once I know what SMTP is, and what the smtplib module does, > and I've used it a couple of times, then seeing the list of > names inside the module might remind me how to use it. > So maybe SMTP is an

[Python-ideas] Re: Add a "partial with placeholders" function to the functools module

> On 27 Jul 2019, at 21:10, Andrew Barnert wrote: > > On Jul 27, 2019, at 08:04, Anders Hovmöller wrote: >> >>> On 27 Jul 2019, at 14:47, Dominik Vilsmeier >>> wrote: >>> >>> currently, regarding positional arguments, `partial` gi

[Python-ideas] Re: Add a "partial with placeholders" function to the functools module

> On 27 Jul 2019, at 14:47, Dominik Vilsmeier wrote: > > Hello, > > currently, regarding positional arguments, `partial` gives us the option to > partialize functions from the left. There's been some interest about > partializing functions from the right instead (e.g. [SO post, 9k views,

[Python-ideas] Re: for ... except, with ... except

> On 27 Jul 2019, at 10:19, Serhiy Storchaka wrote: > > 26.07.19 23:57, Guido van Rossum пише: >> These are interesting ideas. It looks like you intend the except clause of >> the for loop to *only* cover the iter() and next() calls that are implicit >> in the for loop. You're right that

[Python-ideas] Re: Skip modules by default in star-import

> On 26 Jul 2019, at 22:53, Guido van Rossum wrote: > > Serhiy proposed a relatively minor change to the behavior of `import *` in > the absence of __all__. This sounds like an idea we could try though we > should have a look at the implications for various well-known packages. It is >

[Python-ideas] Re: Skip modules by default in star-import

> On 26 Jul 2019, at 20:58, Eric V. Smith wrote: > > On 7/26/2019 2:50 PM, Anders Hovmöller wrote: >>> On 26 Jul 2019, at 20:34, Serhiy Storchaka wrote: >>> >>> 26.07.19 21:10, Anders Hovmöller пише: >>>> This doesn't really solve

[Python-ideas] Re: Skip modules by default in star-import

> On 26 Jul 2019, at 21:50, Brendan Barnwell wrote: > >> On 2019-07-26 11:10, Anders Hovmöller wrote: >> This doesn't really solve the problem imo. Imported symbols shouldn't be i >> portable elsewhere. Not by import * or explicitly. That's the problem. >

[Python-ideas] Re: Skip modules by default in star-import

> On 26 Jul 2019, at 20:34, Serhiy Storchaka wrote: > > 26.07.19 21:10, Anders Hovmöller пише: >> This doesn't really solve the problem imo. Imported symbols shouldn't be i >> portable elsewhere. Not by import * or explicitly. That's the problem. > > I do no

[Python-ideas] Re: Skip modules by default in star-import

This doesn't really solve the problem imo. Imported symbols shouldn't be i portable elsewhere. Not by import * or explicitly. That's the problem. One could propose to fix this by doing: 1. Imported symbols and locally declared symbols are put in two different dicts 2. Deprecation warning when

[Python-ideas] Re: Namespace context managers

On 26 Jul 2019, at 14:25, Ricky Teachey wrote: >> a = 4 >> >> with Namespace("ns") as ns: >> a = 3 >> print(a) # prints "3", not "4" >> >> def func(): >> return a # Closes on ns.a, not global a >> >> assert isinstance(ns, types.ModuleType) >> assert ns.name = "ns" >>

[Python-ideas] Re: Non-standard evaluation for Python

> On 17 Jul 2019, at 21:00, Andrew Barnert wrote: > >> On Jul 17, 2019, at 10:45, Anders Hovmöller wrote: >> >>>> On 17 Jul 2019, at 19:08, Andrew Barnert wrote: >>>> >>>> On Jul 15, 2019, at 05:25, Anders Hovmöller wrote: >

[Python-ideas] Re: Non-standard evaluation for Python

> On 17 Jul 2019, at 19:08, Andrew Barnert wrote: > >> On Jul 15, 2019, at 05:25, Anders Hovmöller wrote: >> >> >>>>> (The fact that they’re positional, but passed as if they were keyword, >>>>> accepted as if they were keyword, and the

[Python-ideas] Re: Universal parsing library in the stdlib to alleviate security issues

> On 17 Jul 2019, at 06:30, Nam Nguyen wrote: > > On Mon, Jul 15, 2019 at 8:47 PM Andrew Barnert > wrote: > On Jul 15, 2019, at 18:44, Nam Nguyen > wrote: > >> I have implemented a tiny (~200 SLOCs) package at >>

[Python-ideas] Re: Non-standard evaluation for Python

> On 15 Jul 2019, at 10:23, Andrew Barnert wrote: > >> On Jul 15, 2019, at 00:27, Anders Hovmöller wrote: >> >> >>> On 14 Jul 2019, at 22:46, Andrew Barnert wrote: >>> >>> But this doesn’t in any way help with late eval. >> &

[Python-ideas] Re: Non-standard evaluation for Python

> On 14 Jul 2019, at 22:46, Andrew Barnert wrote: > >>> First, the function only gets the names, not live expressions that it can >>> eval late, or in a modified environment, etc., so it only handles this >>> case, not cases like df[year>1990]. >> >> I don't understand how it's not the full

[Python-ideas] Re: Non-standard evaluation for Python

> On 14 Jul 2019, at 20:21, Andrew Barnert wrote: > >> On Jul 14, 2019, at 00:33, Anders Hovmöller wrote: >> >> This use case is nicely covered by short form for keyword arguments. So in >> this case instead of plot(x, z), we'd have plot(=x, =z) which woul

[Python-ideas] Re: Non-standard evaluation for Python

This use case is nicely covered by short form for keyword arguments. So in this case instead of plot(x, z), we'd have plot(=x, =z) which would be transformed into plot(**{'x': x, 'z': z}) at compile time. This could work for any expression: foo(=lamda x: x*2) -> foo(**{'lamda x: x*2': lamda x:

[Python-ideas] Re: [Python-Dev] strip behavior provides inconsistent results with certain strings

I'm a big +1. I prefer strip_prefix/strip_suffix but only by a little bit. > On 1 Jul 2019, at 21:34, Kirill Balunov wrote: > >> This was quite extensively discussed on python-ideas recently: >> >>

[Python-ideas] Re: something like sscanf for Python

> On 28 Jun 2019, at 19:01, Rhodri James wrote: > > On 27/06/2019 18:58, James Lu wrote: >>> On Jun 26, 2019, at 7:13 PM, Chris Angelico wrote: >>> >>> The main advantage of sscanf over a regular expression is that it >>> performs a single left-to-right pass over the format string and the

[Python-ideas] Re: A proposal (and implementation) to add assignment and LOAD overloading

> On 26 Jun 2019, at 16:46, Chris Angelico wrote: > >> On Thu, Jun 27, 2019 at 12:37 AM Anders Hovmöller >> wrote: >> >>>> On 26 Jun 2019, at 14:28, Rhodri James wrote: >>>> >>>> On 26/06/2019 08:34, Yanghao Hua wro

[Python-ideas] Re: A proposal (and implementation) to add assignment and LOAD overloading

> On 26 Jun 2019, at 14:28, Rhodri James wrote: > >> On 26/06/2019 08:34, Yanghao Hua wrote: >> I find the objection reasoning very strange as none of the default >> behavior changed, and yet if you use this feature you do need to worry >> about the object behavior regarding assignment, this

[Python-ideas] Re: Comparison operator support (>= and <=) for type

> On 14 Jun 2019, at 11:31, Steven D'Aprano wrote: > >> On Fri, Jun 14, 2019 at 08:02:15AM -, eminbugrasaral--- via Python-ideas >> wrote: >> class Base: >>pass >> >> class A(Base): >>pass > [...] > >> While we can do `A == B`, or `B == C` or `B == B`, I would expect to >> be

Re: [Python-ideas] Operator as first class citizens -- like in scala -- or yet another new operator?

> On 24 May 2019, at 22:11, Yanghao Hua wrote: > >> On Fri, May 24, 2019 at 3:27 PM Ricky Teachey wrote: >> This seems like a hurdle you're going to have trouble passing... especially >> given that all the functionality that is required can be provided using >> existing descriptor

Re: [Python-ideas] Passing positional arguments as keyword arguments (to provide function arguments out of order)

> On 16 May 2019, at 08:50, Serhiy Storchaka wrote: > > 16.05.19 08:46, Anders Hovmöller пише: >> In the general case because of features that until / was introduced was >> unique to functions defined in C. But in the case of the dict constructor >> that's just a

Re: [Python-ideas] Passing positional arguments as keyword arguments (to provide function arguments out of order)

> On 15 May 2019, at 21:55, Jonathan Goble wrote: > >> On Wed, May 15, 2019 at 3:45 AM Anders Hovmöller wrote: >> >>> On 15 May 2019, at 07:51, Jonathan Goble wrote: >>> >>> That's not a realistic goal; there are some use cases, i

Re: [Python-ideas] Passing positional arguments as keyword arguments (to provide function arguments out of order)

> On 15 May 2019, at 07:51, Jonathan Goble wrote: > > That's not a realistic goal; there are some use cases, including in > CPython builtins, that cannot be accomplished without positional-only > arguments. For example, the current behavior of the `dict` constructor > is to accept both

Re: [Python-ideas] Passing positional arguments as keyword arguments (to provide function arguments out of order)

> On 15 May 2019, at 03:07, Robert Vanden Eynde wrote: > > Currently if one wants to provide positional arguments after keyword > arguments, it's not possible, one must begin with positional arguments [1] or > use keyword arguments [2] : I'm my opinion the goal should be that there is no

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

> On 14 May 2019, at 14:13, Steven D'Aprano wrote: > >> On Tue, May 14, 2019 at 10:37:57AM +0300, Serge Matveenko wrote: >> >> My point was that in case of `os.symlink` vs `shutil.symlink` it is >> not obvious how they are different even taking into account their >> namespaces. > > Okay,

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

> On 14 May 2019, at 04:24, Steven D'Aprano wrote: > > It's not "cryptic" that Paris, France is difference from Paris, Texas. > Let's not abuse the word "cryptic" for things which are easy to resolve. I'm sorry I thought you were the one arguing FOR using the same word for two very

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

> On 14 May 2019, at 04:24, Steven D'Aprano wrote: > > *wink*. Function names are mnemonics, not documentation. Certainly not with that attitude. But it easily could be. Maybe you would be fine with a language where all function names are just hex values? *wink* (yes I think this was rude

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

> On 14 May 2019, at 03:33, Steven D'Aprano wrote: > >> On Tue, May 14, 2019 at 12:22:05AM +0300, Serge Matveenko wrote: >> >> As a regular library user, I see and expect no obvious difference >> between `os.symlink` and `shutil.symlink`. > > You "see ... no obvious difference" between two

  1   2   3   >