Python 3 angst 2016 edition
-
@Yamikuronue said in Python 3 angst 2016 edition:
And don't get me started on 2-spaces. Everything looks so damn squished and narrow and it's so easy to be off-by-one.
A useful minimum is 3 (especially on webpages or in other published material) and 4 works really well. Some people like more, but they're just wrong. :p
-
@Yamikuronue said in Python 3 angst 2016 edition:
@pydsigner said in Python 3 angst 2016 edition:
What if you have a maximum line length enforced across your project?
Generally, it's a character limit. So your tab counts as 1, but your four spaces count as 4.
And don't get me started on 2-spaces. Everything looks so damn squished and narrow and it's so easy to be off-by-one.
I've yet to run into a situation where it made sense to use any identation width other than 4. Back in the day when I indented with tabs I went and changed their display width to 4 because 8 is way too much. If you need 2 for your code to be readable... your code is wrong. (As in, too deeply nested.)
-
@pydsigner Two spaces is the de facto standard in Javascript.
-
@pydsigner said in Python 3 angst 2016 edition:
So now the whole point of using tabs is gone because if people use a different tab width for editing than you use in the checker their lines will be uneven.
Not if you use spaces for alignment, like I keep saying.
Tabs: indentation level
Spaces: alignment after reaching the same indentation level, only for line continuations and maybe some special syntaxes that are functionally equivalent to a line continuation.@dkf said in Python 3 angst 2016 edition:
@Dreikin said in Python 3 angst 2016 edition:
Text editors can magically turn tab commands into space characters.
Next you'll be telling us that there are languages that have extra syntax, perhaps based on curly braces, which enables an IDE to reindent the code correctly at the mere touch of a button. What is this strange witchery?!
Even more! There are IDEs that can intelligently color code without any special characters at all!
-
As a side note, I think we can all agree on this: brace-based blocking or language-regulated whitespace-based blocking, either is better than the
behind this:if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail;
-
@Yamikuronue said in Python 3 angst 2016 edition:
@pydsigner Two spaces is the de facto standard in Javascript.
I wasn't aware.
-
@Dreikin said in Python 3 angst 2016 edition:
@pydsigner said in Python 3 angst 2016 edition:
So now the whole point of using tabs is gone because if people use a different tab width for editing than you use in the checker their lines will be uneven.
Not if you use spaces for alignment, like I keep saying.
Tabs: indentation level
Spaces: alignment after reaching the same indentation level, only for line continuations and maybe some special syntaxes that are functionally equivalent to a line continuation.@dkf said in Python 3 angst 2016 edition:
@Dreikin said in Python 3 angst 2016 edition:
Text editors can magically turn tab commands into space characters.
Next you'll be telling us that there are languages that have extra syntax, perhaps based on curly braces, which enables an IDE to reindent the code correctly at the mere touch of a button. What is this strange witchery?!
Even more! There are IDEs that can intelligently color code without any special characters at all!
Different issue, here I'm only discussing use of tabs in general. Let's say I edit with a width: 2 tab, and have my long line marker enabled at 80 characters, while the linter uses a width: 8 tab. Woops, all of my indented lines that come close to the marker will actually be too long! And if the linter uses a width 2 tab and I visualize with a width 8, it'll be the opposite problem: I'll be wrapping code too short and annoying all my colleagues with spurious changes. There's no way to win without editing at the same width as the linter, at which point you might as well use spaces.
-
@pydsigner said in Python 3 angst 2016 edition:
There's no way to win without editing at the same width as the linter, at which point you might as well use spaces.
I've always used spaces: four for every language except SQL, where I use 10. The reason for that is clear from my first post in the SQL Formatting thread.
-
@pydsigner said in Python 3 angst 2016 edition:
@Dreikin said in Python 3 angst 2016 edition:
@pydsigner said in Python 3 angst 2016 edition:
So now the whole point of using tabs is gone because if people use a different tab width for editing than you use in the checker their lines will be uneven.
Not if you use spaces for alignment, like I keep saying.
Tabs: indentation level
Spaces: alignment after reaching the same indentation level, only for line continuations and maybe some special syntaxes that are functionally equivalent to a line continuation.@dkf said in Python 3 angst 2016 edition:
@Dreikin said in Python 3 angst 2016 edition:
Text editors can magically turn tab commands into space characters.
Next you'll be telling us that there are languages that have extra syntax, perhaps based on curly braces, which enables an IDE to reindent the code correctly at the mere touch of a button. What is this strange witchery?!
Even more! There are IDEs that can intelligently color code without any special characters at all!
Different issue, here I'm only discussing use of tabs in general. Let's say I edit with a width: 2 tab, and have my long line marker enabled at 80 characters, while the linter uses a width: 8 tab. Woops, all of my indented lines that come close to the marker will actually be too long! And if the linter uses a width 2 tab and I visualize with a width 8, it'll be the opposite problem: I'll be wrapping code too short and annoying all my colleagues with spurious changes. There's no way to win without editing at the same width as the linter, at which point you might as well use spaces.
That does sound like problem. Perhaps a solution would be better linting tools, that care about the semantic indentation level rather than the representation of it. Specify a maximum line length after the indent, plus a maximum amount of indenting, and you get something that accomplishes the same tasks in a more discrete way (keep line length down and keep indentation level low) and that also accounts for different line width (and viewport width) preferences.
-
@pydsigner ...or you just use a linter that shows per-line errors so the gutter turns red when you go too long. Your line marker's not going to be perfect anyway, unless your tab width is 1 character; it'll imply you can type too much on any line that's indented.
-
@Yamikuronue said in Python 3 angst 2016 edition:
@pydsigner ...or you
justpotentially change a large part of dev stack use a linter that integrates with an IDE and churns CPU in order to showson the fly per-line errors so the gutter turns red when you go too long.@Yamikuronue said in Python 3 angst 2016 edition:
Your line marker's not going to be perfect anyway, unless your tab width is 1 character; it'll imply you can type too much on any line that's indented.
I don't follow.
-
@pydsigner said in Python 3 angst 2016 edition:
I don't follow.
One tab is a single character that takes up more than one space even in a fixed-width font.
-
I've always liked the idea of people using a smudge filter in their git repositories that checks out files in their preferred format and checks in commits in a standardized format. At least, it sounds like a better alternative than constantly switching your IDE settings between projects. On that note, why not take it a step further:
@anonymous234 said in Python 3 angst 2016 edition:
Treating code as an abstract tree seems like a logical idea.
The problem is, how do you edit that tree? Turns out the only efficient way for humans to edit code (that anyone has been able to find) is as text. So you'd have to convert it tree/binary -> text -> back to tree.
Which should be the storage format? AST or human-readable text? I think git is optimized for text, but maybe in the future it could also handle ASTs. Either way you'd still need to be able to quickly compile whatever you're working with.
Heck, why even use a smudge filter at all? Has anyone tried making an editor that displays an on-disk AST as human-readable code you can type in? IDEs already do syntax checking as you type... doesn't seem like too much of a leap. It would significantly complicate the inner workings of programmer-oriented text editors, though...
I'm sure this has all been thought of before but I feel like I never got to read or participate in any such discussions.
@Yamikuronue said in Python 3 angst 2016 edition:
One tab is a single character that takes up more than one space even in a fixed-width font.
I've always wondered why tab width had to be an integer. I feel like I'd be happy at a tab width of 3.5, for instance.
-
@LB_ said in Python 3 angst 2016 edition:
I've always wondered why tab width had to be an integer. I feel like I'd be happy at a tab width of 3.5, for instance.
Lining up columns in fixed-width fonts, which can make things easier to read. Doesn't have to be an integer outside of that, and I wouldn't be surprised if it wasn't in many proportional fonts.
-
@pydsigner said in Python 3 angst 2016 edition:
Ew. Tab indentation is Evil
GTFO. You should be burned at the stake.
-
@pydsigner said in Python 3 angst 2016 edition:
People pay more attention when their build fails than when you complain in code reviews about style concerns.
You have code reviews and you're complaining about how hard your life is?! Boo fucking hoo! After 20 years in this industry I've spent maybe a year total working with a process that includes code reviews. After a lot of pushing, we're finally starting to sometimes do that where I am now.
-
@pydsigner said in Python 3 angst 2016 edition:
Overall, I feel like "but people like different tab widths!" is really weak argument compared to all the baggage tabs give you.
There's no baggage, there's just people doing stuff wrong. Indentation is exactly what tabs have been for, for decades.
"people like different tab widths" isn't an argument for you because you choose the right width (4). What if you have to read code from someone that uses 2? Or 1? (I've seen it, ugh).
-
@Dreikin said in Python 3 angst 2016 edition:
As a side note, I think we can all agree on this: brace-based blocking or language-regulated whitespace-based blocking, either is better than the
behind this:if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail;Of all the things Perl got wrong, one of the few things it got absolutely spot-on is the requirement that all blocks have curly braces.
We use a PMD rule to reject code that's missing curly braces. There's no excuse.
-
@pydsigner said in Python 3 angst 2016 edition:
have my long line marker enabled at 80 characters
I think I've found your problem. You're stuck in 1976.
-
@pydsigner said in Python 3 angst 2016 edition:
@Yamikuronue said in Python 3 angst 2016 edition:
@pydsigner ...or you
justpotentially change a large part of dev stack use a linter that integrates with an IDE and churns CPU in order to showson the fly per-line errors so the gutter turns red when you go too long.Dude, we moved on from Notepad before Notepad was even a thing. Programmer's editors were around a long time ago and already "churns CPU" to provide features that beat a plain text editor. These days, holy shit, have you seen Eclipse or Visual Studio? Plugins and extensions and integrations and stuff all over the place! They even do syntax colouring!
-
@another_sam said in Python 3 angst 2016 edition:
@pydsigner said in Python 3 angst 2016 edition:
have my long line marker enabled at 80 characters
I think I've found your problem. You're stuck in 1976.
i have mine at 120, bit it's more of a guideline. if i find myself writing code that crosses that line it's usually a sign that i either need to decompose the method into sub methods or i'm trying to do too much on a single line.
it's not always the case, but it's often enough that having the marker on screen to remind me is worth it.
-
@Maciejasjmj said in Python 3 angst 2016 edition:
Plus, whitespace can get lost in transit - ever pasted your code somewhere only to have every line start at column 1? With braces you can reconstruct the whitespace, with syntactic whitespace you lost that information.
@boomzilla said in Python 3 angst 2016 edition:
Braces are nice because they are unambiguous. Always. They require less work to decipher in case something goes wrong. Just like putting semicolons in javascript.
@dkf said in Python 3 angst 2016 edition:
there are languages that have extra syntax, perhaps based on curly braces, which enables an IDE to reindent the code correctly at the mere touch of a button
Thinking about it, you're all right. We should aim for something like this to make it easier on the computers:
<function id="main" type="void"> <parameters> <parameter id="args" type="string" array="true"/> </parameters> <call ref="ConditionalHello"> <parameter ref="name">Jeff</parameter> </call> </function> <function id="ConditionalHello" type="void"> <parameters> <parameter id="name" type="string"/> </parameters> <if> <condition> <equal> <left ref="name"/> <right value="Jeff" type="string"/> </equal> </condition> <conditiontrue> <print>Sorry, not welcome here.</print> </iftrue> <conditionnottrue> <print>Hello, <tostring ref="name"/>!</print> </ifnottrue> </if> </function>I have seen the light!
Guess what the chapter I'm currently reading is related to.
-
@Adynathos said in Python 3 angst 2016 edition:
It is not the first time that Zed Shaw's ridiculous behaviour is ridiculed on our forum, last time:
https://what.thedailywtf.com/topic/16422/zed-shaw-gets-schooled-on-c-undefined-behaviorFrom the post, I understand that "Shaw does not like Python 3", but what does he propose instead?
It's my hope that this essay wakes them up and they change their path to something much more friendly to everyone. That they admit Python 3's design was seriously flawed and start Python 4 in an attempt to rescue the language.
Conveniently lacking any proposals of what that direction could be.
If there is ever a Python 4, I am sure there will be a "Case against Python 4" article by Zed Shaw.2to3 translator
Admittedly this could have been done in a better way. Eevee is right that in general this is a difficult problem to translate between languages A and B.
However, the Python devs control the design of language B, so they could design it in a way that improves chances of translation.
Maybe they tried and deemed it not worth the effort. Or python code is just not very good at preserving precise logical information - which is highly likely given lack of static typing.I recently converted a semi-largish library from 2 to a 2+3 library using
six. I ended up learning what the code actually does (I was hoping for a simple replacement but nope it was not possible). Here is what I would have preferred:from __future__ import python2_context with python2_context print 'I am an old fart'At the very least they should have made
sixpart of Python 2.8 and called it__future__.sixPyCharm has a free community edition Zed Shaw better install it and let it detect compatibility issues. It is so fucking smart you can see how AI will conquer the last job market humans still hold.
-
@Dreikin said in Python 3 angst 2016 edition:
@Maciejasjmj said in Python 3 angst 2016 edition:
Plus, whitespace can get lost in transit - ever pasted your code somewhere only to have every line start at column 1? With braces you can reconstruct the whitespace, with syntactic whitespace you lost that information.
@boomzilla said in Python 3 angst 2016 edition:
Braces are nice because they are unambiguous. Always. They require less work to decipher in case something goes wrong. Just like putting semicolons in javascript.
@dkf said in Python 3 angst 2016 edition:
there are languages that have extra syntax, perhaps based on curly braces, which enables an IDE to reindent the code correctly at the mere touch of a button
Thinking about it, you're all right. We should aim for something like this to make it easier on the computers:
<function id="main" type="void"> <parameters> <parameter id="args" type="string" array="true"/> </parameters> <call ref="ConditionalHello"> <parameter ref="name">Jeff</parameter> </call> </function> <function id="ConditionalHello" type="void"> <parameters> <parameter id="name" type="string"/> </parameters> <if> <condition> <equal> <left ref="name"/> <right value="Jeff" type="string"/> </equal> </condition> <conditiontrue> <print>Sorry, not welcome here.</print> </iftrue> <conditionnottrue> <print>Hello, <tostring ref="name"/>!</print> </ifnottrue> </if> </function>I have seen the light!
Guess what the chapter I'm currently reading is related to.
Because why not:
<CompilationUnit> <MethodDeclaration id="Main"> <PredefinedType> <VoidKeyword/> </PredefinedType> <ParameterList> </ParameterList> <Block> <ExpressionStatement> <InvocationExpression> <IdentifierName>ConditionalHello</IdentifierName> <ArgumentList> <Argument> <StringLiteralExpression>Jeff</StringLiteralExpression> </Argument> </ArgumentList> </InvocationExpression> </ExpressionStatement> </Block> </MethodDeclaration> <MethodDeclaration id="ConditionalHello"> <PredefinedType> <VoidKeyword/> </PredefinedType> <ParameterList> <Parameter id="name"> <PredefinedType> <StringKeyword/> </PredefinedType> </Parameter> </ParameterList> <Block> <IfStatement> <EqualsExpression> <Left> <IdentifierName>name</IdentifierName> </Left> <Right> <StringLiteralExpression>Jeff</StringLiteralExpression> </Right> </EqualsExpression> <Block> <ExpressionStatement> <InvocationExpression> <SimpleMemberAccessExpression> <IdentifierName>Console</IdentifierName> <IdentifierName>WriteLine</IdentifierName> </SimpleMemberAccessExpression> <ArgumentList> <Argument> <StringLiteralExpression>Sorry, not welcome here.</StringLiteralExpression> </Argument> </ArgumentList> </InvocationExpression> </ExpressionStatement> </Block> <ElseClause> <Block> <ExpressionStatement> <InvocationExpression> <SimpleMemberAccessExpression> <IdentifierName>Console</IdentifierName> <IdentifierName>WriteLine</IdentifierName> </SimpleMemberAccessExpression> <ArgumentList> <Argument> <InterpolatedStringExpression> <InterpolatedStringText>Hello, </InterpolatedStringText> <Interpolation> <IdentifierName>name</IdentifierName> </Interpolation> <InterpolatedStringText>!</InterpolatedStringText> </InterpolatedStringExpression> </Argument> </ArgumentList> </InvocationExpression> </ExpressionStatement> </Block> </ElseClause> </IfStatement> </Block> </MethodDeclaration> </CompilationUnit>
-
@Dreikin That's like some fusion of old C and HTML! We should give it a snazzy name...something like oldCFusion!
-
@anonymous234 said in Python 3 angst 2016 edition:
@Adynathos said in Python 3 angst 2016 edition:
Anyway, the root of the problem here is that the existing tools still treat code as text, even though there exist many texts which are not valid code.
Treating code as an abstract tree seems like a logical idea.
The problem is, how do you edit that tree? Turns out the only efficient way for humans to edit code (that anyone has been able to find) is as text. So you'd have to convert it tree/binary -> text -> back to tree.
I would think that my presence in this forum would be enough to provide the obvious answer.
OK, so s-expressions are still text, at least when displayed, but I think we can agree that they are basically just a literal for the AST with some extra formatting and explicit identifiers/symbols to make it clearer.
Also, environments such as the Smalltalk Code Browser show that even with text, a program doesn't have to be just a linear sheet of text without any structure to it. This is more an issue of the IDE than the language - though some languages make that sort of structured presentation easier than others do - but the insistence on presenting code qua code solely as text without any real options for alternatives is an idea whose time should have been past decades ago.
However, I should mention that if I ever get the IDE for Thelema off the ground, I will be separating markup and whitespacing entirely from the code proper - the code will be stored as serialized symbols, and the formatting will be left tot he IDE, which makes it both easier to keep consistent, and easier to tweak for different stylistic preferences. I'm even thinking of putting markup categories in the code (or more likely, in meta-data) that could be manipulated independent of the code being worked on.
Not that it will ever happen, mind you, but I can dream, can't I?
-
@ScholRLEA When it does (not) happen, will you let me know? I'm very interested.
-
@ScholRLEA Funny, this kinda means we've gone full circle in a way - the ZX Spectrum had a dialect of BASIC on board the ROM and it stored everything as tokens so that an individual instruction is essentially reduced to a single byte in the storage area. The language was primitive - no functions as we might think of them, and it's an old-school BASIC dialect so structure is done with line numbers and not indentation, but it's the first thing I thought of, in that the structure of the source listing is partially laid out by the system and not just 'code'.
-
@ScholRLEA said in Python 3 angst 2016 edition:
@anonymous234 said in Python 3 angst 2016 edition:
@Adynathos said in Python 3 angst 2016 edition:
Anyway, the root of the problem here is that the existing tools still treat code as text, even though there exist many texts which are not valid code.
Treating code as an abstract tree seems like a logical idea.
The problem is, how do you edit that tree? Turns out the only efficient way for humans to edit code (that anyone has been able to find) is as text. So you'd have to convert it tree/binary -> text -> back to tree.
I would think that my presence in this forum would be enough to provide the obvious answer.
OK, so s-expressions are still text, at least when displayed, but I think we can agree that they are basically just a literal for the AST with some extra formatting and explicit identifiers/symbols to make it clearer.
Also, environments such as the Smalltalk Code Browser show that even with text, a program doesn't have to be just a linear sheet of text without any structure to it. This is more an issue of the IDE than the language - though some languages make that sort of structured presentation easier than others do - but the insistence on presenting code qua code solely as text without any real options for alternatives is an idea whose time should have been past decades ago.
However, I should mention that if I ever get the IDE for Thelema off the ground, I will be separating markup and whitespacing entirely from the code proper - the code will be stored as serialized symbols, and the formatting will be left tot he IDE, which makes it both easier to keep consistent, and easier to tweak for different stylistic preferences. I'm even thinking of putting markup categories in the code (or more likely, in meta-data) that could be manipulated independent of the code being worked on.
Not that it will ever happen, mind you, but I can dream, can't I?
That image above, showing what I based my XML program on, is a portion of the AST for that program via the Roslyn compiler for C#. It encodes pretty much all the info except the spacing, and if I were a little more ambitious, I could've put everything there into the XML tree. Without much work, I think it could be used as the basis for exactly what you're talking about, just for C# instead of Thelema.
-
@Arantor said in Python 3 angst 2016 edition:
@ScholRLEA Funny, this kinda means we've gone full circle in a way - the ZX Spectrum had a dialect of BASIC on board the ROM and it stored everything as tokens so that an individual instruction is essentially reduced to a single byte in the storage area. The language was primitive - no functions as we might think of them, and it's an old-school BASIC dialect so structure is done with line numbers and not indentation, but it's the first thing I thought of, in that the structure of the source listing is partially laid out by the system and not just 'code'.
That's true, and in fact that was the case with most interpreters (especially BASIC interpreters) up until the mid-1980s. The move to storing source code as text really only came t the fore with AWK and other interpreted and compiled/interpreted languages in the Unix sphere starting around 1978 or so, mainly because Unix didn't really do either binary data storage or interactive REPLs - the Unix view was that you used a shell for any and all user interaction and the programs were just fed options and launched, avoiding user interaction wherever possible and only giving feedback on an error. In many ways, early Unix was closer to a batch processing than it's predecessor Multics was - the console was for programmers to edit source code in and start scripts from, and casual users weren't important because no one who wasn't a programmer would ever see a Unix system. That attitude persisted well into the 1990s, long after X Window System put a coat of GUI paint over that. This explains a lot about Linux and especially *BSD even today.
(Keep in mind that X wasn't originally a Unix project, nor was it meant to run a local windowing system - indeed, most implementations relied on the fact that there was an existing graphics engine on the server to drive the actual display, and tell the remote clients the server's capabilities. It was developed as part of Project Athena, a joint MIT/Carnegie-Mellon/DEC experiment in distributed processing, and was designed to be a means of sending video and GUI actions such as mouse clicks, window launches, and image redraws from various systems - mainly VAXs, PDP-10s, and LispMs - to remote workstations and video terminals which might be getting display requests from several distributed sources. This also explains the reversed 'server' and 'client' terminology, where the display is the server and the computers actually running the programs are the clients - the server was the system processing the display requests, and usually wasn't doing much else, often being just a smart terminal or
dicklessdiskless workstation with just enough power to drive the monitor.)
-
@Arantor said in Python 3 angst 2016 edition:
@ScholRLEA Funny, this kinda means we've gone full circle in a way - the ZX Spectrum had a dialect of BASIC on board the ROM and it stored everything as tokens so that an individual instruction is essentially reduced to a single byte in the storage area.
Commodore BASIC did something similar, which is why you can abbreviate most commands as (first letter) plus (shift second letter) in it, like
P┳forPRINT— that’s how they got stored in memory.LISTing the program then showed the expanded form as normal.I don’t feel like getting the programmer’s manual out, but as I recall it has some cautions about doing this due to possibly exceeding the maximum line length (80 characters, off the top of my head) if the expanded form is more than that.
-
@ScholRLEA said in Python 3 angst 2016 edition:
the code will be stored as serialized symbols, and the formatting will be left tot he IDE
So it will only be possible to program in the language at all once you've written the whole IDE? That's a… difficult path to get started on without a lot of up-front investment in tooling. The advantage of plain text is that you've got an adequate GUI for working with it already.
-
@ScholRLEA said in Python 3 angst 2016 edition:
This also explains the reversed 'server' and 'client' terminology, where the display is the server and the computers actually running the programs are the clients
In network terms, the terminology is the correct way round. It's just that many people like to think that servers must be things hidden away in closets (or whatever spare space is pretending to be a machine room today) which is a failure on their part to understand networking.
-
@Gurth said in Python 3 angst 2016 edition:
I don’t feel like getting the programmer’s manual out, but as I recall it has some cautions about doing this due to possibly exceeding the maximum line length (80 characters, off the top of my head) if the expanded form is more than that.
I think the ZX BASIC limit was 255 characters in encoded form per line;
LISTandPRINTwere single bytes. There certainly wasn't an 80 character limit (actual display lines on the system were 32 characters wide; 80 had no special meaning at all). I'm pretty sure that Commodore's BASIC would also go more than 80 characters, because that was needed for certain types of branching structures, but never used one enough to know for sure.
-
@dkf said in Python 3 angst 2016 edition:
I'm pretty sure that Commodore's BASIC would also go more than 80 characters, because that was needed for certain types of branching structures, but never used one enough to know for sure.
IIRC, two lines minus a character, so 79 I think. Even fuzzier memory: that was an editor limit; if you did fancy shit like loading binary to 0x0801, you could have technically have longer lines.
-
@dkf said in Python 3 angst 2016 edition:
more than 80 characters, because that was needed for certain types of branching structures
-
@dkf The compiler will be able to use code written and stored in plain text, but it will be designed to integrate with tools in a way that allows incremental compilation - which includes storing the temporary serialized form, and converting the serialized form back to text when needed. So... some from column A, some from column B.
In other words, the serialized AST form is the preferred form, but it could work with plain text source without trouble.
Keep in mind that my real intent is to use this with xanalogical storage, which doesn't have a concept of files at all. Whether I will get anywhere with that, either, is a highly improbable proposition, but that is my intent.
-
@dkf This is true; while most servers fit into the 'remote machine in a closet somewhere' model, it isn't really what the client-server model is all about. I was looking at it from the 'server as a provider of a service to several clients' (one-to-many, basically) PoV, from which X Window System's terminology also makes sense (even if X is rarely used that way today), but you are right, from my limited understanding of networking topology theory that's the correct terminology, and the networking view is really the technically correct one.
-
@dkf said in Python 3 angst 2016 edition:
I think the ZX BASIC limit was 255 characters in encoded form per line;
LISTandPRINTwere single bytes. There certainly wasn't an 80 character limit (actual display lines on the system were 32 characters wide; 80 had no special meaning at all).Not on a Spectrum, no, but I was talking about the Commodore 64 there, where lines were 40 characters long.
I'm pretty sure that Commodore's BASIC would also go more than 80 characters, because that was needed for certain types of branching structures, but never used one enough to know for sure.
Neither did I, but I bought one a few months ago and spent some time reading in the programmer’s reference guide I got along with it. Let’s see if I can find the relevant passage in it … Ah, check out page 95:
-
@another_sam said in Python 3 angst 2016 edition:
@pydsigner said in Python 3 angst 2016 edition:
have my long line marker enabled at 80 characters
I think I've found your problem. You're stuck in 1976.
You missed the part where both scenarios were hypotheticals, didn't you.
@accalia said in Python 3 angst 2016 edition:
i have mine at 120, bit it's more of a guideline.
I have mine at 100, while the linter will explode at 120.
-
@pydsigner said in Python 3 angst 2016 edition:
You missed the part where both scenarios were hypotheticals, didn't you.
Something something
-
@ScholRLEA said in Python 3 angst 2016 edition:
This also explains the reversed 'server' and 'client' terminology, where the display is the server and the computers actually running the programs are the clients
Why do you think that's "reversed"? You've got a client app that needs stuff done (in this case, drawing things on a screen), and you pass that work off to a server (the X server, that draws stuff on a screen) and hand a result back to the client.
It's no different to how for example a web browser works.
-
@gordonjcp said in Python 3 angst 2016 edition:
@ScholRLEA said in Python 3 angst 2016 edition:
This also explains the reversed 'server' and 'client' terminology, where the display is the server and the computers actually running the programs are the clients
Why do you think that's "reversed"? You've got a client app that needs stuff done (in this case, drawing things on a screen), and you pass that work off to a server (the X server, that draws stuff on a screen) and hand a result back to the client.
The issue is that most people tend to think of servers as only file servers that the user interacts with by using a client browser. Lots of client browsers can connect to one server, so, e.g., everyone can be watching funny cat videos at the same time.
Because of their ubiquitous association of "client" with "user-interaction", having one user-interaction node (X server) for multiple processing units (X clients) just sounds backwards.
It's no different to how for example a web browser works.
Au contraire, it's exactly opposite to how a web browser works. The web server doesn't ask for input or send requests to draw something on the screen. It just sits there waiting for requests to come to it. Clients are the driving force for server action. The server has certain capabilities, and the client asks to use some of it.
-
@djls45 "Au contraire, it's exactly opposite to how a web browser works."
No, it's exactly the same.
The web server accepts requests from clients and goes off and does stuff, generally to do with finding files and possibly running some sort of script to assemble up a page. It generates a few logs, maybe passes a few commands out to other tools, and hands the result back to the client. What the client does with it, we don't have to care about it.
The X server accepts requests from clients and goes off and does stuff, generally to do with slinging pixels at a screen. It might generate some logs but there's really not a lot it needs to tell anyone. It'll hand a result back to the client, but we don't really need to know or care what the client does with it.
Lots and lots of clients can connect to an X server and ask it to do stuff, but those clients can typically only talk to one server at a time. I guess you could make an X client that talked to multiple servers the way that web clients can, by talking to them one after the other.
The crucial thing you're missing out here is that it's purely accidental that the most commonly used web clients - browsers - end up drawing stuff on the screen. A web browser is really just a bit of middleware that translates between a web server and an X server.
-
@gordonjcp said in Python 3 angst 2016 edition:
I guess you could make an X client that talked to multiple servers the way that web clients can, by talking to them one after the other.
I've done this; it takes a lot of book-keeping on the client side, but it works.
-
@Dreikin said in Python 3 angst 2016 edition:
@dkf said in Python 3 angst 2016 edition:
more than 80 characters, because that was needed for certain types of branching structures
In ZX BASIC, if you wanted to do the equivalent of a
switchin sane languages, you had to do a computedGOTO. Utterly horrific.
-
@dkf said in Python 3 angst 2016 edition:
@Dreikin said in Python 3 angst 2016 edition:
@dkf said in Python 3 angst 2016 edition:
more than 80 characters, because that was needed for certain types of branching structures
In ZX BASIC, if you wanted to do the equivalent of a
switchin sane languages, you had to do a computedGOTO. Utterly horrific.
-
@dkf said in Python 3 angst 2016 edition:
@gordonjcp said in Python 3 angst 2016 edition:
I guess you could make an X client that talked to multiple servers the way that web clients can, by talking to them one after the other.
I've done this; it takes a lot of book-keeping on the client side, but it works.
See, that's the sort of entertainingly mad project I love to hear about.
-
@dkf said in Python 3 angst 2016 edition:
In ZX BASIC, if you wanted to do the equivalent of a
switchin sane languages, you had to do a computedGOTO. Utterly horrific.I can’t think of a home computer BASIC of the time that didn’t have this limitation. At least Spectrum BASIC had commands for the kinds of things that users might want to do, like, oh, clearing the screen or drawing lines on it. Try that in Commodore BASIC … (I’ll refer anyone
interestedwith masochistic tendencies to chapter 3 of the C64’s programmer’s manual. I gave up trying to do anything in graphics mode in C64 BASIC not very long after beginning to write a program to draw simple lines.)
-
@Gurth what the hell do you think you're using, QBASIC?
Anyway, it's probably better to cut off the middleman and get a cart with an assembler on it. Coding for C64 is mostly peeking and poking at memmapped registers anyway.
