hi there, folks:
I'd really like to release 0.7.0 but I would like it to be at least a
little bit tested before I do so. Could those of you with CVS trees check
everything out and see if it performs as advertised? Deeper bugs than
that will have to wait for the next release, but I'd at least like to know
if it works for someone other than me.
______ __ __ _____ _ _
| ____ | \_/ |_____] |_____|
|_____| |_____ | | | |
@ t w i s t e d m a t r i x . c o m
In smb I have a SMBPacketReceiver that inherits from t.i.p.Protocol, it
breaks the incoming TCP stream into logical packets (the analogue of
LineReceiver in line-based protocols).
I then subclass SMBPacketReceiver to SMBProtocol which does a lot of the
"heavy lifting" analyzing incoming packets.
I've been told in code review to use composition instead of inheritance,
which is fine in a general sense but I have difficulty applying to
1. how to do Factory.buildProtocol? It has to return a t.i.p.Protocol,
but with composition the Protocol object is a private variable of
SMBPacketReceiver, in turn a private variable of SMBProtocol.
2. what to do instead of overriding Protocol.dataReceived and access
incoming data if not allowed to subclass it?
Now its not that I cant think of workarounds to these two problems, but
Is there some recent twisted code using composition that I can look at?
I've followed the discussion re 3.6 and type annotations, but evidently
not closely enough
when writing new code for twisted today, can we use 3.6 features or is
3.5 still required? (it's actually a library feature enum.IntFlag I'm
curious about, not type annotations)
Last week I did some work and updated twistedchecker
so that it uses pylint >= 2.4.4. Before that, it was using a really old
twistedchecker is run over the Twisted code as part of CI, and reports
various style issues. Now that twistedchecker is using a newer pylint,
it should be compatible with newer Python language features.
Now that Twisted supports Python 3.5+ (with Python 2.7 support being
is it OK to start using newer features of the Python language in the
such as type hints ( https://docs.python.org/3/library/typing.html )?
I don't have experience with that feature, but it looks like it could be
when combined with a tool like mypy. Does anyone else have opinions on
type hints and mypy?
The past week or so, I noticed failures in the Azure Pipelines CI (see
https://github.com/twisted/twisted/pull/1278 for the ticket with them,
among others) that were due to Python + Windows falling apart on
mgorny's name. After some debugging, I ascertained:
- The environment has Unicode strings in it (because environments are
Unicode on Windows)
- but sys.stdout.encoding is cp1252 --
https://www.python.org/dev/peps/pep-0528/ does not apply due to it being
a non-interactive console
- One of the characters in the environment is not printable under
cp1252, which causes an exception.
I think we should avoid running under ANSI-mode by default at all costs,
since it causes non-obvious bugs like this (`print(os.environ)` causing
an exception). This would also bring Windows in line with UNIX, where we
basically assume a non-UTF-8 locale is more or less broken by design and
we don't run the tests on it.
It also seems like Windows is heading in the direction of having console
output be CP65001 (aka UTF-8), so I think this is a reasonable direction
to go in as well.   
PEP-528 makes sys.stdout/sys.stdin use the W ("wide", aka UTF-16LE)
APIs, as it's assumed that a human is on the other side of the console.
For compatibility, it will encode Unicode to UTF-8, pass it to
WindowsConsoleIO, which will then decode it into UTF-16 and pass it to
the console, meaning that writing raw UTF-8 bytes to sys.stdout.buffer
works as you'd expect on Windows and UNIXes. We can enable UTF-8 text
output universally with the environment variable
`PYTHONIOENCODING=utf8:surrogateescape`. If a user wants ANSI output,
they can use the "PYTHONLEGACYWINDOWSSTDIO" environment to make Python
not perform the Unicode conversions for the console, so we could perhaps
use this too, if someone is SURE they want ANSI output.
Python 3.7 has PEP-540's `-X utf8` mode, which also does this, more or
less, but in a nicer way (no environment variables).
Python 3.5 doesn't seem to work with either of these options. Not sure
why. Maybe it's busted.
So, due to this, I would like to propose the following:
- On Windows, raising a deprecation warning when sys.stdout and
sys.stderr are not UTF-8 AND the environment variable
"PYTHONLEGACYWINDOWSSTDIO" is not set.
- Declaring said environments unsupported and running our tests with -X
utf8/PYTHONIOENCODING=utf8 or PYTHONLEGACYWINDOWSSTDIO (which will
require some Unicode tests which fail because CP1252 is bad to be skipped).
- After the deprecation period, start issuing loud RuntimeWarnings
saying that you're probably not doing the thing you want to be doing.