Andreas Maier writes:
> The problem of the default implementation is that "x is not y"
> implies "x != y" and that may or may not be true under a sensible
> definition of equality.
I noticed this a long time ago and just decided it was covered by
"consenting adults". That is, if the "sensible
Andreas Maier writes:
> A class designer can directly implement what equality means to the
> class, but he or she cannot implement an accessor method for the
> value.
Of course she can! What you mean to say, I think, is that Python does
not insist on an accessor method for the value. Ie, the
Ethan Furman writes:
> And what would be this 'sensible definition' [of value equality]?
I think that's the wrong question. I suppose Andreas's point is that
when the programmer doesn't provide a definition, there is no such
thing as a "sensible definition" to default to. I disagree, but given
Rob Cliffe writes:
> > Why? What value (pun intended) is there in adding an explicit statement
> > of value to every single class?
> It troubles me a bit that "value" seems to be a fuzzy concept - it has
> an obvious meaning for some types (int, float, list etc.) but for
> callable objects
Chris Angelico writes:
> The reason NaN isn't equal to itself is because there are X bit
> patterns representing NaN, but an infinite number of possible
> non-numbers that could result from a calculation.
I understand that. But you're missing at least two alternatives that
involve raising on
Steven D'Aprano writes:
> I don't think so. Floating point == represents *numeric* equality,
There is no such thing as floating point == in Python. You can apply
== to two floating point numbers, but == (at the language level)
handles any two numbers, as well as pairs of things that aren't
numb
Alexander Belopolsky writes:
> Why have builtin sum at all if its use comes with so many caveats?
Because we already have it. If the caveats had been known when it was
introduced, maybe it wouldn't have been. The question is whether you
can convince python-dev that it's worth changing the defi
Alexander Belopolsky writes:
> On Sat, Aug 9, 2014 at 3:08 AM, Stephen J. Turnbull
> wrote:
>
> > All the suggestions
> > I've seen so far are (IMHO, YMMV) just as ugly as the present
> > situation.
> >
>
> What is ugly about allowing strings
Chris Angelico writes:
> The justification is illogical. However, I personally believe
> boilerplate should be omitted where possible;
But it mostly can't be omitted. I wrote 22 classes (all trivial)
yesterday for a Python 3 program. Not one derived directly from
object. That's a bit unusual
Glenn Linderman writes:
> On 8/10/2014 1:24 AM, Stephen J. Turnbull wrote:
> > Actually ... if I were a fan of the "".join() idiom, I'd seriously
> > propose 0.sum(numeric_iterable) as the RightThang{tm]. Then we could
> > deprecate "".join(strin
Chris Barker - NOAA Federal writes:
> Is there anything in the language spec that says string concatenation is
> O(n^2)? Or for that matter any of the performs characteristics of build in
> types? Those striker as implementation details that SHOULD be particular to
> the implementation.
Conta
Ethan Furman writes:
> On 08/11/2014 08:50 PM, Stephen J. Turnbull wrote:
> > Chris Barker - NOAA Federal writes:
> >
> >> It seems pretty pedantic to say: we could make this work well,
> >> but we'd rather chide you for not knowing the "proper"
Redirecting to python-ideas, so trimming less than I might.
Chris Barker writes:
> On Mon, Aug 11, 2014 at 11:07 PM, Stephen J. Turnbull
> wrote:
>
> > I'm referring to removing the unnecessary information that there's a
> > better way to do it, and simply
Ben Hoyt writes:
> Fair enough. I don't quite understand, though -- why is the "official
> policy" to kill something that's "essential" on *nix?
They're not essential on *nix. Unix paths at the OS level are "just
bytes" (even on Mac, although the most common Mac filesystem does
enforce UTF-8 U
Greg Ewing writes:
> Stephen J. Turnbull wrote:
>
> > This case can be handled now using the surrogateescape
> > error handler,
>
> So maybe the way to make bytes paths go away is to always
> use surrogateescape for paths on unix?
Backward compatibility
Guido van Rossum writes:
> On Tuesday, August 19, 2014, Stephen J. Turnbull wrote:
> > Greg Ewing writes:
> > > So maybe the way to make bytes paths go away is to always
> > > use surrogateescape for paths on unix?
> >
> > Backward compatibilit
Marko Rauhamaa writes:
> Unix programmers, though, shouldn't be shielded from bytes.
Nobody's trying to do that. But Python users should be shielded from
Unix programmers.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailm
Nick Coghlan writes:
> One idea I had along those lines is a surrogatereplace error handler (
> http://bugs.python.org/issue22016) that emitted an ASCII question mark for
> each smuggled byte, rather than propagating the encoding problem.
Please, don't.
"Smuggled bytes" are not independent ev
Marko Rauhamaa writes:
> My point is that the poor programmer cannot ignore the possibility of
> "funny" character sets.
*Poor* programmers do it all the time. That's why Python codecs raise
when they encounter bytes they can't handle.
> If Python tried to protect the programmer from that po
Chris Barker - NOAA Federal writes:
> This brings up the other key problem. If file names are (almost)
> arbitrary bytes, how do you write one to/read one from a text file
> with a particular encoding? ( or for that matter display it on a
> terminal)
"Very carefully."
But this is strictly fr
Chris Barker writes:
> > The third is to specify the UTF-8 with the surrogate escape error
> > handler. This allows non-UTF-8 codes to be loaded into
> > memory.
Read as bytes and incrementally decode. If you hit an Exception,
retry from that point.
> Just so I'm clear here -- if you write
Chris Angelico writes:
> Not sure why 1251,
All of those codes have repertoires that are Cyrillic supersets,
presumably Russian-language content, based on Oleg's top domain.
> But it's important to note that this is a method of handling junk.
> It's not a design intention; this is for a situa
Chris Barker writes:
> So I write bytes that are encoded one way into a text file that's encoded
> another way, and expect to be abel to read that later?
No, not you. Crap software does that. Your MUD server. Oleg's
favorite web pages with ads, or more likely the ad servers.
> Not for me (
Oleg Broytman writes:
>This is the core of the problem. Python2 favors Unix model but
> Windows people pays the price. Python3 reverses that
This is certainly not true. What is true is that Python 3 makes no
attempt to make it easy to write crappy software in the old Unix
style, that break
Nick Coghlan writes:
> "purge_surrogate_escapes" was the other term that occurred to me.
"purge" suggests removal, not replacement. That may be useful too.
neutralize_surrogate_escapes(s, remove=False, replacement='\uFFFD')
maybe? (Of course the remove argument is feature creep, so I'm only
R. David Murray writes:
> Also, as has been discussed in this thread previously, any program that
> deals with filenames is dealing with human readable languages, even
> if posix itself treats the filenames as bytes.
That's a bit extreme. I can name two interesting applications
offhand: git's
Isaac Morland writes:
> I like your way of putting this - "straight face" indeed. The third
> option really is a hack to allow working around nonsensical situations
> (and even the META tag is pretty questionable). All this complexity
> because people can't be bothered to do things proper
Nikolaus Rath writes:
> In that case, maybe it'd be nice to also explain why you use the
> term "bilingual" for codepage based encoding.
Modern computing systems are written in languages which are invariably
based on syntax expressed using ASCII, and provide by default
functionality for express
Glenn Linderman writes:
> On 8/26/2014 4:31 AM, MRAB wrote:
> > On 2014-08-26 03:11, Stephen J. Turnbull wrote:
> >> Nick Coghlan writes:
> > How about:
> >
> > replace_surrogate_escapes(s, replacement='\uFFFD')
> >
> >
Glenn Linderman writes:
> On 8/27/2014 5:16 AM, Nick Coghlan wrote:
> > Choosing UTF-8 aims to treat formatting text for communication with
> > the user as "just a display issue". It's a low impact design that will
> > "just work" for a lot of software, but it comes at a price:
> >
> > *
Glenn Linderman writes:
> On 8/27/2014 6:08 PM, Stephen J. Turnbull wrote:
> > Glenn Linderman writes:
> > > And further, replacement could be a vector of 128 characters, to do
> > > immediate transcoding,
> >
> > Using what encoding?
>
Nick Coghlan writes:
> The current proposal on the issue tracker is to instead take advantage of
> the existing error handlers:
>
> def convert_surrogateescape(data, errors='replace'):
> return data.encode('utf-8', 'surrogateescape').decode('utf-8',
> errors)
>
> That code i
In the process of booking up for my other post in this thread, I
noticed the 'surrogatepass' handler.
Is there a real use case for the 'surrogatepass' error handler? It
seems like a horrible break in the abstraction. IMHO, if there's a
need, the application should handle this. Python shouldn't
Greg Ewing writes:
> M.-A. Lemburg wrote:
> > we needed
> > a way to make sure that Python 3 also optionally supports working
> > with lone surrogates in such UTF-8 streams (nowadays called CESU-8:
> > http://en.wikipedia.org/wiki/CESU-8).
Besides what Greg says, CESU-8 is an UTF, and therefo
mar...@v.loewis.de writes:
> BTW, it's patented:
>
> http://www.google.de/patents/US6816900
Damn them. I hope they never get a look at my crontab.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-d
Antoine Pitrou writes:
> On Tue, 2 Sep 2014 16:47:35 -0700
> Glyph Lefkowitz wrote:
> > As we keep saying, this is not a break in backwards
> > compatibility, it's a bug fix.
>
> Keeping saying it doesn't make it magically true.
It's not "magically" true, it is "just" true. What the hard
Nick Coghlan writes:
> Sorry, I haven't been a very good maintainer for that buildbot (the main
> reason it never graduated to the "stable" list). If you send me your public
> SSH key, I can add it (I think - if not, I can ask Luke to do it).
> Alternatively, CentOS 6 may exhibit the same prob
Guido van Rossum writes:
> lot: five years ago (when I worked at Google!) it was common to find
> internal services that required SSL but had a misconfigured certificate,
> and the only way to access those services was to override the browser
> complaints. Today (working at Dropbox, a much sma
Glenn Linderman writes:
> Well, this thread seems to be top-posted so...
Not a good enough reason for me!
> Why not provide _urlopen_with_scary_keyword_parameter as the
> monkey-patch option?
>
> So after the (global to the module) monkeypatch, they would _still_ have
> to add the k
Jeff Allen writes:
> A welcome article. One correction should be made, I believe: the area of
> code point space used for the smuggling of bytes under PEP-383 is not a
> "Unicode Private Use Area", but a portion of the trailing surrogate
> range.
Nice catch. Note that the surrogate range
Jeff Allen writes:
> Simply having a block "for private use" seems to create an unmanaged
> space for conflict,
No. The uncharted range of human language (including recently-
invented nonsense like "emoticons" and the annual "design a character"
contest run by a newpaper in Taipei, with the g
Jim J. Jewett writes:
> In terms of best-effort, it is reasonable to treat the smuggled bytes
> as representing a character outside of your unicode repertoire
I have to disagree. If you ever end up passing them to something that
validates or tries to reencode them without surrogateescape, BOOM
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
1 - 100 of 1495 matches
Mail list logo
