选择一种颜色

Etgar Keret, Sondra Silverston
{"title":"选择一种颜色","authors":"Etgar Keret, Sondra Silverston","doi":"10.1353/cgl.2011.0006","DOIUrl":null,"url":null,"abstract":"COLUMNS T he addition of improved support for asynchronous I/O in Python 3 is one of the most significant changes to the Python language since its inception. However, it also balkanizes the language and libraries into synchronous and asynchronous factions—neither of which particularly like to interact with the other. Needless to say, this presents an interesting challenge for developers writing a program involving I/O. In this article, I explore the problem of working in an environment of competing I/O models and whether or not they can be bridged in some way. As a warning, just about everything in this article is quite possibly a bad idea. Think of it as a thought experiment. I recently read an interesting blog post \" What Color Is Your Function? \" by Bob Nystrom [1]. I'm going to paraphrase briefly, but imagine a programming language where every function or method had to be assigned one of two colors, blue or red. Moreover, imagine that the functions were governed by some rules: ◆ ◆ The way in which you call a function differs according to its color. ◆ ◆ A red function can only be called by another red function. ◆ ◆ A blue function can never call a red function. ◆ ◆ A red function can call a blue function, but unknown bad things might happen. ◆ ◆ Calling a red function is much more difficult than calling a blue function. Surely such an environment would lead to madness. What is the deal with those difficult red functions? In fact, after a bit of coding, you'd probably want to ditch all of the red code and its weird rules. Yes, you would, except for a few other details: ◆ ◆ Some library you're using has been written by someone who loves red functions. Sigh. So, those red functions really are annoying. However, you're still going to have to deal with them and their weird rules in some manner.","PeriodicalId":342699,"journal":{"name":"The Yearbook of Comparative Literature","volume":"258 1","pages":"0"},"PeriodicalIF":0.0000,"publicationDate":"2011-04-27","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"0","resultStr":"{\"title\":\"Pick a Color\",\"authors\":\"Etgar Keret, Sondra Silverston\",\"doi\":\"10.1353/cgl.2011.0006\",\"DOIUrl\":null,\"url\":null,\"abstract\":\"COLUMNS T he addition of improved support for asynchronous I/O in Python 3 is one of the most significant changes to the Python language since its inception. However, it also balkanizes the language and libraries into synchronous and asynchronous factions—neither of which particularly like to interact with the other. Needless to say, this presents an interesting challenge for developers writing a program involving I/O. In this article, I explore the problem of working in an environment of competing I/O models and whether or not they can be bridged in some way. As a warning, just about everything in this article is quite possibly a bad idea. Think of it as a thought experiment. I recently read an interesting blog post \\\" What Color Is Your Function? \\\" by Bob Nystrom [1]. I'm going to paraphrase briefly, but imagine a programming language where every function or method had to be assigned one of two colors, blue or red. Moreover, imagine that the functions were governed by some rules: ◆ ◆ The way in which you call a function differs according to its color. ◆ ◆ A red function can only be called by another red function. ◆ ◆ A blue function can never call a red function. ◆ ◆ A red function can call a blue function, but unknown bad things might happen. ◆ ◆ Calling a red function is much more difficult than calling a blue function. Surely such an environment would lead to madness. What is the deal with those difficult red functions? In fact, after a bit of coding, you'd probably want to ditch all of the red code and its weird rules. Yes, you would, except for a few other details: ◆ ◆ Some library you're using has been written by someone who loves red functions. Sigh. So, those red functions really are annoying. However, you're still going to have to deal with them and their weird rules in some manner.\",\"PeriodicalId\":342699,\"journal\":{\"name\":\"The Yearbook of Comparative Literature\",\"volume\":\"258 1\",\"pages\":\"0\"},\"PeriodicalIF\":0.0000,\"publicationDate\":\"2011-04-27\",\"publicationTypes\":\"Journal Article\",\"fieldsOfStudy\":null,\"isOpenAccess\":false,\"openAccessPdf\":\"\",\"citationCount\":\"0\",\"resultStr\":null,\"platform\":\"Semanticscholar\",\"paperid\":null,\"PeriodicalName\":\"The Yearbook of Comparative Literature\",\"FirstCategoryId\":\"1085\",\"ListUrlMain\":\"https://doi.org/10.1353/cgl.2011.0006\",\"RegionNum\":0,\"RegionCategory\":null,\"ArticlePicture\":[],\"TitleCN\":null,\"AbstractTextCN\":null,\"PMCID\":null,\"EPubDate\":\"\",\"PubModel\":\"\",\"JCR\":\"\",\"JCRName\":\"\",\"Score\":null,\"Total\":0}","platform":"Semanticscholar","paperid":null,"PeriodicalName":"The Yearbook of Comparative Literature","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1353/cgl.2011.0006","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
引用次数: 0

摘要

Python 3中增加了对异步I/O的改进支持,这是Python语言自诞生以来最重要的变化之一。然而,它也将语言和库划分为同步和异步两部分——两者都不太喜欢相互交互。不用说,这对编写涉及I/O的程序的开发人员提出了一个有趣的挑战。在本文中,我将探讨在相互竞争的I/O模型环境中工作的问题,以及它们是否可以通过某种方式进行连接。作为警告,本文中的几乎所有内容都很可能是一个坏主意。把它当作一个思想实验。我最近读了一篇有趣的博客文章“你的功能是什么颜色?”作者:Bob Nystrom[1]。我将简要地解释一下,但是想象一种编程语言,其中每个函数或方法必须被分配两种颜色之一,蓝色或红色。此外,假设这些函数受一些规则支配:◆◆调用函数的方式因其颜色不同而不同。◆◆一个红色函数只能被另一个红色函数调用。蓝色函数永远不能调用红色函数。◆◆红色的函数可以调用蓝色的函数,但是未知的不好的事情可能会发生。调用一个红色函数比调用一个蓝色函数要困难得多。这样的环境肯定会导致疯狂。这些困难的红色函数是怎么处理的?事实上,在编写了一些代码后,您可能会想要抛弃所有红色代码及其奇怪的规则。是的,你会,除了一些其他细节:◆◆你正在使用的一些库是由喜欢红色函数的人编写的。叹息。这些红色的函数很烦人。然而,你仍然必须以某种方式处理他们和他们奇怪的规则。
本文章由计算机程序翻译,如有差异,请以英文原文为准。
Pick a Color
COLUMNS T he addition of improved support for asynchronous I/O in Python 3 is one of the most significant changes to the Python language since its inception. However, it also balkanizes the language and libraries into synchronous and asynchronous factions—neither of which particularly like to interact with the other. Needless to say, this presents an interesting challenge for developers writing a program involving I/O. In this article, I explore the problem of working in an environment of competing I/O models and whether or not they can be bridged in some way. As a warning, just about everything in this article is quite possibly a bad idea. Think of it as a thought experiment. I recently read an interesting blog post " What Color Is Your Function? " by Bob Nystrom [1]. I'm going to paraphrase briefly, but imagine a programming language where every function or method had to be assigned one of two colors, blue or red. Moreover, imagine that the functions were governed by some rules: ◆ ◆ The way in which you call a function differs according to its color. ◆ ◆ A red function can only be called by another red function. ◆ ◆ A blue function can never call a red function. ◆ ◆ A red function can call a blue function, but unknown bad things might happen. ◆ ◆ Calling a red function is much more difficult than calling a blue function. Surely such an environment would lead to madness. What is the deal with those difficult red functions? In fact, after a bit of coding, you'd probably want to ditch all of the red code and its weird rules. Yes, you would, except for a few other details: ◆ ◆ Some library you're using has been written by someone who loves red functions. Sigh. So, those red functions really are annoying. However, you're still going to have to deal with them and their weird rules in some manner.
求助全文
通过发布文献求助,成功后即可免费获取论文全文。 去求助
来源期刊
自引率
0.00%
发文量
0
×
引用
GB/T 7714-2015
复制
MLA
复制
APA
复制
导出至
BibTeX EndNote RefMan NoteFirst NoteExpress
×
提示
您的信息不完整,为了账户安全,请先补充。
现在去补充
×
提示
您因"违规操作"
具体请查看互助需知
我知道了
×
提示
确定
请完成安全验证×
copy
已复制链接
快去分享给好友吧!
我知道了
右上角分享
点击右上角分享
0
联系我们:info@booksci.cn Book学术提供免费学术资源搜索服务,方便国内外学者检索中英文文献。致力于提供最便捷和优质的服务体验。 Copyright © 2023 布克学术 All rights reserved.
京ICP备2023020795号-1
ghs 京公网安备 11010802042870号
Book学术文献互助
Book学术文献互助群
群 号:481959085
Book学术官方微信