On 4 June 2018 at 07:44, Pål Grønås Drange wrote:
>> I'm not entirely sure what point you're trying to make here, but you
>> quoted that section somewhat out of context.
>>
>> [...]
>>
>> That seems directly relevant here. I'm not aware of a "timedelta
>> users" community, nor is there a particula
Pål Grønås Drange writes:
> That's good to hear, but if you don't mind asking, is your lack of
> support because you use timedelta "programatically" instead of
> hard-coded time units, or is there a different (or more) reason(s)?
Speaking for myself, not for Paul, I guess my big objection woul
> Speaking for myself, not for Paul, I guess my big objection would be
> that there would be too many collisions with other interpretations.
> Eg, does "5m" mean "5 minutes", "5 meters", or "the number 0.005"? Or
> perhaps "5 minutes of arc"?
Just to clarify, the proposition was actually `5min`,
On 4 June 2018 at 09:44, Pål Grønås Drange wrote:
>> Speaking for myself, not for Paul, I guess my big objection would be
>> that there would be too many collisions with other interpretations.
>> Eg, does "5m" mean "5 minutes", "5 meters", or "the number 0.005"? Or
>> perhaps "5 minutes of arc"?
One thing that could solve both this proposal and the aforementioned
SI-proposition by Ken Kundert, could be supporting user-defined
literals. Suppose that __litXXX___ would make XXX a literal one could
use as a suffix for numbers and strings (and lists, dicts, sets?).
A user-defined literal coul
On 4 June 2018 at 11:59, Pål Grønås Drange wrote:
> One thing that could solve both this proposal and the aforementioned
> SI-proposition by Ken Kundert, could be supporting user-defined
> literals. Suppose that __litXXX___ would make XXX a literal one could
> use as a suffix for numbers and stri
On Sat, Jun 2, 2018 at 2:21 PM, Pål Grønås Drange
wrote:
> Elevator pitch:
>
> (2.5h - 14min + 9300ms).total_seconds()
> # 8169.3
>
> from datetime import datetime as dt
> start = dt.now()
> end = dt.now()
> (end-start) < 5s
> # True
>
>
> chrono::duration:
>
> In C++ 14 the std::chrono::duration
> On 2018 Jun 4 , at 9:08 a, Giampaolo Rodola' wrote:
>
>
>
>
>
> IMO datetimes are not common enough to deserve their own literals. It would
> make the language more complex and harder to learn for a relatively little
> benefit. This would probably make more sense as a third party lib:
>
Pål Grønås Drange,
I do like the idea of literals typed with scientific units, but I often
get short variable names mixed up, so I am not sure if I could use them
without a cheat sheet. Formatting datetime is a good example of how
confusing a collection of short names can get: Is month %m or %M?
On Mon, Jun 4, 2018 at 12:58 AM, Paul Moore wrote:
> > That's good to hear, but if you don't mind asking, is your lack of
> > support because you use timedelta "programatically" instead of
> > hard-coded time units, or is there a different (or more) reason(s)?
> >
> > (I'm ready to yield, now I'm
For the general user-defined literals, here are some example use cases:
Here is how to expose literals:
__literals__ = ['__literal_h__', '__literal_min__', '__literal_s__']
And here is how to import them:
from mymodule import _* # imports all literals from mymodule
# could also be *_ or ** or
I'd like to propose adding `append` and `extend` methods to dicts
which behave like `__setitem__` and `update` respectively, except that
they raise an exception (KeyError?) instead of overwriting preexisting
entries.
Very often I expect that the key I'm adding to a dict isn't already in
it. If I w
On Mon, Jun 4, 2018 at 1:59 PM, Pål Grønås Drange
wrote:
> For the general user-defined literals, here are some example use cases:
>
I kind of like the idea of user-defined literals, but:
> Yes, we could write all these as easily as function calls,
>
> deg(90)
> celsius(20)
> center('my string
On 4 June 2018 at 22:50, Chris Barker via Python-ideas
wrote:
> So maybe you could propose adding:
>
> seconds
> minutes
> hours
> days
>
> to the datetime module, and then we could write:
>
> 60*seconds == 1*minutes
>
> Without any changes to the language at all.
This strikes me as more of a per
The `pop` method of built-in sequences is basically an atomic version of
val = self[pos]
del self[pos]
return val
If this behavior was extended to the case where `pos` is a slice, you
could write things like:
def cut_deck(deck, pos):
deck.extend(deck.pop(slice(0, pos)))
Semantically, I'm not sure append and extend would be universally
understood to mean don't overwrite.
This can be accomplished with a custom subclass for your use case:
```
import collections
class OverwriteGuardedDict(collections.UserDict):
def append(self, key, value):
if key in s
On Mon, Jun 4, 2018 at 3:58 PM George Leslie-Waksman
wrote:
> Semantically, I'm not sure append and extend would be universally
> understood to mean don't overwrite.
>
>
The proposed meanings surprised me too. My initial instinct for
`dict.append` was that it would always succeed, much like `list
On 04/06/2018 19:50, Kyle Lahnakoski wrote:
Maybe the Python parser can be made to add an implied multiplication
between a-number-followed-directly-by-a-variable-name. If so, then I
could write:
(2.5HOUR - 14MINUTE + 9300MILLISECOND).total_seconds()
This strikes me as quite a nifty idea
On Mon, Jun 4, 2018 at 3:21 PM, Paul Moore wrote:
> > So maybe you could propose adding:
> >
> > seconds
> > minutes
> > hours
> > days
> >
> > to the datetime module, and then we could write:
> >
> > 60*seconds == 1*minutes
> >
> > Without any changes to the language at all.
>
> This strikes me
On Mon, Jun 04, 2018 at 03:23:07PM -0700, Ben Rudiak-Gould wrote:
> The `pop` method of built-in sequences is basically an atomic version of
>
> val = self[pos]
> del self[pos]
> return val
Aside from the atomicness, for testing we can subclass list:
# Untested
class MyList(list):
On Mon, Jun 04, 2018 at 02:22:29PM -0700, Ben Rudiak-Gould wrote:
> I'd like to propose adding `append` and `extend` methods to dicts
> which behave like `__setitem__` and `update` respectively, except that
> they raise an exception (KeyError?) instead of overwriting preexisting
> entries.
>
> Ver
On 2018-06-05 01:25, Steven D'Aprano wrote:
On Mon, Jun 04, 2018 at 02:22:29PM -0700, Ben Rudiak-Gould wrote:
I'd like to propose adding `append` and `extend` methods to dicts
which behave like `__setitem__` and `update` respectively, except that
they raise an exception (KeyError?) instead of ov
> d.setdefault(key, value)
I though the OP wanted an error if the key already existed.
This is close, as it won’t change the dict if the key is already
there, but it will add it if it’s not.
@OP
Maybe post those five lines so we know exactly what you want — maybe
there is already a good solutio
I don't think I'd ever guess the intended semantics from the names in a
million years. They seem like horribly misnamed methods, made worse by the
false suggestion of similarity to list operations.
In 20 years of using Python, moreover, I don't think I've ever wanted the
described behavior under a
On Mon, Jun 4, 2018 at 4:02 PM, Yuval Greenfield wrote:
> The proposed meanings surprised me too. My initial instinct for
> `dict.append` was that it would always succeed, much like `list.append`
> always succeeds.
Many of the methods named `append` in the standard libraries fail if
adding the it
I'd say seconds(), minutes() etc functions in the datetime module
might be good. Same for better docstrings.
I dont really think it's worth adding literals though.
@Pål
You can't import literals. They're syntax, not just bound names.
(Unless we're counting future imports, but those aren't real im
26 matches
Mail list logo
