[Python-Dev] Re: f-strings in the grammar

[Anders Munch]

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 tokenize.py will do with f-strings after this?
What would be the output of, say,
$ echo 'f"hello {world!r}."' | python3 -m tokenize
?

regards, Anders

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/XXHWMINTPOLHLECS7BSHZPOC7RRN47T2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 597: Add optional EncodingWarning

[Anders Munch]

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 explicit encoding=None (for 
>> backwards-compatibility) or an explicit encoding='utf-8' (because that was 
>> intended all along).  No twice about it, one change.

> But then people who added an explicit utf-8 encoding need to remove the 
> encoding argument again once the default value changes

Why would they do that?  There's no need to remove anything.  Code that doesn't 
use a default doesn't break because the default changes.

regards, Anders

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/WBUP2BNLAKHILUM3ZE3A2LVQKAQRXQ7T/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 597: Add optional EncodingWarning

[Anders Munch]

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 you're adding encoding="latin1" to the user program, then you are doing 
something very different from what Victor proposed.

regards, Anders

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/IENGLLP67LAOVLVSMJSJX4W6K2ZDTPJ7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 597: Add optional EncodingWarning

[Anders Munch]

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(self._filename, encoding=encoding) as f:
> return f.read()
> ```
> 
> If `encoding=None` suppresses the warning, functions like this never warned.

I don't see why they should be.  The author clearly knew about the encoding
argument to open, they clearly intended for a None value to be given in some
cases, and at the time of writing None meant to use a locale-dependent encoding.

> We are not discussing about changing default encoding for now.

The section "Prepare to change the default encoding to UTF-8" gave me the
impression that this was meant as a stepping stone on the way to doing just
that.  If that was not the intention, my apologies for the misread.

regards, Anders
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/2VWZMIBG2VLASF7NCKDEJ5I22PXWI7D7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 597: Add optional EncodingWarning

[Anders Munch]

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 updated to say encoding=None, and then it 
>> will work on both old and new Pythons without warning.
Paul Moore [mailto:p.f.mo...@gmail.com]
> I don't understand why working code should have to change *twice*.

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 explicit encoding=None (for 
backwards-compatibility) or an explicit encoding='utf-8' (because that was 
intended all along).  No twice about it, one change.
 
regards, Anders

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/BTIXV47LDYPKNIGWNRQSG6LXG4DORS7W/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 597: Add optional EncodingWarning

[Anders Munch]

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:
print(f.read())

But if I change it to this:

with open('file.txt', 'rt', encoding='utf-8') as f:
print(f.read())

then it fails with UnicodeDecodeError.   How it that backwards compatible?

regards, Anders

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/SDFLXIW64ESKDBARCHC2A2JA4NFPBZ2Y/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 597: Add optional EncodingWarning

[Anders Munch]

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 is opt-in warning like BytesWarning.

What use is a warning that no-one sees?  When the default is switched to 
encoding="utf8", it will break software, and people need to be warned of that.
UnicodeDecodeError's will abound when files that used to be read in a 
single-byte encoding fails to decode as utf-8. All it takes is a single é.
If the default encoding is ever to change, there's no way around a noisy 
warning.

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 updated to say encoding=None, and then it will 
work on both old and new Pythons without warning.

regards, Anders
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/GZOHZAXKJDRJPF32U2ET5E32SOYXHR5E/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Anders Munch]

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 too (which is further evidence that it's
> a natural fit).
 
I was thinking that 'match' and 'case' are reversed: The top line presents the
_case_ to be studied.  The patterns that follow try to _match_ the presented 
case.

Trying it out on PEP example:

case input:
match x if x > MAX_INT:
print("Got a large number")

I think it reads well, in particular when like here there's a condition
attached.  The second line is almost English: "match x if x greater than max
int".

Pascal is a precedent for this placement of 'case', although of course Niklaus
Wirth is not a native English speaker either.

regards, Anders

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/EGZSIBVCNXQSDS2LTYS2G6CN37K5M35E/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proliferation of tstate arguments.

[Anders Munch]

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 implied
parameter without creating synchronisation problems.  You do not have to worry
about painting yourself into an architectural corner by using thread-local
variables, because anything you can do with an explicit parameter, you could
also have done with an implied one in thread-local memory.

Correctness is not at stake.  Either approach will work.

regards, Anders
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/CUZQ4NYBPY25M5ISJ5JT66XMW7KWP4DJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proliferation of tstate arguments.

[Anders Munch]

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.

The point is that because threads can't preempt themselves, this:

/*1*/
{
Py_something(other_tstate);
}

and this:

/*2*/
{
   PyInterpreterState* old_tstate = tstate;
   tstate = other_state;
   Py_something();
   tstate = old_tstate;
}

is effectively equivalent, provided tstate is thread-local.  Both will work
equally well from the hypothetical C callback that wants to use a different
subinterpreter.

That wouldn't be true if tstate was process-wide, because that would be a race
condition, some other thread might change tstate.  But if tstate is
thread-local, there's no race condition.

Obviously /*1*/ is cleaner code than /*2*/, but /*2*/ is perfectly sound all 
the same.

regards, Anders
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/NAD6DEOU2EYLBKOK3QACSP3MUMJ4NTOH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Anders Munch]

>> 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 interface with the translator.
 
Security is one reason: A translator could sneak {password} or {signing_key} 
into an unrelated string, if those names happen to be present in the namespace. 
 That may not seem like a big issue if you've only ever used gettext/.po-file 
translation, where the translation is pre-built with the program, but in a more 
dynamic setting where end-users can supply translations, it's a different story.

You could parse the strings and require translations to have the same 
variables, but that is limiting. E.g. that would mean you couldn't translate
'Welcome, {first_name}'
into
'Willkommen, {title} {last_name}'

Another reason is that you don't want variable names in your program and 
translations to have to change in lock-step.
E.g. you might change your code to:
 _('{name} costs ${price:.2f}').format(name=prod.short_name, 

price=context.convert_to_chosen_currency(price))
without needing to change any translations.

regards, Anders

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/A2PDRFFJWK2XYPHLVGKC26QR2DJ6H4QM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Anders Munch]

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.readthedocs.io/en/latest/

This seems to retrieve variables from the surrounding scope, in a manner
reminiscent of f-strings (though obviously implemented very differently).  I
would never use that for translatable strings, partly on security grounds, and
partly because it adds coupling between UI texts and code. 

regards, Anders

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/3GENPV6OVV772BTGSYX3KHH7SMWFBARW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Anders Munch]

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, Anders
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/E6Q2QJU656WQNBE6L6BXOFTVNBBFY7DV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Anders Munch]

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/ moment.

I'm using the u prefix to tag user interface strings for translation.  u"..." 
goes through i18n, "..." doesn't.  I have tools that extract and replace texts, 
identify new strings for translation etc. based on this.  
I was very happy when 3.3 reintroduced the prefix, because it allowed me to 
upgrade without losing my very efficient workflow.  Not to mention having to 
make 10.000 code changes to replace the prefix with something or other.

If the prefix goes, I'm not going to complain, I know my setup is fairly unique 
and I can't really demand that you keep vestigial syntax around just for that.  
But I'd still be sorry to see it go.

regards, Anders
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/WCZDU2M2YK6A2UDP7OSN6P3VUOPMKCYI/
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-Dev] PEP 594: update 1

[Anders Munch]

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 deprecation period). This proposal is 
> no different.

Except perhaps in scale.  The same people that upgrade from 3.x to 3.x+1 
without giving it a second thought, just to be on the latest version, will 
hesitate to go from 3.x to 4.y, because the major version change is a hint that 
they should be more careful.  That means they're ready for it when they get the 
ModuleNotFoundError exception, instead of feeling ambushed.

OK, it may be that this is not enough to warrant a 4.0 release, but I do think 
python-dev should get over its fear of major versions sometime.  And that 
transitioning to a leaner standard library with some things moved to PyPI would 
not be a bad program statement for a Python 4.0.

regards, Anders
 
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 594: update 1

[Anders Munch]

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 is not 
> a sudden new idea.
>
> Also, the proposed schedule (with one exception) is a slower alternative than 
> proposals to add a deprecation warning (if not one already) in 3.8 and remove 
> in 3.9.

About that schedule: I think the removal version should be called 4.0.

These are working modules that to varying degrees are still in use that are 
being removed.  It's perfectly legitimate for python-dev to decide to stop 
maintaining them, but it's a breaking change none the less.

For me, it's a couple of CGI scripts that will break.  If I hadn't read this 
thread, I would at some point be confronted with a ModuleNotFoundError 
exception, with no guidance on how to fix that.  That's not a very good user 
experience, even if a fix can be found after some googling. A major version 
change serves as a heads up that something is going on and you need to check 
the consequences before upgrading.

regards, Anders

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

[Anders Munch]

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 mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Remove tempfile.mktemp()

[Anders Munch]

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
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Remove tempfile.mktemp()

[Anders Munch]

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 disagree.  

> Using 128 bits is just 22 characters using secrets.token_urlsafe().

A little more when you take into account case-insensitive file systems.

regards, Anders

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Remove tempfile.mktemp()

[Anders Munch]

Nathaniel J. Smith:
> Historically, mktemp variants have caused *tons* of serious security
> vulnerabilities. It's not a theoretical issue.

All the more reason to have a standard library function that gets it right.

> The choice of ENTROPY_BYTES is an interesting question. 16 (= 128 bits) would
> be a nice "obviously safe" number, and gives 22-byte filenames. We might be
> able to get away with fewer, if we had a plausible cost model for the
> attack. This is another point where a security specialist might be helpful 
> :-).

I'm not a security specialist but I play one on TV.
Here's my take on it.

Any kind of brute force attack will require at least one syscall per try, to
create a file or check if a file by a given name exists.  It's a safe assumption
that names have to be tried individually, because if the attacker has a faster
way of enumerating existing file names, then the entropy of the filename is
worthless anyway.

That means even with only 41 bits of entry, the attacker will have make 2^40
tries on average.  For an individual short-lived file, that could be enough;
even with a billion syscalls per second, that's over a thousand seconds, leaving
plenty of time to initiate whatever writes the file.

However, there could be applications where the window of attack is very long,
hours or days even, or that are constantly writing new temporary files, and
where the attacker can keep trying at a rapid pace, and then 41 bits is
definitely not secure.

128 bits seems like overkill: There's no birthday attack because no-one keeps
2^(ENTROPY_BITS/2) files around, and the attack is running on the attackee's
system, so there's no using specialised accelerator hardware.  I'd say 64 bits
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 51856626
a...@flonidan.dk  *  www.flonidan.com 
 FLONIDAN A/S  *  Islandsvej 29  *  DK-8700 Horsens  *  CVR: 89919916
Winner of the 2018 Frost & Sullivan Customer Leadership Award
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Remove tempfile.mktemp()

[Anders Munch]

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 help with 
>> security
Sebastian Rittau:
> That is not actually true. The important difference is that with 
> NamedTemporaryFile the file exists with appropriate access right (0600).

You are right, I must have mentally reversed the polarity of the delete 
argument.  And I didn't realise that the access right on a file had the power 
to prevent itself from being removed from the folder that it's in.  I thought 
the access flags were a property of the file itself and not the directory 
entry. Not sure how that works.

But if NamedTemporaryFile(delete=False) is secure then why not use that to 
implement mktemp?

def mktemp(suffix="", prefix=template, dir=None):
with NamedTemporaryFile(delete=False, suffix=suffix, prefix=prefix, 
dir=dir) as f:
return f.name

Yes, it does leave an empty file if the name is not used, but the name is 
usually created with the intent to use it, so that is rarely going to be a 
problem. Just document that that's how it is.  It does mean that where there's 
an explicit file-exists check before writing the file, that code will break. 
But it will break a lot less code than removing mktemp entirely.

regards, Anders

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Remove tempfile.mktemp()

[Anders Munch]

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 security.

If a secure implementation of mktemp is truly impossible, then the same could 
be said for NamedTemperatoryFile(delete=False). Should that be deprecated as 
well?

regards, Anders

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Remove tempfile.mktemp()

[Anders Munch]

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.

But if it hurts when you use /tmp, why use /tmp? Use a path with no 
world-accessible ancestor, or at least no world-writable ancestor.

On Windows, that means creating it somewhere under the CSIDL_LOCAL_APPDATA 
folder. Which is already the default for %TEMP% and %TMP%.
On Unix, it's a $HOME subfolder with access 700 or 600.
How about switching mktemp over to use that?

regards, Anders

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Generator objects and list comprehensions?

[Anders Munch]

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 information.
>>> [(yield 1) for x in range(10)]
  File "", line 1
SyntaxError: 'yield' outside function

regards, Anders

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

[Anders Munch]

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 out of backing store to 
handle page faults, anything can happen.
 
- Anders

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com