You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@JosephSBoyle - thanks for your contributions. I'm commenting here rather than on the PR (although I did add some feedback over there). Please also notice that Lib/email/mime/image.py uses a similar "rules" based mechanism to infer the image/* subtype when not provided.
One reason I went with this in my rewrite was so that we could easily extend the list of subtypes that we could recognize. Just add another @rule and you're done. While rule() isn't explicitly exposed publicly in either module, one could conceivably extend the list of subtypes in 3rd party code by doing something like:
I wouldn't want to lose that implicit extensibility unless there's a good reason to. I'm not sure module size or "marginally improved performance" are compelling enough. Can you provide some performance numbers? Even if they were mind-blowingly better, I'm not sure this is performance critical code.
Would you accept a new, smaller PR to remove the unnecessary header slicing and unused fakefile instance?
I would! Yeah, there's no reason any more to slice the data and it makes sense for audio.py and image.py to have a similar implementation (but not the same implementation because they have different _rules).
Activity
warsaw commentedon Jul 3, 2023
@JosephSBoyle - thanks for your contributions. I'm commenting here rather than on the PR (although I did add some feedback over there). Please also notice that
Lib/email/mime/image.pyuses a similar "rules" based mechanism to infer theimage/*subtype when not provided.One reason I went with this in my rewrite was so that we could easily extend the list of subtypes that we could recognize. Just add another
@ruleand you're done. Whilerule()isn't explicitly exposed publicly in either module, one could conceivably extend the list of subtypes in 3rd party code by doing something like:I wouldn't want to lose that implicit extensibility unless there's a good reason to. I'm not sure module size or "marginally improved performance" are compelling enough. Can you provide some performance numbers? Even if they were mind-blowingly better, I'm not sure this is performance critical code.
JosephSBoyle commentedon Jul 4, 2023
Hi @warsaw, thanks for taking a look at the PR.
Fair enough, I'm sure that someone is registering their own rules so it makes sense to keep that functionality 😄
Would you accept a new, smaller PR to remove the unnecessary header slicing and unused
fakefileinstance?warsaw commentedon Jul 4, 2023
I would! Yeah, there's no reason any more to slice the
dataand it makes sense foraudio.pyandimage.pyto have a similar implementation (but not the same implementation because they have different_rules).JosephSBoyle commentedon Jul 4, 2023
Awesome, I've created the new PR here: #106433.
@warsaw
gh-102542 Remove unused bytes object and bytes slicing (#106433)
Merge branch 'main' into modulelocals
JosephSBoyle commentedon Jul 6, 2023
Closing as completed.