Jim Baker writes:
> Given that Jython uses UTF-16 as its representation, it is possible to
> frequently smuggle isolated surrogates in it. A surrogate pair must be a
> low surrogate in range (D800, DC00), then a high surrogate in range(DC00,
> E000).
>
> Of course, if you do actually have a
R. David Murray writes:
> > Do what, exactly? As I understand you, you treat the unknown bytes as
> > completely opaque, not representing any characters at all. Which is
> > what I'm saying: those are not characters.
>
> Yes. I thought you were saying that one could not treat the string wit
Glenn Linderman writes:
> Some bytes may decode into characters without needing to be
> smuggled... maybe not in text-protocols like email, but in the
> general case. So then some of the bytes that should be interpreted
> as binary data are not in a disjoint set from characters.
True, but irr
Steven D'Aprano writes:
[long example]
> Am I right so far?
>
> So the email package uses the surrogate-escape error handler and ends up
> with this Unicode string:
>
> 'Subject: \udc9c\udc80\udce2NOBODY expects the Spanish Inquisition!”'
>
> which can be encoded back to the bytes we
Jeff Allen writes:
> This feels like a jython-dev discussion. But anyway ...
Well, if the same representation could be used in Jython you could
just point to PEP 383 and be done with it.
> u'\udc83' in u'abc\U00010083xyz'
IMHO being able to type that is a bug. There should be no literal
nota
Steven D'Aprano writes:
> On Wed, Sep 17, 2014 at 09:21:56AM +0900, Stephen J. Turnbull wrote:
>
> > Guido's mantra is something like "Python's str doesn't contain
> > characters or even code points[1], it contains code units."
>
>
R. David Murray writes:
> in the email address (and can't contain non-ASCII yet...we need RFC 6855
> support for that, and I'm not sure *anybody* has that yet).
If it's an RFC, *somebody* has it *somewhere*. :-)
___
Python-Dev mailing list
Python-Dev
R. David Murray writes:
> On Sun, 26 Oct 2014 00:19:44 +0200, Antoine Pitrou
> wrote:
> > My point is that your "Windows build" would not have the same behaviour
> > as a MSVC-produced Windows build, and so testing it with it would not
> > certify that your code would actually be compatible
Tony Kelman writes:
> If potential contributors have a desire to get it working in the
> first place, then they will also be invested in helping keep it
> working on an ongoing basis.
Sure -- as long as it works for them, though, such potential
contributors don't necessarily care if it works f
Tony Kelman writes:
> No, just hearing the words come out of my mouth they sound a little
> nuts. Maybe not, there are after all half a dozen or more
> incompatible alternate Python implementations floating around. I
> think most of them started as from-scratch rewrites rather than
> source
Shorya Raj writes:
> I think it may be prudent to consider adding a Windows specific
> mailing list regarding development on Windows,
One possibly-relevant anecdote. We had such a list for XEmacs, where
the biggest contributor 1998-2005 was Windows-based. *He* preferred
communicating via the
Nick Coghlan writes:
> By contrast, proposals to switch from Mercurial to Git impose a
> *massive* burden on contributors that don't already know git.
Let's not get carried away here. The *massive* burden is the moaning
from git-haters (is there a 12-step program for them?) Agreed,
learning a
Brett Cannon writes:
> How do other projects tend to manage their bugfix vs. in-dev branches?
Emacs uses a similar workflow to Python's current one, AIUI:
1. When feasible, developer decides the lowest applicable branch (in
Emacs there are only two), commits and pushes there.
2. When needed
Ben Finney writes:
> Whether that is a *problem* is a matter of debate, but the fact that
> Git's common workflow commonly discards information that some consider
> valuable, is a simple fact.
It *was* a simple fact in git 0.99. Since the advent of reflogs
(years ago), it is simply false.
Wo
mdcb808 writes:
> These are typically discussed on this list or using the bug
> tracker?
I think this discussion belongs on python-dev because the requirement
is clear, but a full specification involves backward compatibility
with older interfaces, and clearly different people place different
v
Victor Stinner writes:
> *** Now the real question: is it useful to know the inode number
> (st_ino) without the device number (st_dev)? ***
>
> On POSIX, you can still get the st_dev from DirEntry.stat(), but it
> always require a system call. So you loose the whole purpose of
> DirEntry (
Blaxton writes:
> I am having problem building Python RPM on AIX and I think there
> are several bugs in Python .spec files.
This list is for development *of* Python, not development *with*
Python. In this case, you would probably be better off with an AIX
list devoted to packaging, an RPM-spe
Blaxton writes:
> I am using the spec file that comes with Python source code which
> downloaded from python.org website
Ah, sorry, I didn't realize that. My advice still stands; while there
are Red Hat/Fedora/other-RPM-based distro workers here, I don't know
if any of them actually have anyth
Chris Angelico writes:
> I don't mind how long the deprecation period is, as long as there can
> be an option to Python that makes a noisy warning.
If that's OK with you and for the use case you explicitly described,
though, a .bat file that runs a linter first might be the better
option since
Nick Coghlan writes:
> The linter developers don't have a decision making process that lets them
> pursue things like this on their own.
I'm not suggesting that the linter developers do any such thing. I'm
suggesting that users (specifically Chris) customize their preferred
linters (most permi
lou xiao writes:
> I find a bug in str.lstrip, when i call str.lstrip, i get this result.
> >>> a.lstrip('device_')
> 'nfo'
> >>>
Try
a.lstrip('_ecived')
You'll see that you get the same result. I suspect that you
misunderstand the meaning of the argument, which is not a sequence of
c
Eric V. Smith writes:
> Personally, I can't imaging wanting that behavior. I can't say I've ever
> needed additional at all with an IP address, but if I did, it would only
> be to stay within the host portion. To wrap around seems odd.
It's worse than odd. I've occasionally had use for iterat
Yury Selivanov writes:
> To my eye 'async def name()', 'async with', 'async for' look
> better than 'def async name()', 'with async' and 'for async'.
> But that's highly subjective.
I'm with Barry on this one as far as looks go. (But count that as a
+0, since I'm just a literary critic, I don
Literary critic here.
In section "Specification"
> It is strongly suggested that the reader understands how coroutines
> are implemented in Python (PEP 342 and PEP 380). It is also
> recommended to read PEP 3156 (asyncio framework) and PEP 3152
> (Cofunctions).
The usual phrasing of "strong
Yury Selivanov writes:
> Agree. Do you think it'd be better to combine comprehensions
> and async lambdas in one section?
No, I'd keep them separate. For one thing, given Guido's
long-standing lack of enthusiasm for lambda, they'll need to be
separate PEPs.
___
Adam Bartoš writes:
> I am in Windows and my terminal isn't utf-8 at the beginning, but I
> install custom sys.std* objects at runtime and I also install
> custom readline hook,
IIRC, on the Linux console and in an uxterm, PYTHONIOENCODING=utf-8 in
the environment does what you want. (Can't t
Chris Angelico writes:
> It's legal Unicode, but it doesn't mean what he typed in.
Of course, that's obvious. My point is "Welcome to the wild wacky
world of soi-disant 'internationalized' software, where what you see
is what you get regardless of what you type."
Adam Bartoš writes:
> Unfortunately, it doesn't work. With PYTHONIOENCODING=utf-8, the
> sys.std* streams are created with utf-8 encoding (which doesn't
> help on Windows since they still don't use ReadConsoleW and
> WriteConsoleW to communicate with the terminal) and after changing
> the sys
Adam Bartoš writes:
> I'll describe my picture of the situation, which might be terribly wrong.
> On Linux, in a typical situation, we have a UTF-8 terminal,
> PYTHONENIOENCODING=utf-8, GNU readline is used. When the REPL wants input
> from a user the tokenizer calls PyOS_Readline, which calls
Barry Warsaw writes:
> and you would drop into the debugger after foo() but before bar().
> More rationale and details are provided in the PEP:
>
> https://www.python.org/dev/peps/pep-0553/
>
> Unlike David, but like Larry, I have a prototype implementation:
>
> https://github.c
-committers and some individuals dropped from address list.
Nick Coghlan writes:
> Gah, seven years on from Python 2.7's release, I still get caught by
> that. I'm tempted to propose we reverse that decision and go back to
> enabling them by default :P
>
> If app devs don't want their users
Nick Coghlan writes:
> Hence the proposed documentation change: the responsibility for
> silencing these warnings (for both their own code and for their
> dependencies) should rest with *application* developers,
How do you propose to handle users with legacy apps that they can't or
their organ
Ethan Furman writes:
> Suffering from DeprecationWarnings is not "being hosed". Having
> your script/application/framework suddenly stop working because
> nobody noticed something was being deprecated is "being hosed".
OK, so suffering from DeprecationWarnings is not "being hosed".
Neverthele
Paul Moore writes:
> 1. List comprehensions expand into nested for/if statements in the
> "obvious" way - with an empty list created to start and append used to
> add items to it.
>1a. Variables introduced in the comprehension don't "leak" (see below).
> 2. Generator expressions expand in
Greg Ewing writes:
> Consider this:
>
> def g():
>return ((yield i) for i in range(10))
>
> Presumably the yield should turn g into a generator, but...
> then what? My brain is hurting trying to figure out what
> it should do.
I don't understand why you presume that. The ge
Nathaniel Smith writes:
> To make sure I understand, do you actually have a script like this, or
> is this hypothetical?
I have a couple of doctests that assume that pprint will sort by key,
yes. It makes the tests look quite a bit nicer by pprinting the
output, and I get sorting (which matter
Mariatta Wijaya writes:
> I agree it's useful info :)
>
> I went ahead and made a PR [1].
> In my PR, I simply linked to the Format Specification Mini Language[2] from
> f-strings documentation[3].
>
> Not sure about updating PEP 498 at this point..
I don't see any reason not to document
Chris Barker writes:
> Nathaniel Smith has pointed out that eval(pprint(a_dict)) is
> supposed to return the same dict -- so documented behavior may
> already be broken.
Sure, but that's because we put shoes on a snake. Why anybody expects
no impediment to slithering, I don't know!
I underst
Eric Fahlgren writes:
> On Tue, Dec 19, 2017 at 8:47 AM, Stephen J. Turnbull <
> turnbull.stephen...@u.tsukuba.ac.jp> wrote:
>
> > If I were Bach, I'd compose a more-itertools-like module to be named
> > Variations_on_the_F_String. :-)
> >
>
&g
Franklin? Lee writes:
> On Tue, Dec 26, 2017 at 2:01 AM, Yogev Hendel wrote:
> >
> > I don't know if this is the right place to put this,
> > but I've found the following lines of code results in an incredibly long
> > processing time.
> (I think the correct place is python-list. python-dev
Brett Cannon writes:
> I wouldn't characterize it as "big questions". For some people there's a
> question as to how to make them work without type hints, but otherwise how
> they function is settled.
Recently a question has been raised about the decorator overriding
methods defined in the cla
Brett Cannon writes:
> I wouldn't characterize it as "big questions". For some people there's a
> question as to how to make them work without type hints, but otherwise how
> they function is settled.
Recently a question has been raised about the decorator overriding
methods defined in the cla
Christian Heimes writes:
> tl;dr
> This mail is about internationalized domain names and TLS/SSL. It
> doesn't concern you if you live in ASCII-land. Me and a couple of other
> developers like to change the ssl module in a backwards-incompatible way
> to fix IDN support for TLS/SSL.
Yes plea
Ethan Furman writes:
> Good point. So auto-generate a new __repr__ if:
>
> - one is not provided, and
> - existing __repr__ is either:
>- object.__repr__, or
>- a previous dataclass __repr__
-0.5 I'm with Guido here. Just use the simple rule that a new
__repr__ is generated unles
Nathaniel Smith writes:
> Issue 1: Python's built-in IDNA implementation is wrong (implements
> IDNA 2003, not IDNA 2008).
Is "wrong" the right word here? I'll grant you that 2008 is *better*,
but typically in practice versions coexist for years. Ie, is there no
backward compatibility issue w
Chris Barker writes:
> are we only talking about __repr__ here ???
I am, because I haven't thought about the other methods, except to
note I find it hard to imagine a use case *for me* that would require
any of them. That sorta disqualifies me from comment. ;-) I assumed
others were talking ab
Matt Billenstein writes:
> In my mind it becomes easier to bundle deps in a binary installer
> across the board (Linux, OSX, Windows) rather than rely on whatever
> version the operating system provides.
Thing is, as Christian points out, TLS is a rapidly moving target.
Every Mac OS or iOS upd
Barry Warsaw writes:
> My questions are 1) will this become idiomatic enough to be able to
> understand at a glance what is going on,
Is it similar enough to
def f(x=[0]):
which is sometimes seen as a way to produce a mutable default value
for function arguments, to be "idiomatic"?
> ra
Chris Barker writes:
> But I still think the original:
>
> [g(y) for x in range(5) for y in [f(x)]]
>
> Is always going to be confusing to read.
But the point I was making with "def f(x=[0]):" was this: you have a
situation where your desired semantics is "value of some type"[1], but
the l
Michel Desmoulin writes:
> Le 25/02/2018 à 14:11, Nikolaus Rath a écrit :
>>> result = [ (f(x) as y) + g(y) for x in range(10)]
> Honestly I find this version the most readable while the double for
> loop is completely weird to me, despite doing python for a living
> for years.
I find t
Barry Warsaw writes:
> Python 21.12 anyone? :)
Well, for one thing we know that version 42 will be perfect! With
current versioning policy, it will take a loong time to get
there
Steve
--
Associate Professor Division of Policy and Planning Science
http://turnbull/sk.tsu
Christoph Groth writes:
> Wouldn't it be a pity not to liberate assignments from their boring
> statement existence?
Maybe not. While it would be nice to solve the loop-and-a-half
"problem" and the loop variable initialization "problem" (not everyone
agrees these are even problems, especially
Chris Angelico writes:
> There's that word "readability" again. Sometimes I wish the Zen of
> Python didn't use it, because everyone seems to think that "readable"
> means "code I like".
Hey, man, that hurts. Some of us not only *have* precise statements
of the aspects of readability we invok
Tim Peters writes:
> Regardless, Guido has already said "as" is DOA (Dead On Arrival)
> (illustrating that it's also common enough in English to give a short
> name before its long-winded meaning ;-) ).
The parens above are a gloss on a well-known acronym for those who
have not encountered it
Devin Jeanpierre writes:
> Some other programming languages (thinking of Racket) solve this by
> having the debugger let you step through expression evaluation,
> without editing the code.
Good tools are a wonderful thing, and I think pdb should be enhanced
that way (by somebody who has the ti
Chris Angelico writes:
> Additionally, naming sub-parts of a large expression can assist an
> interactive debugger, providing useful display hooks and partial
> results. Without a way to capture sub-expressions inline, this
> would require refactoring of the original code; with assignment
> e
Chris Angelico writes:
> Well, true. The point isn't WHO you're dictating to,
By "period here preferred," I meant I think it's mostly a waste of
space to mention dictation at all in that document. But it's not a
big deal to me, so how about changing "a student or junior programmer"
to "another
Łukasz Langa writes:
> > On 25 Apr, 2018, at 5:20 PM, Chris Angelico wrote:
> You're claiming that `:=` is nicer in this situation because it's less
> prominent than regular assignment and thus doesn't suggest that the name
> stays visible later.
FWIW, I read what he wrote as "*assuming* buf
Steven D'Aprano writes:
> On Wed, Apr 25, 2018 at 09:36:31PM -0500, Ryan Gonzalez wrote:
> > Now, what's the common theme here? **Declarations should be separate from
> > expressions.**
>
> Declarations and assignments are not the same thing.
Ryan mostly meant "initialization" rather than
Tim Peters writes:
> there is absolutely nothing "obvious" about source-control systems,
> or workflows, before you already know them ;-)
Obvious, adj.: More an expletive than a true adjective, shows a state
of mind in which the speaker is comfortable that a statement fits her
preconceptions.
Mark Shannon writes:
> Hello all,
>
> I am pleased to announce that I am accepting PEP 484 (Type Hints).
Congratulations to all concerned!
> Python is your language, please use type-hints responsibly :)
+1 QOTW (not to mention ROTFLMAO)
___
Python
Antoine Pitrou writes:
> For some reason it sounds like we should be altruistic towards
> people who are not :-)
There's always a question of how far to go, of course, but one of the
things I like about this community is the attention the developers
give to others' pain. In that sense, I'm def
Nathaniel Smith writes:
> DVCS back in the day :-). Unfortunately hg makes this a little
> trickier than it could be, because in hg the same commit can't be in
> two different branches; but this just means you have to insert some
> no-op merges, oh well.
Don't use named branches ("friends don
Paul Moore writes:
> In my environments, we frequently have ancient versions of RHEL
> installed, sometimes with no Python at all (IIRC) or nothing better
> than 2.4.
That's pretty advanced as older Red Hat systems go. You're lucky it
isn't 1.5.2!
Getting serious, Red Hat systems have includ
Antoine Pitrou writes:
> On Sat, 30 May 2015 01:49:10 +0200
> Christian Heimes wrote:
> > For performance patches we have to consider our responsibility for the
> > environment. Every improvement means more speed and less power
> > consumption. Python runs of hundreds of thousands of machines
Antoine Pitrou writes:
> > In a community of volunteers, ideology is typically a great
> > motivator.
>
> If and only everyone agrees on it.
That, my friend, is *your* ideology speaking. Some people work on
open source to scratch technical itches -- the program doesn't do what
they want, th
Florian Bruhin writes:
> I think a big issue here is the lack of good newcomer tutorials for
> Python 3.
My business students (who are hardly advanced programmers) don't take
tutorials seriously. They're way too focused on getting results. And
there it's the "Doing with Python" books that
ar
Rustom Mody writes:
> Can submit a bug-report if it looks ok
Thanks for the post. IMO this should have gone directly to the
tracker because (1) you have some support for the idea that at least
some of these are unintentional, and therefore candidates for
alignment with the rest of the code, (2)
Private, since it doesn't really have anything to do with evaluating
actual content. FYI, this thread probably should have stayed on
core-mentorship for a bit and then jumped directly to the tracker.
Rustom Mody writes:
> > because (1) you have some support for the idea that at least
> > some
Cross-posted to redirect discussion. Replies directed to Python-Ideas.
Erik Bray writes on Python-Dev:
> On Mon, Jul 6, 2015 at 6:21 AM, Antoine Pitrou wrote:
> > On Mon, 6 Jul 2015 14:22:46 +1000, Nick Coghlan wrote:
> >>
> >> The main change from the last version discussed on python-ideas
Nick Coghlan writes:
> I wonder: should we start putting some of these process details for
> the different phases in the release PEPs themselves? Larry sent a good
> summary to python-committers for 3.5 a while back, but they'd be
> easier to find in the PEPs, and it would also make it clear w
Robert Collins writes:
> What I am doing is rejecting the argument that because we can't fix
> every mis-use users might make, we therefore should not fix the cases
> where we can fix it.
This involves a value judgment, every time a new fix is proposed, as
to whether it's a mis-use that deserv
Robert Collins writes:
> I rejected an argument that just because some APIs are are
> intrinsically able to be misused, that we should not try to write
> better APIs.
Well, at least to me what you wrote was inconsistent with that
explanation of what you wanted to express:
>> What I am doing
Antoine Pitrou writes:
> Frankly, this kind of inept discussion,
I think you misunderstand what's going on. The people who advocate
removal of a gratuitous special case may lack your perspective, but
they're not incompetent to understand it. Specifically, you have a
senior committer's perspect
s.krah writes:
> I don't think growing committer numbers is CPython's #1 problem.
Maybe not; not being a committer I don't have a strong opinion myself.
However, committers, and especially the group qualified for the BD1P
role, regularly post wishes for more senior developers to these lists.
>
s.krah writes:
> Sorry, that amounts to twisting my words.
Let's not play the dozens here. That just extends the thread to no
point.
> It would be a great loss if he really stops and I hope he'll
> reconsider.
I agree with both points. I don't think anybody disagrees, so let's
not belabor
Terry Reedy writes:
> Good (or certainly much better): this blank>
I think so too, but IMO Nick and Antoine made a serious mistake by
deprecating this as a "minor design decision" without further
rationale. That's no excuse at all! The point of the Zen about
"special cases" is that these mino
Ben Finney writes:
> Definitely agreed, and I'm not implying otherwise.
>
> There is a distinction to be drawn:
>
> * If challenged to do so, could one (the contributor) present a
> compelling justification for the change?
Aside from Paul's disclaimer, this is way too high a bar. Nick
Nick Coghlan writes:
> The draining and demotivating cases are the ones where *no new
> information is introduced*, but the design decision is *challenged
> anyway*.
But this particular thread is an extreme case, that demonstrates why
this kind of thing happens *despite* the good intentions of
Paul Moore writes:
> On 27 July 2015 at 15:57, Ronald Oussoren wrote:
> > IMHO “+ 1 days” and “+ 24 hours” are two different things. Date
> > arithmetic is full of messy things like that. “+ 1 month” is another
> > example of that (which the datetime module punts completely
> > and can be
Terry Reedy writes:
> On 7/27/2015 11:21 AM, MRAB wrote:
>
> > Also, if you "add one year" to 29 February 2016, what date do you get?
>
> I believe the 'conventional' answer is 1 March 2017. That is also 1 Mar
> 2016 + 1 year. 1 March 2017 - 1 year would be 1 Mar 2016. Leap days
> get
Tres Seaver writes:
> - From a human's perspective, "a day from now" is always potentially
> unambigous, just like "a month from now" or "a year from now", whereas
> "24 hours from now" is never so.
I gather you've never been a prof who told a student with aggravated
"writer's block" she had 2
Ben Finney writes:
> I've made a clear distinction between the need to *be able to*
> justify a change, versus arbitrary demands to do so by arbitrary
> members.
>
> The latter is what you're arguing against, and of course I agree. I've
> never advocated that.
Sure, but the former, when st
Xavier de Gaye writes:
> > Here's a query:
> >
> > https://bugs.python.org/issue?@action=search&@columns=title,id,creator,activity,actor,status&@sort=activity&status=-1,1,3,4&message_count=1
> >
>
> This is nice, thanks.
> Note that this is missing the cases where more than one message was
Barry Warsaw writes:
> Besides, any expression you have to calculate can go in a local
> that will get interpolated.
Sure, but that style should be an application programmer choice.
If this syntax can't replace the vast majority of cases where the
format method is invoked on a literal string w
Barry Warsaw writes:
> On Aug 17, 2015, at 11:02 AM, Paul Moore wrote:
>
> >print(f"Iteration {n}: Took {end-start) seconds")
>
> This illustrates (more) problems I have with arbitrary expressions.
>
> First, you've actually made a typo there; it should be
> "{end-start}" -- notice
R. David Murray writes:
> On Tue, 08 Sep 2015 10:12:37 -0400, Gary Robinson wrote:
> > 2) Have a mode where a particular data structure is not reference
> > counted or garbage collected.
>
> This sounds kind of like what Trent did in PyParallel (in a more generic
> way).
Except Gary has a
Augie Fackler writes:
> There is no sacrifice [for git users moving to Mercurial] other
> than familiarity--and because Mercurial indeed has as simpler UI,
> closing the familiarity gap from Git to Mercurial is much easier
> than the other way around.
AFAIK it is still much easier to do the k
Nikolaus Rath writes:
> Hmm, that's odd. As far as I know, the difference between the hg and git
> DAG model can be summarized like this:
>
> * In git, leaves of the DAG must be assigned a name. If they don't have
>a name, they will be garbage collected.
You can turn off automatic garb
Nikolaus Rath writes:
> >> * hg named branches have no equivalent in git.
> >>
> >> Does that help?
> >
> > Well, that last bullet kind of complicates the model, doesn't it? :)
>
> Not if you come from git and want to use hg. You can just ignore
> bookmarks.
No, you cannot just ignor
Nikolaus Rath writes:
> On Sep 17 2015, "Stephen J. Turnbull" wrote:
> > Nikolaus Rath writes:
> >
> > > Hmm, that's odd. As far as I know, the difference between the hg and git
> > > DAG model can be summarized like this:
> > >
Barry Warsaw writes:
> One thing that came up in a similar discussion is pip, and the
> suggested move to `python -m pip`, which makes a lot of sense.
> However, *inside* a virtualenv, there's no ambiguity about the
> Python version associated with direct `pip` invocation, so it still
> makes
Mark Lawrence writes:
> I agree very strongly with your point here. Raising umpteen issues
> over installation failures when a full release comes out strikes me
> as below the belt when there have been multiple previous releases
> without a squeak.
Raising issues is always useful and appropr
Terry Reedy writes:
> Am I correct in guessing that on Windows, at least, R and Emacs do *not*
> run in Command Prompt?
I'm not sure what you mean by that. Of course they do run under
Command Prompt, but the limitations of the command window are so
severe that almost nobody ever does that, th
Chris Barker - NOAA Federal writes:
> Laura Creighton writes:
> > I merely worry about what happens if people
> > start relying upon the fact that a float annotation 'will handle all
> > the numbers I care about' to the forgotten Decimal users such as
> > myself.
>
> Well, that's what you
Laura Creighton writes:
> [W]hat I expect the type annotations to be used for, especially in
> the SciPy world, is to make things easier for Numba to generate
> fast code.
I don't understand why that's a problem. *You* run mypy, and *you*
decide whether to do anything about its warnings. The
Steve Dower writes:
> Saying [UTF-16] is rarely used is rather exposing your own
> unawareness though - it could arguably be the most commonly used
> encoding (depending on how you define "used").
Because we're discussing the storage of .py files, the relevant
definition is the one used by the
Laura Creighton writes:
> Steve Turnbull, who lives in Japan, and speaks and writes Japanese
> is saying that "he cannot see any reason for allowing non-ASCII
> compatible encodings in Cpython".
>
> This makes me wonder.
>
> Is this along the lines of 'even in Japan we do not want such
>
Random832 writes:
> "Stephen J. Turnbull" writes:
> > I don't see any good reason for allowing non-ASCII-compatible
> > encodings in the reference CPython interpreter.
>
> There might be a case for having the tokenizer not care about encodings
>
Stewart, David C writes:
> Note: PGO is not the default way to build Python because it is
> relatively slow to compile it that way. (I think it should be the
> default).
+1
Slow-build-fast-run should be the default if you're sure the
optimization works. Only developers are likely to run a gi
101 - 200 of 1553 matches
Mail list logo
