Just as a further note, it's perfectly possible to write a helper:
def ensure_match(pattern, string):
m = re.match(pattern, string)
if m is None:
raise ValueError(f"Provided string did not match {pattern}")
return m
If the project is concerned about failures to check the
I don't see how it's more likely that people would remember to add a
`require=True` flag than to add `if m: raise RuntimeError("No match")`. The
problem here is people forgetting that a match can fail, not lack of a
means to handle that problem.
Paul
On Sat, 21 Oct 2023 at 11:38, Ram Rachum
On Mon, 24 Jul 2023 at 10:31, anthony.flury via Python-ideas <
python-ideas@python.org> wrote:
> In Python then a better way might be
>
> result = temp := bar() if temp else default
>
> This way only bar() and default are evaluated and invoked once.
>
Or
result = bar()
if not result:
On Tue, 18 Jul 2023 at 16:13, Dom Grigonis wrote:
> To me, they are in the inverse relationship.
>
> Terseness ~ 1 / expressiveness.
>
No, they are unrelated (in general).
Terseness is nothing more than "can I use fewer characters?" and is almost
always the wrong thing to do in isolation (yes,
On Sat, 15 Jul 2023 at 21:09, Dom Grigonis wrote:
> So I would vote for something similar to:
>
> result = bar is None ? default : bar
>
>
result = default if bar is None else bar
Python has a conditional expression already.
Paul
___
Python-ideas
On Sun, 9 Jul 2023 at 15:56, Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> James Addison via Python-ideas writes:
>
> > The implementation of such a system could either be centralized or
> > distributed; the trust signals that human users infer from it
> > should always
On Sun, 2 Jul 2023 at 06:11, Christopher Barker wrote:
>
> The OP of this thread is not alone -- folks want an authoritative source
>
Authority is built over time. Unless someone starts doing this, there will
never be any authoritative source. In case it’s not obvious, none of the
projects or
On Sat, 1 Jul 2023 at 16:41, MRAB wrote:
> How about adding ticks to some PyPI packages? :-)
>
> (There's still the problem of who gets to decide which ones get a tick...)
Precisely. This is just curation but having PyPI host the curators'
decisions. And we've already established that the PyPI
On Sat, 1 Jul 2023 at 07:09, Christopher Barker wrote:
> So I think light curation would help a lot. [*]
>
I'd be completely in favour of someone setting up a curated package index.
You could probably use the Warehouse codebase if you didn't want to write
your own. There would probably be a
On Thu, 1 Jun 2023 at 18:16, David Mertz, Ph.D.
wrote:
> OK, fair enough. What about "has whitespace (including Unicode beyond
> ASCII)"?
>
>>> import re
>>> r = re.compile(r'\s', re.U)
>>> r.search('ab\u2002cd')
❯ py -m timeit -s "import re; r = re.compile(r'\s', re.U)"
On Thu, 1 Jun 2023 at 15:09, Antonio Carlos Jorge Patricio <
antonio...@gmail.com> wrote:
> I suggest including a simple str variable in unicodedata module to mirror
> string.whitespace, so it would contain all characters defined in CPython
> function [_PyUnicode_IsWhitespace()](
>
On Mon, 27 Feb 2023 at 20:58, python--- via Python-ideas
>
> > The base is not the master branch but the 3.11.0 release.
Maybe you should rebase it on main? That will need to happen if it's to be
usable, anyway, and it makes it far easier to review/discuss if you follow
the normal process for
On Tue, 21 Feb 2023 at 12:44, James Addison via Python-ideas <
python-ideas@python.org> wrote:
> On Mon, 20 Feb 2023 at 15:03, Otomatyk dupont wrote:
> >> #import A_WINDOW_MODULE and import A_UNIX_MODULE if except
>
> Here's an attempt to rephrase this slightly, with the following ideas in
>
On Sun, 18 Dec 2022 at 21:42, Christopher Barker
wrote:
> On Sun, Dec 18, 2022 at 9:48 AM David Mertz, Ph.D.
> wrote:
>
>> In general, I find any proposal to change Python "because then my text
>> editor would need to
>> change to accommodate the language" to be unconvincing.
>>
>
> Personally,
On Wed, 30 Nov 2022 at 18:02, Anony Mous wrote:
> For instance, a "local:" declaration could be treated as if it were "def
> function()" with an immediately succeeding call as far as the interpreter
> is concerned. That buys the scoping for (nearly) free.
>
That would make "return" in the local
On Tue, 8 Nov 2022 at 23:34, Steven D'Aprano wrote:
>
> Most Python coders are using Windows. Surely it is time to do better
> for them than "just roll your own"?
While I frequently advocate on the side of "not every 3-line function needs
to be in the stdlib", there are a lot of convenience
On Fri, 14 Oct 2022 at 19:36, Christopher Barker
wrote:
> I’m sorry that my typing-skepticism came across too strong, but while the
> tone and language revealed my personal view, I still think the points were
> correct.
>
> Paul: I didn’t say annotations were experimental. I said “static typing”
On Fri, 14 Oct 2022 at 01:41, Christopher Barker
wrote:
> Static type analysis is still experimental in Python.
>
It's not. This is simply false. Type *annotations* are a standard part of
the language, supported by language syntax, a standard library module, and
a series of PEPs describing
What's wrong with defining a custom exception? It's literally one line:
`class InvalidStateError(Exception): pass`. Two lines if you want to put
the `pass` on its own line.
The built in exceptions are ones that are raised by the core interpreter.
Even the stdlib doesn't get builtin exceptions,
On Mon, 1 Aug 2022 at 13:50, wrote:
> Hello everyone. First time here, so please be forgiving of any missteps on
> my part.
> This is an idea I have thought about for a while, and I believe it could
> be quite useful.
> Would it be possible to enhance the standard range() type to allow for
>
On Thu, 21 Jul 2022 at 16:45, Christopher Barker
wrote:
> I still am dumbfounded that this wasn’t platform I dependent in the first
> place, but you know what essay about hindsight.
>
Indeed. I've no idea why we had the difference in the first place, but
that's water under the bridge at this
On Thu, 21 Jul 2022 at 11:33, Thomas Grainger wrote:
> > A practical approach may be to develop some form of library that "hides"
> the difference behind some form of API for finding the correct value, get
> that added to the stdlib and wait a few years until it's adopted everywhere
> (because
On Thu, 21 Jul 2022 at 11:07, Simão Afonso
wrote:
> On 2022-07-21 09:55:21, Paul Moore wrote:
> > A practical approach may be to develop some form of library that "hides"
> > the difference behind some form of API for finding the correct value, get
> > that add
There is a *lot* of code that depends on the Windows directory being
"Scripts". There have been proposals in the past to change it (sorry, no
links but it has come up a few times on the various packaging forums), but
it simply breaks too much for too little gain.
If you're serious about wanting
That would break huge amounts of existing code. While better names
might have been nice from the start, improving the naming is nowhere
near enough benefit to justify such a disruptive change at this point
in Python's development.
Paul
On Fri, 24 Jun 2022 at 22:47, abed...@gmail.com wrote:
>
>
On Wed, 22 Jun 2022 at 22:52, Martin Di Paola wrote:
> Perhaps this is the real focus to analyze. The PEP suggests that
> x.compute() does something *fundamentally* different from just executing
> the intermediate expressions.
Hang on, did the PEP change? The version I saw didn't have a
On Wed, 22 Jun 2022 at 18:35, David Mertz, Ph.D. wrote:
>
> Hi Martin,
>
> Short answer: yes, I agree.
> Slightly longer: I would be eternally grateful if you wish to contribute to
> the PEP with any such expansion of the Motivation and Expansion.
One concern I have, triggered by Martin's Dask,
On Tue, 21 Jun 2022 at 10:01, Paul Moore wrote:
> PS To be clear, my objections to the PEP aren't based on deferred
> evaluation. So I'm an impartial 3rd party on this matter. I *do* have
> problems with the PEP, so I have an interest in seeing the PEP fairly
> reflect the lack
On Tue, 21 Jun 2022 at 09:20, Chris Angelico wrote:
>
> On Tue, 21 Jun 2022 at 18:15, Paul Moore wrote:
> > I'm not talking about a "full and detailed specification". That's
> > *still* more than is needed for a valid debate (at this point). But
> > w
On Tue, 21 Jun 2022 at 06:27, Chris Angelico wrote:
>
> Okay, here's a compromise.
>
> Go and write a full and detailed specification of the Python-visible
> semantics of deferred evaluation objects, including how they would be
> used to implement late-bound argument defaults.
I'm going to
On Mon, 20 Jun 2022 at 18:42, Steve Jorgensen wrote:
>
> Steven D'Aprano wrote:
> > Okay, I'm convinced.
> > If we need this feature (and I'm not convinced about that part), then it
> > makes sense to keep the star and write it as `spam, eggs, *... = items`.
>
> I thought about that, but to me,
On Mon, 20 Jun 2022 at 11:08, Steven D'Aprano wrote:
> But that's basically islice. So:
>
> # Its okay to put reusable helper functions in a module.
> # Not everything has to be syntax.
> first, second, third = itertools.islice(items, 3)
>
> I think that we have a working solution
On Sat, 18 Jun 2022 at 23:15, Eric V. Smith via Python-ideas
wrote:
>
> On 6/18/2022 5:34 PM, Paul Moore wrote:
> > After all, it has the
> > advantage of working on older versions of Python (and given that one
> > of your use cases is Textual, I can't imagi
On Sat, 18 Jun 2022 at 21:57, Jonathan Slenders wrote:
>
> Good catch! One correction here, I somewhat mixed up the benchmarks. I forgot
> both projects of mine required support for universal line endings exactly
> like splitlines() does this out of the box. That requires a more complex
>
On Sat, 18 Jun 2022 at 15:53, Stephen J. Turnbull
wrote:
> I don't find that burdensome enough to want syntax, and I can't guess
> how quickly I'd start using it if available, that probably depends on
> how often the community seems to be using it (ie, in the code I'm
> reading).
To be honest, I
On Sat, 18 Jun 2022 at 03:45, Chris Angelico wrote:
> > This raises another choice: should lazy defaults be evaluated before
> > entering the body of the function, or at the point where the parameter
> > is used? Which would be more useful?
> >
> > # `defer n=len(items)`
> > def
On Fri, 17 Jun 2022 at 15:55, Chris Angelico wrote:
>
> On Sat, 18 Jun 2022 at 00:21, Paul Moore wrote:
> >
> > On Fri, 17 Jun 2022 at 14:15, Chris Angelico wrote:
> > >
> > > There are several ways to make this clearly sane.
> > >
> > > #
On Fri, 17 Jun 2022 at 14:19, Mauricio Villegas via Python-ideas
wrote:
>
> Look at the following example:
>
> ```
> def some_function(f1: int):
> assert isinstance(f1, int)
>
> def other_function(f0: str, **kwargs):
> assert isinstance(f0, str)
> some_function(**kwargs)
>
>
On Fri, 17 Jun 2022 at 14:15, Chris Angelico wrote:
>
> There are several ways to make this clearly sane.
>
> # Clearly UnboundLocalError
> def frob(n=>len(items), items=>[]):
Um, I didn't see that as any more obvious than the original example. I
guess I can see it's UnboundLocalError, but
On Fri, 17 Jun 2022 at 13:54, Andrew Jaffe wrote:
>
> Is there a *reason* why you are leaving this unspecified? To put it more
> baldly, is there any reason (e.g., difficulty of parsing?) why allowing
> these "forward" references should *not* be allowed? It seems that
> "n=>len(items), items=[]"
On Fri, 17 Jun 2022 at 12:34, Steve Jorgensen wrote:
>
> Although that would be a breaking change, it is already conventional to use
> "_" as a variable name only when we specifically don't care what it contains
> following its assignment, so for any code to be affected by the change would
>
On Wed, 15 Jun 2022 at 14:04, Rob Cliffe via Python-ideas
wrote:
>
> Please. This has been many times by several people already. No-one is going
> to change their mind on this by now. There's no point in rehashing it and
> adding noise to the thread.
To be fair, the only real point in
> On 09/06/2022 09:50, Paul Moore wrote:
> > On Thu, 9 Jun 2022 at 01:12, Steve Jorgensen wrote:
> >> My current thinking in response to that is that using islice is a decent
> >> solution except that it's not obvious. You have to jump outside of the
> >&
On Thu, 9 Jun 2022 at 01:12, Steve Jorgensen wrote:
>
> My current thinking in response to that is that using islice is a decent
> solution except that it's not obvious. You have to jump outside of the
> thinking about the destructuring capability and consider what else could be
> used to
There’s an itertools recipe, “partition”.
On Mon, 6 Jun 2022 at 08:28, Chris Angelico wrote:
> On Mon, 6 Jun 2022 at 16:42, Christopher Barker
> wrote:
> >
> > I think y’all have addressed the OP’s problem — at least the performance
> issues.
> >
> > But I think this brings up a pattern that I
On Sat, 4 Jun 2022 at 09:39, Steve Jorgensen wrote:
>
> I was using the reading of lines from a file as a contrived example. There
> are many other possible cases such as de-structuring from iterator such as
> `itertools.repeat()` with no `count` argument which will generate values
>
Conceivably. I know I've had cases where this would be helpful. (But
on the other hand, it's not *that* hard to write your own persistent
cache for your specific use case if you need it).
I think this is a case where someone should just create a PR and
submit it. No need for a big debate, the
On Tue, 24 May 2022 at 15:42, Jan Costandius wrote:
>
> I think that it would be beneficial for PEP 8 conformance, in the case of
> large nested dicts, if one were able to separate dict indices by a newline.
> What I mean is shown below:
>
> foo["bar"]
> ["baz"]
> ["eggs"]
>
On Sun, 8 May 2022 at 19:38, Ethan Furman wrote:
>
> On 5/8/22 05:08, Valentin Berlier wrote:
>
>
> > This would make it really useful in if statements and list comprehensions.
> Here are a couple motivating examples:
> >
> > # Buy every pizza on the menu
> > cost_for_all_pizzas =
On Sat, 7 May 2022 at 16:42, wrote:
>
> In its current implementation, the list type does not provide a simple and
> straightforward way to retrieve one of its elements that fits a certain
> criteria.
>
> If you had to get the user where user['id'] == 2 from this list of users, for
> example,
On Wed, 4 May 2022 at 17:04, Christopher Barker wrote:
>
> Bringing this back on list -- I hope that was an accident.
If it was, it was me not spotting that your reply to me was on-list, I
thought you're replied offlist so I followed suit. Not a problem
though, I'm fine with this being on-list
On Wed, 4 May 2022 at 13:29, Dr. Guta Gábor wrote:
>
> > I'm not sure there's enough need for this that it should be in the
> > stdlib. And I'm certain it isn't sufficiently common to justify being
> > a builtin.
> How 'enough need' can be measured?
Well, there are at least two libraries on
On Wed, 4 May 2022 at 12:27, Dr. Guta Gábor wrote:
>
> This proposal is about adding a builtin function or a package to the standard
> library to access an element in an object hierarchy with default behavior
> i.e. if at any level the attribute/key/index does not exist in the path the
>
On Tue, 3 May 2022 at 03:04, Steven D'Aprano wrote:
>
> On Mon, May 02, 2022 at 07:44:14PM +0100, Paul Moore wrote:
>
> > I have classes with 20+ parameters (packaging metadata). You can argue
> > that a dataclass would be better, or some other form of refactoring,
>
On Mon, 2 May 2022 at 18:46, Steven D'Aprano wrote:
>
> But **not once** when I have read that same method later on have I
> regretted that those assignments are explicitly written out, or wished
> that they were implicit and invisible.
I have classes with 20+ parameters (packaging metadata).
On Fri, 8 Apr 2022 at 13:09, Matt del Valle wrote:
>
> My personal preference for adding units to python would be to make instances
> of all numeric classes subscriptable, with the implementation being roughly
> equivalent to:
>
> def __getitem__(self, unit_cls: type[T]) -> T:
> return
On Fri, 8 Apr 2022 at 12:22, Ricky Teachey wrote:
> I just get really excited at the idea of it being native to the language and
> am dreaming of being able to use it more often for my every day calculations.
> Right now I just don't feel confident I can.
If you can describe what the Python
On Thu, 7 Apr 2022 at 01:18, Brian McCall
wrote:
>
>> Please can you explain this to me? I don't know what you mean by "get the
>> final answer", nor do I know how astropy.units is relevant. Units seems to
>> be a perfectly acceptable library without astropy, is that not the case?
>
> Am I
On Wed, 6 Apr 2022 at 16:51, Brian McCall
wrote:
> Before I get to this example, though, there is more to arguments for the
> "need" than just counter-examples. I keep using quotes because nothing is
> really a need for anything.
Yes, it's not about "need" in an absolute sense, but more about
On Tue, 5 Apr 2022 at 14:25, Ricky Teachey wrote:
> units are at THE CORE of that need.
>
> i think python should be the language we reach for. i have made python work
> for me as a civil engineer and been extremely successful with it for all the
> usual reasons: ease of learning and community
On Tue, 5 Apr 2022 at 12:37, malmiteria wrote:
>
> ROUND 3 i guess
>
> I promised paul moore an up to date proposal, here it is:
>
> 1) an alterhitance module, dedicated to all __bases__ (the iterable of
> parents) alteration operations
> This replaces the "dependen
On Mon, 4 Apr 2022 at 22:19, malmiteria wrote:
> What i am saying is that *if* super(A, self) *were* to call A's method, that
> would be a simpler API.
I understand that you're specifically responding to Chris, but to be
honest, this is the first time you've explicitly stated this (unless
it
On Mon, 4 Apr 2022 at 18:59, malmiteria wrote:
> super(A, self) does not proxy to A, but to the first *after* A in MRO order.
Correct, that's how it's defined to work.
> When you're actually in need to passing arguments to super, you very likely
> know what class you're gonna be targeting, and
On Sun, 3 Apr 2022 at 18:36, malmiteria wrote:
>
> Chris Angelico writes:
> > And is it still based on the fundamental
> > assumption that super() calls THE parent class?
> what are you even talking about?
It's been explained before in this thread - your fundamental
misconception that there is
On Wed, 30 Mar 2022 at 17:58, Christopher Barker wrote:
>
> On Wed, Mar 30, 2022 at 1:50 AM Stéfane Fermigier wrote:
>>
>> FYI, there is a “parse” library on PyPI: https://pypi.org/project/parse/
>>
>> Parse strings using a specification based on the Python format() syntax.
>>
>> parse() is the
On Wed, 30 Mar 2022 at 15:39, Adrian Torres Justo
wrote:
> > Why not use just to_bool(getenv(key))?
>
> We did use distutils.util.strtobool(os.getenv(key, default)) for a while,
> eventually we just built a helper that did the same because it's easier /
> more comfortable.
>
> > No. There would
On Fri, 11 Mar 2022 at 19:12, wfdc wrote:
> What kind of evidence would satisfy you? And how did previous proposals you
> supported obtain such evidence?
Honestly, probably nothing. I don't think this is a good idea in any
case, the "not every one-line function needs to be a builtin"
principle
On Fri, 11 Mar 2022 at 02:20, wfdc via Python-ideas
wrote:
> If users find themselves re-implementing the same utility function over again
> and over again across different projects, it's a good sign that such a
> function should be part of the standard library.
And yet you haven't
On Mon, 7 Mar 2022 at 23:44, Chris Angelico wrote:
> Not ALL typing changes are just new things in typing.py, so that
> doesn't cover everything. And yes, I am sure that a lot of things get
> proposed and not implemented - my point is that typing-sig is
> successfully finding the good ideas and
On Sun, 6 Mar 2022 at 22:43, Chris Angelico wrote:
>
> On Mon, 7 Mar 2022 at 09:33, Paul Moore wrote:
> > > Do I care enough to write a PEP? No. So this, like many other small
> > > ideas, will probably die on the vine.
> >
> > Yes, this is the real proble
On Sun, 6 Mar 2022 at 21:41, Christopher Barker wrote:
>
>
>> Personally, I'm certainly not ignoring comprehensions. "for thing in
>> (x for x in collection if is_interesting(x))" uses comprehensions just
>> fine, if you don't like the verbosity of "x for x in", then that's an
>> issue with
On Sun, 6 Mar 2022 at 01:55, Christopher Barker wrote:
>
> On Sat, Mar 5, 2022 at 4:33 AM Paul Moore wrote:
>>
>> for thing in filter(is_interesting, this_collection):
>> ...
>>
>> That seems pretty non-clunky. Is the issue here that "filter"
On Sat, 5 Mar 2022 at 12:43, Chris Angelico wrote:
>
> The throwaway function is a *terrible* idea for a lot of situations,
> because it puts the condition completely out-of-line. You have to go
> dig elsewhere to find out the meaning of the filter. A lambda function
> can work, but is about as
On Sat, 5 Mar 2022 at 12:12, Chris Angelico wrote:
>
> On Sat, 5 Mar 2022 at 22:22, Stephen J. Turnbull
> wrote:
>
> > Python has one, and you've already mentioned it:
> >
> > for thing in (x for x in this_collection if is_interesting(x)):
> >
> > It's noticably verbose, but it's an exact
On Wed, 2 Mar 2022 at 10:27, Steven D'Aprano wrote:
> Off-topic, but since you raised the issue... is there a standard
> functional programming term for a variant of map() that applies a single
> argument to a series of different functions?
>
> # regular map
> map(func, list_of_args) #
On Fri, 18 Feb 2022 at 23:53, Steven D'Aprano wrote:
> When pip resolves dependencies, it does it in the simplest possible way
> that *usually* works. It has no satisfiability solver.
>
> "No effort is made to ensure that the dependencies of all packages are
> fulfilled simultaneously. This can
On Wed, 16 Feb 2022 at 14:47, Valentin Berlier wrote:
>
> Hi,
>
> I've been thinking that it would be nice if regex match objects could be
> deconstructed with pattern matching. For example, a simple .obj parser could
> use it like this:
>
> match re.match(r"(v|f) (\d+) (\d+) (\d+)", line):
On Wed, 16 Feb 2022 at 10:23, Chris Angelico wrote:
>
> On Wed, 16 Feb 2022 at 21:01, Stephen J. Turnbull
> wrote:
> > What I think is more interesting than simpler (but more robust for
> > what they can do) facilities is better parser support in standard
> > libraries (not just Python's), and
On Sun, 13 Feb 2022 at 15:43, Chris Angelico wrote:
>
> Which is why the default should be to follow platform expectations. If
> I pass a parameter to a script saying "~/foo/bar", that script should
> be able to expanduser/expandvars to make that behave the way I expect
> it to. If I'm on Windows
On Sun, 13 Feb 2022 at 14:26, Stephen J. Turnbull
wrote:
>
> Paul Moore writes:
>
> > Let's keep it simple. I'm -1 on the request, I don't think expandvars
> > should be added to pathlib.
>
> Would you be happier with a getenv_as_path, so that one could do
>
>
On Sun, 13 Feb 2022 at 01:09, Steven D'Aprano wrote:
> I'm sorry Paul, but this sort of made-up, utterly artificial toy example
> adds no benefit to the discussion, it just adds fear, uncertainty and
> doubt to an extremely straight-forward feature request.
OK, if that's your view then fine. I
On Sat, 12 Feb 2022 at 16:02, Chris Angelico wrote:
>
> On Sun, 13 Feb 2022 at 02:57, Eric V. Smith wrote:
> > See Paul’s example, copied above. Maybe the code isn’t expecting it.
> >
>
> There wasn't an actual example, just a hypothetical one. I have never
> once seen something in real usage
On Fri, 11 Feb 2022 at 18:36, Eric Fahlgren wrote:
>
> Yeah, I have to agree with Neil. I had exactly this issue a couple years
> ago, and it took me an hour or two to figure out that it was a
> property/descriptor-protocol causing the issue, at which point the fix became
> trivial. Just
On Fri, 11 Feb 2022 at 16:37, Christopher Barker wrote:
>
> On Fri, Feb 11, 2022 at 12:28 AM Serhiy Storchaka wrote:
>>
>> expandvars() does not operate on paths, it operates on strings and
>> bytestrings. There is nothing path-specific here. Expanding environment
>> variables consists of three
On Thu, 10 Feb 2022 at 17:11, Christopher Barker wrote:
> agreed. But we seem to be getting a mixed message here:
>
> 1) it's too coplex with too many variable that have to be thought through and
> won't satisfy everyone anyway.
>
> and
>
> 2) It's just a simple one-liner
>
> Those are kind of
On Thu, 10 Feb 2022 at 16:44, Christopher Barker wrote:
>
> Since a started this:-)
>
> 1) the complexities are exactly why this *might* be a candidate for the
> stdlib. Those are the things that someone is likely to get wrong, or not
> think of, when they write something quick themselves, and
On Thu, 10 Feb 2022 at 15:21, Aman Pandey wrote:
>
> Hello Stephen, I think you misunderstood it. we are not talking about
> modifying the existing built-in function range rather adding a new function
> in datetime module that will generate the date and time between two periods.
> if we add a
On Tue, 8 Feb 2022 at 14:00, Aman Pandey wrote:
>
> I wanted to generate all the dates between two date ranges for which I was
> using count function in the itertools and to my surprise count function
> doesn't support datetime operation.
>
> For example
> >import datetime
> >from itertools
On Tue, 8 Feb 2022 at 00:09, Neil Girdhar wrote:
>
> Currently, some type checkers rightly complain that a method is decorated
> with abc.abstractmethod when the class's type does not inherit from ABCMeta.
> Adding a metaclass is a fairly heavy dependency since you're forced to poison
> all
On Mon, 17 Jan 2022 at 18:51, John Sturdy wrote:
>
> My idea is to support the style in which each variable comes into existence
> at a single well-defined point, whatever path is taken through the code, and
> so in the case of that example, it would be encouraging the use of
> conditional
On Mon, 17 Jan 2022 at 17:27, Christopher Barker wrote:
> But this is not how Python works, and it never has, it would be a really
> massive change, and I for one, would not like it :-(
I agree with this.
> I guess what I'm getting at is that I'm pretty sure I would find this useful
>
On Mon, 17 Jan 2022 at 10:12, Steven D'Aprano wrote:
> That would make the creation of frozensets more efficient, possibly
> encourage people who currently are writing slow and inefficient code
> like
>
> targets = (3, 5, 7, 11, 12, 18, 27, 28, 30, 35, 57, 88)
> if n in targets:
>
On Mon, 17 Jan 2022 at 01:11, Chris Angelico wrote:
>
> On Mon, Jan 17, 2022 at 10:14 AM Paul Moore wrote:
> >
> > On Sun, 16 Jan 2022 at 22:55, Steven D'Aprano wrote:
> > > >>> def f():
> > > ... return frozenset({1, 2, 3})
&
On Sun, 16 Jan 2022 at 22:55, Steven D'Aprano wrote:
> >>> def f():
> ... return frozenset({1, 2, 3})
> ...
> >>> a = f.__code__.co_consts[1]
> >>> a
> frozenset({1, 2, 3})
> >>> b = f()
> >>> assert a == b
> >>> a is b
> False
>
> Each time you call the function, you get a distinct frozenset
https://pypi.org/project/platformdirs/ is intended to cover this sort
of requirement.
Paul
On Wed, 15 Dec 2021 at 13:47, JGoutin via Python-ideas
wrote:
>
> Hello,
>
> The idea is to add 3 functions to get "config", "data" and "cache"
> directories that are commonly used to store application
On Thu, 9 Dec 2021 at 20:55, deavid wrote:
>
> So well, my question here is: why is this not a thing? Has anyone proposed
> something like this before? I feel I must have missed something important.
IMO, making types mandatory would severely penalise the use of Python
for scripting, exploratory
On Thu, 9 Dec 2021 at 11:51, Chris Angelico wrote:
>
> Are = and := confusing? They are also very similar, and they have some
> subtle distinctions. Is it a problem for two different operators to
> look similar when they do very similar things?
Maybe. I don't use assignment expressions - I don't
On Thu, 9 Dec 2021 at 06:49, Christopher Barker wrote:
>
> (I started writing this this morning, and there’s been quite a bit more
> discussion since, but I don’t think it’s completely too late)
Your email client is doing "white on white" again. You should try to
get that fixed :-(
I agree,
On Wed, 8 Dec 2021 at 23:40, Chris Angelico wrote:
>
> I have attempted to explain the syntax. What is confusing?
>
> def f(x=spam): ...
>
> def f(x=>spam): ...
Are we using the term "confusing" in different ways? I'm saying that
it's easy to confuse the two forms = and =>, as they look very
On Wed, 8 Dec 2021 at 23:18, Chris Angelico wrote:
> Part of the problem is that it is really REALLY hard to figure out
> what the actual objections are. I asked, and the one clear answer I
> got was one subjective opinion that the cognitive load exceeded the
> benefit. Great! That's one person's
1 - 100 of 793 matches
Mail list logo
