On Sun, Jun 19, 2022 at 11:47:22AM -0700, Lucas Wiman wrote:
> Since "today" depends on the time zone, it should be an optional argument
> to date.today(). The interface should be the same as datetime.now(tz=None),
> with date.today() returning the date in the system time zone.
Sure, that sounds
On Mon, 20 Jun 2022 at 05:32, Mike Miller wrote:
>
> My first thought was next(), which I use occasionally:
>
> >>> items = (i for i in range(9))
> >>> items
> at 0x7f33251766d0>
>
> >>> first, second = next(items), next(items) #
>
> >>> first, second
> (0, 1)
>
On Mon, 20 Jun 2022 at 05:02, David Mertz, Ph.D. wrote:
>
> On Sun, Jun 19, 2022 at 2:24 PM Chris Angelico wrote:
>>
>> > def frobnicate(data, verbose=os.environ.get('LEVEL')==loglevel.DEBUG):
>> > ...
>>
>> Is there any value in not putting that into a global constant?
>
>
> Probably not.
My first thought was next(), which I use occasionally:
>>> items = (i for i in range(9))
>>> items
at 0x7f33251766d0>
>>> first, second = next(items), next(items) #
>>> first, second
(0, 1)
>>> tuple(items)
(2, 3, 4, 5, 6, 7, 8)
No imports needed. Is
+1. I would suggest `fromtimestamp` also accept an optional timezone
argument.
On Sun, 2022-06-19 at 11:47 -0700, Lucas Wiman wrote:
> Since "today" depends on the time zone, it should be an optional
> argument to date.today(). The interface should be the same as
> datetime.now(tz=None), with
On Sun, Jun 19, 2022 at 2:24 PM Chris Angelico wrote:
> > def frobnicate(data,
> verbose=os.environ.get('LEVEL')==loglevel.DEBUG): ...
>
> Is there any value in not putting that into a global constant?
>
Probably not. I was just inventing an ad hoc example to show what I
meant. I didn't
Since "today" depends on the time zone, it should be an optional argument
to date.today(). The interface should be the same as datetime.now(tz=None),
with date.today() returning the date in the system time zone.
Rationale: It is common for processes to run in different timezones than
the relevant
On Mon, 20 Jun 2022 at 03:06, David Mertz, Ph.D. wrote:
>>
>> > I guess '>=' also looks "confusable", but it's far less common in
>> > signatures, and the meaning is further away.
>>
>> It's no less valid than your other examples, nor less common (why
>> would you have "==" in a function
>
> > I guess '>=' also looks "confusable", but it's far less common in
> signatures, and the meaning is further away.
>
> It's no less valid than your other examples, nor less common (why
> would you have "==" in a function signature, for instance?).
>
I guess I probably use `==` more often in
On Sun, Jun 19, 2022, 12:02 PM Chris Angelico
> I've no idea what you mean by "sophistical" here. Please explain?
>
1. of or characteristic of sophists or sophistry
2. clever and plausible, but unsound and tending to mislead
a sophistical argument
3. using sophistry
Plato's dialog _The
On Mon, 20 Jun 2022 at 01:37, David Mertz, Ph.D. wrote:
>
> Unfortunately, in relation to this PEP, I find your arguments tend to be
> sophistical. They ate not generally so in other threads, but for whatever
> reason your attachment to this has a different quality.
>
I've no idea what you
Unfortunately, in relation to this PEP, I find your arguments tend to be
sophistical. They ate not generally so in other threads, but for whatever
reason your attachment to this has a different quality.
There's an interesting point you raise though. You seem to feel that
closely related
Thanks all for all the responses! That's quite a bit to think about.
A couple of thoughts:
1. First, I do support a transition to UTF-8, so I understand we don't want
to add more methods that deal with character offsets. (I'm familiar with
how strings work in Rust.) However, does that mean we
As for the universal new lines— it seems that either converting when the
file is read (default behavior) or a simple replace of “\r\n” first is a
simple solution.
I’m still confused about the use case though. It seems it involves large
amounts of text, where you need to access individual lines,
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`.
--
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe
>
> "Self-explanatory". This is how we got Perl and APL o_O
What I mean is that if you already know the destructuring syntax, then it’s
pretty clear what it means. If you already know existing syntax, / isn’t
suggesting of anything. The only related syntax is for declaring
positional-only
On Mon, 20 Jun 2022 at 00:06, David Mertz, Ph.D. wrote:
>
> On Sun, Jun 19, 2022, 3:27 AM Chris Angelico
>>
>> > I'm still -1 because I don't think the purpose alone is close to worth the
>> > cost of new syntax... And especially not using sigils that are confusing
>> > to read in code.
>> >
>>
On Sun, Jun 19, 2022, 3:27 AM Chris Angelico
> > I'm still -1 because I don't think the purpose alone is close to worth
> the cost of new syntax... And especially not using sigils that are
> confusing to read in code.
> >
> > The topic of "late binding in function signatures" simply isn't
>
Hi
This is a nice problem, well presented. Here's four comments / questions.
1. How does the introduction of faster CPython in Python 3.11 affect the
benchmarks?
2. Is there an across-the-board change that would speedup this line-offsets
task?
3. To limit splitlines memory use (at small
Jonathan Slenders wrote:
> Hi everyone,
> Today was the 3rd time I came across a situation where it was needed to
> retrieve all the positions of the line endings (or beginnings) in a very
> long python string as efficiently as possible.
>
> [...]
>
> Would it make sense to add a
On Sun, Jun 19, 2022 at 12:21:50AM -0700, Lucas Wiman wrote:
> Using either * or / could lead to some odd inconsistencies where a missing
> space is very consequential, eg:
> x, / = foo # fine
> x, /= foo # syntax error?
> x / = foo # syntax error
> x /= foo # fine, but totally different from
Lucas Wiman writes:
> That said, the * syntax feels intuitive in a way that / doesn’t.
I disagree. In C-like languages, it says "dereference a pointer" (ie,
use the content at the pointer). In Python, it's used for
destructuring iterables, ie, use the content at the iteration pointer
by
Jonathan Slenders writes:
> 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.
I can't remember ever seeing an application where such a method
On Sun, 19 Jun 2022 at 13:44, David Mertz, Ph.D. wrote:
>
> On Sat, Jun 18, 2022, 9:21 PM Rob Cliffe
>>
>> Sorry again, but IMO discussing any model except one where late-bound
>> defaults are evaluated at function call time is just adding FUD.
>
>
> It's definitely rude to repeatedly state that
Using either * or / could lead to some odd inconsistencies where a missing
space is very consequential, eg:
x, / = foo # fine
x, /= foo # syntax error?
x / = foo # syntax error
x /= foo # fine, but totally different from the first example.
That said, the * syntax feels intuitive in a way that
On Fri, Jun 17, 2022 at 11:32:09AM -, Steve Jorgensen wrote:
> That leads me to want to change the proposal to say that we give the
> same meaning to "_" in ordinary destructuring that it has in
> structural pattern matching, and then, I believe that a final "*_" in
> the expression on the
26 matches
Mail list logo
