Skip to content

check whether safeCPickleDumps(obj): is still needed #189

Description

@sbillinge

This may be another py2 compatibility function. Check where it is used and whether it can be removed.

Write tests to make sure the behavior is still handled.

Activity

  1. added this to the v3.2.0 milestone on Aug 21, 2024
  2. Tieqiong commented on Aug 26, 2024

    @Tieqiong
    Contributor

    @sbillinge this method ensures that an object is serialized even if it contains problematic floating-point values by falling back to a simpler serialization protocol if the default one fails.

    In Python 3, the pickle module uses more recent protocols, and the SystemError related to frexp() is less likely to occur. So I think the fallback to ASCII protocol (protocol 0) is not necessary any more.

    Yes test would be the right thing to do

  3. bobleesj commented on Sep 24, 2024

    @bobleesj
    Contributor

    @Tieqiong will take care of it for v3.1.0

  4. bobleesj commented on Oct 2, 2024

    @bobleesj
    Contributor

    @Tieqiong could you please share an update on this issue?

  5. sbillinge commented on Dec 15, 2024

    @sbillinge
    ContributorAuthor

    @Tieqiong can we close this?

  6. Tieqiong commented on Dec 16, 2024

    @Tieqiong
    Contributor

    Yes let's close this one! @sbillinge @bobleesj thanks

  7. sbillinge commented on Dec 16, 2024

    @sbillinge
    ContributorAuthor

    @Tieqiong we need a report on what you did and why it is ok to close it.

  8. Tieqiong commented on Dec 16, 2024

    @Tieqiong
    Contributor

    @sbillinge This is along with the utf-8 string issue when dropping py2 support. As I mentioned before this is for serialization protocols. Even if the related error (SystemError related to frexp() as I saw people mentioned) is less likely to occur in py3, it's still no harm to just follow a simpler serialization protocol and have files in the basic ASCII encoding. Also another reason is this function is still being used by other modules so some changes and tests are needed before removing this function.

    If we are shooting for cleaning things up as much as possible, then we still want to keep this issue.

  9. sbillinge commented on Dec 16, 2024

    @sbillinge
    ContributorAuthor

    yes, we want to keep this open then. But I will move it to a later milestone. No hurry on this.

  10. modified the milestones: v3.1.0, v3.2.0 on Dec 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions