[Python-ideas] Deprecate PEP 249 (DB-API 2.0)

We would like to propose the following improvements to DB-API 2.0 that would require bumping it up to DB-API 3.0: - Get rid of SQL strings - Get rid of SQL strings - Use package resources to store what would otherwise be SQL strings While we cannot prevent someone from going out of their way

[Python-ideas] Virtual packages

Python allows setting __path__ to turn a module into a package. However, it's allegedly only defined for __init__.py? Proposal: A virtual package is a non-__init__.py whose first line of code, after comments and future imports, assigns to __path__. This would allow -m virtualpackage to call

[Python-ideas] The exact operation of -m is unclear

A simple virtual package could be: # foo.py __path__ = [__file__ + ".d"] But unfortunately this doesn't work with -m: # foo.py.d/__main__.py print("this will never run") (n.b. -m foo.__main__ works but nobody's writing that.) Is it possible to change this backwards-compatibly? If not, is it

[Python-ideas] Re: A modulo operator consistent with euclidean division.

We feel like this may make sense to bring up, too: https://rust-lang.github.io/rfcs/2169-euclidean-modulo.html On 2022-03-20 04:06, Om Joshi wrote: > Has anyone in this thread linked this blog post yet? > > http://python-history.blogspot.com/2010/08/why-pythons-integer-division-floors.html > >

[Python-ideas] Re: Creating ranges with ellipsis

On 2022-02-16 10:45, Steven D'Aprano wrote: > On Wed, Feb 16, 2022 at 09:44:07AM -0300, Soni L. wrote: > > This might be a silly idea but, would it be a good idea to have > > ...[a:b:c] return a range(a, b, c)? > > Similar ideas have been suggested before: > > https

[Python-ideas] Creating ranges with ellipsis

This might be a silly idea but, would it be a good idea to have ...[a:b:c] return a range(a, b, c)? ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org

[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

[Python-ideas] Re: Better exception handling hygiene

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

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

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

[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:fakedme...@gmail.com>> 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 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

ives 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 10:01 p.m., Soni L.

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

[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 > > public A

[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-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() > >

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

[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

[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

[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 __getattribute__(

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

[Python-ideas] Re: Extension methods in Python

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 go ahead and use lists as normal. Whether you >

[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

ope, 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%2...@gmail.com>> wrote: > > > > On 2021-06-21 8:42 p.m., Steven D'Aprano wrote: > > On Mon, Jun 21, 202

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

[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

[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 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 > kinds of

[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

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

urn, and no finally block would be allowed. > > > > > On Tue, 15 Jun 2021 at 21:58, Chris Angelico <mailto:ros...@gmail.com>> wrote: > > On Wed, Jun 16, 2021 at 10:51 AM Soni L. <mailto:fakedme%2...@gmail.com>> wrote: > > > > Som

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

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

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

: 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, especially no

[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

[Python-ideas] Re: Regular Expression | re - Support String List Input Type List[str]

would rather it took List[str] patterns instead, for matching against List[str] input. so you could do things like: pattern = ["foo", "?", "\", "?", "bar", "baz"] input = ["foo", "?", "bar", "baz"] # matches input = ["?", "bar", "baz"] # matches input = ["foo?barbaz"] # doesn't match bonus

[Python-ideas] Re: exception instance call should raise exception

On 2020-07-05 12:58 p.m., MRAB wrote: On 2020-07-05 14:10, Soni L. wrote: On 2020-07-05 10:03 a.m., MRAB wrote: On 2020-07-05 13:39, Soni L. wrote: 1. saves keywords and 2. can be passed as callables. since there's no lambda: raise, 2 is a new feature. How would you re-raise

[Python-ideas] Re: exception instance call should raise exception

On 2020-07-05 10:03 a.m., MRAB wrote: On 2020-07-05 13:39, Soni L. wrote: 1. saves keywords and 2. can be passed as callables. since there's no lambda: raise, 2 is a new feature. How would you re-raise an exception? just call it. What would be the replacement for:     raise ex from

[Python-ideas] Re: exception instance call should raise exception

1. saves keywords and 2. can be passed as callables. since there's no lambda: raise, 2 is a new feature. On 2020-07-05 1:15 a.m., Steven D'Aprano wrote: On Sun, Jul 05, 2020 at 12:48:08AM -0300, Soni L. wrote: > ValueError()() should be the same as raise ValueError() but with an > extr

[Python-ideas] exception instance call should raise exception

ValueError()() should be the same as raise ValueError() but with an extra call level. and raise should be deprecated. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org

[Python-ideas] Re: Add builtin function for min(max())

On 2020-07-03 9:37 p.m., Christopher Barker wrote: On Fri, Jul 3, 2020 at 5:25 PM > wrote: > I'd go for val[min:max] tbh. another reason this is Not Good: in slicing syntax, a:b means >=a and < b -- this asymmetry is not what we would want here. It doesn't

[Python-ideas] Re: Add builtin function for min(max())

On 2020-07-03 7:53 p.m., tcphon...@gmail.com wrote: > I'd go for val[min:max] tbh. > benefits: > > - currently not allowed! > - replaces min and max! Is this a serious suggestion? No offence intended, but this seems ill-thought-out. val[min:max] is perfectly legal syntax and it will only

[Python-ideas] Re: Add builtin function for min(max())

On 2020-07-03 6:05 p.m., Federico Salerno wrote: Even after years of coding it sometimes takes me a moment to correctly parse expressions like `min(max(value, minimum), maximum)`, especially when the parentheses enclose some local computation instead of only references, and the fact that

[Python-ideas] Re: [Python-Dev] Re: Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

On 2020-06-29 11:46 a.m., Giampaolo Rodola' wrote: On Mon, Jun 29, 2020 at 12:34 PM Nathaniel Smith > wrote: On Mon, Jun 29, 2020 at 2:31 AM Steve Holden mailto:st...@holdenweb.com>> wrote: > The commit message used, however, reveals implementation details

[Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

On 2020-06-27 1:33 a.m., Steven D'Aprano wrote: On Fri, Jun 26, 2020 at 11:36:47PM -0400, David Mertz wrote: > On Fri, Jun 26, 2020, 8:40 PM Steven D'Aprano wrote: > > > "Clear and easily understandable" is subjective. What is clear and > > understandable to me may be impenetrably

[Python-ideas] Re: the 'z' string escape

On 2020-06-17 1:23 p.m., Christopher Barker wrote: less than ideal, yes -- but please post the \z version -- is it any better? I did, look again. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to

[Python-ideas] Re: the 'z' string escape

On 2020-06-17 12:46 p.m., Christopher Barker wrote: On Wed, Jun 17, 2020 at 6:09 AM Soni L. <mailto:fakedme%2...@gmail.com>> wrote: This also gives us two ways of doing indented strings (in Lua): local ugly = "foo\n    \z   bar\n    \z    

[Python-ideas] Re: the 'z' string escape

On 2020-06-17 7:44 a.m., Stephen J. Turnbull wrote: Soni L. writes: > Explicit is better than implicit. > > and \z is more explicit than #cont It's not more explicit. Line continuation in a string literal is perfectly explicit and easy to explain *exactl

[Python-ideas] Re: the 'z' string escape

On 2020-06-16 2:37 a.m., Stephen J. Turnbull wrote: Soni L. writes: > so I propose a \z string escape which lets me write the above as shown > below: > >     """switches to toml config format. the old 'repos' \z >     ta

[Python-ideas] the 'z' string escape

in Lua 5.2+, there's this string escape that allows you to put "whitespace" (in particular, including newlines) in a string literal, by skipping them entirely. now, unlike lua's long strings, python *does* have escapes in long strings. however, sometimes you have help text:    

[Python-ideas] Re: New attribute __convert__ for classes

On 2020-06-14 12:33 p.m., artem6191 wrote: This attribute will use for convertion classes to other types, i.e. int(MyClass) will return __convert__ result in MyClass Example: class MyClass: def __init__(self, numer: int): self.number = number def __convert__(self, type):

[Python-ideas] Re: await outside async function

he benefits of async/await, and all the benefits of blocking APIs, and you get to choose whether to use autodetection or explicitly force the latter. (you could also force the existence of a nested event loop, but I don't think that'd be a good idea.) On Fri, Jun 12, 2020 at 7:20 PM S

[Python-ideas] await outside async function (was: Re: await outside async function could map to asyncio.run ?)

On 2020-06-12 5:47 p.m., J. Pic wrote: Hi all, Currently, you can not use await outside an async function, the following code:   async def lol():     return 'bar'   def test():     return await lol()   print(test()) Will fail with: SyntaxError: 'await' outside async function Of course,

[Python-ideas] Re: zip(x, y, z, strict=True)

On 2020-05-06 12:48 p.m., Christopher Barker wrote: On Tue, May 5, 2020 at 5:43 PM Steven D'Aprano > wrote: Christopher's quoting is kinda messed up and I can't be bothered fixing it, sorry, so you'll just have to guess who said what :-) Ideally, we

[Python-ideas] Re: Equality between some of the indexed collections

On 2020-05-03 10:19 p.m., Steven D'Aprano wrote: On Sat, May 02, 2020 at 11:01:21PM +0200, Alex Hall wrote: > On Sat, May 2, 2020 at 10:52 PM Dominik Vilsmeier > wrote: > > > `frozenset` and `set` make a counterexample: > > > > >>> frozenset({1}) == {1} > > True > > > > Nice catch! That's

[Python-ideas] Re: Introduce 100 more built-in exceptions

On 2020-05-02 7:29 p.m., Steven D'Aprano wrote: On Sat, May 02, 2020 at 03:39:50PM -0300, Soni L. wrote: > def foo(): >   yield from () >   raise ValueError def foo(): yield from ()   raise ValueUnpackingError Does that help? the idea is that it

[Python-ideas] Re: Introduce 100 more built-in exceptions

On 2020-05-02 1:45 p.m., Steven D'Aprano wrote: On Sat, May 02, 2020 at 01:20:01PM -0300, Soni L. wrote: > > > On 2020-05-02 1:07 p.m., Steven D'Aprano wrote: > >On Sat, May 02, 2020 at 12:50:19PM -0300, Soni L. wrote: > > > >> how about: > >> >

[Python-ideas] Re: Introduce 100 more built-in exceptions

On 2020-05-02 1:07 p.m., Steven D'Aprano wrote: On Sat, May 02, 2020 at 12:50:19PM -0300, Soni L. wrote: > how about: > > result = Foo.save() > try: >   x, y = result > except ValueUnpackingError: >   return ... If you do that, what benefit is ValueUnpackingError

[Python-ideas] Re: Introduce 100 more built-in exceptions

On 2020-05-02 11:59 a.m., Eric V. Smith wrote: On 5/2/2020 7:18 AM, Alex Hall wrote: On Sat, May 2, 2020 at 12:39 PM Henk-Jaap Wagenaar mailto:wagenaarhenkj...@gmail.com>> wrote: Of course, there are other ways of writing this code, but imagine this for a database interface where a

[Python-ideas] Re: PEP 618: Add Optional Length-Checking To zip

On 2020-05-01 4:43 p.m., Chris Angelico wrote: On Sat, May 2, 2020 at 5:21 AM Soni L. wrote: > > > > On 2020-05-01 3:41 p.m., Chris Angelico wrote: > > On Sat, May 2, 2020 at 4:38 AM Soni L. wrote: > > > > > > > > > > > > On 2020-05-01

[Python-ideas] Re: PEP 618: Add Optional Length-Checking To zip

On 2020-05-01 3:41 p.m., Chris Angelico wrote: On Sat, May 2, 2020 at 4:38 AM Soni L. wrote: > > > > On 2020-05-01 3:10 p.m., Brandt Bucher wrote: > > I have pushed a first draft of PEP 618: > > > > https://www.python.org/dev/peps/pep-0618 > > > > Pl

[Python-ideas] Re: PEP 618: Add Optional Length-Checking To zip

On 2020-05-01 3:10 p.m., Brandt Bucher wrote: I have pushed a first draft of PEP 618: https://www.python.org/dev/peps/pep-0618 Please let me know what you think – I'd love to hear any *new* feedback that hasn't yet been addressed in the PEP! What about using an optional kwarg for a

[Python-ideas] Re: is a

On 2020-05-01 2:46 p.m., Steele Farnsworth wrote: So this would make `a` a new keyword. I don't think that could be added into python 4 at the earliest because it would immediately break all code for which `a` is a variable name. we could have keyphrases instead of keywords, tbh. I can

[Python-ideas] Re: Introduce 100 more built-in exceptions

On 2020-05-01 3:48 a.m., Ram Rachum wrote: Hi, Here's something I wanted in Python for many years. If this has been discussed in the past, please refer me to that discussion. On one hand, it's something that I can't imagine the python-dev community supporting. On the other hand, it would

[Python-ideas] Re: zip(x, y, z, strict=True)

On 2020-04-30 1:07 p.m., Ethan Furman wrote: On 04/30/2020 07:58 AM, Christopher Barker wrote: On 04/29/2020 10:51 PM, Stephen J. Turnbull wrote: I think that the issue of searchability and signature are pretty compelling reasons for such a simple feature to be part of the function name.

[Python-ideas] Re: extended for-else, extended continue, and a rant about zip()

On 2020-04-28 12:32 p.m., Edwin Zimmerman wrote: On April 28, 2020 9:38 AM Soni L. wrote: > On 2020-04-28 7:50 a.m., Edwin Zimmerman wrote: > > On 4/27/2020 11:47 PM, Soni L. wrote: > > [snip] > > > tbh my particular case doesn't make a ton of practical sen

[Python-ideas] Re: extended for-else, extended continue, and a rant about zip()

On 2020-04-28 7:50 a.m., Edwin Zimmerman wrote: On 4/27/2020 11:47 PM, Soni L. wrote: [snip] > tbh my particular case doesn't make a ton of practical sense. I have config files and there may be errors opening or deserializing them, and I have a system to manage configs and overrides. wh

[Python-ideas] Re: extended for-else, extended continue, and a rant about zip()

On 2020-04-28 12:28 a.m., Andrew Barnert wrote: On Apr 27, 2020, at 17:01, Soni L. wrote: > >>> On 2020-04-27 8:37 p.m., Andrew Barnert wrote: >>> On Apr 27, 2020, at 14:38, Soni L. wrote: >> [snipping a long unanswered reply] >>> The explicit

[Python-ideas] Re: extended for-else, extended continue, and a rant about zip()

On 2020-04-27 8:37 p.m., Andrew Barnert wrote: On Apr 27, 2020, at 14:38, Soni L. wrote: [snipping a long unanswered reply] > The explicit case for zip is if you *don't* want it to consume anything after the stop. Sure, but *when do you want that*? What’s an example of code you w

[Python-ideas] Re: extended for-else, extended continue, and a rant about zip()

for you.  It will be very hard to convince most of the people on this list if the only reason you can give is "I think this would look great".  Great ideas are based on real needs, not on flights of fancy. On 4/27/2020 7:15 PM, Soni L. wrote: > the point of posting here is to f

[Python-ideas] Re: extended for-else, extended continue, and a rant about zip()

the point of posting here is to find other use-cases! there's a reason this isn't a PEP! On 2020-04-27 7:14 p.m., Chris Angelico wrote: On Tue, Apr 28, 2020 at 7:41 AM Soni L. wrote: > I haven't found a real use-case for this yet, tho. So maybe hold off until you have one? Chr

[Python-ideas] Re: extended for-else, extended continue, and a rant about zip()

On 2020-04-27 6:11 p.m., Andrew Barnert wrote: On Apr 27, 2020, at 12:49, Soni L. wrote: > > I wanna propose making generators even weirder! Why? Most people would consider that a negative, not a positive. Even if you demonstrate some useful functionality with realistic ex

[Python-ideas] extended for-else, extended continue, and a rant about zip()

I wanna propose making generators even weirder! so, extended continue is an oldie: https://www.python.org/dev/peps/pep-0342/#the-extended-continue-statement it'd allow one to turn:     yield from foo into:     for bar in foo:     continue (yield bar) but what's this extended for-else?

[Python-ideas] Re: Make type(None) the no-op function

On 2020-04-24 12:26 p.m., Chris Angelico wrote: On Sat, Apr 25, 2020 at 1:20 AM Soni L. wrote: > > Currently type(None) returns None if you call it with no args: > > >>> print(type(None)()) > None > > it'd be nice if it did the same regardless of args. curre

[Python-ideas] Make type(None) the no-op function

Currently type(None) returns None if you call it with no args: >>> print(type(None)()) None it'd be nice if it did the same regardless of args. currently it raises: >>> print(type(None)(1)) Traceback (most recent call last):   File "", line 1, in TypeError: NoneType takes no arguments

[Python-ideas] Re: zip should return partial results in StopIteration

On 2020-04-22 11:08 a.m., Soni L. wrote: On 2020-04-22 6:47 a.m., Steven D'Aprano wrote: On Wed, Apr 22, 2020 at 01:43:10AM -0300, Soni L. wrote: > are there *any* solutions for getting partial results out of zip with > different-length iterators of unknown origin? No. If yo

[Python-ideas] Re: zip should return partial results in StopIteration

On 2020-04-22 6:47 a.m., Steven D'Aprano wrote: On Wed, Apr 22, 2020 at 01:43:10AM -0300, Soni L. wrote: > are there *any* solutions for getting partial results out of zip with > different-length iterators of unknown origin? No. If you want to continue getting results even wh

[Python-ideas] Re: zip should return partial results in StopIteration

On 2020-04-21 7:12 p.m., Steven D'Aprano wrote: On Tue, Apr 21, 2020 at 05:33:24PM -0300, Soni L. wrote: > 1. see the other thread (strict zip), especially the parts where they > brought up the lack of peekable/unput iterators in the context of > getting a count out of an iterato

[Python-ideas] Re: zip should return partial results in StopIteration

On 2020-04-21 12:48 p.m., Serhiy Storchaka wrote: 21.04.20 17:10, Soni L. пише: I feel like zip could return partial results: try:    next(zip([0], [])) except StopIteration as exc:    assert StopIteration.args == (0,) how much would this break? Why do you need this feature? 3 reasons

[Python-ideas] Re: zip should return partial results in StopIteration

On 2020-04-21 12:01 p.m., Soni L. wrote: On 2020-04-21 11:20 a.m., Eric V. Smith wrote: On 4/21/2020 10:14 AM, Eric V. Smith wrote: On 4/21/2020 10:10 AM, Soni L. wrote: I feel like zip could return partial results: try:   next(zip([0], [])) except StopIteration as exc:   assert

[Python-ideas] Re: zip should return partial results in StopIteration

On 2020-04-21 11:20 a.m., Eric V. Smith wrote: On 4/21/2020 10:14 AM, Eric V. Smith wrote: On 4/21/2020 10:10 AM, Soni L. wrote: I feel like zip could return partial results: try:   next(zip([0], [])) except StopIteration as exc:   assert StopIteration.args == (0,) how much would

[Python-ideas] zip should return partial results in StopIteration

I feel like zip could return partial results: try:   next(zip([0], [])) except StopIteration as exc:   assert StopIteration.args == (0,) how much would this break? ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email

[Python-ideas] Re: zip(x, y, z, strict=True)

+1. I implemented my own zip (because exceptions[1]) and it's so easy to accidentally have length-related bugs everywhere because your tests are just stopping short with no error. [1]

[Python-ideas] Re: collections.UpdateDict, collections.InsertDict, collections.InsertOrIgnoreDict

On 2020-04-16 2:42 p.m., Andrew Barnert wrote: On Apr 16, 2020, at 07:19, Soni L. wrote:  what about a dict.setdefaults (note the s) that takes in an iterable or a dict, and uses insert-or-ignore behaviour? (unfortunately a lot of iterables and all generators are hashable, and we can't

[Python-ideas] Re: collections.UpdateDict, collections.InsertDict, collections.InsertOrIgnoreDict

On 2020-04-16 11:43 a.m., Steven D'Aprano wrote: On Thu, Apr 16, 2020 at 11:17:33AM -0300, Soni L. wrote: > what about a dict.setdefaults (note the s) Do you have any idea of how much confusion and many silent errors will be caused by having methods setdefault and setdefaults on the s

[Python-ideas] Re: collections.UpdateDict, collections.InsertDict, collections.InsertOrIgnoreDict

instead of letting users implement what they need? On Thu, Apr 16, 2020 at 2:37 PM Soni L. <mailto:fakedme%2...@gmail.com>> wrote: currently dicts have insert-or-update semantics, e.g.:  >>> dict([((), 1), ((), 2)]) {(): 2} this is fine. however, in man

[Python-ideas] collections.UpdateDict, collections.InsertDict, collections.InsertOrIgnoreDict

currently dicts have insert-or-update semantics, e.g.: >>> dict([((), 1), ((), 2)]) {(): 2} this is fine. however, in many cases insert or insert-or-ignore are more useful: (hypothetical examples) >>> InsertOrIgnoreDict([((), 1), ((), 2)]) {(): 1} >>> InsertDict([((), 1), ((), 2)])

[Python-ideas] Re: Exception spaces

promote it to the stdlib? just need to encourage ppl not to check the type of their espace argument so you can silently swap the external one for the stdlib one and nothing breaks. (still need a better way to pass it into operators but eh) On 11.04.20 18:07, Soni L. wrote: the reason I'm proposing

[Python-ideas] Re: Exception spaces

it in to operators and stuff tho. On Sat, Apr 11, 2020, 11:37 AM Soni L. I'm not saying rust has the best solution. I don't like how it's so explicit about error handling. sometimes letting it bubble up is great. but rust doesn't have the problem of exception handling being

[Python-ideas] Re: Exception spaces

On 2020-04-11 12:52 p.m., Chris Angelico wrote: On Sun, Apr 12, 2020 at 1:37 AM Soni L. wrote: > in current python, you can't safely handle exceptions, *because* of the remote chance of them being raised *by the wrong thing/for the wrong reason*. > > rust doesn't have tha

[Python-ideas] Re: Exception spaces

On 2020-04-11 10:46 a.m., Eric V. Smith wrote: On 4/11/2020 9:38 AM, Soni L. wrote: On 2020-04-11 10:27 a.m., Eric V. Smith wrote: tl;dr: I show how the goal of Soni L's exception spaces can be addressed today, via less intrusive means. (Assuming I understand their proposal

[Python-ideas] Re: Exception spaces

On 2020-04-11 10:27 a.m., Eric V. Smith wrote: tl;dr: I show how the goal of Soni L's exception spaces can be addressed today, via less intrusive means. (Assuming I understand their proposal, that is.) what's the point of having standard types if you're not supposed to use them because

  1   2   3   >