R. David Murray writes:
> On Tue, 23 Apr 2013 22:29:33 +0900, "Stephen J. Turnbull"
> wrote:
> > R. David Murray writes:
> >
> > > You transform *into* the encoding, and untransform *out* of the
> > > encoding. Do you have an example wh
R. David Murray writes:
> > I think you're completely missing my point here. The problem is that
> > in the cases I mention, what is encoded data and what is decoded data
> > can only be decided by asking the user.
>
> I think I understood that. I don't understand why that's a
> problem.
Greg Ewing writes:
> Web developers might grumble about the need for an extra call,
> but they can no longer claim it would kill the performance of
> their web server.
Of course they can. There never was any performance measurement that
supported that claim in the first place. I don't see ho
Terry Jan Reedy writes:
> .transform should be explicit and always take two args, no implicit
> defaults, the 'from form' and the 'to' form. They can labelled by
> position in the natural order (from, to)
Not natural to escaped-from-C programmers, though. I hesitate to say
"make it keywor
Tres Seaver writes:
> On 04/23/2013 09:29 AM, Stephen J. Turnbull wrote:
> > By RFC specification, BASE64 is a *textual* representation of
> > arbitrary binary data.
>
> It isn't "text" in the sense Py3k means:
RFC 4648 repeatedly refers to *characters*
Lennart Regebro writes:
> Base64 is an encoding that transforms between 8-bit streams. Let it be
> that. Don't try to shoehorn it into a completely different kind of
> encoding.
By "completely different kind of encoding" do you mean "codec"?
I think that would be an unfortunate result. These
Lennart Regebro writes:
> On Thu, Apr 25, 2013 at 4:22 PM, MRAB wrote:
> > The JSON specification says that it's text. Its string literals can
> > contain Unicode codepoints. It needs to be encoded to bytes for
> > transmission and storage, but JSON itself is not a bytestring format.
>
> OK
MRAB writes:
> RFC 4648 says """Base encoding of data is used in many situations to
> store or transfer data in environments that, perhaps for legacy reasons,
> are restricted to US-ASCII [1] data.""".
>
> To me, "US-ASCII" is an encoding, so it appears to be talking about
> encoding bina
Steven D'Aprano writes:
> >>- should an enum item be selectable via __call__ instead of __getitem__
> >> (i.e. Seasons(3) is AUTUMN)
> >
> > No opinion.
>
> Does anyone know why this is even an issue? Is this pure
> bike-shedding over the API, or are there technical reasons for
> choo
Ethan Furman writes:
> I would hope that you would pay more attention to my arguments and
> rationale than to poorly chosen names.
I do. Nevertheless, it requires conscious effort. It's quite
appropriate for you to ask that of me, but ... do you think you're
doing Python any good to ask more
Steven D'Aprano writes:
> > Rather than risk obscure bugs, I would suggest restricting the extensions
> > to 3 characters. For the “Windowed Python ZIP Applications” case, could we
> > use .pzw as the extension instead of .pyzw?
+0
> Many official Microsoft file extensions are four or more l
Steven D'Aprano writes:
> > Give us a non-MS example, please.
> I'm afraid I don't understand your question.
There were two problems mentioned. Paul worries about 4-letter
extensions under PowerShell. You mentioned conflicts in Linux file
managers. In both cases, a bug on Windows in detecti
Ethan Furman writes:
> I will certainly ask for advice on which modules to spend my time
> on. I know enums are not a cure-all, but they are great for
> debugging and interactive work.
Especially in new code where they are used throughout. Not so in the
existing stdlib, I expect.
The concre
Raymond Hettinger writes:
> whether users will see any actual benefits (particularly for
> internal constants).
I don't understand the parenthetical remark. It seems to me that
changing internal constants should have the benefits that Ethan points
to for understanding, debugging, and interacti
Gregory P. Smith writes:
> I really do applaud the goal of keeping examples in documentation up to
> date. But doctest as it is today is the wrong approach to that. A repr
> mismatch does not mean the example is out of date.
Of course it does. The user sees something in the doc that's
differ
Nick Coghlan writes:
> threading module) and decided the cost/benefit ratio was too low to
> justify ever doing that again.
I think you just failed Econ 101, Nick.
I-teach-that-s**t-for-a-living-ly y'rs,
P.S. Of course we all understood what you meant. :-)
Ethan Furman writes:
> Enumerations can be pickled and unpickled::
>
> >>> from enum import Enum
> >>> class Fruit(Enum):
> ... tomato = 1
> ... banana = 2
> ... cherry = 3
> ...
> >>> from pickle import dumps, loads
> >>> Fruit.tomato
Serhiy Storchaka writes:
> 08.06.13 11:23, Benjamin Peterson написав(ла):
> > 2013/6/8 Serhiy Storchaka :
> >> Here is attached a list of obsoleted RFCs referred in the *.rst,
> >> *.txt, *.py, *.c and *.h files. I think it would be worthwhile
> >> to update the source code and documentation f
Gustavo Carneiro writes:
> On Fri, Jun 21, 2013 at 8:20 PM, Steven D'Aprano wrote:
>> -1 Reading the Python source code is a very good way for beginner
>> programmers to learn about things like this.
> On the other hand, it is counter-productive to learn about code
> that is conceptually _
Victor Stinner writes:
> In my opinion, make distclean should only remove files generated by
> configure and a build. It should not remove random files.
FWIW, the GNU standard for these targets is something like:
## make clean or make mostlyclean
## Delete all files from the current dir
Terry Reedy writes:
> Ok, I won't add them when a function's name actually makes what it does
> obvious. But when I have to spend at least a few minutes reading the
> body to make sense of it, I will try to add the summary line that I wish
> had been there already.
+1 That's a *great* rul
Steve Dower writes:
> I don't see any good reason for Python to support an OS that
> Microsoft doesn't,
How about the *users* of that OS?
I don't see any good reason to take into account what Microsoft does
or doesn't support. If that lack of support leads to Python users
dropping XP like hot
Ben Finney writes:
> "Stephen J. Turnbull" writes:
>
> > I don't see any good reason to take into account what Microsoft does
> > or doesn't support.
>
> It seems you're advocating a position quite ad odds with
> http://www.python.
Nick Coghlan writes:
>> Of course private modules are sane. I never suggested "no new private
>> modules at all". But putting them in the same namespace as public
>> modules is not, just to save a leading underscore in the file name.
> It's not to save a leading underscore - it's to avoid ren
Guido van Rossum writes:
> And I still think that any return type for group() except bytes or str
> is wrong. (Except possibly a subclass of these.)
I'm not sure I understand. Do you mean in the context of the match
object API, where constructing "(target, match.start(), match.end())"
to get a
Guido van Rossum writes:
> I'm not sure I understand you. :-(
My apologies. This:
> > Or is this something deeper, that a group *is* a new object in
> > principle?
>
> No, I just think of it as returning "a string" and I think it's most
> useful if that is always an immutable object, eve
Terry Reedy writes:
> On 7/15/2013 10:20 PM, Guido van Rossum wrote:
>
> >> Or is this something deeper, that a group *is* a new object in
> >> principle?
> >
> > No, I just think of it as returning "a string"
>
> That is exactly what the doc says it does. See my other post.
The problem
Terry Reedy writes:
> > "stringish"
>
> This word is an adjective, not a noun.
Ah, a strict grammarian. That trumps any cards I could possibly play.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pytho
Chris Angelico writes:
> On Thu, Aug 1, 2013 at 5:58 PM, Alexander Shorin wrote:
> > fun = lambda i: i[1]
> > for key, items in groupby(sorted(items, key=fun), key=fun):
> > print(key, ':', list(items))
>
> I'd do a direct translation to def here:
>
> def fun(i): return i[1]
> for key
Nick Coghlan writes:
> On 7 August 2013 05:26, Antoine Pitrou wrote:
> > I would like to point out that we currently fail at handling GSoC
> > projects and bringing them to completion.
>
> Agreed.
I have no opinion on that statement, having not looked at the
projects.
> > What didn't pro
R. David Murray writes:
> It is the *change itself* that causes
> action to be needed. If a project has a policy of dealing with deprecated
> features when the warnings happen, then they need to do that work before
> the version where the feature is removed is released. If they have
> a pol
Eli Bendersky writes:
> I'm strongly opposed to reverting [the change to ElementTree]
> because it cleaned up messy code duplication and actually make the
> code size smaller. While I agree that the API of incremental parsing
> should be given another look, IncrementalParser can also be seen a
Eli Bendersky writes:
> On Sat, Aug 24, 2013 at 5:55 PM, Stephen J. Turnbull
> wrote:
>> FWIW, as somebody who can recall using ET exactly once,
>> IncrementalParser is what I used.
> Just to be on the safe side, I want to make sure that you indeed
> mean Incr
R. David Murray writes:
> But I would certainly appreciate review from anyone so moved, since I
> haven't gotten any yet.
I'll try to make time for a serious (but obviously partial) review by
Monday.
I don't know if this is "serious" bikeshedding, but I have a comment
or two on the example:
Steven D'Aprano writes:
> which may explain why Stephen Turnbull's reply contains mojibake.
Nah. It was already there, I just copied it. Could be my MUA's
fault, though; I've tweaked it for Japanese, and it doesn't
R. David Murray writes:
> Full validation is something that is currently a "future
> objective".
I didn't mean it to be anything else. :-)
> There's infrastructure to do it, but not all of the necessary knowledge
> has been coded in yet.
Well, I assume you already know that there's no way t
This is getting off-topic IMO; we should probably take this thread to
email-sig.
Glenn Linderman writes:
> I recall being surprised when first seeing messages generated by
> Apple Mail software, that are multipart/related, having a sequence
> of intermixed text/plain and image/jpeg parts. This
> Glenn writes:
> > Steve writes:
>> OTOH, if the message is structured
>>
>> multipart/related
>> multipart/alternative
>> text/plain
>> text/html
>> image/png
>> image/png
>>
>> the receiver can infer that the images are related t
R. David Murray writes:
> I'm still not understanding how the text/plain part *refers* to the
> related parts.
Like this: "Check out this picture of my dog!" Or this: "The terms of
the contract are found in the attached PDF. Please print it and sign
it, then return it by carrier pigeon (attac
R. David Murray writes:
> I meant "a text/plain root part *inside* a multipart/alternative", which
> is what you said, I just didn't understand it at first :) Although I
> wonder how many GUI MUAs do the fallback to multipart/mixed with just a
> normal text/plain root part, too. I would expe
Barry Warsaw writes:
> On Sep 06, 2013, at 12:36 AM, Oleg Broytman wrote:
> > You cannot login using OpenID to most interesting popular sites.
> >GMail? No. Twitter? No. Facebook? FriendFeed? identi.ca? No, no, no.
>
> I'd be surprised if you ever saw the big social networking sites support
Antoine Pitrou writes:
> http://blogs.msdn.com/b/oldnewthing/archive/2012/09/07/10347136.aspx
That was worth it just for the comment from Australia!
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
U
Guido van Rossum writes:
> On Sun, Sep 8, 2013 at 1:48 PM, Oscar Benjamin
> wrote:
> > On 8 September 2013 18:32, Guido van Rossum wrote:
> >> Going over the open issues:
> >>
> >> - Parallel arrays or arrays of tuples? I think the API should require
> >> an array of tuples. It is trivial
Antoine Pitrou writes:
> ExitStack was quite a new thing, API-wise. The proposal here is to
> generalize something which already exists in various forms all over the
> Internet, and respecting a well-known API, MutableMapping.
What Nick said was "I was too close to the design, and time and a v
As will become evident, I disagree with Steven at almost every point.
However, I think his point about users not reading documentation is
well-taken. Due to hyperlinking, users are very likely to skip past
module docstrings. I suggest two (perhaps informal) additions to the
documentation policy i
Terry Reedy writes:
> On 9/16/2013 4:14 PM, R. David Murray wrote:
>
> > Well, we tend to avoid single boolean arguments in favor of differently
> > named functions.
>
> The stdlib has lots of boolean arguments. My impression is that they are
> to be avoided when they would change the ret
Skip Montanaro writes:
> I suspect other Mac users stuck on Snow Leopard who are not Python
> developers would rue the lack of binary installers more than me.
Perhaps, but if Python current as of now isn't good enough for someone
for the foreseeable future, aren't they going to want up-to-date
Skip Montanaro writes:
> > That's why I get my Python (for Snow Leopard) from MacPorts.
>
> Unless things have changed, that probably doesn't support Mac-specific
> stuff, does it?
You mean in the Python port or in general? MacPorts supports
Mac-specific APIs in a number of ports where upst
Eli Bendersky writes:
> IMHO the right way to think about it is that the .rst files are by
> far the more important documentation. Sometimes we forget that
> most Python programmers are people who won't go into the source
Why "source"? The whole point of docstrings is that they are *not*
com
Guido van Rossum writes:
> On Sun, Sep 22, 2013 at 5:31 PM, Steven D'Aprano wrote:
>> My own preference is to err on the side of too much rather than
>> too little, since I live by help() and only fall back on the web
>> documentation when I really must.
> I guess preferences differ.
Indee
Guido van Rossum writes:
> On Mon, Sep 23, 2013 at 8:17 AM, Zero Piraeus wrote:
>> On Mon, Sep 23, 2013 at 09:45:46AM -0400, Chris Lambacher wrote:
>>> [...] An example of how this will be used in practice is:>
>>> {% if object.state == object.state.completed %}
>>> some html
>>>
MRAB writes:
> > The word doesn't literally mean the exception itself was unraisable. It
> > means it was raised, we caught it and we're writing it to stderr because
> > we *can't raise it again*.
> Ah, you mean "unreraisable". :-)
+1
Ugly as sin, but satisfies all other criteria (except fo
Donald Stufft writes:
> On Sep 25, 2013, at 7:04 PM, Barry Warsaw wrote:
>
> > So, why shouldn't we add enum to the Python 2.7 stdlib? Or any
> > other new feature? Just be aware that if this PEP is accepted
> > for Python 2.7, the bar will be set much lower for other Really
> > Useful F
Nick Coghlan writes:
> I'm not sure what usage model you're assuming for _ensurepip, but it
> appears to be wrong. End users should be able to just run pip, and
> either have it work, or else get a message from the OS vendor telling
> them to install the appropriate system package.
I don't un
Paul Moore writes:
> I can't speak for Linux distros or OSX users, but for Windows I do
> believe that this is a significant improvement,
Nobody doubts this.
> and worth the (IMO, negligible) risk involved in adding this to a
> maintenance release.
Doesn't that argument apply equally well t
Nick Coghlan writes:
> You have confirmed my belief that your model is incorrect.
*shrug* I just think the risks are higher than acknowledged (just
because you have so far failed to imagine a problem doesn't mean it
won't appear), and that the meta effect that "Even Guido admits that
Python 3 i
张佩佩 writes:
> If we can overloading these operators, why we can't overloading
> other operators? (like .* often used in matrix, U in set
> operation)
AIUI, it's considered unpythonic. Operators are considered to be part
of the *syntax* of Python, unlike Haskell, where infix syntax can be
use
Nick Efford writes:
> Widely-used and linked web resources tend to persist for a very
> long time, so we shouldn't use the prevalence of Python 2 resources
> as a reason for excessive caution. The key question is how much
> good material is available based on Python 3 - and this has improved
Stefan Behnel writes:
> Hi, I'm looking back on a rather unpleasant experience that I
> recently had in this developer community. Actually, twice by
> now. Here's what I take from it: You should take responsibility for
> your commits.
I have no clue who you're addressing this advice to. If i
Nick Coghlan writes:
> I suspect "list" may have been the intended comparison there.
> "array.array" is another appropriate comparison. Having bytearray
> operations differ in algorithmic complexity from those two types
> would be very strange and surprising
I don't see why. If you really w
Amer writes:
> Hello,
>
> I would like to thank you for your great effort
> I have this question:
>
> I want to do the following IP address style in python
>
> ANY.45.10.ANY
> ANY.x.y.z
This list is for developing the Python language itself (including the
CPython interpreter and the st
Nick Coghlan writes:
> (RDM is also right that the exception still has the effect of
> terminating the block early, but I view names as mnemonics rather
> than necessarily 100% accurate descriptions of things).
This is just way too ambiguous for my taste. I can't help reading
with contex
Victor Stinner writes:
Quoting someone else:
>> For that matter, what names would you give to the myriad unicode
>> peps?
For what value of "you"? ISTM that's important.
> Let me try to name PEPs related to Unicode:
Of the ones you suggest, the only one that rings bells for me is
"surrogat
Cameron Simpson writes:
> But we've got "ignore" in play already. Can't we accept that it is
> somewhat evocative though clearly not perfect for everyone, and
> move on?
No, that is *way* out. We can overrule the objections, recognizing
that sometimes compromise is the worst of the four possi
Victor Stinner writes:
> the idea), but I don't understand the purpose of adding a new syntax
> doing exactly the same than try/except:
>
> > with trap(OSError) as cm:
> > os.unlink('missing.txt')
> > if cm.exc:
> > do_something()
>
> Nobody noticed that this can
Eric Snow writes:
> That's why I'm surprised by the reaction to this change. It just
> seems like the whole thing is being blown way out of proportion to
> the detriment of other interesting problems.
The feature itself a perfect bikeshedding pitfall. Everybody here
understands the Zen, and
Ethan Furman writes:
> * Deprecate passing single integer values to ``bytes`` and
> ``bytearray``
Why? This is a slightly awkward idiom compared to .zeros (EITBI etc),
but your 32-bit clock will roll over before we can actually remove it.
There are a lot of languages that do this kind of ini
Neil Schemenauer writes:
> I have to wonder if you guys actually ported at lot of Python 2
> code.
Python 3 (including stdlib) itself is quite a bit of code.
> According to you guys, there is no problem
No, according to us, there are problems, but in the code, not in the
language or its impl
This is related to David Mertz's request for backward compatible
initialization, not to the bdfl decision.
Steven D'Aprano writes:
> I don't think that's something which the Python interpreter ought to do
> for you, but you can write to /dev/urandom or /dev/random (both keep
> their own, sep
Steven D'Aprano writes:
> base64.b64encode take bytes as input and returns bytes. Some people are
> arguing that this is wrong behaviour, as RFC 3548
That RFC is obsolete: the replacement is RFC 4648. However, the text
is essentially unchanged.
> specifies that Base64 should transform byte
Greg Ewing writes:
> The RFC does *not* do that. It describes the output in terms of
> characters, and does not specify any bit patterns for the
> output.
The RFC is unclear on this point, but I read it as specifying the
ASCII coded character set, not the ASCII repertoire of (abstract)
charact
Nick Coghlan writes:
> - even if there is a test suite, sufficiently pervasive [str/bytes]
> type ambiguity may make it difficult to use for fault isolation
Difficult yes, but I would argue that that difficuly is inherent[1].
Ie, if it's pervasive, the fault should be isolated to the whole
modu
Brett Cannon writes:
> Do we need a security SIG? E.g. would people like Christian and
> Cory like to have a separate place to talk about the ssl stuff
> brought up at the language summit?
Besides what Barry brought up about the potential for attractive
nuisance where people post security issu
Donald Stufft writes:
> I guess one question would be, what does the secrets module do if
> it’s on a Linux that is too old to have getrandom(0), off the top
> of my head I can think of:
>
> * Silently fall back to reading os.urandom and hope that it’s been
> seeded.
> * Fall back to os.
Ned Deily writes:
> I don't think OS X support should be a gating factor in deciding to
> move ahead with C99 adoption but it does point out that there might
> be more ramifications to this decision.
I may be talking through my hat here, but Apple has been using LLVM
for several major releases
Ned Deily writes:
> But the point I was trying to make is that, by changing the
> language requirement, we will likely have an effect on what
> platforms (across the board) and versions we support and we should
> take that into account when making this decision. It may be the
> right decisio
Please talk to the lawyers (IANAL TINLA).
Steven d'Aprano writes:
> I now wish to change that and have it licenced under Python's
> standard licence. Is there anything I need to do other than just
> remove the Apache licence boilerplate from the file?
IMHO, no; in fact I would argue that its
Nick Coghlan writes:
> On 21 August 2016 at 06:31, Steve Dower wrote:
> > My biggest concern is that it then falls onto users to know how
> > to start Python with that flag.
The users I'm most worried about belong to organizations where
concerted effort has been made to "purify" the environme
Steve Dower writes:
> The Windows world is Unicode. Mostly represented in UTF-16, but UTF-8 is
> entirely equivalent.
Sort of, yes, and not for present purposes.
AFAICS, the Windows world is mostly application/* media that require
substantial developer effort to extract text from; character e
eryk sun writes:
> I just wrote a simple function to enumerate the 822 system locales on
> my Windows box (using EnumSystemLocalesEx and GetLocaleInfoEx, which
> are Unicode-only functions), and 36.7% of them lack an ANSI codepage.
> They're Unicode-only locales. UTF-8 is the only way to suppo
Steve Dower writes:
> * Stephen sees "no reason not to change locale.getpreferredencoding()"
> (default encoding for open()) at the same time with the same switches,
> while I'm not quite as confident. Do users generally specify an encoding
> these days? I know I
tritium-l...@sdamon.com writes:
> Once you get to var lengths like that, arcane single character flags start
> looking preferable. How about "PYTHONWINLEGACY" to just turn it all on or
> off. If the code breaks on one thing, it obviously isn't written to use the
> other two, so might as well
Guido van Rossum writes:
> I just spoke to someone who noted that [PEP 526] is likely to evoke
> an outsize emotional response. (Similar to what happened with PEP 484.)
Emotional, yes, but I resent the "outsize" part. Although that word
to the wise is undoubtedly enough, i.e., tl:dr if you lik
Please respect Reply-To, set to python-ideas.
Greg Ewing writes:
> Chris Angelico wrote:
> > Forcing people to write 1.0 just to be compatible with 1.5 will cause
> > a lot of annoyance.
>
> Indeed, this would be unacceptable IMO.
But "forcing" won't happen. Just ignore the warning. *All*
Stephen J. Turnbull writes:
> My version ... furthermore makes mypy into a units checker,
That isn't true, mypy does want annotations on all the variables it
checks and does not infer them from initializer type.
Sorry for the misinf
Mark Shannon writes:
> The problem with using the term "variable" is that it is *not* vague.
> Variables in python have well defined scopes and lifetimes.
Sure, but *hints* are not well-defined by Python (except the syntax,
once PEP 526 is implemented). A *hint* is something that the
typechec
Nikolaus Rath writes:
> Out of curiosity: is this test repeated periodically on different
> architectures? Or could it be that it only ever was true 10 years
> ago on Tim's Power Mac G5 (or whatever he used)?
This is the same Tim Peters of the eponymous test for readability of
syntax: "Syntax
Victor Stinner writes:
> 2016-10-12 11:34 GMT+02:00 INADA Naoki :
> > I see. My proposal should be another PEP (if PEP is required).
>
> I don't think that adding a single method deserves its own method.
You mean "deserves own PEP", right? I interpreted Nick to say that
"the reasons that a
Rasmus Villemoes writes:
> First, apologies if this isn't the appropriate list; I trust I'll be
> nudged in the right direction.
Given the relatively advanced state of patch, I doubt that this is the
*wrong* list. However, you would probably benefit from posting to
python-l...@python.org to co
Mark Lawrence via Python-Dev writes:
> Surely patches related to any bugs, not just security related ones, will
> be accepted until EOL in 2020?
Maybe, since it is the last in the 2.x line -- ask the RM, not me. I
shouldn't have said anything, my apologies.
But that doesn't matter for this c
Francisco Couzo writes:
> I'd be interested in writing a patch to make itertools more consistent if
> there's a consensus.
I don't understand what you mean by "consistent". I would argue that
in Python, an argument of None means "use the TOOWTDI default". For
"filterfalse", bool() is pretty o
Wes Turner writes:
> So forks with modules added or removed cannot be called Python?
> Forks without the blessing of the PSF cannot be called Python?
> That's really not open source.
Of course it is. The source is open and free.
But that's not what is in play here. The legal theory is tha
c 12, 2016 at 2:40 AM, Stephen J. Turnbull <
> turnbull.stephen...@u.tsukuba.ac.jp> wrote:
>
> > The legal theory is that the name "Python" is reserved so that
> > users can know that Python-Dev's strict (or not so, YMMV) QA
> > policies have been appl
Cory Benfield writes:
> The TL;DR is: I understand Christian’s concern, but I don’t think
> it’s important if you’re very, very careful.
But AIUI, the "you" above is the end-user or admin of end-user's
system, no? We know that they aren't very careful (or perhaps more
accurate, this is too fsc
Cory Benfield writes:
> From a security perspective I think we have to discount the
> possibility of administrator error from our threat model.
I disagree in a certain sense, and in that sense you don't discount it
-- see below.
> A threat model that includes “defend the system against intrus
Nathaniel Smith writes:
> > Well, I'm afraid to contact this closed and not-for-mortals list,
> > not sure this very basic question should go there ;) perhaps you
> > are already a member, feel free to forward.
>
> core-mentorship is intended as a friendly place for folks who are
> starting
Sylvain Bellemare writes:
> Hi,
>
> I hope this is the right place to post this kind of question. If not I
> apologize.
>
> I was simply wondering if anyone had been looking into supporting RFC 6920 (
> https://tools.ietf.org/html/rfc6920).
>
> For a simple example of what this is abou
Marc Mueller writes:
> True, but from my experience 'None' is just by far the most common
> default. Why not improve how we handle it?
The question is whether this is an improvement in the long run. When
some falsies are expected, in-range values, "if arg is None: ..." or
"x = default if arg i
makap...@gmail.com writes:
> When you call extractfile() on a TarFile, the result is a buffered
> version of a _FileInFile pseudo-file. When fileno() is called on
> this resulting file, fileno() it not exist (understandably) and an
> AttributeError is raised. I would like to suggest raising
Serhiy Storchaka writes:
> This is excellent!
>
> 01.11.21 14:17, Petr Viktorin пише:
> >> CPython treats the control character NUL (``\0``) as end of input,
> >> but many editors simply skip it, possibly showing code that Python
> >> will not
> >> run as a regular part of a file.
>
> It
501 - 600 of 1553 matches
Mail list logo
