I've written something like this far too many times:
lines = (line.rstrip('\n') for line in open(frame).readlines())
It's not unworkable, but it's definitely common to want the lines without
the newlines. The corresponding .writelines() hits me less, but it's still
a concern.
I slightly shorter
Umm?!
items = (j for j in range(10) if j not in {2, 8})
We don't need a new keyword. Nor a tortured use of an old one.
On Mon, Jun 28, 2021, 8:46 PM Rob Cliffe via Python-ideas <
python-ideas@python.org> wrote:
> Another wild idea: Suppose that after a line that introduces a suite,
> including
Nice to see you on the list also, Santiago.
The generator is my impression of what is most useful. But someone else
might opine differently, of course.
On Sat, Jun 26, 2021, 1:50 PM wrote:
> Hey David, great to find you here!!
>
> I really like what you're proposing. I could make it a generator
This seems useful to me. But I think it would be better if made more
eager. Let's say you have tasks A, B, C, D, E to process.
If they complete in order E, D, C, B, A then of course you can't do any
in-order processing until they've all completed.
But what if they finish in order A, B, E, D, C.
I've read all the posts in this thread, and am overall at least -0.5 on the
idea. I like methods well enough, but mostly it just seems to invite
confusion versus the equivalent and existing option of importing functions.
I am happy, initially, to stipulate that "some clever technique" is
available
On Sun, Jun 20, 2021, 2:07 PM Sebastian Berg
> NumPy has:
>
> * `flatten()` (always copy)
> * `ravel()` (copies if needed, and additionally ensures contiguity)
> * `reshape(-1)` (copies if needed)
>
> They are all subtly different, unfortunately.
>
Oops! Sebastian is right, and I made an error. N
On Sun, Jun 20, 2021 at 1:07 PM Christopher Barker
wrote:
> Flatten is used in numpy:
> Where it is a method, and goes all the way to one dimension.
>
I think it's worth keeping in mind the differences though. In NumPy,
arr.flatten() doesn't even TOUCH the array itself. It is solely a
manipula
On Thu, Jun 17, 2021 at 5:52 PM Jelle Zijlstra
wrote:
> El jue, 17 jun 2021 a las 14:45, David Mertz () escribió:
>
>> On Thu, Jun 17, 2021, 5:24 PM Ben Rudiak-Gould
>>
>>> Okay, slightly off-topic, but can we *please* allow
>>>
>>> [*chun
On Thu, Jun 17, 2021, 5:24 PM Ben Rudiak-Gould
> Okay, slightly off-topic, but can we *please* allow
>
> [*chunk for chunk in list_of_lists]
>
It is completely non-obvious to me what that would even MEAN. I cannot
derive anything obvious from other uses of *.
If I had to guess, I'd think tha
Still an import for that version!
On Thu, Jun 17, 2021, 2:07 AM Guido van Rossum wrote:
> Just trolling along, flattening a list could be written as
>
> functools.reduce(list.__iadd__, xs, [])
>
> Right?
>
> On Wed, Jun 16, 2021 at 22:53 David Mertz wrote:
>
>>
On Thu, Jun 17, 2021, 1:38 AM Chris Angelico
> >>> list(chain.from_iterable(list_of_lists))
>
> > More-itertools has flatten():
> https://more-itertools.readthedocs.io/en/stable/api.html#more_itertools.flatten.
> That seems better than a method specific to lists.
>
> ... which is built on top of c
On Thu, Jun 17, 2021, 1:14 AM Christopher Barker
> I'm sympathetic to raising an exception on `sum(list_of_lists)` similar to
>> `sum(list_of_strings)`. But what exactly is the recommended substitute?
>> We have this:
>>
>> list(chain.from_iterable(list_of_lists))
>>
>
> If you read the BPO the O
On Wed, Jun 16, 2021 at 7:35 PM Oliver Margetts
wrote:
> I came across this just processing JSON data - flattening a list of
> 'deals' into a list of individual 'trades'. Flattening nested lists is not
> uncommon. And yes sum seemed the natural way to do it at the time.
>
I remember the discussi
>
>
>>1. It is too verbose. Typing "conditional_escape(...)" again and
>> again is cumbersome.
>>
>> from django import conditional_espace as esc
> f'Hi {esc(name)}'
>
It's too bad that ␛ U+251B isn't a valid Python identifier. Then we could
do it in one character :-)
But as I keep sayi
On Fri, Jun 11, 2021 at 2:37 AM Thomas Güttler
wrote:
> If you don't create HTML with Python daily, then you might not feel the
> pain.
>
If you create many HTML strings daily, then you will be typing `foo=foo,
> bar=bar` (to pass the variables
> into the template) over and over again.
> My goal
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.
Python already had excellent HTML templating in libraries. The fact Django
has a function with a lon
On Mon, May 31, 2021 at 11:41 PM Steven D'Aprano
wrote:
> It's pretty standard behaviour for Python. Right now, `eval(repr(...))`
> works unless you have shadowed the name
> Ellipsis.
>
> >>> err = ValueError('something went wrong')
> >>> ValueError = list
> >>> eval(repr(err))
>
On Mon, May 31, 2021 at 9:12 PM David Mertz wrote:
> >>> foo = "bar"
>
>>> eval(repr(foo)) == eval(repr(eval(repr(foo
> True
> >>> eval(repr(None)) == eval(repr(eval(repr(None
> True
>
> Let's change the behavior of
>
> I think you are going against the design of the language here. With only
>
a handful of critical exceptional cases (None, True, False are the only
> ones that come to mind), names can be rebound.
>
The following genuinely surprised me. I was trying to show something
different in reply, but I
I think making 'Ellipsis' a reserved word is too much. The analogy with
non-reserved words like `int`, `str`, `map`, `print`, and so on, illustrate
this, I think. I.e. redefining those is likely to cause bad things to
happen, but we're consenting adults, and in the end they are just names.
Howev
On Tue, May 25, 2021 at 9:36 PM Steven D'Aprano wrote:
> > ALLCAPS means "this value should only be set once and not changed."
>
> `math.pi` says hello.
>
(U ⇒ O) ⊬ (¬U ⇒ ¬O)
The existence of math.pi and the fact that probably nobody ever has
> introduced a bug into their code by carelessly ass
We've already had all of this since long before typing.py existed.
ALLCAPS means "this value should only be set once and not changed."
_underscore means "this is not part of public API, and it may change in
next version.
__double_under means "this is SERIOUSLY not something you should muck with,
The more explanation I see from the OP, the more I oppose the idea. It
becomes more clear that this is a specialization, basically only to help
SymPy, while introducing semantic changes for everyone else (even if minor
ones).
Moreover, SymPy already has several readily available ways to do this,
a
On Sat, May 15, 2021, 3:13 PM Oscar Benjamin
> That would mean that a simple statement like x = -1.01d could assign
> different values depending on the context. Maybe with the new parser it is
> easier to change this so that an unary +/- can be part of the literal.
Steven, at least, stated he as
On Fri, May 14, 2021, 4:31 PM Jonathan Fine wrote:
> >>> 1/2 + 1/3
>> 5/6
>> 1 / 2 + 1 / 3
>> 0.83
>>
>
> I'm sighted. I can see the difference. I suspect a blind person using a
> screen reader would struggle a lot to spot the difference. (I don't know
> enough about scre
1
On Fri, May 14, 2021, 11:38 AM Paul Moore wrote:
> On Fri, 14 May 2021 at 16:29, David Mertz wrote:
> >
> > The memory simply blows up too fast for this to be practical (at least
> as a default) a float is always 64 bits, a fraction is unboundedly large if
> numerator a
The memory simply blows up too fast for this to be practical (at least as a
default) a float is always 64 bits, a fraction is unboundedly large if
numerator and denominator are coprime.
A toy example with a half dozen operations won't make huge fractions. A
loop over a million operations will ofte
On Thu, May 6, 2021, 11:12 AM Shreyan Avigyan
wrote:
> David Mertz:
> > I am a strong -1 on this
>
> Thanks for your feedback. But I'm not suggesting introducing a new
> behavior. The @property already creates read-only member variables. What
> I'm suggesting is th
I am a strong -1 on this.
On Thu, May 6, 2021 at 2:41 PM Shreyan Avigyan
wrote:
> André Roberge:
> > My own email specifically referred to two instances where I found it
> necessary to **modify** methods that are indicated as being private as
> their names begin with double underscores. So, I am
On Mon, May 3, 2021 at 6:49 PM Stestagg wrote:
> class A:
> Namespace B:
> C = 1
>
> A.__dict__ == {‘B.C’: 1, ‘B’: }
OK, that is a difference. I don't really understand why it's desirable,
but I see the difference.
I can make that happen with a metaclass that would allow:
class A
On Mon, May 3, 2021 at 6:37 PM Stestagg wrote:
> 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 descript
So yes... as I thought, SimpleNamespace does EVERYTHING described by the
proposal, just without needing more keywords:
>>> from types import SimpleNamespace
>>> class A(SimpleNamespace):
... class B(SimpleNamespace):
... foo = 'bar'
...
>>> A.B.foo
'bar'
>>> A.B
>>> import sys
>>> var
On Mon, May 3, 2021 at 9:04 AM Paul Moore wrote:
> On Mon, 3 May 2021 at 04:00, David Álvarez Lombardi
> > This is the mindset that I had. I understand there are other ways to do
> what I am asking. (I provided one in my initial post.) I am saying it
> relies on what I believe to be a notoriously
I recommend posters read the code-of-conduct at the foot of every email on
this list.
On Sun, May 2, 2021, 3:07 PM Abdur-Rahmaan Janhangeer
wrote:
> Greetings,
>
> I read as far as the 4th sentence:
> "Use it for your next SaaS!" [no link atached] What on earth (I
> wanted to use a stronge
lock ultimately lives. This is very different
> to how nested classes or types.SimpleNamespace works.
>
> I'm happy to answer any questions, just please read the full proposal
> first :)
>
> On Sun, May 2, 2021 at 1:25 AM David Mertz wrote:
>
>> So this is exa
So this is exactly the same as `types.SimpleNamespace`, but with special
syntax?!
On Sat, May 1, 2021, 7:57 PM Matt del Valle wrote:
> Hi all!
>
> So this is a proposal for a new soft language keyword:
>
> namespace
>
> I started writing this up a few hours ago and then realized as it was
> star
On Sat, May 1, 2021, 3:17 AM Cameron Simpson wrote:
> >Let's take a not-absurd hypothetical:
> >
> >GET [http://example.com/picture] 200 image/jpeg
> >POST [http://nowhere.org/data] 200 application/json
> >PUT [https://example.org/page] 200 text/html
>
> Though for this, they are ok. Or even just
I was actually thinking about this before the recent "string comprehension"
thread. I wasn't really going to post the idea, but it's similar enough
that I am nudged to. Moreover, since PEP 616 added str.removeprefix() and
str.removesuffix(), this feels like a natural extension of that.
I find my
Ok... If the suggestion is trying concatenation of arbitrary objects that
aren't strings, I go from thinking it's unnecessary to thinking it's a
massively horrible idea.
On Fri, Apr 30, 2021, 11:43 PM Valentin Berlier wrote:
> > the ONLY predicate that can be expressed about a single character i
Strings are VERY different from other iterables. Every item in a string is
itself an (iterables) string. In many ways, strings are more like scalars,
and very often we treat them as such.
You could make an argument that e.g. a NumPy array of homogenous scalars is
similar. However, that would be a
Given that there is very little you can test about a single character, a
new construct feels excessive. Basically, the only possible question is "is
it in this subset of codepoints?"
However, that use is perfectly covered by the str.translate() method
already. Regular expressions also cover this w
>
> Yes. Scalars aren't containers. Except strs, which are containers
>
all the way down. :-þ
Wow... how do I get a keyboard with a thorn character on it? :-)
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to pyt
On Fri, Apr 9, 2021, 3:23 PM Peter Ludemann
wrote:
> David Mertz wrote:
> > The pattern of "Create an empty collection, then add stuff in a loop" is
> quite common, ...
>
> Or you can use comprehensions, in which case there's no need for creating
> an empt
I don't do twitter, so hadn't seen Raymond's comment. But I agree that
`{*()}` is too-clever-by-half. Moreover, it's the same character count as
`set()`, so it doesn't even save anything.
Using five characters to create an empty `set()` really isn't that many. I
do that all the time. Proposals
Would it include digamma, san, koppa, or sampi... Or strictly Koine letters?
To a lesser extent than Greek, Hebrew letters are also used commonly in
math. What about the double struck capitals like ℤ, ℚ, and ℕ?
It kinda feels like a very simple third party module couple give many such
names for
On Sat, Apr 3, 2021, 12:34 AM Greg Ewing
> In my experience, RPN is always harder to read than infix. A slew of
> parens can be confusing, but a bunch of operators piled up at the end of an
> expression doesn't make it any better for me.
>
When I first saw the original post, I honestly believed i
omething I did on a regular basis, but
something I had seen as already old fashioned when I was 10 yo.
On Sat, Apr 3, 2021, 12:41 AM Greg Ewing
wrote:
> On 3/04/21 4:33 pm, David Mertz wrote:
> > add all these 20 receipts together without needing 19 "+" signs, but
> > j
On Fri, Apr 2, 2021, 10:52 PM John wrote:
> Study was in calculators, yeah.
>
>
> https://vdocuments.mx/electronic-calculators-which-notation-is-the-better.html
So in 1980, accountants using ticker tape calculators found suffix syntax
less error prone?!
The fundamental point you seen to miss i
I assume it's always April 1 somewhere on Earth. :-)
On Fri, Apr 2, 2021, 12:13 PM Jonathan Goble wrote:
> On Fri, Apr 2, 2021 at 11:58 AM Richard Damon
> wrote:
>
>> I think python only has 3 unary operations, + - and ~ and only + and -
>> can also be binary operations.
>>
>> unary + has le
I have very often wanted versions of itertools.product(),
itertools.permutations(), and itertools.combinations() that don't
concretize their iterators.
They very much violate the spirit of itertools, and hard-lock my machine
when I forget the bad design and try infinite iterators.
I don't think w
I remember Parrot. As I understand it their original goal was a
> language-agnostic virtual machine, which might have complicated things.
>
> I will do a bit of reading and add some text to the "PEP."
>
> Skip
>
> On Sat, Mar 20, 2021, 11:36 AM David Mertz wrote:
&g
The Parrot project was also intended to be the same thing, and for a while
had a fair number of contributors. Unfortunately, it never obtained the
performance wins that were good for.
On Sat, Mar 20, 2021, 11:55 AM Skip Montanaro
wrote:
> Back in the late 90s (!) I worked on a reimagining of the
I quite like multiple dispatch. It's odd to claim it's not OOP, since a
relatively old object-oriented system, the Common Lisp Object System (CLOS)
uses this as it's fundamental construct.
A long time ago, I wrote about and created an example library for
multimethods. Lots of other folks have done
I have written tens of thousands of lines of Pandas code, and I've taught
thousands of people to use Pandas. I've worked with the core developers of
Pandas as well.
This is the first time I've ever seen `\` line continuation used for fluent
programming style rather than just using parentheses as a
On Sat, Mar 6, 2021 at 7:07 AM David Mertz wrote:
> This sounds like a very verbose repeated statement that "there may be a
> use in the future." That's definitely not going to get a feature, no matter
> how many times repeated.
>
> If this is something you actu
This sounds like a very verbose repeated statement that "there may be a use
in the future." That's definitely not going to get a feature, no matter how
many times repeated.
If this is something you actually need, write a subclass of list in Cython
or C, and add that capability. I cannot think of a
On Wed, Feb 24, 2021 at 1:38 PM Paul Korir wrote:
> I've been using the argparse library for a long time and one use case that
> repeatedly shows us is the need to have two arguments appear together i.e
> either both appear or none of them appear. I'll refer to these as *mutually
> inclusive* in
On Mon, Feb 22, 2021 at 2:09 AM Brendan Barnwell
wrote:
> Thinking about this more, I think the main obstacle to use of
> SimpleNamespace isn't the name, it's its the location. No one is going
> to look in the types module for something like this. Why not just put
> SimpleNamespace in t
Cheeseshop!
On Sat, Feb 20, 2021, 1:08 PM Jan Kaliszewski wrote:
> 2021-02-18 Chris Angelico dixit:
>
> [...]
> > Okay. Let's start bikeshedding. If SimpleNamespace were to become a
> > builtin, what should its name be? It needs to be short (obviously),
> > but not TOO short, and it needs to be
On Thu, Feb 18, 2021 at 8:46 PM Steven D'Aprano wrote:
> Although I have heard from Ruby enthusiasts that the ability to write
> large, complex, multi-statement anonymous block functions is really
> useful, its not something I can personally say I have missed.
> I think that once you get past a f
Why is this a discussion?!
Just start your program with:
from types import SimpleNamespace as myfavname
On Wed, Feb 17, 2021 at 11:22 PM Daniel Moisset wrote:
> If we're bike shedding, I'd go for "mutableobject". It's not terribly
> short, but it is built on familiar python terminology and d
On Mon, Feb 15, 2021, 12:26 PM Ricky Teachey
> f(x,y)=>x,y->str
>>
>
I read this as "my cat walked across my keyboard, and I'm very proud she
wants to be a programmer."
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an em
On Mon, Feb 15, 2021 at 4:19 PM Guido van Rossum wrote:
> Okay, here’s my dilemma. It looks like this thread wants to devise a new
> syntax for lambda, using e.g. (x, y) -> x+y, or the same with =>. That’s
> great, but doesn’t open new vistas. OTOH, for people using type
> annotations, a much mor
On Sun, Feb 14, 2021, 5:46 PM Steven D'Aprano wrote:
> I'm curious why you say that if and with are "almost" orthogonal concepts?
> They seem completely orthogonal to me. You can mix and match them in
> literally every combination:
>
I mean in a conceptual sense, not as a matter of Python gramma
On Mon, Feb 8, 2021, 2:15 AM Brendan Barnwell wrote:
> On 2021-02-07 22:36, David Mertz wrote:
> > Code is READ far more often than it is written!
> > Lines more than 80-ish characters impose a rapidly increasing cognitive
> > and visual burden with every additional charac
ou into the
> method, and we're now at a 88 char line :-)
>
> -Chris B
>
>
> On Sun, Feb 7, 2021 at 11:09 PM Chris Angelico wrote:
>
>> On Mon, Feb 8, 2021 at 6:04 PM David Mertz wrote:
>> >
>> > There's a reason that never in the last 3800 ye
>From what I can tell, zero-width tabs. Terrible script to write Python
in... But fine for the compacted JavaScript sent by most servers.
On Mon, Feb 8, 2021, 2:07 AM Chris Angelico wrote:
> On Mon, Feb 8, 2021 at 6:04 PM David Mertz wrote:
> >
> > There's a reason that
utive graphemes.
On Mon, Feb 8, 2021, 1:36 AM David Mertz wrote:
> Code is READ far more often than it is written!
>
> Lines more than 80-ish characters impose a rapidly increasing cognitive
> and visual burden with every additional character. Really, starting at more
> like 70 charac
Code is READ far more often than it is written!
Lines more than 80-ish characters impose a rapidly increasing cognitive and
visual burden with every additional character. Really, starting at more
like 70 characters. It's not quite exponential in the harm, but it's
strongly super-linear, after the
>
> what if we had special support for python -c (and maybe in some other
> places like exec(), but definitely not for source files) for the purpose of
> one-liners? Then the syntax wouldn't need to be suitable for general
> purpose use, and you could do something like "have ~{ ~} ~; as alternate
>
ts.map
On Sat, Jan 9, 2021 at 9:37 PM David Mertz wrote:
> On my system:
>
> % find ~ -name '*.*.*' | rev | cut -d. -f-2 | rev | sort | uniq -c | sort
> -nr | head -30
> 17278 d.ts
> 11314 js.map
>6600 symbolic.png
>4041 png.i
>3968 cpytho
On my system:
% find ~ -name '*.*.*' | rev | cut -d. -f-2 | rev | sort | uniq -c | sort
-nr | head -30
17278 d.ts
11314 js.map
6600 symbolic.png
4041 png.i
3968 cpython-37.pyc
2656 yarn-metadata.json
2614 yarn-tarball.tgz
2575 c.i
2526 csv.gz
1727 h.i
1659 opt-1.pyc
On Tue, Jan 5, 2021 at 10:04 AM Chris Angelico wrote:
> So my question to you is: Why raise all these threads on python-ideas
> that have approximately zero chance of being accepted into the core
> language?
"Approximately zero" overstates the likelihood. "Strictly equal to zero"
is a more acc
On Wed, Dec 23, 2020 at 11:16 PM Brandt Bucher
wrote:
> I didn't participate in the mailing list discussions for PEP 637, but I
> have become somewhat involved in the reference implementation and final
> revisions. While reviewing the PEP, I noticed what I think is a missed
> opportunity to final
2020 at 2:58 PM David Mertz wrote:
>
>> Somewhat supporting my concern, I just was surprised to find this:
>>
>> % ll `which clear`
>> -rwxrwxr-x 2 dmertz 14344 Nov 14 17:07 /home/dmertz/miniconda3/bin/clear
>> % ll /usr/bin/clear
>> -rwxr-xr-x 1 root 1
On Tue, Dec 22, 2020 at 10:26 PM Chris Angelico wrote:
> A tight loop clearing the screen? If you have that, you have much
> bigger problems :). But shelling out to clear/cls has another problem:
> it's a big ol'
> dependency. You need to have the corresponding command, and it needs
> to be acces
On Tue, Dec 22, 2020 at 1:14 AM Chris Angelico wrote:
> > I know why, but I'm not so sure -- no one was using a built in True or
> False as an integer, because they didn't exist.
>
> No, but AIUI people were creating their own globals to do that job.
>
Indeed. The discussion around this was qui
On Mon, Dec 21, 2020 at 6:32 PM Chris Angelico wrote:
> But the real question is: Why do points compare equal based on their
> locations, if you need them to be independently stored in a set?
> Logically, if they are equal, the set either contains that one thing
> or it doesn't.
>
This is a 3 mi
On Mon, Dec 21, 2020 at 5:56 PM Paul Bryan wrote:
> I'm interested in knowing when (id(x), x) would be preferable over
> (type(x), x).
>
Something along these lines:
>>> class Point:
... def __init__(self, x, y):
... self.x = x
... self.y = y
... def __eq__(self, other):
On Mon, Dec 21, 2020 at 5:27 PM Christopher Barker
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. As others have pointed out, 1 and 1.0 are
> considered equal, a
etty fundamental to many other patterns also. And
likewise, things being in sets by equality rather than identity is likewise
fundamental. The change you suggest to make `True != 1` "breaks the world".
>
> On Mon, 2020-12-21 at 03:09 -0500, David Mertz wrote:
>
> I sure h
I sure hope this never happens! It would break millions of working lines
and kill a common useful pattern.
ntrue = sum(this == that for this, that in items)
-100.
On Mon, Dec 21, 2020, 3:00 AM Paul Bryan wrote:
> I know this has come up in the past.
>
> Could the consensus have changed regardi
On Tue, Dec 15, 2020 at 11:22 AM Chris Angelico wrote:
> Seriously, are you actually unaware of this fundamental, or are you
> playing dumb to try to make a point? I'm still trying to figure out
> your point here.
I've already put him in my killfile, but probably unwisely, I still see the
follo
On Sun, Dec 13, 2020, 5:11 PM Paul Sokolovsky d
> a + b + c vs a + (b + c)
>
> Here, there's even no guarantee of the same result, if we have user
> objects with weirdly overloaded __add__().
>
0.1 + 0.2 + 0.3 != 0.1 + (0.2 + 0.3)
>
___
Python-idea
I understand the concept, but no real use case comes to my mind, and
certainly I personally have not needed this. Itertools is kept extremely
minimal by design, containing only a small set of orthogonal primitives.
The recipes in its docs contain others, as does more-itertools. This feels
like so
On Tue, Dec 8, 2020 at 3:31 PM Ricky Teachey wrote:
> I agree with the person who called this a brilliant solution. Here is the
> code from the link for completeness:
>
I'm not diss'ing the approach. But it doesn't really save that much over a
sentinel variable `break_to_middle`. And if you wa
On Sat, Dec 5, 2020 at 6:20 PM Steve Barnes wrote:
> How about reserving unicode numeric superscript characters 0..9 as label
> identifiers only to be used for loop & break, etc. Then the example below
> would become:
>
>
> while¹ not processed():
>
> for² x in the_stuff:
>
> if all_d
On Sat, Dec 5, 2020 at 11:05 AM Alexis Masson
wrote:
> I agree with you that the point of `break x` — labeled or numbered — is to
> target a specific loop to "jump" to, but I'm not comfortable with
> introducing labels to Python. The reason for this is that they look too
> much like identifiers,
I like the idea of named breaks, but I *hate* the idea of numerically
labeled breaks, whether numbered from the inside or from the outside.
On the occasions—which are actually relatively frequent—that I want to
break all the way out of an inner loop, I wind up using a sentinel STOP
variable. I kn
On Thu, Dec 3, 2020 at 8:31 AM Paul Sokolovsky wrote:
> I'm not sure if you already smell it in the air, but the idea of a
> "fully compliant Python" is getting old (simply because it was there
> all this time, and people learned its drawbacks too).
[... etc ...]
I'm not sure if anyone else fee
See https://docs.python.org/3/library/gettext.html.
'_' is the standard name for i18n conversion.
I am against any more standard renaming of breakpoint(). If someone wants
to bind that to another name, they are free to. The point isn't the
length, but the memorability of the name.
On Wed, Dec
There exist TWO highly successful, widely used, JIT compilers for Python.
PyPy and Numba. Neither one of them would have any use whatsoever for this
constantness. Or if you believe otherwise, get a developer of one of those
to comment so. JIT'd Python simply is not slow, even compared to compile
On Tue, Dec 1, 2020 at 5:43 PM Paul Sokolovsky wrote:
> That's in the eye of the beholder, I'm afraid. So, if you don't want to
> be convinced of those clarity improvements, you'll never be.
>
It's hard to be convinced by something that neither you nor anyone else on
the thread has actually pres
On Tue, Dec 1, 2020 at 10:38 AM Paul Sokolovsky wrote:
> And the const is the cheapest way to make Python a tad faster (for
> sure open up possibilities for further optimizations), which should be
> accessible even to such an old clumsy behemoth as CPython.
>
This is at least the 50th idea I've
On Mon, Nov 30, 2020, 5:20 AM Paul Sokolovsky
> So, if anything, we're re-tracing JavaScript steps. We're in dire need
> of const'ness in the language.
Somehow I've used Python for 22 years without experiencing that direness.
I've taught thousands of students already experienced in other langua
On Sun, Nov 29, 2020, 11:52 PM Greg Ewing
wrote:
> On 30/11/20 9:46 am, David Mertz wrote:
> > def f(a, b, c=21, _foo=foo, _bar=bar):
> >
> > Of course I know that users COULD call `f(1, 2, _foo=something_else)`.
> > But we have asked them not to politely, and &qu
On Sun, Nov 29, 2020 at 8:28 PM Brendan Barnwell
wrote:
> After following this thread I'm still not convinced changing the for
> loop is really a good idea. I basically agree with Steven D'Aprano that
> the supposed benefits of "protecting" against accidental name shadowing
> are marginal at bes
> bow = Ribbon(colour='yellow')
> tie(bow, old_oak_tree)
> for archer in troop:
> let bow = get_weapon()
> archer.take(bow)
> assert bow.colour = 'yellow'
>
I had just this problem yesterday, and on many other days. However, I
don't think the opt-in block scoping w
On Thu, Nov 26, 2020, 5:12 AM Greg Ewing
> Then we just need a way to specify that particular names are
> captured by value. Not sure how to do that in a way that doesn't look ugly
> and/or obscure.
>
Isn't that EXACTLY what you call "default argument abuse"?!
To me, that is concise, obvious, an
On Thu, Nov 26, 2020 at 9:08 AM Steven D'Aprano wrote:
> > and simplifies implementation of the widely used convolution operation
> in signal processing.
>
> For the benefit of the 99.9% of Python programmers who have no idea
> what this "convolution operation" is, can you give an example? It's o
201 - 300 of 1177 matches
Mail list logo
