[Python-ideas] Re: Reconstructing datetime from microsecond timestamp
*puts on contributor hat* Well all right then! Filed https://github.com/python/cpython/issues/109849, recapping this and asking some questions about the specifics. I'll try to put together a PR. On Mon, Sep 25, 2023 at 3:49 AM Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > Samuel Freilich via Python-ideas writes: > > > This might all be too much thought about edge cases that don't > > matter, but given the *_ns() functions in the time module (PEP > > 564), I'm curious why datetime doesn't have a constructor that > > takes an integer timestamp with the full precision that supports. > > This is such an obvious improvement that the only answer I can think > of is "Because you haven't submitted a merge request yet?" ;-) > > TBH honest you're right about the edge case, mostly datetime is about > talking to humans and that's almost by definition not worth the time > of a core dev to shave nanoseconds off the operation. But if someone > is looking for a chance to put in a patch, this looks likely to be > approved to me. > > > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/N3GSWPC3EXKBRZDRBGTJ35FFDUS7ICFP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Reconstructing datetime from microsecond timestamp
datetime.datetime has microsecond precision, and if you want to reconstruct a datetime from microseconds since the Unix epoch in a provided timezone, you can do: (datetime(1970, 1, 1, tzinfo=timezone.utc) + timedelta(microseconds=timestamp_us)).astimezone(tz) This is a general solution, but it constructs two extra datetimes and a timedelta on the way. datetime.fromtimestamp could bring that to just the one, but it takes float seconds, so there's no way to avoid losing precision (for far enough date in the future, but well short of datetime.max). One solution is to handle the micros separately: datetime.fromtimestamp(timestamp_us // 100, tz).replace(microsecond=timestamp_us % 100) This still requires constructing two datetimes, and it bakes in an assumption that the timezone offset doesn't affect and isn't affected by the millisecond component. (Which probably is the case! I think.) This might all be too much thought about edge cases that don't matter, but given the *_ns() functions in the time module (PEP 564), I'm curious why datetime doesn't have a constructor that takes an integer timestamp with the full precision that supports. Peace, -Sam ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/46PNI5Z24OTYMIHG5JMTC4JLQHT35W2B/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: startswith() and endswith() methods returning the matched value
I was just saying that using the bool return value as an index is a bit
obscure, compared to using it as a condition in an if statement. But even
in the more common use, returning the matched string is still a chance in
behavior.
On Mon, Aug 9, 2021, 10:13 AM Chris Angelico wrote:
> On Tue, Aug 10, 2021 at 12:03 AM Simão Afonso
> wrote:
> >
> > On 2021-08-09 23:57:42, Chris Angelico wrote:
> > > On Mon, Aug 9, 2021 at 10:32 PM Samuel Freilich
> wrote:
> > > > Even without it being used in as complicated a way as that it's
> still not backward compatible because of the trivial case, as
> foo.endswith("") is True.
> > >
> > > I was talking specifically about the original, which can be depended
> > > upon to return True or False. Changing the return value would break
> > > anything that depends on that.
> > >
> > > Not sure what you're referring to.
> >
> > I think this is the problem:
> >
> > > >>> "str".endswith("") is True
> > > True
> > > >>> "" is True
> > > :1: SyntaxWarning: "is" with a literal. Did you mean "=="?
> > > False
> >
> > Even if you use the return value as a bool, it will flip the result.
>
> Yep, that's also a problem, but I don't understand why my comment
> about "can be used eg for indexing" was being quoted for context
> there. I was talking about how you could do something like this:
>
> protocol = ("ws:", "wss:")[url.startswith("https:")]
>
> If the return value changes, this breaks.
>
> ChrisA
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/EMTRLSZTJMTDFV7JFXOJR3KIT4YEOMLU/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/GKSJL3DF6PLK7CYYGLQUF6O7SFUID4FO/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: startswith() and endswith() methods returning the matched value
> that can be used (eg) for indexing
Even without it being used in as complicated a way as that it's *still* not
backward compatible because of the trivial case, as foo.endswith("") is
True.
On Sun, Aug 8, 2021 at 11:55 PM Chris Angelico wrote:
> On Mon, Aug 9, 2021 at 1:42 PM wrote:
> >
> > This is a proposal to change the behaviour of the startswith() and
> > endswith() methods for str, bytes and bytearray objects, making them
> > return the matched value instead of the True boolean.
>
> Unfortunately this would break backward compatibility, since it's
> currently guaranteed that they return precisely True or False, and
> that can be used (eg) for indexing. To maintain that, you'd have to
> create new methods which return the matched value or None (and can
> then define startswith/endswith as the boolification of that). For
> instance:
>
> domain.findsuffix((".fr", ".com", ".org"))
>
> ChrisA
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/722CDS6W3FKLPWF4TBGUBHOL2RA5LZUV/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/JDE22XCNDPDQQRF3FMTS33TFVJ7MLOFY/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Standard tool for iterating over recursive data structures?
Interesting to look at the code for some of this. list.repr and dict.repr seem to be taking the "construct a set of seen items" approach. Except it's not using a set of ids, it's doing a linear pass over a list of visited PyObjects each time (which seems somewhat surprising to me, though it's only O(n*d) where d is the nesting depth, not O(n^2)): https://github.com/python/cpython/blob/3bf05327c2b25d42b92795d9d280288c22a0963d/Objects/object.c#L1974 copy.deepcopy keeps track with a dict: https://github.com/python/cpython/blob/3bf05327c2b25d42b92795d9d280288c22a0963d/Lib/copy.py#L138 (That uses a sentinel object as the default for the lookup so it can tell if that's explicitly set to None, though that seems convoluted compared to just checking whether the value is None or not. Is that considering that "copy.deepcopy(x) is None and x is not None" might be true?) Peace, -Sam On Fri, Jan 1, 2021 at 7:07 PM Greg Ewing wrote: > On 2/01/21 6:14 am, Jeff Allen wrote: > > we may as > > well say that the required result takes the form of an iterable of the > > nodes, which may subsequently be iterated by a consumer. > > In general you need more than that, I think. If you're printing > a representation of the graph, you want to know about the structure, > not just get a flat list of nodes. > > > But we must have to do something > > very similar to pickle arbitrary (potentially cyclic) structures, which > > is likewise dependent on special help from the particular built-in type. > > Can something be founded on |||__getstate__| ? > > I don't think so. All the logic for dealing with cycles is buried > inside pickle -- __getstate__ just gets info about one object. > > -- > Greg > > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/3FMDYC76POOMNJ4OZUOJ2U3KCEMTGPII/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/TVXHQCSAE3V54V6MTKFGXEXSFD3RTBTT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: execute function on iterator items without changing or consuming iterator
This seems like it might be a reasonable thing to have in intertools? It's not hard to write this sort of thing with map: some_iter = map(lambda x: (print(x), x)[1], some_iter) But it's a little awkward. (Though maybe I'm missing a less awkward way to do that.) Java has Stream.peek for similar functionality, while Stream.forEach is analogous to Python's map. On Sun, Oct 25, 2020 at 9:02 AM wrote: > Python has many tools for iteration, such as map and filter, that change > an iterator into another iterator without consuming the iterator. These > make it simple to deal with many items in a list without consuming > excessive memory. > > Occasionally it is useful to be able to tap into iterator items and > execute a function (such as a side effect to validate elements or print > them) without making any changes to the overall iterator. This is similar > to the idea of a tap in rxjs: > https://rxjs-dev.firebaseapp.com/api/operators/tap. > > The proposed interface would be: > def generate_items() -> list[int]: > some_iter = range(10) > some_iter = tap(assert_int, some_iter) > some_iter = tap(print, some_iter) > return list(some_iter) > > This would be useful to (for example): > 1. Debug chained iterators without a debugger (at the moment you would > have to convert the list and then print the whole list or include a print > statement in one of the chained functions) > 2. Check that items in an iterator conform to assumptions and raising > exceptions if they do not > 3. Improve type hints in editors since after the assert is executed all > items conform to the assert in the tap (for example, they are an integer) > > The implementation would be quite simple (at least in python): > def tap(func: typing.Callable[[T], typing.Any], iter: typing.Iterable[T]) > -> typing.iterable[T]: > for item in iter: > func(item) > yield item > > Thoughts? > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/7Q3NR4SKUC72PVQ3APK2HL2HNX3HP2IE/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/7AUUGTM77ZJFJ4PSZUYHB2PW2VJKBYYT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Improved Error Message for "Unhashable Type"
> The code which raises TypeError does not know whether it was called internally by dict or set method or explicitly by hash It's true, but I don't think it would be too hard to preserve some of the context in some of those common cases. In that bug report, I suggested adding an optional parameter for the format string used to generate the error message to PyObject_Hash and PyObject_HashNotImplemented (but I haven't yet tried to sketch out a full code change). That doesn't fully cover the case where hash calls hash recursively, and obviously we wouldn't want to handle that in a way that potentially mucks with the performance of hash functions. > do any existing built in error message have links in them? I don't think so, which is maybe a reason to avoid the inconsistency. I don't know whether that's the result of some intentional decision. I do think it can be useful to have more direct links to documentation, though. > at least add "unhashable" to the glossary -- after all, both "mutable" and "immutable" are in there. I think that's reasonable. On Mon, Sep 28, 2020 at 11:41 AM Christopher Barker wrote: > On Mon, Sep 28, 2020 at 6:34 AM Samuel Freilich via Python-ideas < > python-ideas@python.org> wrote: > >> The message does not include: >> >> * The word "hashable" verbatim, which appears in the glossary >> > * A link to https://docs.python.org/3/glossary.html#term-hashable >> > > That's a pretty good entry that does talk about the importance of > hashability in dicts and sets. So making it easier to find might be enough > to help here. > > So +1 on adding that link to the error message (if, in fact, links in > error messages are on the table at all -- do any existing built in error > message have links in them? > > and/or at least add "unhashable" to the glossary -- after all, both > "mutable" and "immutable" are in there. > > -CHB > > > > > > > > > >> * A suggestion of what to do instead >> >> For example: >> TypeError: dict keys must be hashable ( >> https://docs.python.org/glossary.html#term-hashable), 'list' is not. >> Consider using a primitive type (e.g. int, str) or immutable sequence (e.g. >> tuple, frozenset). >> >> (That could be too much stuff, my point is I think there's room for >> improvement over "unhashable type: 'list'".) >> >> I filed a bug about this (https://bugs.python.org/issue41114), but it >> was closed by a core contributor, who suggested discussing that on this >> list instead. While it's true that you can Google the error message and >> find the relevant information, I think the error message text would be >> worth improving. >> >> Peace, >> -Sam >> ___ >> Python-ideas mailing list -- python-ideas@python.org >> To unsubscribe send an email to python-ideas-le...@python.org >> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-ideas@python.org/message/B6OMGYIM47OVGOCZLEY3MEUJDFURJRDV/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > > > -- > Christopher Barker, PhD > > Python Language Consulting > - Teaching > - Scientific Software Development > - Desktop GUI and Web Development > - wxPython, numpy, scipy, Cython > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/YVXEYKK5A76QTCNNSZP2DMSHPKBGFEYV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Improved Error Message for "Unhashable Type"
The error message for using a mutable sequence as a set item or map key
seems to frequently confuse Python beginners. The current wording is:
>>> {[1, 2, 3]: [4, 5, 6]}
TypeError: unhashable type: 'list'
The first thing a Google search finds for "unhashable type" is ~4k Stack
Overflow results like:
https://stackoverflow.com/questions/13264511/typeerror-unhashable-type-dict
The message does not include:
* The type on which the operation is performed
* Which input to the operation is the problem
* The word "hashable" verbatim, which appears in the glossary
* A link to https://docs.python.org/3/glossary.html#term-hashable
* A suggestion of what to do instead
For example:
TypeError: dict keys must be hashable (
https://docs.python.org/glossary.html#term-hashable), 'list' is not.
Consider using a primitive type (e.g. int, str) or immutable sequence (e.g.
tuple, frozenset).
(That could be too much stuff, my point is I think there's room for
improvement over "unhashable type: 'list'".)
I filed a bug about this (https://bugs.python.org/issue41114), but it was
closed by a core contributor, who suggested discussing that on this list
instead. While it's true that you can Google the error message and find the
relevant information, I think the error message text would be worth
improving.
Peace,
-Sam
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/B6OMGYIM47OVGOCZLEY3MEUJDFURJRDV/
Code of Conduct: http://python.org/psf/codeofconduct/
