When using `exec(string)`, the standard Python REPL, or `python -c` in a
terminal, the executed source code is not stored anywhere and cannot be
retrieved (except in the `-c` case by looking at `sys.argv`). This means that:
- The source line doesn't show up in tracebacks, e.g:
>>> exec("1/0
On Mon, Jan 4, 2021 at 1:30 PM Paul Sokolovsky wrote:
>
> Which leads us back to the question - did anyone of those who did that
> over decades ever bothered to post some kind of "spec" for this
> alternative syntax?
>
Is there a lot that needs to be specified? I imagine that the braces would
co
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 = executing.Source.executing(frame).node
arg = call.args[0]
if isinstance(arg, ast
Here's a simple runtime implementation that doesn't require any
dependencies or source code access:
import dis
import inspect
from functools import lru_cache
def nameof(_):
frame = inspect.currentframe().f_back
return _nameof(frame.f_code, frame.f_lasti)
@lru_cache
def _nameof(code, of
[email protected]
>
> You can reach the person managing the list at
> [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Python-ideas digest..."Today's Topics:
>
>
There are already several libraries which improve tracebacks in various ways,
including the standard library module `cgitb`. These libraries often simply
include multiple lines surrounding the primary one, which in most cases will
give you the context you need and maybe some extra.
I recently w
Christopher Barker wrote:
> I think it’s a “Bad Idea” to use an environment variable — who knows what
> Python script may be running on a given system?
> But a standard command line argument to the interpreter could be useful.
Can you clarify what the concern is about other Python scripts running?
This is a proposal for a new syntax where a comprehension is written as the
appropriate brackets containing a loop which can contain arbitrary statements.
Here are some simple examples. Instead of:
[
f(x)
for y in z
for x in y
if g(x)
]
one may write:
Antoine Rozo wrote:
> I think this syntax is very hard to read because the
> yielding-expression can be anywhere in the block and there is nothing
> to identify it.
Would you feel better if `yield` was always required?
> Even in your examples I can't figure out which expression will be
> used.
F
> Yes but then it's the same as defining a generator-function.
List comprehensions are already the same as other things, but they're nice
anyway. `lambda` is the same as defining a function, but it's nice too.
Syntactic sugar is helpful sometimes. I think this:
clean = [
for line in
OK, I think the verdict is in and I will not try to debate it.
> Does opening a [{( and having any : statements inside
> just imply one more indentation level? Or can the statements inside
> be validly less indented than the line containing the = [...
> opening bracket?
I think this is a fun ques
Thanks Ricky :)
Technically, if yield is always required, it would have to look like this:
[
for row in matrix:
yield [
for cell in row:
yield f(cell)
]
]
___
Python-ideas maili
> You might be able to avoid calling the method twice using the walrus
operator.
I specifically discussed the walrus operator solution, but both you and Dominik
Vilsmeier seem to have missed that.
> I'd use the list constructor with a
> named function anyway, rather than inlining it in a compreh
Andrew, you raise a good point that I hadn't considered. I think you're right
that yield inside an expression shouldn't be allowed, to avoid confusion. If we
found a good reason to allow it we could change it later.
___
Python-ideas mailing list -- pyth
> The weird block structures inside comprehension reads terribly even in the
> trivial case shown
David, it's fine if you have that opinion, but you're replying specifically to
my post where I asked someone to elaborate on that kind of opinion, so it
bothers me that you just restated it without
1. At least in my editor (PyCharm), I can collapse (fold) list comprehensions
just as easily as functions.
2. In this example the list comprehension already has a name - `clean_lines`.
Using a function actually forces me to come up with a second pointless name.
3. On the note of coming up with na
PyCharm (I think only the paid edition) does recognise SQL in plain string
literals just because it looks like SQL, and it offers various features from
there including syntax highlighting. It also recognises that the first argument
to functions like `re.match` is a regex and has features for tha
I've also had to special case strings when dealing with iterables
generically, and it's annoying, but it's not a big deal. The real problem
is when you meant to pass an iterable of strings and you just passed a
single string and it produces confusing behaviour - something more subtle
than each char
Steven D'Aprano wrote:
> On Sun, Feb 23, 2020 at 08:51:55PM -, Steve Jorgensen wrote:
> Python has not just the "iterator protocol" using __iter__ and
> __next__, but also has an older sequence protocol used in Python 1.x
> which still exists to this day. This sequence protocol falls back on
> A library implemented in a confusing way is not an example of nothing
wrong on Python strings. (I myself has made this stupid mistake many times
and I cannot blame neither Python nor sqlite for being careless.)
> In my humble opinion, your example does not prove that iterable strings
are faulty.
> Are you implying that we should deprecate the `in` operator for strings
No, we should definitely keep the `in` operator. We can revisit the best
wording for the error/warning message later, my point is just that it
should be more considerate to beginners than "TypeError: 'str' object is
not iter
kind of problem that will be caused by
seeing said warning and contemplating inconsistencies in the data model.
On Mon, Feb 24, 2020 at 6:37 PM Chris Angelico wrote:
> On Tue, Feb 25, 2020 at 3:21 AM Alex Hall wrote:
> > > It is not a question of right or wrong, better or worse. It
ady been shown
iteration over a string and discovers it for themselves, because that is
the scenario which seems most likely to cause confusion and thus it's the
most favourable to Chris' argument and the most damaging to mine.
On Mon, Feb 24, 2020 at 9:22 PM André Roberge
wrote:
>
>
&g
l problem then I'm
very confused and would appreciate more explanation.
On Mon, Feb 24, 2020 at 7:11 PM Paul Moore wrote:
> On Mon, 24 Feb 2020 at 16:23, Alex Hall wrote:
> > Roughly, though I think you might be hearing me wrong. There is lots of
> existing code that correct
I would like to reiterate a point that I think is very important and many
people seem to be brushing aside. We don't have to *break* existing code.
We can get a lot of value, at least in terms of aiding debugging, just by
adding a warning. That warning never has to evolve into an exception,
certain
On Mon, Feb 24, 2020 at 9:12 PM Chris Angelico wrote:
> On Tue, Feb 25, 2020 at 5:52 AM Alex Hall wrote:
> >
> > Of course consistency is valuable. I am asking how it is automatically
> more valuable than "better or worse", which isn't an idea that makes
Just add the appropriate code to filter that category of warnings. I think
you have the option of two lines of Python code or one environment variable.
On Mon, Feb 24, 2020 at 11:16 PM David Mertz wrote:
> On Mon, Feb 24, 2020 at 4:08 PM Alex Hall wrote:
>
>> Even when there is
This is inspired by the [discussion on iterable
strings](https://mail.python.org/archives/list/[email protected]/thread/WKEFHT4JYCL2PMZ5LB6HJRLVP3OGZI56/),
although I think it has applications elsewhere.
Sometimes programs emit warnings that need to be filtered out. Maybe they're
coming f
Kyle Stanley wrote:
> Hmm, I think we may benefit from focusing the efforts on this point (at
> least at first), particularly with regards to making the official
> documentation for the warnings module [1] easier to understand with some
> more examples, or perhaps writing a warnings HOWTO guide [2]
I'm still not clear on what the problem is with a function that prints code to
be copy pasted. It should probably output to stderr rather than stdout, and
maybe that can be configurable, but I don't think that's what your problem is.
I think that even if you've filtered warnings before, it's har
Which actual use cases have you had?
How much better would it have been than doing it manually?
It seems like most of this would be very easy to implement yourself with the
exact semantics that you prefer and find most intuitive, while other people
might have different expectations. Why should
Currently this code:
d = {"key": "value"}
for key, value in d:
pass
produces this error:
ValueError: too many values to unpack (expected 2)
I suggest that the error message should also have:
1. The name of the type of the unpacked value
2. The length of the unpacked value, if it exists and
Chris Angelico wrote:
> So the only way would be to call len(), and if it fails, fall back
> on
> the "expected 2" form. And I'm not sure if that would be worthwhile,
> given that it's going to have to run arbitrary code just for the sake
> of the error message.
I did address these:
> The length
>
> IIRC, the new unpacking code still works like the old in that it
> special-cases list and tuple (where it can use the fast indexing API that
> just accesses the C array underneath), but for everything else it calls a
> function with iter(obj). If so, adding the length for list and tuple would
>
On Mon, Mar 2, 2020 at 12:47 AM Christopher Barker
wrote:
> That being said, more information is better than less, so maybe an
> unpacking error should show the *value* of what was being unpacked:
>
> >>> a, b = 1, 2, 3
> Traceback (most recent call last):
> File "", line 1, in
> ValueError: t
On Wed, Mar 4, 2020 at 9:26 AM Steve Jorgensen wrote:
> Chris Angelico wrote:
> > On Wed, Mar 4, 2020 at 6:04 PM Steve Jorgensen [email protected] wrote:
>
> > https://en.wikipedia.org/wiki/Partially_ordered_set
> > "Partially ordered" means you can compare pairs of elements and find
> > which
>
> Taking one step back out of the realm of mathematical definition, however,
> the original idea was simply to distinguish what I now understand to be
> "totally ordered" types from other types, be they "partially ordered" or
> unordered — not even having a full complement of rich comparison oper
Can you explain where `except ParameterError` would produce better code
than the best current alternative? It seems to me that using this is like
stating "this code might be wrong" and would generally produce bad code.
For example if I wanted to use math.gcd on multiple values but I need to
support
>
> Is there any commonly used or even imaginable useful type that uses them
> in weirder ways than set and float (which are both partially ordered) or
> np.array (where they aren’t even Boolean-values)? In particular,
> transitivity keeps coming up, but all of those examples are transitive
> (it’s
> Both of these calls raise TypeError, but for different reasons:
> # right number of arguments passed to the key function,
> # but the wrong argument type
> sorted([3, 5, 1], key=len)
>
> # wrong number of arguments passed to the key function
> sorted([3, 5, 1], key=isinstance)
>
> It might be
I've defined functions like this in my own utility library and I use them
all the time, so I think they're very useful and would like to seem them
built in. But I have two functions for each end:
def strip_optional_suffix(string, suffix):
"""
>>> strip_optional_suffix('abcdef', 'def')
Might be helpful to look at https://github.com/tommikaikkonen/prettyprinter
and https://github.com/wolever/pprintpp
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python
How about http://www.grantjenks.com/docs/sortedcontainers/sorteddict.html ?
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.o
Just the first occurrence. The vast majority of the time, that's what
people want to do, and they will usually forget to add a 'count' parameter.
Many people probably wouldn't even know it exists. It would be disastrous
if code did the correct thing 99.9% of the time but occasionally silently
mutil
wrote:
> Well, str.replace has a count parameter. Presumably people use it (even
> if by accidentally discovering that without it, it replaces all occurrences
> when they only wanted one replaced).
> On 18/03/2020 18:44, Alex Hall wrote:
>
> Just the first occurrence. The vast major
Yes
https://docs.python.org/3/library/contextlib.html#contextlib.ContextDecorator
On Thu, Mar 19, 2020 at 3:26 PM Stephen J. Turnbull <
[email protected]> wrote:
> Andrew Barnert via Python-ideas writes:
>
> > [A] context manager seems perfect. It allows you to hint any
> > st
I think I'm missing something, why is case insensitivity a mess?
On Mon, Mar 23, 2020 at 9:32 AM Chris Angelico wrote:
> On Mon, Mar 23, 2020 at 5:06 PM Steve Barnes
> wrote:
> >
> > I personally think that there is a better case for an ignore_case flag –
> the number of times that I have been
This would break uses of locals(), e.g.
def foo(a, b):
x = a + b
if not x:
return None
del x
print('{x}, {a}, {b}'.format(**locals()))
return a * b
foo(1, 2)
Plus if the calculation raises an exception and I'm looking at the report
on Sentry, I'd like to see the value
range(len(x)) is actually not that important. You probably need to be using
enumerate() more often.
On Fri, Apr 10, 2020 at 9:44 PM Chamoun Saoma wrote:
> I have an idea to improve the python language through the creation of a
> new and very readable function.
>
>
> #
> def ranle
I just tried playing with this idea:
from collections import UserDict
class InsertOrIgnoreDict(UserDict):
__setitem__ = UserDict.setdefault
print(InsertOrIgnoreDict([(1, 2), (3, 4)]))
It caused an infinite chain of exceptions:
Traceback (most recent call last):
File
"/home/alex/.pyenv/
Here's a similar thread:
https://mail.python.org/archives/list/[email protected]/thread/SQKZ273MYAY5WNIQRGEDLYTKVORVKNEZ/#LXMU22F63VPCF7CMQ4OQRH2CG6H7WCQ6
Personally I write code like this all the time and would love this feature,
but I can see how it would be a mess for beginners to learn.
>
> I beg to differ. I do find "def foo(a, *, b)" gets in the way of
> readability.
>
> --
> Rhodri James *-* Kynesim Ltd
>
In what way?
In any case, focusing on the calling syntax being proposed, is there
anything unreadable about:
foo(a, *, b)
compared to
foo(a, b=b)
? I think in the propo
>
> And what would you do if you wanted to call:
>
> self.do_something(positional, keyword=keyword, keyword1=somethingelse,
> keyword2=keyword2)
>
> ?
>
> Eric
>
I think this is still pretty clear:
self.do_something(positional, *, keyword, keyword1=somethingelse, keyword2)
but if you don't like
>
> I’m not sure if this would work out the same way or not. And even if it
> does, that hurdle of describing the syntax in a way that people won’t get
> confused the way they do when they first learn the feature in C++ might be
> hard to overcome. But it’s at least plausible that it could be reada
On Thu, Apr 16, 2020 at 10:13 PM Kyle Stanley wrote:
> Dominik Vilsmeier wrote:
> > I'm not sure if this is doable from the compiler perspective, but what
> > about allowing tuples after `**` unpacking:
> >
> > requests.post(url, **(data, params))
> >
> > # similar to
> > requests.
On Thu, Apr 16, 2020 at 10:47 PM Dominik Vilsmeier
wrote:
>
> On 16.04.20 22:28, Alex Hall wrote:
>
> On Thu, Apr 16, 2020 at 10:13 PM Kyle Stanley wrote:
>
>> Dominik Vilsmeier wrote:
>> > I'm not sure if this is doable from the compiler perspective, but wh
On Fri, Apr 17, 2020 at 5:08 AM Steven D'Aprano wrote:
> On Thu, Apr 16, 2020 at 07:50:30PM +0200, Alex Hall wrote:
> > >
> > > And what would you do if you wanted to call:
> > >
> > > self.do_something(positional, keyword=keyword, key
On Fri, Apr 17, 2020 at 11:57 AM Steven D'Aprano
wrote:
> On Fri, Apr 17, 2020 at 11:25:15AM +0200, Alex Hall wrote:
>
> > I don't think you really need to know what it means to read the code for
> > most purposes.
>
> *blink*
>
> > You look at t
>
> But this means the reader could miss the star, especially with a very
> large function call over multiple lines, and if that reader happens to use
> that particular function A LOT and know the parameter order without having
> to look they would pretty easily believe the arguments are doing some
On Fri, Apr 17, 2020 at 6:09 PM David Mertz wrote:
> On Fri, Apr 17, 2020 at 9:57 AM wrote:
>
>> The mode-switch proposal though would not impede one to mix shorthand and
>> longhand forms. This should be valid syntax:
>>
>> ```python
>> return render_template("index.html", *,
>> twitter, us
Perhaps an easier next step would be to get better data about people's
opinions with a simple poll? Is there a standard way to vote on things in
this list?
I say we do a simple approval vote. Everyone ticks all the syntaxes that
they think would be acceptable to include in the language. It's not v
h), lineno), end="")
print()
main()
```
On Fri, Apr 17, 2020 at 8:40 PM Paul Svensson
wrote:
> On Fri, 17 Apr 2020, Alex Hall wrote:
>
> >Perhaps an easier next step would be to get better data about people's
> opinions with a simple poll? Is there a stan
I also find the example with :keyword a bit jarring at first glance, so I
propose a double colon to alleviate the problem if we go in that direction.
Compare:
{ :a, "b": x, :c }
{ ::a, "b": x, ::c }
On Fri, Apr 17, 2020 at 10:05 PM Rhodri James wrote:
> On 17/04/2020 19:21, Andrew Barn
>
> If typing the same variable from the caller to use in the parameter is
> really too much repetition, you could maybe just do this:
>
> >>> render_template("index.html",
> ... username="display_name",
> ... setups="setups",
> ... **Q("x y z"))
> ('index.html',)
> {'username': 'displa
>
> And now Lisp bites me, because '::a' means ...
>
And a single colon also means something else in Lisp.
Does it matter much what that notation means in a different language?
Python will struggle to evolve if it can't conflict with other languages.
I myself am rarely annoyed by this issue, with
nvented the syntax -- I think it might have been
> Alex Hall?)
>
lol everyone thinks I invented things I didn't...
The idea was first suggested by Dominik:
https://mail.python.org/archives/list/[email protected]/message/S44VDMZ4AFBSGIQEVWMKKWOW4P6WRVXY/
I just suggested mak
On Sat, Apr 18, 2020 at 5:03 PM Steven D'Aprano wrote:
> On Sat, Apr 18, 2020 at 02:13:51PM +0200, Alex Hall wrote:
>
> > My issue with this, and maybe it's what Andrew is also trying to say, is
> > that it breaks our usual assumptions about composing expressions. `{u
>
> It would be good if we had something that was neither excessive verbose
> nor painfully terse, required nothing but ASCII, that was similar enough
> to dict unpacking to suggest a connection, but without being confusable
> to anything else even to newbies, was self-descriptive without needing
>
On Sun, Apr 19, 2020 at 11:49 AM Steven D'Aprano
wrote:
> On Sun, Apr 19, 2020 at 10:19:41AM +0200, Alex Hall wrote:
>
> > But the problem here is not that your proposal doesn't meet all the
> > requirements, it's that you have different requirements from us. You
On Sun, Apr 19, 2020 at 7:58 AM Stephen J. Turnbull <
[email protected]> wrote:
> Alex Hall writes:
>
> > > And now Lisp bites me, because '::a' means ...
>
> > And a single colon also means something else in Lisp.
>
> Yeah,
>
> And notice that there is absolutely no difficulty with some future
> enhancement to allow positional arguments after keyword arguments.
>
We've already discussed in this thread that we shouldn't fear conflicting
with other (real or hypothetical) proposals, even if they're likely. As I
see it,
>
> >> function(*, dunder, invert, private, meta, ignorecase)
> >>
> >
> >
> > No reader will ever have to think about the difference. They will simply
> > see the second version and know which arguments are being passed.
>
> I seem to be immune to this magical knowledge.
>
Sorry, what? How i
On Sun, Apr 19, 2020 at 7:06 PM Stephen J. Turnbull <
[email protected]> wrote:
> Alex Hall writes:
>
> > OK, that's fair. What about `{foo::}`?
>
> I don't like any of them. People who are going to use the syntax
> should choose it, not t
>
> So, if M() existed, you could say:
>
> d = M(telephone, name)
> func(**d)
>
> or
>
> func(**M(telephone, name))
>
> Or, you could just use "d" from the first example for your own purposes
> unrelated to function calling.
>
My point is: We already have a way to pass the items in a dictionary as
On Sun, Apr 19, 2020 at 5:59 PM David Mertz wrote:
> On Sun, Apr 19, 2020 at 7:00 AM Chris Angelico wrote:
>
>> Yes, exactly. One strike doesn't mean it's out, and with a proposal
>> like this, it's a matter of looking at a whole lot of imperfect
>> alternatives and seeing which tradeoffs we wan
>
> Per your wish, Eric, the glorious successor of Q() ... named M():
>
> >>> def M(*vals):
> ... import sys
> ... import inspect
> ... caller = sys._getframe(1)
> ... call = inspect.stack()[1].code_context[0]
> ... _, call = call.split('M(')
> ... call = call.strip()[:-1]
>
On Sun, Apr 19, 2020 at 11:00 PM David Mertz wrote:
> See this thread where I created M() as successor of Q().
>
>>
I saw, and I mentioned it:
I see you've tried while I wrote this, and it's pretty clear it's very far
> from robust.
It's really not that hard, I don't think. Probably there are
On Sun, Apr 19, 2020 at 11:18 PM David Mertz wrote:
> If this were in the library I or my project used, whatever limitations and
> edge cases exist wouldn't really matter. If I REALLY cared about saving a
> few duplicate names in function calls, I could easily include it with the
> knowledge tha
On Mon, Apr 20, 2020 at 2:48 AM Steven D'Aprano wrote:
> On Sun, Apr 19, 2020 at 02:10:21PM +0200, Alex Hall wrote:
> > >
> > > And notice that there is absolutely no difficulty with some future
> > > enhancement to allow positional arguments after keyword arg
On Mon, Apr 20, 2020 at 12:57 PM Steven D'Aprano
wrote:
> On Mon, Apr 20, 2020 at 11:15:32AM +0200, Alex Hall wrote:
> > On Mon, Apr 20, 2020 at 2:48 AM Steven D'Aprano
> wrote:
> >
> > > On Sun, Apr 19, 2020 at 02:10:21PM +0200, Alex Hall wrote:
> &g
On Mon, Apr 20, 2020 at 5:04 AM Steven D'Aprano wrote:
> On Sun, Apr 19, 2020 at 06:06:50PM +0200, Alex Hall wrote:
> > Sorry, what? How is there any doubt that the arguments being passed are
> > dunder, invert, private, meta, and ignorecase? They're right there.
>
&g
On Mon, Apr 20, 2020 at 7:37 PM Christopher Barker
wrote:
> On Sun, Apr 19, 2020 at 3:37 AM Alex Hall wrote:
>
>> ```
>> File "setup.py", line 2232
>> self.add(Extension('_decimal',
>>include_dirs=inc
On Mon, Apr 20, 2020 at 10:46 PM Christopher Barker
wrote:
> On Mon, Apr 20, 2020 at 1:35 PM Alex Hall wrote:
>
>>
>> So let's assume that a beginner is likely to notice arguments out of
>> order and think that something is wrong, and focus on what happens from
&
>
> x = iter(range(5))
> y = [0]
> try:
> zipped = zip(x, y, strict=True)
> except ValueError: # assuming that’s the exception you want?
> print(next(x))
>
> Should this print 1 or 2 or raise StopIteration or be a don’t-care?
Surely no exception is raised because
On Tue, Apr 21, 2020 at 9:45 AM M.-A. Lemburg wrote:
> In the use case discussed here, that namespace would be
> locals(), so you could just as well write render_template(**locals()),
>
Doing that gets in the way of tools. At the very least it makes it
impossible to highlight accidentally unused
On Sun, Apr 19, 2020 at 10:50 PM Alex Hall wrote:
> On Sun, Apr 19, 2020 at 5:59 PM David Mertz wrote:
>
>>
> I think you've missed on alternative. Well, it's a variation on "status
>> quo": Use a silly magic helper function like my Q() or
On Tue, Apr 21, 2020 at 11:01 AM M.-A. Lemburg wrote:
> On 21.04.2020 10:07, Alex Hall wrote:
> >
> >
> > On Tue, Apr 21, 2020 at 9:45 AM M.-A. Lemburg > <mailto:[email protected]>> wrote:
> >
> > In the use case discussed here, that namespace wo
It's not clear to me why people prefer an extra function which would be
exactly equivalent to lru_cache in the expected use case (i.e. decorating a
function without arguments). It seems like a good way to cause confusion,
especially for beginners. Based on the Zen, there should be one obvious way
t
On Sun, Apr 26, 2020 at 6:57 PM Tom Forbes wrote:
> I agree, that was the topic of my original post to the python-ideas
> discussion group[1]. I thought we should special-case `lru_cache()` to
> account for this use case.
>
> The general consensus was that a `once()` decorator would be less
> con
On Sun, Apr 26, 2020 at 7:47 PM Eric Fahlgren
wrote:
> On Sun, Apr 26, 2020 at 9:46 AM Alex Hall wrote:
>
>> It's not clear to me why people prefer an extra function which would be
>> exactly equivalent to lru_cache in the expected use case (i.e. decorating a
>> fu
Some libraries implement a 'lazy object' which forwards all operations to a
wrapped object, which gets lazily initialised once:
https://github.com/ionelmc/python-lazy-object-proxy
https://docs.djangoproject.com/en/3.0/_modules/django/utils/functional/
There's also a more general concept of proxyi
Recent related discussion:
https://mail.python.org/archives/list/[email protected]/thread/MXPCNEAWXWJPOHB3DC3QW3S3ZPOFSM4Q/
On Fri, May 1, 2020 at 8:53 AM Ram Rachum wrote:
> Hi,
>
> Here's something I wanted in Python for many years. If this has been
> discussed in the past, please refer
On Fri, May 1, 2020 at 10:58 PM Andrew Barnert via Python-ideas <
[email protected]> wrote:
> A separate function can be used in third-party libraries immediately, as
> long as there’s an available backport (whether that’s more-iterools, or a
> trivial zip39 or whatever) that they can requir
D'Aprano wrote:
> On Fri, May 01, 2020 at 11:30:17PM +0200, Alex Hall wrote:
>
> > Specifically the PEP says:
> >
> > > Another proposed idiom, per-module shadowing of the built-in zip with
> some
> > > subtly different variant from itertools, is an
On Sat, May 2, 2020 at 3:50 AM Steven D'Aprano wrote:
> On Thu, Apr 30, 2020 at 07:58:16AM -0700, Christopher Barker wrote:
>
> > Imagine someone that uses zip() in code that works for a while, and then
> > discovers a bug triggered by unequal length inputs.
> >
> > If it’s a flag, they look at t
On Sat, May 2, 2020 at 12:39 PM Henk-Jaap Wagenaar <
[email protected]> wrote:
> Of course, there are other ways of writing this code, but imagine this for
> a database interface where a save normally returns the saved object
> (inspired by Django)
>
> ```
> try:
> x, y = Foo.save()
>
On Sat, May 2, 2020 at 1:19 PM Steven D'Aprano wrote:
> On Sat, May 02, 2020 at 09:54:46AM +0200, Alex Hall wrote:
>
> > I would say that in pretty much all cases you wouldn't catch the
> exception.
> > It's the producer's responsibility to produce co
On Sat, May 2, 2020 at 1:19 PM Steven D'Aprano wrote:
> But I question whether *enough* people need it *often enough* to make it
> a builtin, or to put a flag on plain zip.
> It has taken years for it to be added to more-itertools, suggesting that
> the real world need for this is small.
>
>
On Sat, May 2, 2020 at 4:34 PM Steven D'Aprano wrote:
> On Sat, May 02, 2020 at 02:58:57PM +0200, Alex Hall wrote:
>
>
> > > Yes? Is it our responsibility to put everything in builtins because
> > > people might not think to look in math, or functools, or o
On Sat, May 2, 2020 at 2:58 PM Alex Hall wrote:
> On Sat, May 2, 2020 at 1:19 PM Steven D'Aprano
> wrote:
>
>> Rolling your own on top of
>>
> zip_longest is easy. It's half a dozen lines. It could be a recipe in
>> itertools, or a function.
>
>
&g
1 - 100 of 241 matches
Mail list logo
