Pablo Galindo Salgado [mailto:pablog...@gmail.com] wrote:
> We already expose APIs that return AST objects that can be used for all sort
> of things and a tokenizer module that exposes some form of lexing that is
> relatively close to the one that CPython uses internally.
What do you envision
Paul Moore [mailto:p.f.mo...@gmail.com]: wrote:
> On Wed, 10 Feb 2021 at 14:33, Anders Munch wrote:
>> The idea is to make is so that working code only needs to change once, even
>> when supporting multiple Python versions.
>> That one change is to add either an explic
Inada Naoki [mailto:songofaca...@gmail.com] wrote:
> There are several ways:
> * encoding="latin1" -- This is the best. Works perfectly.
> * Don't touch -- You don't need to enable EncodingWarning.
> [...]
I'm replying to Victor's statement that ``encoding="utf8" is backward
compatible´´.
If yo
On Wed, Feb 10, 2021 at 1:46 AM Anders Munch wrote:
>> How about swapping around "locale" and None?
Inada Naoki wrote:
>
> I thought it, but it may not work. Consider about function like this:
>
> ```
> def read_text(self, encoding=None):
> with open(sel
On Tue, 9 Feb 2021 at 16:52, Anders Munch wrote:
>> How about swapping around "locale" and None? That is, make "locale" the new
>> default that emits a warning, and encoding=None emits no warning. That has
>> the advantage that old code can be upd
Victor Stinner [mailto:vstin...@python.org] wrote:
> encoding="utf8" is backward compatible and is likely to fix encoding bugs
> when the locale encoding is not UTF-8
This program runs just fine on 3.8.7 Windows, against a file.txt that contains
latin-1 text:
with open('file.txt', 'rt') as f:
Victor Stinner [mailto:vstin...@python.org] wrote:
> The warning can explicitly suggest to use encoding="utf8", it should work in
> almost all cases.
The warning should also explain how to get backwards-compatible behaviour, i.e.
suggest encoding="locale".
Inada Naoki wrote:
> This warning i
Eric Nieuwland :
>> I have some doubt about the keyword
Guido van Rossum [mailto:gu...@python.org]:
> Many people have tried to come up with a different keyword here, but nothing
> has been found that comes even close to the simplicity of match. Plus, several
> other languages (Scala, Rust) use it
Antoine Pitrou [mailto:solip...@pitrou.net]:
> This example is mixing up the notion of interpreter state and thread state.
Sorry about that, I was making a more general point and not paying so much
attention to the specific names.
The general point is this: A thread-local variable can work as an
Chris Angelico [mailto:ros...@gmail.com]:
> And by that logic, globals are even more capable. I don't understand your
> point. Isn't the purpose of the tstate parameters to avoid the problem of
> being unable to have multiple tstates within the same OS thread? I think I've
> missed something here.
>> I'm struggling to see what i-strings would do for i18n that str.format
>> doesn't do better.
Serhiy Storchaka [mailto:storch...@gmail.com]
> You would not need to repeat yourself.
> _('{name} costs ${price:.2f}').format(name=name, price=price)
A small price to pay for having a well-defined
Barry Warsaw [mailto:ba...@python.org] wrote:
> str.format() really isn’t enough to do proper i18n; it’s actually a fairly
> complex topic.
Obviously.
> I’m not convinced that PEP 501 would provide much benefit on the technical
> side.
My point exactly.
> flufl.i18n - https://flufli18n.readth
Victor Stinner [mailto:vstin...@python.org] wrote:
> You may want to have a look at the deferred PEP 501 -- General purpose string
> interpolation:
> https://www.python.org/dev/peps/pep-0501/
I'm struggling to see what i-strings would do for i18n that str.format doesn't
do better.
regards, Ande
Chris Angelico [mailto:ros...@gmail.com] wrote:
> The first one is already the case. PEP 414 reintroduced the u"..." literal
> form, specifically
> as a porting tool. Given that it has absolutely zero value in pure Py3 code
> [...]
Challenge accepted :) Here comes my https://xkcd.com/1172/ mom
Fra: Paul Moore [mailto:p.f.mo...@gmail.com]:
> > A major version change serves as a heads up that something is going on and
> > you need to check the consequences before upgrading.
> Python's backward compatibility policy allows breaking changes between
> versions X.Y and X.Y+1 (with a suitable
Fra: Python-Dev [mailto:python-dev-bounces+ajm=flonidan...@python.org] På vegne
af Terry Reedy:
>> Deprecation schedule
>>
>
> I think it worth adding that some modules were deprecated years ago but kept
> until after 2.7 end-of-life to ease 3.x transition. Removing modules
Fra: Python-Dev [mailto:python-dev-bounces+ajm=flonidan...@python.org] På vegne
af Christian Heimes
> * The removed modules will be available through PyPI.
Will they? That's not the impression I got from the PEP.
regards, Anders
___
Python-Dev maili
Victor Stinner:
> To be clear: mktemp() is vulnerable by design
No: mktemp() is vulnerable by implementation. Specifically, returning a file
name in a world-accessible location, /tmp.
regards, Anders
___
Python-Dev mailing list
Python-Dev@python.org
Steven D'Aprano:
>> 128 bits seems like overkill: There's no birthday attack because
>> no-one keeps 2^(ENTROPY_BITS/2) files around
> You haven't seen my Downloads folder... :-)
I put it to you that those files are not temporary :-)
> Why be so miserly with entropy?
I don't necessarily disagre
is enough under those circumstances, but I wouldn't be surprised if a better
security specialist could make a case for more. So maybe go with 80 bits,
that's puts it at 15 or 16 characters.
Med venlig hilsen/Best regards
Anders Munch
Chief Security Architect
T: +45 76266981 * M: +45 51856
Anders Munch:
>>> So use NamedTemporaryFile(delete = False) and close it before passing it to
>>> the other program.
>> That's effectively the same as calling tempfile.mktemp. While it does
>> waste time opening and closing an unused file, that doesn't
Greg Ewing:
> So use NamedTemporaryFile(delete = False) and close it before passing it to
> the other program.
That's effectively the same as calling tempfile.mktemp. While it does waste
time opening and closing an unused file, that doesn't help with security. If
anything, it might worsen se
Antoine Pitrou:
> And if there is an easy replacement, then how about re-implementing
> mktemp() using that replacement, instead of removing it?
Indeed. The principal security issue with mktemp is the difficulty in creating
a user-specific thing under a shared /tmp folder in a multi-user setup.
Craig Rodrigues :
> Make this return a list on Python 3, like in Python 2: [(yield 1) for x in
> range(10)]
Give Python 2 a little more credit.
Python 2.7.10 (default, May 23 2015, 09:40:32) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more informa
Steven D'Aprano:
> although I must admit I don't understand why the entire OS is effected.
A consequence of memory overcommit, I'd wager. The crasher code not only
allocates vast swathes of memory, but accesses it as well, which is bad news
for Linux with overcommit enabled. When the OS runs ou
25 matches
Mail list logo
