You meant math.radians(degrees), and Robert already mentioned the problem
with this:
>>> math.cos(math.radians(90))
6.123233995736766e-17
On Thu, 7 Jun 2018 at 16:22 Ryan Gonzalez wrote:
> You could always do e.g. math.sin(math.degress(radians)) and so forth...
>
> On June 7, 2018 3:07:21 PM Ro
n my tests. Making
this work with pkg_resources took a few tries. It sounds like importlib
won't really improve the situation.
On Tue, 15 May 2018 at 16:30 Barry Warsaw wrote:
> On May 15, 2018, at 14:03, Rob Speer wrote:
>
> > Consider a mini-Web-server written in Python (ther
On Mon, 14 May 2018 at 12:17 Chris Angelico wrote:
> On Tue, May 15, 2018 at 2:05 AM, Chris Barker via Python-ideas
> wrote:
> > But my question is whether high precision timedeltas belongs with
> "calendar
> > time" at all.
> >
> > What with UTC and leap seconds, and all that, it gets pretty ug
While importlib.resources looks very good, I'm certain that it can't
replace every use of __file__ for accessing files relative to your Python
code.
Consider a mini-Web-server written in Python (there are, of course, lots of
these) that needs to serve static files. Users of the Web server will
exp
By now, it sounds right to me that I should implement these codecs in a
package. I accept that I've established the use case, but not sufficiently
established why it belongs in Python.
The package can easily be ftfy -- although I should point out that what's
in ftfy at the moment isn't quite right
On Wed, 31 Jan 2018 at 12:50 Serhiy Storchaka wrote:
> The passed encoding differs from the name of new Python encoding. It is
> just 'windows-1252', not 'windows-1252-whatwg'. If just change the
> existing encoding, this can break other code that expects the standard
> 'windows-1252'. Thus every
I'd like to limit this proposal to single-byte encodings, addressing the
discrepancies in the C1 characters and possibly that Hebrew vowel point. If
there are differences in the JIS encodings, that is a can of worms I'd like
to not open at the moment.
-- Rob Speer
On Mon, 22 Jan 201
n PEP form instead
of PR form can be the right way to focus discussion.
Thanks for the recommendation there, and I'd like a little extra
information -- I don't know _mechanically_ how to write a PEP. (Where do I
submit it to, for example?)
-- Rob Speer
On Sun, 21 Jan 2018 at 05:44 Steven D'A
I see how this is another way to get what I was asking for: a way to decode
some unfortunately common text encodings, ones that Web browsers use, in
Python without having to import additional modules.
I appreciate other ideas about how to solve this problem, but the
generality here seems pretty un
uest
not the next step, for example? I never got a good answer on the process),
or because this thread is just constantly being derailed.
On Fri, 19 Jan 2018 at 13:14 M.-A. Lemburg wrote:
> On 19.01.2018 18:12, Rob Speer wrote:
> > Error handlers are quite orthogonal to this proble
Error handlers are quite orthogonal to this problem. If you try to solve
this problem with an error handler, you will have a different problem.
Suppose you made "c1-control-passthrough" or whatever into an error
handler, similar to "replace" or "ignore", and then you encounter an
unassigned charac
I'm going to push back on the idea that this should only be used for
decoding, not encoding.
The use case I started with -- showing people how to fix mojibake using
Python -- would *only* use these codecs in the encoding direction. To fix
the most common case of mojibake, you encode it as web-1252
On Thu, 11 Jan 2018 at 11:43 Random832 wrote:
> Maybe we need a new error handler that maps unassigned bytes in the range
> 0x80-0x9f to a single character in the range U+0080-U+009F. Do any of the
> encodings being discussed have behavior other than the "normal" version of
> the encoding plus wh
> The question is rather: how often does web-XXX mojibake happen?
Very often. Particularly web-1252 mixed up with UTF-8.
My ftfy library is tested on data from Twitter and the Common Crawl, both
prime sources of mojibake. One common mojibake sequence is when a right
curly quote is encoded as UTF-
orrifies me).
Calling a register() function makes flake8 happy, at the cost of
convenience, but it still has no clear connection to the place where you
use the registered encodings.
On Wed, 10 Jan 2018 at 14:57 M.-A. Lemburg wrote:
> On 10.01.2018 20:13, Rob Speer wrote:
> > I was ori
andards organization, but it _is_ the standards organization for the Web.
I'm really not interested in best-fit mappings that turn infinity into "8"
and square roots into "v". Making weird mappings like that sounds like a
job for the "unidecode" library, not the
ncodings that match the WHATWG encodings exactly. If they have to be given
a different name, that's fine with me.
On Wed, 10 Jan 2018 at 03:38 M.-A. Lemburg wrote:
> On 10.01.2018 00:56, Rob Speer wrote:
> > Oh that's interesting. So it seems to be Python that's the ex
s-1252" works as an alias for "cp1252". That alias should
be added, right?
On Tue, 9 Jan 2018 at 21:46 Nick Coghlan wrote:
> On 10 January 2018 at 09:56, Rob Speer wrote:
> > Oh that's interesting. So it seems to be Python that's the exception
> here.
> &
irst of all, many thanks for such a excellently writen letter. It was a
> real pleasure to read.
> On 10.01.2018 0:15, Rob Speer wrote:
>
> Hi! I joined this list because I'm interested in filling a gap in Python's
> standard library, relating to text encodings.
>
Hi! I joined this list because I'm interested in filling a gap in Python's
standard library, relating to text encodings.
There is an encoding with no name of its own. It's supported by every
current web browser and standardized by WHATWG. It's so prevalent that if
you ask a Web browser to decode "
20 matches
Mail list logo
