{"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}
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.