Currently you can write
term.join(xs) + term
if you want 1, 1, 2, 3, ... terminators when xs has 0, 1, 2, 3, ...
elements, and
term.join([*xs, '']) # or b''
if you want 0, 1, 2, 3, ... terminators, neither of which is prohibitively
annoying. What I don't like about the status quo is
On Thu, Feb 16, 2023 at 8:09 AM Barry wrote:
> This is valid and does not match your rules. ‘\x9b’ that is the ANSI CSI
> in 8-bit.
> In 7-bit it is ‘\x1b[‘.
>
Shouldn't that be b‘\x9b’?
___
Python-ideas mailing list -- python-ideas@python.org
To
On Wed, Jun 22, 2022 at 6:36 PM Joao S. O. Bueno
wrote:
> implement "all possible"
> dunder methods, and proxy those to the underlying object, for a "future
> type" that was
> calculated off-process, and did not need any ".value()" or ".result()"
> methods to be called.
>
Here's a package on
>
> On Wed, Jun 22, 2022 at 02:30:14PM -0400, David Mertz, Ph.D. wrote:
> >But basically, think about `x = (later expensive1() + later expensive2())
> /
> >later expensive3()`. How can we make `x` itself be a zero argument
> >lambda? [... see below ...]
>
x = lambda: (expensive1() +
This calls the predicate once per element:
def partition(pred, iterable):
t1, t2 = tee((pred(x), x) for x in iterable)
return (x for b, x in t1 if not b), (x for b, x in t2 if b)
It's kind of inefficient though.
___
Python-ideas
On Wed, May 18, 2022 at 12:24 PM Serhiy Storchaka
wrote:
> try:
> expression block
> expect Exception if condition else ():
> expression block
>
That's an interesting idea I haven't seen before, but it doesn't work if
the condition you want to test depends on the exception object,
Cython seems to me rather different from what the original post was talking
about. If I put
class Foo:
def bar(self):
pass
in a .pyx file and run it through Cython, the result is a 5600-line,
200-kilobyte lump of C that clearly isn't meant to be understood or
modified by
On Sun, Apr 3, 2022 at 10:10 PM Chris Angelico wrote:
> On Mon, 4 Apr 2022 at 14:13, Ricky Teachey wrote:
> > What does that idea bring other than being able to say 5.0m
> [...] instead of 5.0*m [...]?
>
> A large amount of clarity, readability, and namespacing (you don't have to
> pollute your
On Fri, Mar 18, 2022 at 8:30 PM MRAB wrote:
> Wikipedia describes Euclidean division.
>
> Basically, the modulo is non-negative:
>
> a == b * q + r where 0 <= r < abs(b)
That convention in the Wikipedia article dates back to a 2004 edit by
an anonymous (IP) editor. The only reference in
On Fri, Mar 18, 2022 at 8:31 AM Chris Angelico wrote:
> if y < 0: return -(x // -y), x % y
I think that should be
if y < 0: return -(x // -y), x % -y
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to
On Tue, Mar 1, 2022 at 4:51 PM Steven D'Aprano wrote:
> Then Python is the wrong language for you, because it uses exceptions to
> direct control flow *wink*
>
> The iteration protocol uses StopIteration to end iteration. The older
> sequence protocol uses IndexError for the same purpose.
>
I
On Tue, Mar 1, 2022 at 2:23 PM Steven D'Aprano wrote:
> try:
> do_this()
> if condition: raise MyBreak
> do_that()
> if condition: raise MyBreak
> do_next_step()
> if condition: raise MyBreak
> do_last_step()
> except MyBreak:
>
On Mon, Feb 21, 2022 at 1:39 PM Tim Peters wrote:
> [Mark Dickinson ]
> > It Would Be Nice If
> > `-1 * complex(inf, 0.0)` gave `complex(-inf, -0.0)` instead
> > of the current result of `complex(-inf, nan)`.
> Except replacing -1 with "-1.0" or "complex(-1)" would
> presumably _still_
On Mon, Feb 21, 2022 at 12:24 PM Mark Dickinson wrote:
> e.g., It Would Be Nice If `-1 * complex(inf, 0.0)` gave `complex(-inf,
> -0.0)` instead of the current result of `complex(-inf, nan)`. But the price
> in added complexity - both conceptual complexity and implementation
> complexity - seems
On Sun, Feb 20, 2022 at 9:41 AM Tim Peters wrote:
> It's a slippery slope, of scant discernible benefit, and still hackish.
> For example, 10**600 / 1e200 / 1e200.
>
That's how IEEE arithmetic works: a/b is computed to infinite precision
then properly rounded, but (a/b)/c isn't. Yes, it's not
On Saturday, February 19, 2022, Stefan Pochmann
wrote:
> >>> 1e200.is_integer()
> True
>
> So that could losslessly be converted to int, and then the division would
> succeed
If the float argument isn't an integer, you can multiply both sides by a
power of 2 that makes it one (if it's finite,
On Tue, Feb 15, 2022 at 6:13 PM Chris Angelico wrote:
> Once upon a time, a "regular expression" was a regular grammar. That is no
> longer the case.
>
I use "regex" for the weird backtracking minilanguages and deliberately
never call them "regular expressions". (I was under the impression that
There seem to be two different reasons people want a generic freeze syntax:
1. Making a hashable copy of an arbitrary object
2. Avoiding O(n) rebuilding of literals on every use (a constant for
bytecode, as you put it)
In both 1 and 2, not only the object but all of its children need to be
My preferred syntax for a frozenset literal would be something like
{1, 2, 3}.freeze()
This requires no new syntax, and can be safely optimized at compile time
(as far as I can tell).
set.freeze would be a new method of sets which could also be used at run
time. It would return a new
If you didn't know, range objects already support most non-mutating list
methods:
>>> fakelist = range(1, 101)
>>> fakelist[-1]
100
>>> fakelist[-10:]
range(91, 101)
>>> 50 in fakelist
True
>>> fakelist.index(50)
49
Range objects are more efficient than lists
On Sat, Oct 23, 2021 at 5:16 PM Chris Angelico wrote:
> # Very common: Use None and replace it in the function
> def bisect_right(a, x, lo=0, hi=None, *, key=None):
> if hi is None:
> hi = len(a)
>
Note that if this is changed to
def bisect_right(a, x, lo=0,
On Sat, Oct 23, 2021 at 11:53 PM Steven D'Aprano
wrote:
> If we had thunks, that would give us late binding for free:
>
> def bisect(a, x, lo=0, hi=thunk len(a), *, key=None)
>
I'm unclear on exactly what the semantics of a thunk would be, but I don't
see how it could do what you want here.
On Tue, Aug 24, 2021 at 9:08 AM Jon Kiparsky wrote:
> > Numbers in general are useful concepts that help us with real-world
> > problems, but it's really hard to pin them down.
>
> Not that hard, really. A number is just a hackenbush game :)
>
RIP Berlekamp, Conway and Guy. They all died within
On Thu, Jun 17, 2021 at 3:09 PM Steven D'Aprano wrote:
> On Thu, Jun 17, 2021 at 02:22:29PM -0700, Ben Rudiak-Gould wrote:
> > [*chunk for chunk in list_of_lists]
>
> What would that do?
The difference between chunk and *chunk in the expression of a list
comprehension wo
On Thu, Jun 17, 2021 at 12:37 AM Serhiy Storchaka
wrote:
> And it is equivalent to pure Python code
>
> [x for chunk in list_of_lists for x in chunk]
>
Okay, slightly off-topic, but can we *please* allow
[*chunk for chunk in list_of_lists]
some day. I think it was left out because
On Sun, Mar 21, 2021 at 11:10 PM Chris Angelico wrote:
> At what point does the process_objects list cease to be referenced?
> After the last visible use of it, or at the end of the function?
In Python as it stands, at the end of the function, as you say.
Skip Montanaro's PEP suggested that
In the "Object Lifetime" section you say "registers should be cleared upon
last reference". That isn't safe, since there can be hidden dependencies on
side effects of __del__, e.g.:
process_objects = create_pipeline()
output_process = process_objects[-1]
return output_process.wait()
On Fri, Mar 19, 2021 at 8:59 PM Dennis Sweeney
wrote:
> I think these don't generally fit with the "feel" of the itertools module
> though since almost everything there accepts iterables and returns iterators
itertools.product as written barely seems to fit. It might as well accept
only
On Wed, Feb 17, 2021 at 6:12 PM Chris Angelico wrote:
> But if object() could get arbitrary attributes, then __slots__ wouldn't
> work.
>
It seems to me that all you'd have to do is add a line or two to the
add_dict logic in type_new so that instances of object get a dict. Then
instances of
On Thu, Feb 4, 2021 at 3:29 PM Chris Angelico wrote:
> With "t", it takes/gives Unicode objects, but with "b" it uses bytes.
Sure, in Python 3, but not in Python 2, or C.
Anyway, moral correctness is beside the point. People in point of fact
don't write encoding='utf-8' when they should,
There's a long ongoing thread with the subject "Make UTF-8 mode more
accessible for Windows users."
There are two obvious problems with UTF-8 mode. First, it applies to entire
installations, or at least entire running scripts, including all imported
libraries no matter who wrote them, etc.,
On Wed, Jan 27, 2021 at 11:36 PM Inada Naoki wrote:
> * UnicodeDecodeError is raised when trying to open a text file written in
> UTF-8, such as JSON.
> * UnicodeEncodeError is raised when trying to save text data retrieved
> from the web, etc.
> * User run `pip install` and `setup.py` reads
On Thu, Dec 24, 2020 at 1:34 AM Barry Scott wrote:
> if sys.playform == 'win32':
> os.system('cls')
> else:
> sys.stdout.write('\x1b[2J' '\x1b[H')
>
> No concern about CLS being a trojan becuse as a builtin to CMD and
> PowerShell
> and it takes priority over cls.bat etc.
On Tue, Dec 22, 2020 at 4:46 PM Christopher Barker
wrote:
> Though, yeah shelling out to an arbitrary command on the system is a bit
> scary -- does the Python stdlib currently do that anywhere?
>
Here's what I found by grepping the sources for uses of os.system and
subprocess:
* pydoc shells
On Sun, Dec 20, 2020 at 8:06 PM Eryk Sun wrote:
> The entire buffer can be scrolled out, like
> the CMD shell's CLS command, or one can just scroll the buffer enough
> to clear the visible window.
>
The Windows console model is a bit different from POSIX terminals. Instead
of having a screen
On Mon, Dec 21, 2020 at 9:25 AM Christopher Barker
wrote:
> [Mathew Elman wrote:]
>
>> Surely what you're looking for is some kind of typed hash table?
>
>
> Maybe, maybe not. My impression is that the Typed hash table is a kluge
> to get around this one issue.
>
For what it's worth,
On Wed, Nov 18, 2020 at 9:54 PM Greg Ewing
wrote:
> Essentially the idea is this: If the loop body contains a def or lambda
> that captures the loop variable, then on each iteration, a new binding
> is created, instead of changing an existing binding.
>
> Note that this is *not* the same as
I don't think __bytes__ is necessarily a bad idea, but I want to point out
a couple of things you may be unaware of. First, slicing a memoryview
object creates a subview, so you can wrap your mmap object in a memoryview
and then create slices for each partition, cluster run, etc. without
wasting
On Tue, Oct 20, 2020 at 8:57 AM Antal Gábor
wrote:
> My idea is to return a list with an empty string in all cases mentioned
> above.
>
This will never be fixed in 3.x, but if it's fixed in The Version That Must
Not Be Named, my preference would be that they all return [] because then
it's easy
On Wed, Sep 30, 2020 at 1:43 PM David Mertz wrote:
> Fluent programming is uncommon in Python, and hence few methods return a
> call of the same or similar type.
>
I think that if you include built-in operators as (shorthand for) method
calls, and you count the number of occurrences in typical
On Sun, Sep 27, 2020 at 2:18 PM MRAB wrote:
> Consider, for example, the use-case of a function that has an optional
> parameter and you want a way to know whether an argument has been
> provided but None is a valid value that could be passed in.
>
> Having a singleton such as Missing would be
I don't understand the problem here.
d[p=q] --> d.__{get,set,del}item__((), ..., p=q)
d[1, p=q] --> d.__{get,set,del}item__((1), ..., p=q)
d[1, 2, p=q] --> d.__{get,set,del}item__((1, 2), ..., p=q)
d[1, 2, 3, p=q] --> d.__{get,set,del}item__((1, 2, 3), ..., p=q)
d[1,
On Fri, Sep 25, 2020 at 8:26 PM David Mertz wrote:
> E.g. we would have:
>
> newthing[(), foo=1, bar=4:5] == newthing[foo=1, bar=4:5]
>
Right, but we also have
newthing[(2, 3), foo=1, bar=4:5] == newthing[2, 3, foo=1, bar=4:5]
which seems exactly analogous. A disambiguation scheme
On Wed, Sep 23, 2020 at 3:10 AM David Mertz wrote:
> On Tue, Sep 22, 2020 at 11:55 PM Paul Moore wrote:
>
>> The point of this request is that Python's packaging infrastructure is
>> looking at what compression we use for wheels - the current
>> compression is suboptimal for huge binaries like
This is a terrible idea.
No one should ever be trying to extract data from strings that are
obviously meant for human consumption, like "It is 11:45 PM".
I'll grant you that it's sometimes necessary. But it needs to be approached
very carefully. You need to use a --porcelain flag if available,
On Mon, Aug 17, 2020 at 8:02 AM Steven D'Aprano wrote:
> Perhaps I have misunderstood, but isn't this a pure implementation
> change, with no user visible API changes and backward compatible output?
>
According to the documentation [1], it only supports compression levels
0-3. They're supposed
On Wed, Aug 12, 2020 at 8:49 AM David Mertz wrote:
> The start/stop/step sound like they might be nice. But that wouldn't give
> you a length, since you never know when an iterator will be exhausted. I
> feel like `len(islice(it, 1, 1_000_000))` telling you the "maximum possible
> length" is
On Fri, Jul 3, 2020 at 5:07 PM Steven D'Aprano wrote:
> As I recall, there was some positive support but it ran out of steam
> because nobody could agree on how to handle NANs even though the
> IEEE-754 standard tells us how to handle them *wink*
>
> See my responses at the time re NANs here:
>
>
There isn't really any contention for these memory locations in
CPython as it stands because only one interpreter thread can run at a
time. The only time a cache handoff is needed is during a thread
switch when the new thread is scheduled on a different core, which is
pretty rare (at CPU
On Mon, Mar 16, 2020 at 12:57 AM Andrew Barnert wrote:
> Even if the extra indirection overhead turns out not to be an issue, just
> from the added complexity (to every possible implementation) it seems like it
> would be a bad idea to make that a requirement.
The only change needed to support
On Sun, Mar 15, 2020 at 9:41 PM Andrew Barnert via Python-ideas
wrote:
> Do you really want to require “binary”?
I don't think so; they never talked about binary trees, only "binary
search tree semantics." It could alternately be called autobalanced
tree semantics or something.
>Sorted
On Thu, Mar 12, 2020 at 2:32 PM Marco Sulla via Python-ideas
wrote:
>
> On Thu, 12 Mar 2020 at 21:22, Chris Angelico wrote:
> > They actually ARE already discarded
>
> 0O
> You're right. So *how* can juliantaylor said he measured a speedup of
> 2x for large ndarrays?
I think that currently
On Thu, Mar 12, 2020 at 10:43 AM Andrew Barnert via Python-ideas
wrote:
> Also, you need to think through what happens with a del expression inside all
> kinds of contexts that currently can’t have del—eval, lambdas and
> comprehensions (can I del something from the outer scope?), etc.; just
>
On Wed, Mar 11, 2020 at 10:09 AM Serhiy Storchaka wrote:
> There is a precedence (although not in the stdlib): NumPy array with
> dtype=bool.
>
> >>> import numpy
> >>> bool(numpy.array([False, False]))
> Traceback (most recent call last):
> File "", line 1, in
> ValueError: The
On Mon, Feb 10, 2020 at 9:50 AM Andrew Barnert via Python-ideas
wrote:
> It’s a well-known problem that async is “contagious”: [...]
>
> But C# and every other language that’s borrowed the idea has the same
> problem, and as far as I know, nobody’s thought of a good answer yet.
Threads don't
On Sun, Oct 27, 2019 at 4:17 PM Andrew Barnert wrote:
> On Oct 27, 2019, at 15:07, Ben Rudiak-Gould wrote:
> >from __future__ import raise_function
> That’s a pretty big breaking change.
I agree, it's a bad idea. It'd have to be Python 4, like
print_function was Python 3.
>
throw is an expression, not a statement, in C++. I see no reason raise
couldn't be an expression in Python. It doesn't even need a special
rule in the grammar:
from __future__ import raise_function
foo.setParseAction(lambda a, b, c: raise(MumbleMumble()))
Looking up and calling the
Since this is Python 4000, where everything's made up and the points
don't matter...
I think there shouldn't be a char type, and also strings shouldn't be
iterable, or indexable by integers, or anything else that makes them
appear to be tuples of code points.
Nothing good can come of decomposing
On Tue, Oct 1, 2019 at 9:26 AM Andrew Barnert wrote:
> On Sep 30, 2019, at 23:46, Ben Rudiak-Gould wrote:
> > ABC membership is a subtype relationship in some sense, and ordinary Python
> > subclassing is a subtype relationship in some sense, but they aren't quite
>
On Mon, Sep 30, 2019 at 10:08 AM Andrew Barnert via Python-ideas
wrote:
> Also, what we’re checking for really is subtyping.
Is it? Subtyping in type theory satisfies some axioms, one of which is
transitivity. The addition of the ABCs broke transitivity:
>>> issubclass(list, object)
On Tue, Jun 25, 2019 at 2:11 PM nate lust wrote:
>if an instance is bound to a variable name, any attempts to rebind that name
>will result in a call to the __setself__ (name negotiable) of the instance
>already bound to that name.
I am very, very strongly opposed to this. It would mean that I
On Tue, Mar 26, 2019 at 2:40 AM Richard Whitehead
wrote:
> Using Python’s Condition class is error-prone and difficult.
After looking at your example, I think the problem is just that you
aren't using condition variables the way they're intended to be used.
To write correct condition-variable
On Fri, Mar 8, 2019 at 6:23 PM Steven D'Aprano wrote:
> A sets the argument tuple to (1, 2)
> B sets the argument tuple to (2, 3)
> B calls spam()
> A calls spam() # Oops!
I'm pretty sure the idea was to have constant tuples (1, 2) and (3, 4)
in the module instead of LOAD_CONST
On Sat, Mar 9, 2019 at 4:14 PM Greg Ewing wrote:
>
> A large part of the reason that common operations are written
> using infix operators is that the operator symbols used are very
> compact. That benefit disappears if your operator is an entire
> word.
I suppose people bring up Haskell too
> It's well documented how checked exceptions lead to bad code.
Please cite a paper. I know "everyone knows" that they're bad, but
"everyone knows" a lot of things.
Here's a recentish proposal by Herb Sutter to add a kind of checked
exception to C++:
On Wed, Feb 20, 2019 at 2:43 AM Chris Angelico wrote:
> That's because a generator function conceptually has three ways to
> provide data (yield, return, and raise), but mechanically, one of them
> is implemented over the other ("return" is "raise StopIteration with a
> value"). For other raised
On Tue, Feb 19, 2019 at 3:19 PM Steven D'Aprano wrote:
> And I note that in Java, where the idea of checked exceptions
> originated, it turned out to be full of problems and a very bad idea.
What should be the default behavior of a language when the programmer
doesn't explicitly handle an error?
> On 3/31/18 5:43 PM, Steven D'Aprano wrote:
> > But we could avoid that runtime cost if the keyhole optimizer performed
> > the dedent at compile time:
> >
> > triple-quoted string literal
> > .dedent()
> >
> > could be optimized at compile-time, like other constant-folding.
There are
Note: none of the following is an endorsement of the r/python_ideas
idea. I'm just responding point-by-point to what you wrote.
On Fri, Feb 1, 2019 at 10:47 PM Steven D'Aprano wrote:
> - I can have as many email identities as I like; I can only have one
> Reddit identity at a time.
Do you mean
On Sat, Feb 2, 2019 at 3:31 PM Steven D'Aprano wrote:
> The comprehension version isn't awful:
>
> [(a*2).name.upper() for a in seq]
>
> but not all vectorized operations can be written as a chain of calls on
> a single sequence.
>
If they are strictly parallel (no dot products) and you
On Sat, Feb 2, 2019 at 3:23 PM Christopher Barker
wrote:
> performance asside, I use numpy because:
>
> c = np.sqrt(a**2 + b**2)
>
> is a heck of a lot easer to read, write, and get correct than:
>
> c = list(map(math.sqrt, map(lambda x, y: x + y, map(lambda x: x**2, a),
>
On Fri, Feb 1, 2019 at 11:24 AM Abe Dillon wrote:
> "why not make everything default to 'final' and put 'var' or something
> in-front of the few outliers?".
>
If it happens, it'll be another example of mainstream languages adopting
ideas from functional programming. I love it when that happens,
Aren't the arguments for accepting PEP 463 basically the same as the
arguments for accepting assignment expressions? The current syntax is
painfully verbose and people use inefficient and ad hoc constructions to
get around it. Better to have a language feature to support the way that
people
On Mon, Jun 4, 2018 at 5:11 PM, Steven D'Aprano wrote:
> class MyList(list):
> def pop(self, pos):
> if isinstance(pos, slice):
> temp = self[pos]
> del self[pos]
> return temp
> return super().pop(pos)
>
> Is that what you have in mind?
-specific constraint.
Regardless, I'm not too attached to those names. I want the underlying
functionality, and the names made sense to me. I'd be okay with
`unique_setitem` and `unique_update`.
On Mon, Jun 4, 2018 at 5:25 PM, Steven D'Aprano wrote:
> On Mon, Jun 04, 2018 at 02:22:29PM -0700, Ben
The `pop` method of built-in sequences is basically an atomic version of
val = self[pos]
del self[pos]
return val
If this behavior was extended to the case where `pos` is a slice, you
could write things like:
def cut_deck(deck, pos):
deck.extend(deck.pop(slice(0, pos)))
76 matches
Mail list logo
