Mailman 3 February 2019 - Python-ideas

Adding a thin wrapper class around the functions in stdlib.heapq
by bunslow Feb. 18, 2022

Feb. 18, 2022

Nothing so bombastic this time. The heapq functions are basically all named "heapsomething", and basically all take a "heap" for their first argument, with supplementary args coming after. It's a textbook example of the (hypothetical) Object Oriented Manifesto™ where defining a class increases type safety and programmers' conceptual clarity. There're practically no drawbacks, and the code to be added would be very simple. Updating the tests and docs would probably be harder. In pure Python, … [View More]

17 32

Make fnmatch.filter accept a tuple of patterns
by Andre Delfino March 26, 2021

March 26, 2021

Frequently, while globbing, one needs to work with multiple extensions. I’d like to propose for fnmatch.filter to handle a tuple of patterns (while preserving the single str argument functionality, alas str.endswith), as a first step for glob.i?glob to accept multiple patterns as well. Here is the implementation I came up with: https://github.com/python/cpython/compare/master...andresdelfino:fnmatch-mu… If this is deemed reasonable, I’ll write tests and documentation updates. Any opinion?

9 15

Dataclasses, keyword args, and inheritance
by George Leslie-Waksman March 12, 2021

March 12, 2021

The proposed implementation of dataclasses prevents defining fields with defaults before fields without defaults. This can create limitations on logical grouping of fields and on inheritance. Take, for example, the case: @dataclass class Foo: some_default: dict = field(default_factory=dict) @dataclass class Bar(Foo): other_field: int this results in the error: 5 @dataclass ----> 6 class Bar(Foo): 7 other_field: int 8 ~/.pyenv/versions/3.6.2/envs/… [View More]clover_pipeline/lib/python3.6/site-packages/dataclasses.py in dataclass(_cls, init, repr, eq, order, hash, frozen) 751 752 # We're called as @dataclass, with a class. --> 753 return wrap(_cls) 754 755 ~/.pyenv/versions/3.6.2/envs/clover_pipeline/lib/python3.6/site-packages/dataclasses.py in wrap(cls) 743 744 def wrap(cls): --> 745 return _process_class(cls, repr, eq, order, hash, init, frozen) 746 747 # See if we're being called as @dataclass or @dataclass(). ~/.pyenv/versions/3.6.2/envs/clover_pipeline/lib/python3.6/site-packages/dataclasses.py in _process_class(cls, repr, eq, order, hash, init, frozen) 675 # in __init__. Use "self" if possible. 676 '__dataclass_self__' if 'self' in fields --> 677 else 'self', 678 )) 679 if repr: ~/.pyenv/versions/3.6.2/envs/clover_pipeline/lib/python3.6/site-packages/dataclasses.py in _init_fn(fields, frozen, has_post_init, self_name) 422 seen_default = True 423 elif seen_default: --> 424 raise TypeError(f'non-default argument {f.name!r} ' 425 'follows default argument') 426 TypeError: non-default argument 'other_field' follows default argument I understand that this is a limitation of positional arguments because the effective __init__ signature is: def __init__(self, some_default: dict = <something>, other_field: int): However, keyword only arguments allow an entirely reasonable solution to this problem: def __init__(self, *, some_default: dict = <something>, other_field: int): And have the added benefit of making the fields in the __init__ call entirely explicit. So, I propose the addition of a keyword_only flag to the @dataclass decorator that renders the __init__ method using keyword only arguments: @dataclass(keyword_only=True) class Bar(Foo): other_field: int --George Leslie-Waksman [View Less]

12 35

@classproperty, @abc.abstractclasspropery, etc.
by K. Richard Pixley Dec. 16, 2020

Dec. 16, 2020

There's a whole matrix of these and I'm wondering why the matrix is currently sparse rather than implementing them all. Or rather, why we can't stack them as: class foo(object): @classmethod @property def bar(cls, ...): ... Essentially the permutation are, I think: {'unadorned'|abc.abstract}{'normal'|static|class}{method|property|non-callable attribute}. concreteness implicit first arg type name comments {unadorned} {unadorned} method def foo(): exists … [View More]now {unadorned} {unadorned} property @property exists now {unadorned} {unadorned} non-callable attribute x = 2 exists now {unadorned} static method @staticmethod exists now {unadorned} static property @staticproperty proposing {unadorned} static non-callable attribute {degenerate case - variables don't have arguments} unnecessary {unadorned} class method @classmethod exists now {unadorned} class property @classproperty or @classmethod;@property proposing {unadorned} class non-callable attribute {degenerate case - variables don't have arguments} unnecessary abc.abstract {unadorned} method @abc.abstractmethod exists now abc.abstract {unadorned} property @abc.abstractproperty exists now abc.abstract {unadorned} non-callable attribute @abc.abstractattribute or @abc.abstract;@attribute proposing abc.abstract static method @abc.abstractstaticmethod exists now abc.abstract static property @abc.staticproperty proposing abc.abstract static non-callable attribute {degenerate case - variables don't have arguments} unnecessary abc.abstract class method @abc.abstractclassmethod exists now abc.abstract class property @abc.abstractclassproperty proposing abc.abstract class non-callable attribute {degenerate case - variables don't have arguments} unnecessary I think the meanings of the new ones are pretty straightforward, but in case they are not... @staticproperty - like @property only without an implicit first argument. Allows the property to be called directly from the class without requiring a throw-away instance. @classproperty - like @property, only the implicit first argument to the method is the class. Allows the property to be called directly from the class without requiring a throw-away instance. @abc.abstractattribute - a simple, non-callable variable that must be overridden in subclasses @abc.abstractstaticproperty - like @abc.abstractproperty only for @staticproperty @abc.abstractclassproperty - like @abc.abstractproperty only for @classproperty --rich [View Less]

10 15

Add the imath module
by Serhiy Storchaka March 22, 2020

March 22, 2020

What are your thoughts about adding a new imath module for integer mathematics? It could contain the following functions: * factorial(n) Is just moved from the math module, but non-integer types are rejected. Currently math.factorial() accepts also integer floats like 3.0. It looks to me, the rationale was that at the time when math.factorial() was added, all function in the math module worked with floats. But now we can revise this decision. * gcd(n, m) Is just moved from the math … [View More]

14 38

Re: [Python-ideas] Allow star unpacking within an slice expression
by Neil Girdhar March 7, 2020

March 7, 2020

I didn't think of this when we were discussing 448. I ran into this today, so I agree with you that it would be nice to have this. Best, Neil On Monday, December 4, 2017 at 1:02:09 AM UTC-5, Eric Wieser wrote: > > Hi, > > I've been thinking about the * unpacking operator while writing some numpy > code. PEP 448 allows the following: > > values = 1, *some_tuple, 2 > object[(1, *some_tuple, 2)] > > It seems reasonable to me that it should be extended to … [View More]

2 2

Specify number of items to allocate for array.array() constructor
by Sven Rahmann Feb. 22, 2020

Feb. 22, 2020

At the moment, the array module of the standard library allows to create arrays of different numeric types and to initialize them from an iterable (eg, another array). What's missing is the possiblity to specify the final size of the array (number of items), especially for large arrays. I'm thinking of suffix arrays (a text indexing data structure) for large texts, eg the human genome and its reverse complement (about 6 billion characters from the alphabet ACGT). The suffix array is a long int … [View More]

14 20

Fixed point format for numbers with locale based separators
by Łukasz Stelmach Dec. 20, 2019

Dec. 20, 2019

Hi, I would like to present two pull requests[1][2] implementing fixed point presentation of numbers and ask for comments. The first is mine. I learnt about the second after publishing mine. The only format using decimal separator from locale data for float/complex/decimal numbers at the moment is "n" which behaves like "g". The drawback of these formats, I would like to overcome, is the inability to print numbers ranging more than one order of magnitude with the same number of decimal digits … [View More]

5 9

Please consider adding of functions file system operations to pathlib
by George Fischhof Nov. 16, 2019

Nov. 16, 2019

Good day all, as a continuation of thread "OS related file operations (copy, move, delete, rename...) should be placed into one module" https://mail.python.org/pipermail/python-ideas/2017-January/044217.html please consider making pathlib to a central file system module with putting file operations (copy, move, delete, rmtree etc) into pathlib. BR, George

3 3

Start argument for itertools.accumulate() [Was: Proposal: A Reduce-Map Comprehension and a "last" builtin]
by Raymond Hettinger Oct. 23, 2019

Oct. 23, 2019

> On Friday, April 6, 2018 at 8:14:30 AM UTC-7, Guido van Rossum wrote: > On Fri, Apr 6, 2018 at 7:47 AM, Peter O'Connor <peter.ed...(a)gmail.com> wrote: >> So some more humble proposals would be: >> >> 1) An initializer to itertools.accumulate >> functools.reduce already has an initializer, I can't see any controversy to adding an initializer to itertools.accumulate > > See if that's accepted in the bug tracker. It did come-up once but was closed … [View More]for a number reasons including lack of use cases. However, Peter's signal processing example does sound interesting, so we could re-open the discussion. For those who want to think through the pluses and minuses, I've put together a Q&A as food for thought (see below). Everybody's design instincts are different -- I'm curious what you all think think about the proposal. Raymond --------------------------------------------- Q. Can it be done? A. Yes, it wouldn't be hard. _sentinel = object() def accumulate(iterable, func=operator.add, start=_sentinel): it = iter(iterable) if start is _sentinel: try: total = next(it) except StopIteration: return else: total = start yield total for element in it: total = func(total, element) yield total Q. Do other languages do it? A. Numpy, no. R, no. APL, no. Mathematica, no. Haskell, yes. * http://docs.scipy.org/doc/numpy/reference/generated/numpy.ufunc.accumulate.… * https://stat.ethz.ch/R-manual/R-devel/library/base/html/cumsum.html * http://microapl.com/apl/apl_concepts_chapter5.html \+ 1 2 3 4 5 1 3 6 10 15 * https://reference.wolfram.com/language/ref/Accumulate.html * https://www.haskell.org/hoogle/?hoogle=mapAccumL Q. How much work for a person to do it currently? A. Almost zero effort to write a simple helper function: myaccum = lambda it, func, start: accumulate(chain([start], it), func) Q. How common is the need? A. Rare. Q. Which would be better, a simple for-loop or a customized itertool? A. The itertool is shorter but more opaque (especially with respect to the argument order for the function call): result = [start] for x in iterable: y = func(result[-1], x) result.append(y) versus: result = list(accumulate(iterable, func, start=start)) Q. How readable is the proposed code? A. Look at the following code and ask yourself what it does: accumulate(range(4, 6), operator.mul, start=6) Now test your understanding: How many values are emitted? What is the first value emitted? Are the two sixes related? What is this code trying to accomplish? Q. Are there potential surprises or oddities? A. Is it readily apparent which of assertions will succeed? a1 = sum(range(10)) a2 = sum(range(10), 0) assert a1 == a2 a3 = functools.reduce(operator.add, range(10)) a4 = functools.reduce(operator.add, range(10), 0) assert a3 == a4 a4 = list(accumulate(range(10), operator.add)) a5 = list(accumulate(range(10), operator.add, start=0)) assert a5 == a6 Q. What did the Python 3.0 Whatsnew document have to say about reduce()? A. "Removed reduce(). Use functools.reduce() if you really need it; however, 99 percent of the time an explicit for loop is more readable." Q. What would this look like in real code? A. We have almost no real-world examples, but here is one from a StackExchange post: def wsieve(): # wheel-sieve, by Will Ness. ideone.com/mqO25A->0hIE89 wh11 = [ 2,4,2,4,6,2,6,4,2,4,6,6, 2,6,4,2,6,4,6,8,4,2,4,2, 4,8,6,4,6,2,4,6,2,6,6,4, 2,4,6,2,6,4,2,4,2,10,2,10] cs = accumulate(cycle(wh11), start=11) yield( next( cs)) # cf. ideone.com/WFv4f ps = wsieve() # codereview.stackexchange.com/q/92365/9064 p = next(ps) # 11 psq = p*p # 121 D = dict( zip( accumulate(wh11, start=0), count(0))) # start from sieve = {} for c in cs: if c in sieve: wheel = sieve.pop(c) for m in wheel: if not m in sieve: break sieve[m] = wheel # sieve[143] = wheel@187 elif c < psq: yield c else: # (c==psq) # map (p*) (roll wh from p) = roll (wh*p) from (p*p) x = [p*d for d in wh11] i = D[ (p-11) % 210] wheel = accumulate(cycle(x[i:] + x[:i]), start=psq) p = next(ps) ; psq = p*p next(wheel) ; m = next(wheel) sieve[m] = wheel [View Less]

17 49

support toml for pyproject support
by Jimmy Girardet July 29, 2019

July 29, 2019

Hi, I don't know if this was already debated but I don't know how to search in the whole archive of the list. For now the adoption of pyproject.toml file is more difficult because toml is not in the standard library. Each tool which wants to use pyproject.toml has to add a toml lib as a conditional or hard dependency. Since toml is now the standard configuration file format, it's strange the python does not support it in the stdlib lije it would have been strange to … [View More]

13 15

Re: [Python-ideas] Trigonometry in degrees
by Hugh Fisher May 8, 2019

May 8, 2019

> Date: Thu, 7 Jun 2018 12:33:29 +0000 > From: Robert Vanden Eynde <robertvandeneynde(a)hotmail.com> > To: python-ideas <python-ideas(a)python.org> > Subject: [Python-ideas] Trigonometry in degrees > Message-ID: > > > I suggest adding degrees version of the trigonometric functions in the math module. > > - Useful in Teaching and replacing calculators by python, importing something is seen by the young students much more easy than to define a … [View More]function. I agree that degrees are useful for teaching. They are also very useful for graphics programming, especially with my favourite OpenGL API. But I think that the use of radians in programming language APIs is more prevalent, so the initial advantage of easy learning will be outweighed by the long term inconvenience of adjusting to what everyone else is doing. Writing degrees(x) and radians(x) is a little inconvenient, but it does make it clear what units are being used. And even if your proposal is adopted, there is still going to be a lot of code around that uses the older math routines. With the current API it is a least safe to assume that angles are radians unless stated otherwise. > - Special values could be treated, aka when the angle is a multiple of 90, young students are often surprise to see that cos(pi/2) != 0 > > Testing for a special value Isn't very costly (x % 90 == 0) but it could be pointed out that there is a small overhead using the "degrees" equivalent of trig function because of the radians to degrees conversion And the special values testing. Not just young students :-) I agree with this, but I would prefer the check to be in the implementation of the existing functions as well. Any sin/cos very close to 0 becomes 0, any close to 1 becomes 1. > - Standard names will be chosen so that everyone will use the same name convention. I suggest adding a "d" like sind, cosd, tand, acosd, asind, atand, atan2d. Not "d". In the OpenGL 3D API, and many 3D languages/APIs since, appending "d" means "double precision". It's even sort of implied by the C math library which has sinf and friends for single precision. > > Creating a new package like 'from math.degrees import cos' however I would not recommend that because "cos" in the source code would mean to lookup the import to know if it's in degrees or radians (and that leads to very filthy bugs). Also "degrees" is already so the name would have to change the name of the package. Agree, not a good idea. -- cheers, Hugh Fisher [View Less]

16 29

f-string "debug" conversion
by Eric V. Smith May 3, 2019

May 3, 2019

This idea was proposed to me at the core sprints last month by Larry Hastings. I've discussed it with a few people, who seem generally positive about it, and we've tweaked it a little bit. I've spent some time implementing it, and I think it's doable. I thought I'd post it here for any additional feedback. Here’s the idea: for f-strings, we add a !d conversion operator, which is superficially similar to !s, !r, and !a. The meaning of !d is: produce the text of the expression (not its … [View More]

12 36

Dict joining using + and +=
by João Matos March 22, 2019

March 22, 2019

35 94

Return for assignment blocks
by Calvin Spealman March 20, 2019

March 20, 2019

I'd like to suggest what I think would be a simple addition to `def` and `class` blocks. I don't know if calling those "Assignment Blocks" is accurate, but I just mean to refer to block syntaxes that assign to a name. Anyway, I propose a combined return-def structure, and optionally also allowing a return-class version. Omitting the name would be allowable, as well. This would only apply to a `def` or `class` statement made as the last part of the function body, of course. def ignore_exc(… [View More]

14 33

Allow async defs for __await__
by Thomas Gläßle Feb. 28, 2019

Feb. 28, 2019

Hi, I suggest to allow defining awaitable classes in terms of `async def`-s: class FeynmanAlgorithm: async def __await__(self): await self.write_down_the_problem() await self.think_real_hard() await self.write_down_the_solution() IMO, this would be the "… [View More]one obvious way" for anyone who's using it for anything other than defining low-level primitives. It is also easier to teach and and more consistent with how you can define iterables - where `__iter__` is explicitly allowed to be defined in terms of generator function (which I would consider the equivalent to the async defs of awaitables). The implementation could be as easy as calling `__await__` as long as the returned object is not an iterator instead of going straight to TypeError. Currently `__await__` must return an iterator, and one has to define a separate function or method (or use a decorator) to do the same, e.g.: class FeynmanAlgorithm: def __await__(self): return self.perform().__await__() async def perform(self): [...] IMO, this is far from obvious and has been subject to a few subtle differences between python versions. For example: import asyncio class Waiter: def __await__(self): return asyncio.sleep(1).__await__() asyncio.get_event_loop().run_until_complete( asyncio.ensure_future(Waiter())) works fine on python 3.7 but fails on python 3.5 with "AttributeError: 'generator' object has no attribute '__await__'" because some awaitables are implemented using generator type coroutines. Adding to potential confusion, `async def __await__` seems to be work in certain situations: import asyncio class Waiter: async def __await__(self): await asyncio.sleep(1) # this works on py3.7: asyncio.get_event_loop().run_until_complete( asyncio.ensure_future(Waiter())) but, awaiting them in a coroutine context causes an error: async def foo(): await Waiter() # "TypeError: __await__() returned a coroutine": asyncio.get_event_loop().run_until_complete( asyncio.ensure_future(foo())) In earlier python versions (at least up to 3.5) the situation is somewhat reversed. The `yield from` analogue of the above used to work in coroutine context: import asyncio class Waiter: def __iter__(self): yield from asyncio.sleep(1) @asyncio.coroutine def foo(): yield from Waiter() # works on py3.5: asyncio.get_event_loop().run_until_complete( asyncio.ensure_future(foo())) While the following doesn't: # "TypeError: An asyncio.Future, a coroutine or an awaitable is required": asyncio.get_event_loop().run_until_complete( asyncio.ensure_future(Waiter())) What do you think? Kind regards, Thomas See also: https://stackoverflow.com/questions/33409888/how-can-i-await-inside-future-… [View Less]

1 0

PEP 8 update on line length
by Simon Feb. 27, 2019

Feb. 27, 2019

Hello, I'd like to propose an update to PEP8. Indeed, the 80 characters per line guideline is, I feel, outdated. I understand the need for it, back when monitors were small, and everyone coded on terminals, but nowadays, I feel like that guideline is more of a hinderance, and that it promotes poor code. Indeed, people abiding by this rule tend to choose shorter variable names, reduce the amount of indentation, and other tricks to just keep the character count under 80. I think a 100 or even … [View More]

36 86

PEP 8 and long string literals
by Jonathan Fine Feb. 26, 2019

Feb. 26, 2019

I've started this thread, because I think long string literals are somewhat special, and may have an easy resolution. According to PEP 8 a good reason to ignore the line-length (or any other) guideline is that "applying the guideline would make the code less readable, even for someone who is used to reading code that follows this PEP." PEP 8 also says "Limit all lines to a maximum of 79 characters." So perhaps it is enough, for long string literals, to add a note to PEP 8: When sensible to … [View More]

7 9

Type hints for functions with side-effects and for functions raising exceptions
by Miikka Salminen Feb. 25, 2019

Feb. 25, 2019

Hi! To help automatic document generators and static type checkers reason more about the code, the possible side-effects and raised exceptions could also be annotated in a standardized way. I'll let some example code talk on my behalf. Here's a simple decorator for annotating exceptions: In [1]: import typing as t In [2]: def raises(exc: Exception) -> t.Callable: ...: def decorator(fn: t.Callable) -> t.Callable: ...: fn.__annotations__["__raises__"] = exc ...: … [View More] return fn ...: return decorator ...: In [3]: @raises(ValueError) ...: def hello_if_5(x: int) -> None: ...: if x != 5: ...: raise ValueError("number other than 5 given") ...: print("Hello!") ...: In [4]: hello_if_5.__annotations__ Out[4]: {'x': int, 'return': None, '__raises__': ValueError} In [5]: hello_if_5(1) --------------------------------------------------------------------------- ValueError Traceback (most recent call last) <ipython-input-5-7fb1d79ce3f4> in <module> ----> 1 hello_if_5(1) <ipython-input-3-1084d197ce1b> in hello_if_5(x) 2 def hello_if_5(x: int) -> None: 3 if x != 5: ----> 4 raise ValueError("number other than 5 given") 5 print("Hello!") 6 ValueError: number other than 5 given In [6]: hello_if_5(5) Hello! In [7]: and here's a simple decorator for annotating side-effects: In [1]: import typing as t In [2]: def side_effect(has_side_effect: bool) -> t.Callable: ...: def decorator(fn: t.Callable) -> t.Callable: ...: fn.__annotations__["__side_effect__"] = has_side_effect ...: return fn ...: return decorator ...: In [3]: a = 10 In [4]: @side_effect(True) ...: def change_a(val: int) -> None: ...: global a ...: a = val ...: In [5]: change_a.__annotations__ Out[5]: {'val': int, 'return': None, '__side_effect__': True} In [6]: change_a(100) In [7]: a Out[7]: 100 In [8]: @side_effect(True) ...: def mutate_list(items: t.List) -> None: ...: items.append("new item") ...: In [9]: mutate_list.__annotations__ Out[9]: {'items': typing.List, 'return': None, '__side_effect__': True} In [10]: l = ["old item"] In [11]: mutate_list(l) In [12]: l Out[12]: ['old item', 'new item'] In [13]: The example implementations have some obvious limitations, such as only allowing one error type. What do you think of the idea in general? Do you feel this is something that could be included in Python? typing would probably be a good module to store such decorators, I guess… Miikka Salminen miikka.salminen(a)gmail.com [View Less]

9 20

Support localization of unicode descriptions
by Pander Feb. 25, 2019

Feb. 25, 2019

Dear all, Who might also be interested in setting up a project that supports localization for Unicode block description and character description. Translations are available from https://github.com/unicode-table/unicode-table-data/tree/master/loc <https://github.com/unicode-table/unicode-table-data/tree/master/loc> If possible, use a gettext approach similar to https://pypi.org/project/pycountry/ <https://pypi.org/project/pycountry/> Implementing this feature will allow users to … [View More]

5 8

Re: [Python-ideas] PEP 8 update on line length
by Philip Bergen Feb. 22, 2019

Feb. 22, 2019

I agree that 80 columns produces too much artificial wrapping that is not more readable and harder to maintain. To that point see the bug in Chris Barker's email :) raise ValueError(f"Expected woozle to be between" "{self.min_woozle} and {self.max_woozle}") The missing f prefix on the second row is hard to spot. In my work we have settled on 100 characters. It's below the practical limitation where code review tools such as github pull request falls … [View More]apart and still easily allows side by side editing. On Thu, Feb 21, 2019 at 3:20 PM <python-ideas-request(a)python.org> wrote: > Send Python-ideas mailing list submissions to > python-ideas(a)python.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.python.org/mailman/listinfo/python-ideas > or, via email, send a message with subject or body 'help' to > python-ideas-request(a)python.org > > You can reach the person managing the list at > python-ideas-owner(a)python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Python-ideas digest..." > Today's Topics: > > 1. Re: PEP 8 update on line length (pylang) > 2. Re: PEP 8 update on line length (Chris Barker) > 3. Re: Type hints for functions with side-effects and for > functions raising exceptions (Juancarlo A?ez) > > > > ---------- Forwarded message ---------- > From: pylang <pylang3(a)gmail.com> > To: Mike Miller <python-ideas(a)mgmiller.net> > Cc: "python-ideas(a)python.org" <python-ideas(a)python.org> > Bcc: > Date: Thu, 21 Feb 2019 17:32:12 -0500 > Subject: Re: [Python-ideas] PEP 8 update on line length > Some feedback: > > I code on a 13.5 inch laptop. I split my screen between my browser on the > left half and editor on the right half of the screen. > The 80 character suggestion has been helpful to me in reading code. > Otherwise I'd use up time with random horizontal scrolling. > > On Thu, Feb 21, 2019 at 4:11 PM Mike Miller <python-ideas(a)mgmiller.net> > wrote: > >> >> On 2/21/19 10:53 AM, Paul Ferrell wrote: >> > I think the solution is for everyone to rotate their widescreen >> monitors 90° >> > into a really tall portrait mode. :) >> >> Yep, that's what I do, but would prefer a squarer monitor so I could get >> two >> windows side by side on that one also. My old 1600x1200 4:3 in portrait >> allowed >> that comfortably. 16:10 might. >> >> -Mike >> >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas(a)python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > > > > ---------- Forwarded message ---------- > From: Chris Barker <chris.barker(a)noaa.gov> > To: Python-Ideas <python-ideas(a)python.org> > Cc: > Bcc: > Date: Thu, 21 Feb 2019 17:06:51 -0800 > Subject: Re: [Python-ideas] PEP 8 update on line length > On Thu, Feb 21, 2019 at 12:01 PM Raymond Hettinger < > raymond.hettinger(a)gmail.com> wrote: > >> I concur. We now put expressions in f-strings and have assignment >> expressions that easily spill over 80 characters if one uses all but the >> most compact variable names. Comprehensions tend to make expressions >> longer. Queries and filters in Pandas also easily spill over. The 80 >> character limit pre-dates these evolutions of the language. >> > > >> In particular, the case where I most want to let people run with long >> lines is in forming messages to be displayed to a user. > > > I agree here -- and if it's messages (also comments - a twenty char > comment after a 70 char line should be fine!) then it's not part of the > logic of the code -- so not as bd if there is some spill off the screen for > those folks that do code on tablets ;-) Actually for me, the issue s comes > up when I'm showing code on a projector -- I use a huge font so folks in > the back can see) > > >> class Frabawidget: >> ... >> @wozzle.setter >> def (self, woozle): >> if not (self.min_woozle < woozle < self.max_woozle): >> raise ValueError(f"Expected woozle to be between >> {self.min_woozle} and {self.max_woozle}") >> self._wozzle = normalize(woozle) >> > > That's 103 chars long -- and very readable. But, is this that much worse? > > class Frabawidget: > ... > @wozzle.setter > def (self, woozle): > if not (self.min_woozle < woozle < self.max_woozle): > raise ValueError(f"Expected woozle to be between" > "{self.min_woozle} and {self.max_woozle}") > self._wozzle = normalize(woozle) > > (it IS harder to write, that's for sure) > > In doing code reviews, I see many fewer atrocities from long lines than I >> do from weird line-wraps and from variable names that have been >> over-shortened to make the line fit in 80 characters. To avoid these >> issues, my clients typically set their line limits at 90 or 100 > > > and yet the above example was 103 ... you do need a limit somewhere. > > I actually would really like the "limit" to depend on what the line is -- > that is, it's OK to go longer if it's essentially text -- message to the > user, comment, etc., rather than part of the code logic. > > In fact, now that I write that, I think I actually DO do that -- and even > add a # noqa sometimes so my linter will stop bugging me. A smart linter > would be nice here. > > PEP 8 is mostly about readability. However, the line length limit often >> seems to cause less readable code. >> > > So what do you suggest? simply increase the recommended line length? Or > would softening the language about extending it be enough? > > Maybe something along the lines of: > > A line length limit should be well defined for each project / organization > -- 80 char per line is safest for all users, but anything up to 100 is > appropriate if the team maintaining the code agrees. > > Raymond: As a core dev -- are suggesting extending the line limit for the > standard library? > > To all the folks quoting theory: let's be honest. Yes, really long lines > are harder to read, but the 80 char limit comes from old terminals, NOT any > analysis that somehow that is optimum for readability. > > -CHB > > -- > > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR&R (206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > Chris.Barker(a)noaa.gov > > > > ---------- Forwarded message ---------- > From: "Juancarlo Añez" <apalala(a)gmail.com> > To: Ivan Levkivskyi <levkivskyi(a)gmail.com> > Cc: Miikka Salminen <miikka.salminen(a)gmail.com>, python-ideas < > python-ideas(a)python.org> > Bcc: > Date: Thu, 21 Feb 2019 21:20:38 -0400 > Subject: Re: [Python-ideas] Type hints for functions with side-effects and > for functions raising exceptions > > > On Thu, Feb 21, 2019 at 6:28 PM Ivan Levkivskyi <levkivskyi(a)gmail.com> > wrote: > >> The idea about "checked exceptions" appeared several times in various >> places. I used to think that this would be hard to support for any >> realistic use cases. But now I think there may be a chance >> to turn this into a usable feature if one frames it correctly (e.g. the >> focus could be on user defined exceptions, rather than on standard ones, >> since there is no way we can annotate every function in typeshed). >> > > It's well documented how checked exceptions lead to bad code. That's why > C#, which came after Java, didn't include them. > > Exceptions may be logically thought as of part of the type of a method, > and of the type of the method's class, but that requires that the type > catches every exception that may be raised from the implementation and > either handles it, or translates it to one belonging to the type. It's a > lot of work, it's cumbersome, and it is fragile, as the exception handling > may need to change over minor implementation changes. If dependencies don't > treat the exceptions that may escape from them as part of the type, then > our own types will need to be changes every time a dependency changes its > implementation. > > The strategy of catching only exceptions of interest and letting others > pass produces less fragile and easier to test code. > > -- > Juancarlo *Añez* > _______________________________________________ > Python-ideas mailing list > Python-ideas(a)python.org > https://mail.python.org/mailman/listinfo/python-ideas > -- *Philip Bergen* P: +1(415)200-7340 *"Without data you are just another person with an opinion" -- W. Edwards Deming* [View Less]

1 0

add fluent operator to everything
by Jimmy Girardet Feb. 22, 2019

Feb. 22, 2019

Hi, There was the discussion about vector, etc... I think I have a frustration about chaining things easily in python in the stdlib where many libs like orm do it great. Here an example : The code is useless, just to show the idea >>> a = [1,2,3] >>> a.append(4) >>> a.sort() >>> c = max(a) + 1 I would be happy to have >>> [1,2,3].append(4)::sort()::max() +1 It makes things very easy to read: first create list, then append 4, then … [View More]

13 25

About PEP-582
by Philip Bergen Feb. 20, 2019

Feb. 20, 2019

First attempt at this, so please be gentle. :) I am very interested in the overall goal of not needing virtualenvs, but I'm curious about the motivations behind pep-582. Could someone help me understand if this has previously been discussed and in that case why it was decided against? 1: Why only look in CWD and not traverse root-wise? 2: It feels to me like there is a larger story here about sprucing up PYTHONPATH. About 2) I would prefer if we had a mechanism to automatically look for .… [View More]

3 2

Discuss: what should statistics.mode do?
by Steven D'Aprano Feb. 19, 2019

Feb. 19, 2019

See https://bugs.python.org/issue35892 The issue here is that statistics.mode, as initially designed, raises an exception for the case of multiple equal most-frequent data points. This is true to the way mode is taught in schools, but it may not be the most useful behaviour. Raymond has suggested: - keep the status quo; - change mode() to return "the first tie" instead of raising an exception (with or without a deprecation warning for one release); - add a flag to specify the … [View More]

2 1

Re: [Python-ideas] Consistency in naming [was Re: ...ALL CAPS] (off-list)
by James Lu Feb. 18, 2019

Feb. 18, 2019

Python’s decline is in not growing. Sent from my iPhone > On Feb 3, 2019, at 11:20 AM, Ned Batchelder <ned(a)nedbatchelder.com> wrote: > > James, you say below, "This kind of readability issue, datetime.now, is an example of what’s contributing to Python’s decline." > > Do you have any evidence of Python's decline? Lots of metrics (albeit simplistic ones) point to Python growing in popularity: > > https://www.techrepublic.com/article/fastest-growing-programming-… [View More]language-p… > https://www.netguru.com/blog/why-python-is-growing-so-quickly-future-trends > https://www.economist.com/graphic-detail/2018/07/26/python-is-becoming-the-… > Are there indicators we are missing? > > --Ned. > >> On 2/2/19 11:56 PM, James Lu wrote: >> Sent from my iPhone >> >>>> On Feb 2, 2019, at 3:41 AM, Steven D'Aprano <steve(a)pearwood.info> wrote: >>>> >>>>> On Sat, Feb 02, 2019 at 12:06:47AM +0100, Anders Hovmöller wrote: >>>>> >>>>> - the status quo means "no change", so there is no hassle there; >>>> Not quite true. There is a constant hassle of "do I need to write >>>> datetime.datetime.now() or datetime.now()?" >>> My point was that there is no hassle from *making a change* if you don't >>> actually make a change. (There may, or may not, be other, unrelated >>> hassles.) >>> >>> Besides, I'm not seeing that this is any worse than any other import. Do >>> I call spam.Eggs.make() or Eggs.make()? If you don't remember what you >>> imported, the names don't make much difference. >>> >>> I accept that datetime.datetime reads a bit funny and is a bit annoying. >>> If we had the keys to the time machine and could go back a decade to >>> version 3.0, or even further back to 1.5 or whenever the datetime module >>> was first created, it would be nice to change it so that the class was >>> DateTime. But changing it *now* is not free, it has real, serious costs >>> which are probably greater than the benefit gained. >> Why can’t we put “now” as a property of the module itself, reccomend that, and formally deprecate but never actually remove datetime.datetime.now? >>>> I solved this at work by changing all imports to follow the "from >>>> datetime import datetime" pattern and hard banning the other >>>> statically in CI. But before that people suffered for years. >>> Oh how they must have suffered *wink* >>> >>> I'm surprised that you don't do this: >>> >>> from datetime import datetime as DateTime >>> >>> >>>> I have a colleague who likes to point that the future is longer than >>>> the past. It's important to keep that perspective. >>> Actually, no, on average, the projected lifespan of technologies, >>> companies and cultural memes is about the same as their current age. It >>> might last less, or it might last more, but the statistical expectation >>> is about the same as the current age. So on average, "the future" is >>> about the same as "the past". >>> >>> Python has been around not quite 30 years now, so we can expect that it >>> will probably last another 30 years. But chances are not good that it >>> will be around in 300 years. >> A big reason why projects last as long as you say they last is that the maintainers get un-ambitious, they get used to relaxing in the language they know so well, they are no longer keen on change. >> >> This kind of readability issue, datetime.now, is an example of what’s contributing to Python’s decline. >> >> Bottom line: if someone submits a PR for this, will anyone merge it? >>> -- >>> Steve >>> _______________________________________________ >>> Python-ideas mailing list >>> Python-ideas(a)python.org >>> https://mail.python.org/mailman/listinfo/python-ideas >>> Code of Conduct: http://python.org/psf/codeofconduct/ >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas(a)python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ [View Less]

7 8