It's not uncommon for C++ tutorials etc, to refer to using:
system("cls");
to clear the screen (in windows console environments only). I assume this
is what ankith was talking about.
The python equivalent would be:
import os
os.system('cls')
or in the repl:
_ = os.system('cls').
Note,
For what it's worth, I was just writing the following today, and Steven's
proposal came to mind.
If we ignore the set of questionable (but realistic) decisions that led to
me having to do the following, and the discussion on how the unpacking
syntax would look:
---[ wot I wrote ] ---
if
I'm (weakly) +1 for the concept of for..else being confusing, weird, and
somehow not quite suitable/useful for many use-cases where it feels like it
should.
I'm -1 for each of the suggested improvements that I've understood so far.
I agree that the suggested 'ban' on changes in this area is
are justified just for enabling indexing).
The cPython patch can be found here:
https://github.com/stestagg/dict_index/blob/master/changes.patch, and the
benchmark results are linked below.
The tl/dr from my perspective is that these results make the change
challenging to continue proposing without
)...
...But I'm not afraid of doing horribly evil things to python for the
purposes of proof-of-concepts.
The code in this gist:
https://gist.github.com/stestagg/4962d4e86fb586b14138f19af4ae4a02
Implements a very ugly codec hack to make python 'understand' keywords in
index constructs, and I use it to show
I was following you right up till this bit:
>
> By the way, as previously noted
> d[1, 2]
> d[(1, 2)]
> are at present equivalent. However, in the new syntax
> d[1, 2, a=3]
> d[(1, 2), a=3]
> are not equivalent. (The first has three arguments, the second two, the
> first of which
Yes fair point.
That seems more correct
On Thu, Aug 6, 2020 at 2:49 PM MRAB wrote:
> On 2020-08-06 14:16, Stestagg wrote:
> > I was following you right up till this bit:
> >
> >
> > By the way, as previously noted
> > d[1, 2]
> >
On Sat, 1 Aug 2020 at 00:32, Guido van Rossum wrote:
> If true this would be a huge argument against adding indexing and slicing
> (other than the special case starting with 0). However, I don't think it's
> true. The dict implementation (again, starting in 3.6) actually stores the
> list of
On Wed, Jul 1, 2020 at 12:03 PM Steven D'Aprano wrote:
> On Mon, Jun 29, 2020 at 06:42:37PM +0100, Stestagg wrote:
>
> > One simple example of where this is surprising is in the following:
> >
> > >>> random.choice({'a': 1,}.keys())
> > TypeError:
On Wed, Jul 1, 2020 at 12:18 PM Steven D'Aprano wrote:
> On Tue, Jun 30, 2020 at 10:18:34AM +0100, Stestagg wrote:
>
> > This property is nice, as .keys() (for example) can operate like a set
> and
> > give lots of convenience features. However this doesn't really mean t
python syntax might be considered better
than the more elegant custom version, but yes, it's a bit sad
Steve
On Thu, Jul 2, 2020 at 12:27 PM Greg Ewing
wrote:
> On 2/07/20 10:49 pm, Stestagg wrote:
> > Coincidentally, cython has a custom, deprecated syntax for properties
> > t
On Wed, Jul 1, 2020 at 3:24 PM Steven D'Aprano wrote:
> On Wed, Jul 01, 2020 at 01:36:34PM +0100, Stestagg wrote:
> > On Wed, Jul 1, 2020 at 12:18 PM Steven D'Aprano
> wrote:
> >
> > > On Tue, Jun 30, 2020 at 10:18:34AM +0100, Stestagg wrote:
> > >
>
should be
trivial once the change has some agreement behind it.
Steve
On Wed, Jul 1, 2020 at 4:31 PM Stestagg wrote:
> I'll try to unwind the rabbit holes a bit and suggest that the differences
> in opinion here boil down to:
>
> Is it most useful to consider dict_keys/
Hi
A quick collection of responses:
But we're not talking about *dict*, we're talking about dict.items which
> returns a set-like object:
>
> py> from collections.abc import Set
> py> isinstance({}.items(), Set)
> True
>
>
This property is nice, as .keys() (for example) can operate
Re the benchmarks:
yes, they're micro benchmarks, the intent was to show that the
performance can be non impacting
no, that doesn't invalidate them (just scopes their usefulness, my sales
pitch at the end was slightly over-egging things but reasonable, imo),
yes I ignored direct quadratic
>
>
> Adding indexing to views adds another requirement to the dict
> implementation:
>
Yes, that's the proposed change
> indexing for sequences at least suggests that access is O(1).
>
That makes it impossible to use, as an example, a linked list to preserve
> insertion order.
>
The docs for
On Fri, Jul 10, 2020 at 1:28 PM Ronald Oussoren
wrote:
>
>
> On 10 Jul 2020, at 14:08, Stestagg wrote:
>
>
>> Adding indexing to views adds another requirement to the dict
>> implementation:
>>
>
> Yes, that's the proposed change
>
>
>> indexi
) nor the most readable version, but is more
readable than the next(iter(dict.keys()) alternative that's been mooted.
On Fri, Jul 10, 2020 at 2:20 PM Paul Moore wrote:
> On Fri, 10 Jul 2020 at 13:47, Stestagg wrote:
>
> > The intent of my statement was: The current implementation
Coincidentally, cython has a custom, deprecated syntax for properties that
is actually pretty similar, and nice:
cdef class Spam:
property cheese:
"A doc string can go here."
def __get__(self):
# This is called when the property is read.
...
> I too have sometimes proposed what I think of as "minor quality-of-life"
> enhancements, and had them shot down. It stings a bit, and can be
> frustrating, but remember it's not personal.
>
I don't mind the shooting down, as long as the arguments make sense :D.
It seems like we're both in
This new patch works for keys(), .items(), and .values() (as intended by
the original change)
On Wed, Jul 1, 2020 at 5:27 PM Stestagg wrote:
> For what it's worth, I've attached a patch that implements this as a
> prototype.
>
> It's definitely not mergeable right now. I'm not
Just for clarification, I assume you meant ‘per-interpreter’ there, not
‘Perl-interpreter’ which would be a somewhat more interesting option
Steve
On Mon, 29 Jun 2020 at 21:48, Brett Cannon wrote:
> It's a discussion issue. PEP 554 is trying to focus on the API of
> subinterpreters and
I'm quite supportive (+1) of the proposal to add numeric indexing to the
'dict_*' views.
Given that dictionaries are now ordered, it seems reasonable to look-up,
for example, keys by index,
One simple example of where this is surprising is in the following:
>>> random.choice({'a':
I was thinking about the "Load JSON file as single line" thread from a bit
back, and had an idea for a neat solution, albeit one that has potential
stylistic issues.
Idea:
Create two new methods on pathlib.Path objects:
Path.load(loader, **kwargs)
and
Path.dump(dumper, obj, **kwargs)
That makes sense, so these are kind of 'views' over a sequence, but ones
that implement a copy-on-write when the underlying object is modified in
any way?
I can see this being super hard/impossible to implement reliably, but would
be a pretty nice addition if it can be done.
On Wed, Dec 9, 2020
On Wed, Dec 9, 2020 at 12:05 PM Mathew Elman wrote:
> Steven D'Aprano wrote:
> > On Tue, Dec 08, 2020 at 11:46:59AM -, Mathew Elman wrote:
> > > I would like to propose adding lazy types for casting
> > > builtins in a
> > > lazy fashion. e.g. lazy_tuple which creates a reference to the
> >
On Thu, Dec 17, 2020 at 8:58 AM Paul Sokolovsky wrote:
> Hello,
>
> On Thu, 17 Dec 2020 00:03:51 +0100
> Marco Sulla wrote:
>
> > On Wed, 16 Dec 2020 at 20:18, Paul Sokolovsky
> > wrote:
> > > But still, are there Python implementations which compile "(a.b)()"
> > > faithfully, with its
Endorsing putting docstrings in stub files is an intriguing idea, but I can
see some potential issues with the approach:
>From pep 484, the use-cases listed for stub files are:
- Extension modules
- Third-party modules whose authors have not yet added type hints
- Standard library
On Fri, Jan 1, 2021 at 2:21 PM Marco Sulla
wrote:
> On Fri, 1 Jan 2021 at 06:38, Steven D'Aprano wrote:
> > Relevant: https://bugs.python.org/issue42801
>
> Can't reproduce on the latest trunk (3.10). I get 1989 as a result.
>
There were a spate of bugs about this, and was fixed by
On Mon, Jan 4, 2021 at 2:53 PM Calvin Spealman wrote:
>
> This is true, but...
> it might be possible to include something more like pipenv's "shell" which
> spawns a new instance of your shell with the right paths. It effectively
> achieves the same goal, without needing to source,
>
>
> There
On Thu, Jun 10, 2021 at 2:58 PM Ricky Teachey wrote:
> Something I don't understand is whether there is anything about this
> proposed feature that can't be accomplished with a simple function...
>
>
> And use it like this:
>
> >>> templify("Here, have some {foo}.")
>
On Thu, Jun 10, 2021 at 7:31 AM Thomas Güttler
wrote:
> Thank you Guido, Chris, Matt and Richard for your feedback to my last
> email.
>
> Here is an updated version called "Template Literals".
>
>
I much prefer:
Alternative Ideas
Instead of backticks for example t'...' could be used.
instead
On Thu, Jun 10, 2021 at 2:35 PM David Mertz wrote:
> Strong -1
>
> As others noted in prior discussion, even if this existed, it works be an
> anti-pattern for SQL. So basically, it's just baking in an HTML-only
> template language into the language syntax.
>
> The discussion I could find on the
-1 for all of this unless it’s included as part of a bigger change that has
proven performance benefits when constants are used
On Mon, 24 May 2021 at 23:10, Joren wrote:
> We could define "change" in terms of the hash of the object the name
> points to, as well as the name itself (the pointer
On Wed, May 26, 2021 at 1:10 PM Shreyan Avigyan
wrote:
> Reply to Paul Moore:
>
> In Python terms, a constant is a name that binds itself to a value in
> memory and that name cannot bind itself to a different value now (unlike
> variables). The value can be mutated (if mutable) but the name
On Wed, May 26, 2021 at 1:38 PM Shreyan Avigyan
wrote:
> Reply to Stestagg:
>
> That's annotation to make sure no one uses a name.
No.
> This is a proposal to implement constant name binding in Python.
Here are some excerpts from pep 591, specifically, how are they different
f
On Tue, May 25, 2021 at 4:02 PM Ethan Furman wrote:
> On 5/25/21 5:23 AM, Chris Angelico wrote:
> > On Tue, May 25, 2021 at 9:55 PM Shreyan Avigyan wrote:
>
> >> The proposed syntax is as follows,
> >>
> >> constant x = 10
> >> constant y = ["List"]
> >> constant z: str = "Hi"
> >
> >
On Tue, May 25, 2021 at 4:41 PM Shreyan Avigyan
wrote:
> First it would seem useless or not necessary but soon this becomes clear.
> 1) It would help programmers debug their code easily and help them find out
> that the bug's not in the constant,
A reasonable type checker will detect cases
FYI, default here is unused.
On Sun, 23 May 2021 at 14:29, Ricky Teachey via Python-ideas <
python-ideas@python.org> wrote:
> I think you can already do all of this with a custom exception-swallowing
> decorator function.
>
> Something like this:
>
> from functools import wraps
>
> def
On Tue, May 25, 2021 at 5:24 PM Shreyan Avigyan
wrote:
> Reply to Chris:
>
> Wait. Deployment? Before deploying we *run the code* at least once and
> then we get the errors. And I'm not sure but type checking is ok but
> sometimes enforcing is a better option. Why? Mypy or typecheckers have to
>
On Fri, 30 Apr 2021 at 17:08, David Álvarez Lombardi
wrote:
> I propose a syntax for constructing/filtering strings analogous to the one
> available for all other builtin iterables. It could look something like
> this.
>
> >>> dirty = "f8sjGe7"
> >>> clean = c"char for char in dirty if char in
On Sun, 2 May 2021 at 00:57, Matt del Valle wrote:
> Hi all!
>
> So this is a proposal for a new soft language keyword:
>
> namespace
>
> …
> - any name bound within the namespace block is bound in exactly the same
> way it would be bound if the namespace block were not there, except that
> the
One issue with many common programming languages is that they appear to
offer access protections via private/protected etc, but seldom do so
securely (`private` modifiers are never, to my knowledge, intended to be a
security mechanism).
/
Take for example C++:
#include
#include
On Mon, 3 May 2021 at 19:24, David Mertz wrote:
> So yes... as I thought, SimpleNamespace does EVERYTHING described by the
> proposal, just without needing more keywords:
>
Except that the code and description of the proposal explicitly outline
behaviours that SimpleNamespace does not provide
for some
nicer nested API definitions (a-la pandas DataFrame.str.xxx methods) where
an intermediate name os used just to group and organise methods.
On Mon, 3 May 2021 at 19:40, David Mertz wrote:
> On Mon, May 3, 2021 at 6:37 PM Stestagg wrote:
>
>> On Mon, 3 May 2021 at 19:24, David
On Sun, 14 Mar 2021 at 18:58, Guido van Rossum wrote:
> On Sun, Mar 14, 2021 at 7:11 AM Theia Vogel wrote:
>
>> > import the_module
>>
>> > the_module.sys
>>
>> > would work, but
>>
>> > from the_module import sys
>>
>> > would not work?
>>
>> > That might be odd and confusing.
>>
>> Good
ly because they've been burned when trying to
> evolve their API) and feel so strongly about it that they implement their
> own restrictive access controls (without resorting to writing C code).
>
> On Sun, Mar 14, 2021 at 12:42 PM Stestagg wrote:
>
>> On Sun, 14 Mar
I was quite feeling pretty positive about the 'stab' (thanks Steve for this
term!) operator idea, until I tried out some examples locally, and it just
feels a bit too out-of-place in python, for me (100% subjective opinion
here).
Having used stabs and compact closure syntax in various languages:
My take on this is that it's actually a valid suggestion, albeit wrapped in
some unhelpful language.
This is a more common example, in my opinion:
=== fileA.py ===
class MyClass:
def do_thing(self, arg_a, arg_b):
pass
=== fileB.py ===
...
class MySubClass(MyClass):
pass
===
To avoid confusion, the traceback below has been updated here with correct
names:
On Mon, Feb 22, 2021 at 11:07 PM Stestagg wrote:
> My take on this is that it's actually a valid suggestion, albeit wrapped
> in some unhelpful language.
>
> This is a more common example, i
50 matches
Mail list logo
