I don't like the actual proposal. It weirdly combines almost orthogonal
concepts into the same block statement. Obviously matters other than
indent level are important too (notwithstanding my sincere digression into
my bête noire).
Nested blocks are an excellent way to express roughly orthogonal
>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 never in the last 3800 y
On Mon, Feb 8, 2021 at 3:58 PM Christopher Barker wrote:
>
>> Should we support it in Unix? I don't think so.
>> Command-line and environment variables are easy to use on Unix.
>
>
> maybe, but we have many of the same issues -- we want the configuration tied
> to the environment, not to the user
bringing this back (closer to) on lopic:
Are you suggesting that we add syntax to Python that makes it easier to
keep the number of levels of indentation down?
Because when you have a method in a class, you've already lost 1/10 or your
line. then you have a for, and an if, and a with, and you've
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 character. Really, starting at
more like 70 characters. It's not quite exponential in the harm,
On Mon, Feb 8, 2021 at 6:04 PM David Mertz wrote:
>
> There's a reason that never in the last 3800 years since Proto-Sinaitic was
> the first human script to approximately represent phonemes, has text EVER
> been set at more than 80 characters as a widespread convention.
>
What did they use as
There's a reason that never in the last 3800 years since Proto-Sinaitic was
the first human script to approximately represent phonemes, has text EVER
been set at more than 80 characters as a widespread convention.
Large print sizes have existed for a long time, such as newspapers and
broadsheets.
On Sun, Feb 7, 2021 at 3:58 PM Inada Naoki wrote:
> > Chiefly, I don't want to overload "pyvenv.cfg" with new behavior
> > that's unrelated to virtual environments.
>
This is my point -- this is NOT unrelated to virtual environments -- UTF-8
mode, and other configuration parameters are very much
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
Oscar Benjamin writes:
> On Sun, 7 Feb 2021 at 23:55, Greg Ewing wrote:
> > On 8/02/21 6:59 am, Christopher Barker wrote:
> > > I find myself
> > I often write
> My preferred option is
There's ALWAYS more than one way to do it! :-)
I'm not a fan of the proposed new syntax. A big issue for
On Mon, Feb 8, 2021 at 4:21 PM Random832 wrote:
>
> > On Sat, Feb 6, 2021 at 5:21 PM Random832 wrote:
> > >
> > > While we're on the subject of assignment expression limitations, I've
> > > occasionally wanted to write something like
> > >
> > > try:
> > > return a_dict[key]
> > > except Key
> On Sat, Feb 6, 2021 at 5:21 PM Random832 wrote:
> >
> > While we're on the subject of assignment expression limitations, I've
> > occasionally wanted to write something like
> >
> > try:
> > return a_dict[key]
> > except KeyError:
> > return (a_dict[key] := expression to construct value
I finally got around to submitting a PR for this. Linking here to close the
loop should anyone stumble across this thread in future.
https://bugs.python.org/issue43160
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email
On 2021-02-07 09:59, Christopher Barker wrote:
All that being said, it's not that big a deal, and I personally don't
try to limit to 80 chars per line anyway -- preferring 90 or 95 -- I
haven't used a VT100 in decades
To be honest I find it kind of ridiculous that people are still
worryi
On Sun, 7 Feb 2021 at 23:55, Greg Ewing wrote:
>
> On 8/02/21 6:59 am, Christopher Barker wrote:
>
> > I find myself reading entire files into memory and then processing
> > them, so as to avoid having to extra-indent all the processing code.
>
> I don't know why some people seem to be so afraid o
On Sun, Feb 7, 2021 at 4:16 PM Eryk Sun wrote:
>
> On 2/6/21, Christopher Barker wrote:
> > On Sat, Feb 6, 2021 at 11:47 AM Eryk Sun wrote:
> >
> >> Relative to the installation, "python.cfg" should only be found in the
> >> same directory as the base executable, not its parent directory.
> >
>
On 8/02/21 6:59 am, Christopher Barker wrote:
I find myself reading entire files into memory and then processing
them, so as to avoid having to extra-indent all the processing code.
I don't know why some people seem to be so afraid of
indentation levels. Remember, you don't *have* to indent
This discussion should probably be held on typing-...@python.org. (Hope
you're aware of that list.)
I will have to admit that in PEP 484 we screwed up with `*args` and
`**kwds` -- we thought that these would always be homogeneous and we
thought we'd save the user some time by letting them write `*
Hi Paul,
I suggest that you just go straight to the PEP phase.
--Guido
On Thu, Feb 4, 2021 at 11:54 PM Paul Sokolovsky wrote:
> Hello,
>
> Everyone knows how hard to find a compelling usecase for the assignment
> expression operator (":=", colloquially "walrus operator").
> https://www.python.
I see many people who have their project something like this:
```
directory/
some_module.py
main.py
```
and in main.py they do
```
from some_module import some_function
```
while they have a library named `some_module` that is installed from pip, and
they can't figure out why Python sa
> it's subject to change in future releases; you'll need to change
> your code accordingly if it changes
> because it's language change, it's unlikely you can conditionally
> choose which syntax to use based on the version of Python being used
> you enable it explicitly and accept the instability o
On Sun, Feb 7, 2021 at 12:37 AM Jonathan Crall wrote:
> a with directly after an if costs me 8 spaces instead of 4.\
>
Frankly, I think many (most) uses of with are a waste of an indentation
level. For example, if all I'm doing is opening a file -- that isn't
"logically" a separate block.
In fa
I'm encountering a situation where it would be far cleaner to use
**kwargs (multiple functions taking the same set of parameters); I'd
like to have type hints, and avoid repeating multiple function
definitions, explicitly enumerating all parameters for each function
definition.
Therefore, I'd like
To clarify, the point of __provisional__ would be to enable some
syntactical feature in the language that should not be considered
stable? I'm not sure I see a reason to use this for a new module or
package in stdlib for example; a docstring or perhaps some decorator
like @provisional could indicat
Reading the latest discussion about PEP 622/634-636 on the Python Dev mailing
list, I've noticed there appears to be confusion about what `__future__`
imports are supposed to be used for. Multiple people in that thread (and
probably elsewhere in one of the many many threads about these PEPs) hav
El dom, 7 feb 2021 a las 9:38, Jonathan Crall ()
escribió:
>
>
> Currently my timerit package requires syntax like:
>
> import timerit
> for timer in timerit.Timerit(num=100, bestof=3, verbose=1):
> with timer:
> [code]
>
> But that could be simplified to
>
>
> import timerit
> for tim
@MRAB
> It's not that much shorter. You wouldn't be saving much typing or space.
IMO, that's a weak point. The amount of indentation you need doubles, and
that is significant.
Also, common style guides and best practices recommend no more than 80
chars per line.
Losing 5.5% of my available space
27 matches
Mail list logo
