[Python-ideas] Deprecate/change the behaviour of ~bool

Currently ~False is -1 and ~True is -2. Would be nicer if ~bool was the same as not bool. Hopefully nobody actually relies on this but nevertheless, it would be a backwards-incompatible change so the whole deprecation warnings and whatnot would be required. In particular, this is nice for xnor

[Python-ideas] Re: Deprecate/change the behaviour of ~bool

wrote: On Mon, Feb 22, 2021 at 10:11:14PM -0300, Soni L. wrote: > Currently ~False is -1 and ~True is -2. Would be nicer if ~bool was the > same as not bool. That's your opinion. I disagree. Bitwise-not is not the same thing as boolean-not, and they should not be spelled the same, esp

[Python-ideas] Re: Deprecate/change the behaviour of ~bool

On 2021-02-23 7:10 p.m., Steven D'Aprano wrote: On Tue, Feb 23, 2021 at 01:57:08PM -0300, Soni L. wrote: > What about getting the parser to recognize ^~ as an XNOR operator and > have __xnor__ on bools actually do xnor on bools? Make xnor a real > operator by fusing two oper

[Python-ideas] Re: Have virtual environments led to neglect of the actual environment?

On 2021-02-23 9:45 p.m., Random832 wrote: I was reading a discussion thread about various issues with the Debian packaged version of Python, and the following statement stood out for me as shocking: Christian Heimes wrote: >

[Python-ideas] "except;" - semicolon after except, to get rid of indentation when doing error recovery

Sometimes it would be useful to be able to write: def foo():   try: return thing()   except ValueError;   try: return otherthing()   except ValueError;   try: return yetotherthing()   except ValueError;   if shouldraise(): raise But currently this needs to be written like so: def foo():   try: r

[Python-ideas] Re: "except;" - semicolon after except, to get rid of indentation when doing error recovery

with a return, and no finally block would be allowed. > > > > > On Tue, 15 Jun 2021 at 21:58, Chris Angelico <mailto:[email protected]>> wrote: > > On Wed, Jun 16, 2021 at 10:51 AM Soni L. <mailto:fakedme%[email protected]>> wrote: > > >

[Python-ideas] Re: Extension methods in Python

On 2021-06-20 7:48 p.m., Steven D'Aprano wrote: > The technique you are calling "extension methods" is known as > "monkey-patching" in Python and Ruby. > > With respect to a fine language, Kotlin, it doesn't have the user-base > of either Python or Ruby. Python does not allow monkey-patching b

[Python-ideas] Re: Extension methods in Python

On 2021-06-21 12:26 p.m., Stephen J. Turnbull wrote: > Soni L. writes: > > > The trick to extension methods is that they're only available when you > > explicitly use them. > > What does "explicitly use them" mean? How does this help avoid the > kind

[Python-ideas] Re: Extension methods in Python

On 2021-06-21 12:49 p.m., Chris Angelico wrote: > On Tue, Jun 22, 2021 at 1:44 AM Soni L. wrote: > > > > > > > > On 2021-06-21 12:26 p.m., Stephen J. Turnbull wrote: > > > Soni L. writes: > > > > > > > The trick to extension methods is

[Python-ideas] Re: Extension methods in Python

On 2021-06-21 3:01 p.m., Chris Angelico wrote: > Thanks for clarifying. This doesn't change the problem though - it > just changes where the issue shows up. (BTW, what you're describing is > closer to __getattribute__ than it is to __getattr__, so if you're > proposing this as the semantics, I st

[Python-ideas] Re: Extension methods in Python

On 2021-06-21 8:42 p.m., Steven D'Aprano wrote: > On Mon, Jun 21, 2021 at 02:54:52PM -0300, Soni L. wrote: > > > Quite the opposite. You ask the local module (the one that the code was > > compiled in), and the module decides whether/when to ask the object itself. > &g

[Python-ideas] Re: Extension methods in Python

per scope, but in practice it's per module because nobody would actually use this per scope even tho they could. :p > > On Tue, 22 Jun 2021, 00:55 Soni L., <mailto:fakedme%[email protected]>> wrote: > > > > On 2021-06-21 8:42 p.m., Steven D'Aprano wrote: >

[Python-ideas] Re: Extension methods in Python

On 2021-06-21 9:39 p.m., Steven D'Aprano wrote: > > Fourth step is that you go ahead and use lists as normal. Whether you > use getattr or dot syntax, any extension methods defined in spam.py will > show up, as if they were actual list methods. > > hasattr([], 'head') # returns True >

[Python-ideas] Re: Extension methods in Python

ry Soni, I don't understand what you are arguing here. See below. > > > On Mon, Jun 21, 2021 at 10:09:17PM -0300, Soni L. wrote: > > > > > > On 2021-06-21 9:39 p.m., Steven D'Aprano wrote: > > > > > > > > > > Fourth step is that you

[Python-ideas] Re: Extension methods in Python

On 2021-06-22 9:25 a.m., Chris Angelico wrote: > (Oh, and another wrinkle, although a small one: Code objects would > need to keep track of their modules. Currently functions do, but code > objects don't. But that seems unlikely to introduce further > complications.) What? No you just stop emit

[Python-ideas] Re: Extension methods in Python

On 2021-06-22 3:43 p.m., Brendan Barnwell wrote: > On 2021-06-22 05:14, Chris Angelico wrote: >> Fair point. However, I've worked with a good number of languages that >> have some notion of object methods, and generally, an object has or >> doesn't have a method based on what the object*is*, not

[Python-ideas] Re: Extension methods in Python

On 2021-06-22 5:23 p.m., Chris Angelico wrote: > On Wed, Jun 23, 2021 at 6:13 AM Soni L. wrote: > > Think about it like this, extension methods give you the ability to make > > imported functions that look like this: > > > > foo(bar, baz) > > > > look

[Python-ideas] Re: Extension methods in Python

On 2021-06-22 5:54 p.m., Chris Angelico wrote: > On Wed, Jun 23, 2021 at 6:41 AM Soni L. wrote: > > > > > > > > On 2021-06-22 5:23 p.m., Chris Angelico wrote: > > > On Wed, Jun 23, 2021 at 6:13 AM Soni L. wrote: > > > > Think about it like this

[Python-ideas] Re: Extension methods in Python

On 2021-06-22 5:34 p.m., Brendan Barnwell wrote: > On 2021-06-22 13:09, Soni L. wrote: >> Think about it like this, extension methods give you the ability to make >> imported functions that look like this: >> >> foo(bar, baz) >> >> look like this inste

[Python-ideas] Re: Extension methods in Python

On 2021-06-22 7:38 p.m., Chris Angelico wrote: > On Wed, Jun 23, 2021 at 8:30 AM Soni L. wrote: > > > > > > > > On 2021-06-22 5:54 p.m., Chris Angelico wrote: > > > On Wed, Jun 23, 2021 at 6:41 AM Soni L. wrote: > > > > It would have local s

[Python-ideas] Re: Extension methods in Python

On 2021-06-22 8:11 p.m., Chris Angelico wrote: > On Wed, Jun 23, 2021 at 9:06 AM Soni L. wrote: > > On 2021-06-22 7:38 p.m., Chris Angelico wrote: > > > Have you actually tried designing this into a larger project to see > > > what problems you run into, or is

[Python-ideas] Re: Extension methods in Python

On 2021-06-23 5:21 a.m., Steven D'Aprano wrote: > On Tue, Jun 22, 2021 at 08:44:56AM -0300, Soni L. wrote: > > > Oh this is a long one. > > > > Hypothetically, let's say you have a proxy object: > > > > class Foo: > >   def __getat

[Python-ideas] Re: Extension methods in Python

On 2021-06-23 10:21 a.m., Steven D'Aprano wrote: > > What about other functions implemented in C? If I write a C module > > that calls PyObject_GetAttr, does it behave as if dot notation were > > used in the module that called me, or does it use my module's > > extension methods? > > That depend

[Python-ideas] Better exception handling hygiene

So uh, this is a hardly at all fleshed out idea, but one thing we really don't like about python is having to do stuff like this so as to not swallow exceptions: def a_potentially_recursive_function(some, args):   """   Does stuff and things.   Raises ExceptionWeCareAbout under so and so condition

[Python-ideas] Re: Better exception handling hygiene

On 2021-09-29 10:09 p.m., Chris Angelico wrote: > On Thu, Sep 30, 2021 at 11:03 AM Soni L. wrote: > > > > So uh, this is a hardly at all fleshed out idea, but one thing we really > > don't like about python is having to do stuff like this so as to not > >

[Python-ideas] Re: Better exception handling hygiene

On 2021-09-29 11:46 p.m., Steven D'Aprano wrote: > In Soni's original code snippet, there is a clear separation of code > that is inside the try block from code that is outside the try block: > > > def a_potentially_recursive_function(some, args): > >   try: > > some.user_code() > > ex

[Python-ideas] Re: Better exception handling hygiene

On 2021-09-30 4:15 a.m., Steven D'Aprano wrote: > On Thu, Sep 30, 2021 at 12:03:37AM -0300, Soni L. wrote: > > > > Only some.user_code is guarded by the try block. If it turns out that > > > code_we_assume_is_safe is not actually safe, and fails with an > >

[Python-ideas] Re: Better exception handling hygiene

On 2021-09-30 10:08 a.m., Chris Angelico wrote: > On Thu, Sep 30, 2021 at 8:43 PM Soni L. wrote: > > You misnderstand exception hygiene. It isn't about "do the least stuff > > in try blocks", but about "don't shadow unrelated exceptions into your > >

[Python-ideas] Re: Better exception handling hygiene

On 2021-09-30 11:23 a.m., Chris Angelico wrote: > > For example this: (real code) > > > > def get_property_values(self, prop): > > try: > > factory = self.get_supported_properties()[prop] > > except KeyError as exc: raise PropertyError from exc > > iterator

[Python-ideas] Re: Better exception handling hygiene

ad. this gives you far more control over what your API exceptions, the exceptions you documented in your function's documentation, are, and especially under which conditions they'll actually be raised (and be catchable by the caller). this is what we mean by exception hygiene. On 2021-09-29

[Python-ideas] Re: Better exception handling hygiene

On 2021-09-30 2:04 p.m., Chris Angelico wrote: > On Fri, Oct 1, 2021 at 1:10 AM Soni L. wrote: > > > > > > > > On 2021-09-30 11:23 a.m., Chris Angelico wrote: > > > > For example this: (real code) > > > > > > > &g

[Python-ideas] Re: Better exception handling hygiene

On 2021-09-30 5:34 p.m., Barry Scott wrote: > > >> On 30 Sep 2021, at 17:25, Soni L. > <mailto:[email protected]>> wrote: >> >> Alright, some ppl asked us to rephrase this, so: >> >> The plan is to take the function syntax: >> >>

[Python-ideas] Re: Better exception handling hygiene

On 2021-09-30 6:08 p.m., Chris Angelico wrote: > I still think that your use of LookupError is confusing the issue > somewhat, partly because it's a base class rather than something > that's ever raised per se. > > If you were using a custom exception type, how likely is it that that > exception

[Python-ideas] Re: Better exception handling hygiene

On 2021-10-01 2:04 a.m., Steven D'Aprano wrote: > Let's get to the fundamental problem with this. It is DWIM magic, and > you haven't (as far as I have seen) yet specified how we are supposed to > use it or predict how it is supposed to work. > > Here is your syntax again: > > > > def a_pot

[Python-ideas] Re: Better exception handling hygiene

On 2021-10-01 8:26 a.m., Steven D'Aprano wrote: > On Thu, Sep 30, 2021 at 01:25:42PM -0300, Soni L. wrote: > > >     def foo(): > >     raise Bar > >     def baz() with Bar: > >     foo() > >     baz() > > > > would make a Runtim

[Python-ideas] Re: Better exception handling hygiene

nks for insisting on context managers. Does the attached context manager clarify what the proposal is about? # Antichecked Exceptions for Python # Copyright (c) 2021 Soni L. # # Permission is hereby granted, free of charge, to any person ("You") obtaining # a copy of this software and assoc

[Python-ideas] Antichecked exceptions

PEP 479 introduced this idea that basically boils down to raising your exceptions only when you mean it. Specifically: generators only raise StopIteration when they return/exit/terminate. And they prevent the user from raising it under other circumstances. Can we call this "antichecked exceptions

[Python-ideas] Why not accept lists or arbitrary iterables in str.endswith?

I'm parsing configs for domain filtering rules, and they come as a list. However, str.endswith requires a tuple. So I need to use str.endswith(tuple(list)). I don't know the reasoning for this, but why not just accept a list as well? ___ Python-ideas

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

foo.setParseAction(lambda a, b, c: raise FuckPython(":(")) is invalid syntax, which makes pyparsing useless. ___ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/m

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

that's a waste of a perfectly good name in the namespace. On 2019-10-27 11:27 a.m., Anders Hovmöller wrote: 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(":(")) i

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

On 2019-10-27 12:14 p.m., Eric V. Smith wrote: On 10/27/2019 10:35 AM, Soni L. wrote: that's a waste of a perfectly good name in the namespace. Names are cheap. If "wasting" a name is a concern, then perhaps Python isn't the language for you. It also lacks local scopes

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

On 2019-11-03 12:24 p.m., Andrew Barnert via Python-ideas wrote: On Nov 2, 2019, at 21:02, Random832 wrote: > >> On Sun, Oct 27, 2019, at 19:17, Andrew Barnert via Python-ideas wrote: >>> On Oct 27, 2019, at 15:07, Ben Rudiak-Gould wrote: >>> >>> throw is an expression, not a statement, in

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

On 2019-11-03 2:01 p.m., Andrew Barnert wrote: On Nov 3, 2019, at 15:38, Soni L. wrote: >> > Or, C#'s throw is allowed in certain specific contexts (lambda bodies and conditional expressions) without being a general expression. >> Just like, e.g., yield_expr is a

[Python-ideas] Re: Using 'with' with extra brackets for nicer indentation

On 2019-11-18 9:10 a.m., Oscar Benjamin wrote: [snip] To me that seems clumsy and awkward compared to nested though: with nested(*map(open, filenames)) as files: ... Ideally I would design nested to take an iterable rather than *args and then it would be fine to do e.g. with nested(ope

[Python-ideas] Re: Using 'with' with extra brackets for nicer indentation

On 2019-11-18 11:32 a.m., Oscar Benjamin wrote: On Mon, 18 Nov 2019 at 13:12, Soni L. wrote: > > On 2019-11-18 9:10 a.m., Oscar Benjamin wrote: > > [snip] > > > > To me that seems clumsy and awkward compared to nested though: > > > > with ne

[Python-ideas] Re: Using 'with' with extra brackets for nicer indentation

On 2019-11-18 5:13 p.m., Andrew Barnert via Python-ideas wrote: On Nov 18, 2019, at 10:51, Random832 wrote: > > On Mon, Nov 18, 2019, at 12:46, Paul Moore wrote: >> But open() isn't designed *just* to be used in a with statement. It >> can be used independently as well. What about >> >>

[Python-ideas] Re: Using 'with' with extra brackets for nicer indentation

On 2019-11-18 5:22 p.m., Soni L. wrote: On 2019-11-18 5:13 p.m., Andrew Barnert via Python-ideas wrote: On Nov 18, 2019, at 10:51, Random832 wrote: > > On Mon, Nov 18, 2019, at 12:46, Paul Moore wrote: >> But open() isn't designed *just* to be used in a with statement.

[Python-ideas] Re: Using 'with' with extra brackets for nicer indentation

On 2019-11-18 10:59 p.m., Andrew Barnert wrote: On Nov 18, 2019, at 16:35, Soni L. wrote: > > >> On 2019-11-18 5:22 p.m., Soni L. wrote: >> >> >>> On 2019-11-18 5:13 p.m., Andrew Barnert via Python-ideas wrote: >>>> On Nov 18, 2019, at 10:

[Python-ideas] Re: Using 'with' with extra brackets for nicer indentation

On 2019-11-19 3:37 p.m., Rhodri James wrote: On 19/11/2019 17:12, Brian Skinn wrote: @jayvdb on GitHub and I are working on a new version of one of my packages, stdio-mgr (https://github.com/bskinn/stdio-mgr), with a dramatically expanded API and capabilities. Context managers feature heavi

[Python-ideas] namedtuple for dict.items()/collections.abc.Mappings.items()

I have a lot of code that looks like this:     def filter(self, it, defs):     for x in it:     for y in _match_helper(self.key, defs, x[0]):     yield (y, x[1])     def filter(self, it):     for el in it:     try:     if self.compiled.search(el[0]

[Python-ideas] Re: namedtuple for dict.items()/collections.abc.Mappings.items()

On 2019-12-01 10:11 a.m., Kyle Stanley wrote: >>> for item in data.items(): item[0], item[1] 874 µs ± 21.5 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each) >>> for key, value in data.items(): key, value 524 µs ± 4.26 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each) >>> for ite

[Python-ideas] Sets for easy interning(?)

This is an odd request but it'd be nice if, given a set s = {"foo"}, s["foo"] returned the "foo" object that is actually in the set, or KeyError if the object is not present. Even use-cases where you have different objects whose differences are ignored for __eq__ and __hash__ and you want to g

[Python-ideas] Re: Sets for easy interning(?)

On 2019-12-03 8:34 a.m., Steven D'Aprano wrote: On Tue, Dec 03, 2019 at 01:54:44AM -0800, Andrew Barnert via Python-ideas wrote: > On Dec 2, 2019, at 16:27, Soni L. wrote: > > > > Even use-cases where you have different objects whose differences are ignored for __eq__

[Python-ideas] Re: Sets for easy interning(?)

On 2019-12-03 8:44 p.m., Greg Ewing wrote: On 4/12/19 7:26 am, Andrew Barnert via Python-ideas wrote: If you’re using interning for functionality, to distinguish two equal strings that came from different inputs or processes, your code is probably broken. That's not what interning is normal

[Python-ideas] Re: Suggestion for language addition

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 pseudo code that may or may not match any previous proposal: for x i

[Python-ideas] Re: Suggestion for language addition

On 2019-12-04 6:05 p.m., Anders Hovmöller wrote: > 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 ap

[Python-ideas] Re: lowercase exception names trip-up .

On 2019-12-06 3:58 p.m., Christopher Barker wrote: I notice that most(all?) of those are from pretty old modules, which explains the "old", pre PEP-8 names. I think it would be good to clean this up with a set of aliases -- but it is a fair bit of code-churn for not much real gain. I guess i

[Python-ideas] Re: Change StopIteration handling inside generator-like builtins

On 2019-12-08 12:38 p.m., Chris Angelico wrote: On Mon, Dec 9, 2019 at 1:57 AM Oscar Benjamin wrote: > > On Sun, 8 Dec 2019 at 14:37, Chris Angelico wrote: > > > > PEP 479 (https://www.python.org/dev/peps/pep-0479/) changed the rules > > around generators: if it would have leaked StopIterati

[Python-ideas] Re: Sets for easy interning(?)

On 2019-12-11 7:40 a.m., Jonathan Fine wrote: Consider these two examples: >>> {0} == {0.0} == {False} True >>> hash(0) == hash(0.0) == hash(False) True >>> 0.0 in {False} True >>> class mystr(str): pass >>> 'hi' in {mystr('hi')} True The original poster want a way to obtain the actual objec

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

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 | _ | 0 | (none) 0 | _ | 1 | 3 1 | 0 | _ | 1,3 1 | 1 | _ | 1,2,3 and each statement is evaluated once, when encountered. (as such, y and z may not be evaluated at a

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

On 2019-12-21 4:15 p.m., Andrew Barnert wrote: > On Dec 21, 2019, at 08:41, 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 | resul

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

On 2019-12-21 4:52 p.m., Chris Angelico wrote: On Sun, Dec 22, 2019 at 6:35 AM Soni L. wrote: > > > > On 2019-12-21 4:15 p.m., Andrew Barnert wrote: > > > On Dec 21, 2019, at 08:41, Soni L. wrote: > > > > > > I'd like to see the ability to d

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

end-all of programming. Python is not an OOP language. If you want to breathe and preach OOP, you should quite frankly just use Java. Le sam. 21 déc. 2019 à 20:32, Soni L. <mailto:fakedme%[email protected]>> a écrit : On 2019-12-21 4:15 p.m., Andrew Barnert wrote: > > On

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

he chance of engaging in a productive discussion and perhaps learning a new perspective. Oh. Okay. Fair enough. Sorry, Gregory. On Sat, Dec 21, 2019 at 3:10 PM Soni L. <mailto:fakedme%[email protected]>> wrote: On 2019-12-21 4:58 p.m., Gregory Salvan wrote: Years ago ther

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

On 2019-12-21 5:22 p.m., Chris Angelico wrote: On Sun, Dec 22, 2019 at 7:06 AM Soni L. wrote: > On 2019-12-21 4:52 p.m., Chris Angelico wrote: > > I'm not sure I understand what switch construct would translate into > > this style. Can you show an example of code in

[Python-ideas] Re: Alternative to `enumerate` and `range(len(sequence))`: indexes() and entries()

You want Lua. and pairs(). I have my own pairs() implementation as part of my library. It handles the following: - Sequence becomes enumerate(seq) - Mapping becomes seq.items() - Set becomes ((x,x) for x in set) - Everything else is an error. (Arguably Set should be (x, None) or (x, True) or

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

I would like this code to work, but currently python ignores __subclasscheck__ in many places where it checks for subclasses: class MM(type):     def __subclasscheck__(self, subclass):     return issubclass(subclass, type) class M(type, metaclass=MM):     pass class N(type):     pass c

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

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

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

ple you're trying to post before posting it. > On 31 Dec 2019, at 19:19, Soni L. wrote: > > Okay. How about this then: > > class MM(type): > def __subclasscheck__(self, subclass): > return issubclass(subclass, type) > > > class M(type, me

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

On 2019-12-31 3:56 p.m., Andrew Barnert wrote: On Dec 31, 2019, at 09:43, Soni L. wrote: > > I would like this code to work, but currently python ignores __subclasscheck__ in many places where it checks for subclasses: > > class MM(type): > def __subclasscheck__

[Python-ideas] Re: Target-and-expression lists and if-try

On 2019-12-31 7:28 p.m., Andrew Barnert via Python-ideas wrote: Every so often, someone suggests that Python should have a pattern matching case statement like Scala, C#, Swift, Haskell, etc. Or they just suggest that “Python needs algebraic data types” but end up concluding that the biggest

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

On 2019-12-31 4:28 p.m., Andrew Barnert wrote: On Dec 31, 2019, at 11:02, Soni L. wrote: > > >> On 2019-12-31 3:56 p.m., Andrew Barnert wrote: >> On Dec 31, 2019, at 09:43, Soni L. wrote: >> > > I would like this code to work, but currently python igno

[Python-ideas] python -m quality of life improvements

currently python -m requires you to cwd to the desired package root. I'd like to suggest the ability to python -m relative/path/to/package/root/module.submodule and python -m /absolute/path/to/package/root/module.submodule thoughts? ___ Python-ideas

[Python-ideas] Re: python -m quality of life improvements

On 2020-01-11 4:06 a.m., Andrew Barnert via Python-ideas wrote: On Jan 10, 2020, at 20:40, Steven D'Aprano wrote: > > On Fri, Jan 10, 2020 at 11:53:10PM -0300, Soni L. wrote: >> currently python -m requires you to cwd to the desired package root. I'd >> li

[Python-ideas] Re: python -m quality of life improvements

20-01-11 2:21 p.m., Steven D'Aprano wrote: On Sat, Jan 11, 2020 at 11:27:51AM -0300, Soni L. wrote: > PYTHONPATH=foo/bar python -m baz.qux > > becomes > > python -m foo/bar/baz.qux > > which is less of a kludge. Sorry Soni, I completely disagree with you. The stat

[Python-ideas] Re: python -m quality of life improvements

in if it does `export PYTHONPATH`. Then, I have this alias for one of my home-brewed tools, and it works as I want: alias chubby='PYTHONPATH=~/chubby ~/.virtualenvs/chubby/bin/python -Oum chubby' I too think that the semantics of `python -m` are fine. On Sat, Jan 11, 2020

[Python-ideas] Re: python -m quality of life improvements

es `import` follows under `PYTHONPATH`. What you're asking for is that `python` sets `PYTHONPATH` before executing a module. Maybe another option to `python`? python -p /path/to -m foo I would agree that would be nice. On Sat, Jan 11, 2020 at 6:07 PM Soni L. <mailto:fakedme%

[Python-ideas] Re: python -m quality of life improvements

On 2020-01-11 8:33 p.m., Andrew Barnert wrote: On Jan 11, 2020, at 14:09, Soni L. wrote: > >  why are we allowed to have fancy `python /path/to/foo.py` but not fancy `python -m /path/to/foo`? There’s nothing fancy about the first one. It’s a path, and it’s up to your OS what a path

[Python-ideas] Re: python -m quality of life improvements

On 2020-01-11 9:01 p.m., Steven D'Aprano wrote: On Sat, Jan 11, 2020 at 02:46:14PM -0300, Soni L. wrote: > I just want python foo/bar/baz/qux/__main__.py but with imports that > actually work. -m works, but requires you to cd. -m with path would be > an more than huge improve

[Python-ideas] Re: python -m quality of life improvements

On 2020-01-11 10:30 p.m., Juancarlo Añez wrote: The biggest difference is that scripts can't do relative imports. So here's a counter-proposal: Allow "from . import modulename" to import "modulename.py" from the directory that contains the script that Python first executed (or,

[Python-ideas] Re: python -m quality of life improvements

Consider a directory structure like this one: ganarchy/ ├── cli │   ├── debug.py │   ├── __init__.py │   └── __pycache__ ├── config.py ├── __init__.py ├── __main__.py └── __pycache__ abdl/ ├── exceptions.py ├── __init__.py ├── _parser.py ├── __pycache__ ├── validators.py └── _vm.py If one cd'd t

[Python-ideas] Re: python -m quality of life improvements

PS: typoed "~/git" as "~/.git", oops. sorry. On 2020-01-12 11:09 a.m., Soni L. wrote: Consider a directory structure like this one: ganarchy/ ├── cli │   ├── debug.py │   ├── __init__.py │   └── __pycache__ ├── config.py ├── __init__.py ├── __main__.py └── __pycache__ abd

[Python-ideas] Re: python -m quality of life improvements

None of this is even about relative imports. Absolute imports are also broken between them, as I tried to demonstrate using my project structure. The *whole* import system breaks. On 2020-01-12 3:12 p.m., Brendan Barnwell wrote: On 2020-01-11 23:34, Steven D'Aprano wrote: On Sun, Jan 12, 2020

[Python-ideas] f(doc)string resource imports

We have importlib resources. We should put it to use. Imagine if you could separate your docs from your code and yet include them in your package. ``` f"""{from mymodule.docs include main.rst}""" def foo():   f"""{from mymodule.docs include foo.rst}"""   pass class Bar:   f"""{from mymodule.

[Python-ideas] Resource imports (as strings/bytes)

We have importlib. We have importlib.resources. We can import modules. We cannot (yet) import resources using the same-ish module import machinery. It would be nice if we could. I'm thinking of something like: from foo.bar import resources "foo.txt" as foo, "bar.txt" as bar # string imports f

[Python-ideas] Re: Resource imports (as strings/bytes)

thus far in my career. What does this achieve which reading the file and then writing the file does not? uses the import machinery. On Sun, Jan 19, 2020 at 11:11 PM Soni L. <mailto:fakedme%[email protected]>> wrote: We have importlib. We have importlib.resources. We can import m

[Python-ideas] Re: Resource imports (as strings/bytes)

On 2020-01-20 12:48 a.m., Andrew Barnert wrote: On Jan 19, 2020, at 15:10, Soni L. wrote: > > We have importlib. We have importlib.resources. We can import modules. We cannot (yet) import resources using the same-ish module import machinery. First, do you know about setuptools res

[Python-ideas] Re: Resource imports (as strings/bytes)

On 2020-01-20 1:52 a.m., Andrew Barnert wrote: On Jan 19, 2020, at 20:13, Soni L. wrote: > > >> On 2020-01-20 12:48 a.m., Andrew Barnert wrote: >> On Jan 19, 2020, at 15:10, Soni L. wrote: >> > > We have importlib. We have importlib.resources. We can i

[Python-ideas] Re: Resource imports (as strings/bytes)

On 2020-01-20 5:54 a.m., Steven D'Aprano wrote: On Sun, Jan 19, 2020 at 08:09:32PM -0300, Soni L. wrote: > We have importlib. We have importlib.resources. We can import modules. > We cannot (yet) import resources using the same-ish module import machinery. Actually we

[Python-ideas] Re: Resource imports (as strings/bytes)

On 2020-01-20 5:13 p.m., Steven D'Aprano wrote: Soni, you seem to be using Thunderbird as a mail client. As far as I remember from my time with Thunderbird, it allows, and makes it quite simple, to trim your quoting. There's no need to quote an entire 100 line message to add a single one senten

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

On 2020-01-30 7:17 p.m., Andrew Barnert via Python-ideas wrote: On Jan 30, 2020, at 11:20, Johan Vergeer wrote: > ## Attribute names > > You should be able to get the name of an attribute. > > ```python > class Foo: >bar: str = "Hello" > >def __init__(self): >self.baz =

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

On 2020-01-31 2:36 p.m., Andrew Barnert wrote: On Jan 31, 2020, at 08:03, Soni L. wrote: > > Consider: > > x=nameof(foo.bar) > > in today's python becomes: > > foo.bar > x="bar" > > and when running this you get an AttributeError or s

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

On 2020-02-01 12:00 a.m., Andrew Barnert wrote: On Jan 31, 2020, at 14:51, Soni L. wrote: >>> On 2020-01-31 2:36 p.m., Andrew Barnert wrote: >> That does work, but that means foo.bar has to exist and have a value before you look up the name. Consider these cases: &

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

On 2020-02-02 12:08 p.m., Jeff Allen wrote: On 01/02/2020 02:48, Richard Damon wrote: On 1/31/20 9:28 PM, Christopher Barker wrote: I am really confused by this whole thread: My understanding is that the impetus of the request is that if you start from an expression like nameof(foo.bar) to

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

On 2020-02-02 2:00 p.m., Johan Vergeer wrote: This would look pretty nice when it would just be used in f-strings. My proposal isn't just about f-strings though. It should also allow developers to get the name of a variable, class, method or function anywhere else. where do you want to do

[Python-ideas] Annotated string literals

It'd be cool to attach metadata to string literals that doesn't end up in the resulting string object. This metadata could be used by all sorts of tools, everything from localization to refactoring. In C, some localization libraries use macros for it, such as: #define LOCALIZE(s) s and it act

[Python-ideas] Re: Annotated string literals

On 2020-02-02 11:29 p.m., Eric V. Smith wrote: On 2/2/2020 8:28 PM, Soni L. wrote: It'd be cool to attach metadata to string literals that doesn't end up in the resulting string object. This metadata could be used by all sorts of tools, everything from localization to refactori

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

On 2020-02-04 3:33 a.m., Bruce Leban wrote: Here is a much more readable alternative which has the advantage that it is already supported by Python. I'm going to show a harder example where I want to reference foo.bar and allow both foo and bar to be refactored. Here's the original proposa

[Python-ideas] Re: allow full expressions in decorators

why not add an identity function to the builtins? @noop(buttons[0].clicked.connect) def foo():   ... # do whatever On 2020-02-03 9:08 p.m., Guido van Rossum wrote: I’ve always resisted changing this, but it keeps coming up, and in other cases we don’t restrict the grammar (except when there are

[Python-ideas] Re: Really long ints

that's not such a good idea if you can't specify base. On 2020-02-04 8:17 p.m., Ricky Teachey wrote: Why not just build the number using some kind of fancy "continuing integer" constructor function? Then you could just use commas, Blacken the code, and it will look great, right? P = my_int_ma

  1   2   3   >