freeCodeCamp Daily Coding Challenge 实战用 Python 实现 Screen Time 屏幕时间判定函数【免费下载链接】freeCodeCampfreeCodeCamp.orgs open-source codebase and curriculum. Learn math, programming, and computer science for free.项目地址: https://gitcode.com/GitHub_Trending/fr/freeCodeCamp本篇技术指南围绕 freeCodeCamp 开源仓库中daily-coding-challenges-python块的第 33 道编程挑战展开给定一个包含一周 7 天手机使用时长小时的整数数组编写 Python 函数too_much_screen_time判断该周屏幕时间是否过多。文章将完整还原题目约束、7 组官方测试用例与参考解法并结合仓库中 API 路由、客户端渲染与种子数据脚本剖析这道挑战从题目 Markdown 到在线评测的完整运行链路帮助你掌握数组遍历、滑动窗口均值与多条件判定的 Python 实战写法。挑战背景Daily Coding Challenge 在仓库中的位置这道题目对应的源文件是 curriculum/challenges/english/blocks/daily-coding-challenges-python/68af0687ef34c76c28ffa54d.md其 YAML frontmatter 标注了关键元数据id: 68af0687ef34c76c28ffa54d title: Challenge 33: Screen Time challengeType: 29 dashedName: challenge-33其中challengeType: 29表示 Python 代码挑战类型对应客户端show-daily-coding-challenge.tsx中challengeType: 29的 Python 分支而 JavaScript 分支为 28。在 curriculum/structure/blocks/daily-coding-challenges-python.json 中该挑战位列challengeOrder的第 33 项与 Challenge 1: Vowel Balance 到 Challenge 35: Word Frequency 等数百道题目共同组成了 Python 每日编程挑战块。该块配置了helpCategory: Python、usesMultifileEditor: true即挑战在多功能编辑器中完成。从仓库结构看这套挑战与Dev Playground超级块相关联种子脚本 tools/daily-challenges/seed-daily-challenges.ts 会从该超级块抓取挑战数据写入freecodecamp数据库的DailyCodingChallenges集合详见 tools/daily-challenges/README.md。因此这道Screen Time挑战既存在于课程文件中也会按日期作为每日编程挑战通过 API 对外提供。问题描述三条屏幕时间过多判定规则题目的输入是一个包含 7 个整数的数组hours每个整数代表一周中某一天使用手机的小时数。需要根据以下三条约束判断这周的屏幕时间是否过多只要满足任意一条即判定为过多返回True单日超标如果任意一天的使用时长大于等于 10 小时判定过多连续三天超标如果任意连续三天的平均使用时长大于等于 8 小时判定过多整周超标如果 7 天的平均使用时长大于等于 6 小时判定过多。三条规则是或的关系只要命中一条即可提前返回True只有三条规则全部不满足时才返回False。这里需要特别注意边界条件大于等于而非即恰好 10 小时、恰好均值 8、恰好均值 6 都属于过多。函数签名与初始代码题目提供的初始种子代码位于源文件# --seed--部分def too_much_screen_time(hours): return hours注意初始代码直接return hours返回了原始数组这是一个占位实现——hours是长度为 7 的整数列表你需要将其替换为真正的判定逻辑最终返回布尔值True或False。参考解法逐行拆解源文件# --solutions--部分给出了官方参考解法def too_much_screen_time(hours): for h in hours: if h 10: return True for i in range(5): avg3 sum(hours[i:i3]) / 3 if avg3 8: return True weekly_avg sum(hours) / 7 if weekly_avg 6: return True return False该解法按三条规则分三段实现逻辑清晰且能提前返回是典型的短路判定模式规则一单日检测。遍历hours中的每个元素一旦发现h 10立即return True。最坏情况是 7 次比较时间复杂度 O(n)。规则二连续三天滑动窗口。使用for i in range(5)遍历窗口的起始位置。为什么是 5因为 7 个元素的数组中长度为 3 的连续子数组共有7 - 3 1 5个分别从下标 0、1、2、3、4 开始。Python 的切片hours[i:i3]天然生成子数组sum(...) / 3计算平均值。这是经典的固定长度滑动窗口技巧也等价于嵌套循环枚举所有连续三元组。规则三整周均值。对全部 7 个元素求和后除以 7得到weekly_avg与 6 比较。兜底返回。三条规则全部未命中时返回False。从复杂度看规则一与规则三均为 O(n)n7 时是常数级规则二枚举 5 个窗口整体是线性时间 O(n)、常数空间 O(1)没有使用任何额外数据结构对于长度为 7 的固定输入而言效率完全足够。官方测试用例逐项验证源文件# --hints--部分内嵌了 7 组由runPythonunittest.TestCase.assertIs驱动的测试其中 3 组期望False、4 组期望True。下面逐项演算验证参考解法与题意的吻合输入hours规则一(单日≥10)规则二(连续3日均值≥8)规则三(7日均值≥6)期望结果[1, 2, 3, 4, 5, 6, 7]无最大窗口均值 (567)/3628/74False[7, 8, 8, 4, 2, 2, 3]无(788)/3≈7.6734/7≈4.86False[5, 6, 6, 6, 6, 6, 6]无(666)/3641/7≈5.86False[1, 2, 3, 11, 1, 3, 4]有 11命中规则一—True[1, 2, 3, 10, 2, 1, 0]有 10命中规则一—True[3, 3, 5, 8, 8, 9, 4]无(889)/3≈8.3340/7≈5.71True[3, 9, 4, 8, 5, 7, 6]无(485)/3≈5.6742/76True值得关注的几个边界陷阱第 3 组[5, 6, 6, 6, 6, 6, 6]单日最大 6、连续三天均值 6、整周均值 41/7≈5.86三条规则全部擦边但均未达到阈值因此返回False。这组用例专门用于验证均值 6 但不是 ≥6的临界情况。第 7 组[3, 9, 4, 8, 5, 7, 6]没有任何连续三天均值 ≥8但整周均值恰好等于 42/7 6命中规则三的 6边界返回True。这组用例验证了整周均值恰好等于阈值也算过多。第 5 组[1, 2, 3, 10, 2, 1, 0]单日恰好 10 小时即触发规则一验证 10的含等号语义。这些测试用例在评测时通过runPython注入执行题目的--hints--块会在用户代码环境中调用too_much_screen_time并对返回值做assertIs严格类型断言True/False必须是布尔字面量因此函数必须返回布尔值而非0/1之类的等价值。评测闭环从题目文件到在线判定这道挑战在 freeCodeCamp 平台上的运行不止于算法本身其背后是一条完整的工程链路理解它有助于你在本地复现与调试课程文件题目的描述、hints、seed 与 solution 都存放在 curriculum/challenges/english/blocks/daily-coding-challenges-python/68af0687ef34c76c28ffa54d.md--hints--中的 JS 包装代码通过runPython执行 Python 断言。种子入库执行 tools/daily-challenges/README.md 描述的流程复制sample.env为.env、安装依赖、以显示未上线更改模式运行客户端再cd tools/daily-challenges pnpm seed-daily-challenges把挑战从 GraphQL 抓取并写入数据库集合。API 对外暴露后端 api/src/daily-coding-challenge/routes/daily-coding-challenge.ts 注册了/daily-coding-challenge/date/:date、/day/:day、/today、/month/:month、/all、/newest六类公开 GET 路由其中/day/:day接收MM-DD格式参数通过 api/src/daily-coding-challenge/utils/helpers.ts 中的monthDayStringToUtcDate与getSourceDate映射到原始挑战日期还处理了 2 月 29 日回退到 2 月 28 日这类边界并从fastify.prisma.dailyCodingChallenges查询返回。路由的请求/响应结构由 api/src/daily-coding-challenge/schemas/daily-coding-challenge.ts 中的 TypeBox schema 约束挑战响应体包含id、date、challengeNumber、title、description以及javascript/python两个语言对象每个语言对象内是tests含text与testString即上文的提示文本与runPython测试串和challengeFiles含初始contents。客户端渲染client/src/client-only-routes/show-daily-coding-challenge.tsx 按日期请求/daily-coding-challenge/day/{MM-DD}先用 client/src/utils/daily-coding-challenge-validator.ts 中的 Joi schema 校验响应数据再调用formatChallengeData将数据库结构组装成经典挑战组件所需的 props最后交给ShowClassic渲染——Python 分支的challengeFiles被映射为fileKey: mainpy、文件名为main.py的编辑器文件评测时执行的就是--hints--中的 Python 测试代码。也就是说你在浏览器编辑器里写下的too_much_screen_time最终会被这条课程文件 → seed → API → 客户端的链路驱动执行测试字符串来自题目文件的--hints--初始代码来自--seed--而判定结果完全取决于你的函数是否满足三条规则。边界情况与易错点总结阈值含等号三处比较均为。10 小时、均值 8、均值 6 都算超标切勿写成。连续三天的窗口数量7 天共 5 个连续三天窗口下标 0~4 起始range(5)不多不少写range(7)会出现越界切片Python 切片越界不报错但窗口不完整、均值失真。返回值必须是布尔值测试使用assertIs(..., True/False)严格断言返回1/0或字符串会导致测试失败。提前返回 vs 全部检查官方解法采用命中即return True的短路策略若你选择先算全部指标再统一判断务必保证逻辑等价——任一规则命中即真三者全不命中才假。输入约定题目保证输入为 7 个整数小时数无需考虑空数组、负数或非整数的健壮性处理但代码中保留对任意长度数组的兼容如用len(hours)代替硬编码 7也是不错的习惯。扩展思路同样规则的多种 Python 实现除了官方解法这道题还适合练习几种常用 Python 技巧any 生成器表达式把三条规则压缩为声明式判断。def too_much_screen_time(hours): if any(h 10 for h in hours): return True if any(sum(hours[i:i3]) / 3 8 for i in range(5)): return True return sum(hours) / 7 6利用数学关系减少遍历注意到sum(hours[i:i3]) / 3 8等价于sum(hours[i:i3]) 24即连续三天合计 ≥ 24 小时可以避开浮点除法直接用整数比较既消除精度问题也更易读def too_much_screen_time(hours): if any(h 10 for h in hours): return True if any(sum(hours[i:i3]) 24 for i in range(5)): return True return sum(hours) 42 # 7 * 6同理整周均值 6等价于总时长 42。这条思路展示了浮点判定问题转整数判定的通用技巧。滑窗滚动累加不使用sum切片当窗口很大或追求 O(1) 空间内的线性扫描时可先累加前 3 个元素再逐次加新去旧滑动窗口和这对理解滑动窗口算法本身很有帮助。小结Screen TimeChallenge 33是一道非常适合训练多条件判定 滑动窗口基本功的入门题它用一个贴近生活的场景把单元素扫描、固定长度子数组均值、整组均值三种判定模式组合在一起并以含等号的阈值边界考验对题意的精确理解。通过逐条对照仓库中的 7 组官方测试用例你可以确认自己的实现与 freeCodeCamp 在线评测完全一致。若想继续深入仓库中同一块还有 Challenge 34: Missing Numbers、Challenge 35: Word Frequency 等大量同系列题目后端与前端代码也完整可读是研究课程内容如何被评测引擎驱动的绝佳样例。【免费下载链接】freeCodeCampfreeCodeCamp.orgs open-source codebase and curriculum. Learn math, programming, and computer science for free.项目地址: https://gitcode.com/GitHub_Trending/fr/freeCodeCamp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 freeCodeCamp Daily Coding Challenge 实战：用 Python 实现 Screen Time 屏幕时间判定函数
freeCodeCamp Daily Coding Challenge 实战用 Python 实现 Screen Time 屏幕时间判定函数【免费下载链接】freeCodeCampfreeCodeCamp.orgs open-source codebase and curriculum. Learn math, programming, and computer science for free.项目地址: https://gitcode.com/GitHub_Trending/fr/freeCodeCamp本篇技术指南围绕 freeCodeCamp 开源仓库中daily-coding-challenges-python块的第 33 道编程挑战展开给定一个包含一周 7 天手机使用时长小时的整数数组编写 Python 函数too_much_screen_time判断该周屏幕时间是否过多。文章将完整还原题目约束、7 组官方测试用例与参考解法并结合仓库中 API 路由、客户端渲染与种子数据脚本剖析这道挑战从题目 Markdown 到在线评测的完整运行链路帮助你掌握数组遍历、滑动窗口均值与多条件判定的 Python 实战写法。挑战背景Daily Coding Challenge 在仓库中的位置这道题目对应的源文件是 curriculum/challenges/english/blocks/daily-coding-challenges-python/68af0687ef34c76c28ffa54d.md其 YAML frontmatter 标注了关键元数据id: 68af0687ef34c76c28ffa54d title: Challenge 33: Screen Time challengeType: 29 dashedName: challenge-33其中challengeType: 29表示 Python 代码挑战类型对应客户端show-daily-coding-challenge.tsx中challengeType: 29的 Python 分支而 JavaScript 分支为 28。在 curriculum/structure/blocks/daily-coding-challenges-python.json 中该挑战位列challengeOrder的第 33 项与 Challenge 1: Vowel Balance 到 Challenge 35: Word Frequency 等数百道题目共同组成了 Python 每日编程挑战块。该块配置了helpCategory: Python、usesMultifileEditor: true即挑战在多功能编辑器中完成。从仓库结构看这套挑战与Dev Playground超级块相关联种子脚本 tools/daily-challenges/seed-daily-challenges.ts 会从该超级块抓取挑战数据写入freecodecamp数据库的DailyCodingChallenges集合详见 tools/daily-challenges/README.md。因此这道Screen Time挑战既存在于课程文件中也会按日期作为每日编程挑战通过 API 对外提供。问题描述三条屏幕时间过多判定规则题目的输入是一个包含 7 个整数的数组hours每个整数代表一周中某一天使用手机的小时数。需要根据以下三条约束判断这周的屏幕时间是否过多只要满足任意一条即判定为过多返回True单日超标如果任意一天的使用时长大于等于 10 小时判定过多连续三天超标如果任意连续三天的平均使用时长大于等于 8 小时判定过多整周超标如果 7 天的平均使用时长大于等于 6 小时判定过多。三条规则是或的关系只要命中一条即可提前返回True只有三条规则全部不满足时才返回False。这里需要特别注意边界条件大于等于而非即恰好 10 小时、恰好均值 8、恰好均值 6 都属于过多。函数签名与初始代码题目提供的初始种子代码位于源文件# --seed--部分def too_much_screen_time(hours): return hours注意初始代码直接return hours返回了原始数组这是一个占位实现——hours是长度为 7 的整数列表你需要将其替换为真正的判定逻辑最终返回布尔值True或False。参考解法逐行拆解源文件# --solutions--部分给出了官方参考解法def too_much_screen_time(hours): for h in hours: if h 10: return True for i in range(5): avg3 sum(hours[i:i3]) / 3 if avg3 8: return True weekly_avg sum(hours) / 7 if weekly_avg 6: return True return False该解法按三条规则分三段实现逻辑清晰且能提前返回是典型的短路判定模式规则一单日检测。遍历hours中的每个元素一旦发现h 10立即return True。最坏情况是 7 次比较时间复杂度 O(n)。规则二连续三天滑动窗口。使用for i in range(5)遍历窗口的起始位置。为什么是 5因为 7 个元素的数组中长度为 3 的连续子数组共有7 - 3 1 5个分别从下标 0、1、2、3、4 开始。Python 的切片hours[i:i3]天然生成子数组sum(...) / 3计算平均值。这是经典的固定长度滑动窗口技巧也等价于嵌套循环枚举所有连续三元组。规则三整周均值。对全部 7 个元素求和后除以 7得到weekly_avg与 6 比较。兜底返回。三条规则全部未命中时返回False。从复杂度看规则一与规则三均为 O(n)n7 时是常数级规则二枚举 5 个窗口整体是线性时间 O(n)、常数空间 O(1)没有使用任何额外数据结构对于长度为 7 的固定输入而言效率完全足够。官方测试用例逐项验证源文件# --hints--部分内嵌了 7 组由runPythonunittest.TestCase.assertIs驱动的测试其中 3 组期望False、4 组期望True。下面逐项演算验证参考解法与题意的吻合输入hours规则一(单日≥10)规则二(连续3日均值≥8)规则三(7日均值≥6)期望结果[1, 2, 3, 4, 5, 6, 7]无最大窗口均值 (567)/3628/74False[7, 8, 8, 4, 2, 2, 3]无(788)/3≈7.6734/7≈4.86False[5, 6, 6, 6, 6, 6, 6]无(666)/3641/7≈5.86False[1, 2, 3, 11, 1, 3, 4]有 11命中规则一—True[1, 2, 3, 10, 2, 1, 0]有 10命中规则一—True[3, 3, 5, 8, 8, 9, 4]无(889)/3≈8.3340/7≈5.71True[3, 9, 4, 8, 5, 7, 6]无(485)/3≈5.6742/76True值得关注的几个边界陷阱第 3 组[5, 6, 6, 6, 6, 6, 6]单日最大 6、连续三天均值 6、整周均值 41/7≈5.86三条规则全部擦边但均未达到阈值因此返回False。这组用例专门用于验证均值 6 但不是 ≥6的临界情况。第 7 组[3, 9, 4, 8, 5, 7, 6]没有任何连续三天均值 ≥8但整周均值恰好等于 42/7 6命中规则三的 6边界返回True。这组用例验证了整周均值恰好等于阈值也算过多。第 5 组[1, 2, 3, 10, 2, 1, 0]单日恰好 10 小时即触发规则一验证 10的含等号语义。这些测试用例在评测时通过runPython注入执行题目的--hints--块会在用户代码环境中调用too_much_screen_time并对返回值做assertIs严格类型断言True/False必须是布尔字面量因此函数必须返回布尔值而非0/1之类的等价值。评测闭环从题目文件到在线判定这道挑战在 freeCodeCamp 平台上的运行不止于算法本身其背后是一条完整的工程链路理解它有助于你在本地复现与调试课程文件题目的描述、hints、seed 与 solution 都存放在 curriculum/challenges/english/blocks/daily-coding-challenges-python/68af0687ef34c76c28ffa54d.md--hints--中的 JS 包装代码通过runPython执行 Python 断言。种子入库执行 tools/daily-challenges/README.md 描述的流程复制sample.env为.env、安装依赖、以显示未上线更改模式运行客户端再cd tools/daily-challenges pnpm seed-daily-challenges把挑战从 GraphQL 抓取并写入数据库集合。API 对外暴露后端 api/src/daily-coding-challenge/routes/daily-coding-challenge.ts 注册了/daily-coding-challenge/date/:date、/day/:day、/today、/month/:month、/all、/newest六类公开 GET 路由其中/day/:day接收MM-DD格式参数通过 api/src/daily-coding-challenge/utils/helpers.ts 中的monthDayStringToUtcDate与getSourceDate映射到原始挑战日期还处理了 2 月 29 日回退到 2 月 28 日这类边界并从fastify.prisma.dailyCodingChallenges查询返回。路由的请求/响应结构由 api/src/daily-coding-challenge/schemas/daily-coding-challenge.ts 中的 TypeBox schema 约束挑战响应体包含id、date、challengeNumber、title、description以及javascript/python两个语言对象每个语言对象内是tests含text与testString即上文的提示文本与runPython测试串和challengeFiles含初始contents。客户端渲染client/src/client-only-routes/show-daily-coding-challenge.tsx 按日期请求/daily-coding-challenge/day/{MM-DD}先用 client/src/utils/daily-coding-challenge-validator.ts 中的 Joi schema 校验响应数据再调用formatChallengeData将数据库结构组装成经典挑战组件所需的 props最后交给ShowClassic渲染——Python 分支的challengeFiles被映射为fileKey: mainpy、文件名为main.py的编辑器文件评测时执行的就是--hints--中的 Python 测试代码。也就是说你在浏览器编辑器里写下的too_much_screen_time最终会被这条课程文件 → seed → API → 客户端的链路驱动执行测试字符串来自题目文件的--hints--初始代码来自--seed--而判定结果完全取决于你的函数是否满足三条规则。边界情况与易错点总结阈值含等号三处比较均为。10 小时、均值 8、均值 6 都算超标切勿写成。连续三天的窗口数量7 天共 5 个连续三天窗口下标 0~4 起始range(5)不多不少写range(7)会出现越界切片Python 切片越界不报错但窗口不完整、均值失真。返回值必须是布尔值测试使用assertIs(..., True/False)严格断言返回1/0或字符串会导致测试失败。提前返回 vs 全部检查官方解法采用命中即return True的短路策略若你选择先算全部指标再统一判断务必保证逻辑等价——任一规则命中即真三者全不命中才假。输入约定题目保证输入为 7 个整数小时数无需考虑空数组、负数或非整数的健壮性处理但代码中保留对任意长度数组的兼容如用len(hours)代替硬编码 7也是不错的习惯。扩展思路同样规则的多种 Python 实现除了官方解法这道题还适合练习几种常用 Python 技巧any 生成器表达式把三条规则压缩为声明式判断。def too_much_screen_time(hours): if any(h 10 for h in hours): return True if any(sum(hours[i:i3]) / 3 8 for i in range(5)): return True return sum(hours) / 7 6利用数学关系减少遍历注意到sum(hours[i:i3]) / 3 8等价于sum(hours[i:i3]) 24即连续三天合计 ≥ 24 小时可以避开浮点除法直接用整数比较既消除精度问题也更易读def too_much_screen_time(hours): if any(h 10 for h in hours): return True if any(sum(hours[i:i3]) 24 for i in range(5)): return True return sum(hours) 42 # 7 * 6同理整周均值 6等价于总时长 42。这条思路展示了浮点判定问题转整数判定的通用技巧。滑窗滚动累加不使用sum切片当窗口很大或追求 O(1) 空间内的线性扫描时可先累加前 3 个元素再逐次加新去旧滑动窗口和这对理解滑动窗口算法本身很有帮助。小结Screen TimeChallenge 33是一道非常适合训练多条件判定 滑动窗口基本功的入门题它用一个贴近生活的场景把单元素扫描、固定长度子数组均值、整组均值三种判定模式组合在一起并以含等号的阈值边界考验对题意的精确理解。通过逐条对照仓库中的 7 组官方测试用例你可以确认自己的实现与 freeCodeCamp 在线评测完全一致。若想继续深入仓库中同一块还有 Challenge 34: Missing Numbers、Challenge 35: Word Frequency 等大量同系列题目后端与前端代码也完整可读是研究课程内容如何被评测引擎驱动的绝佳样例。【免费下载链接】freeCodeCampfreeCodeCamp.orgs open-source codebase and curriculum. Learn math, programming, and computer science for free.项目地址: https://gitcode.com/GitHub_Trending/fr/freeCodeCamp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考