Hi, Brett:
Thanks for your comments. Yes, we want to submit more fixes on test_failures of
stardard library after 3.8.0 beta1. Expect those can be accepted and get
merged☺☺
Thanks,
Peixing
From: Brett Cannon [mailto:br...@python.org]
Sent: Wednesday, March 20, 2019 2:42 AM
To: Xin, Peixing
Cc:
One main purpose of the beta period is to discover and fix bugs and
otherwise tweek behavior in the new features included in the first beta.
This usually presupposes that the feature is thought to be
'ready-to-go' as-is, absent new discoveries.
Interpretation and issuance of exceptions is usu
On Tue, Mar 19, 2019 at 3:43 PM Giampaolo Rodola' wrote:
>
> On Tue, Mar 19, 2019 at 6:21 PM Guido van Rossum wrote:
>
> >> On Tue, Mar 19, 2019 at 10:14 AM Giampaolo Rodola'
> >> wrote:
> >> Technically you cannot make it 100% safe, only less likely to occur.
> > That seems unnecessarily pedan
Hi Victor,
I pinged our product manager and he’s open to the idea of setting up a
consulting arrangement with a core developer to help move things along.
At least in principal.
If anyone on the core team is interested, and reasonably unaligned with Wind
River’s competitors, please contact me off
On 3/19/19, Victor Stinner wrote:
>
> When I write tests, I don't really care of security, but
> NamedTemporaryFile caused me many troubles on Windows: you cannot
> delete a file if it's still open in a another program. It's way more
> convenient to use tempfile.mktemp().
Opening the file again f
On Tue, Mar 19, 2019 at 6:21 PM Guido van Rossum wrote:
>> On Tue, Mar 19, 2019 at 10:14 AM Giampaolo Rodola'
>> wrote:
>> Technically you cannot make it 100% safe, only less likely to occur.
> That seems unnecessarily pedantic. A cryptographic random generator, like the
> one in the secrets m
Antoine Pitrou wrote:
Does it always work? According to the docs, """Whether the name can be
used to open the file a second time, while the named temporary file is
still open, varies across platforms
So use NamedTemporaryFile(delete = False) and close it before passing
it to the other program.
On Tue, Mar 19, 2019, 4:53 AM Ned Batchelder wrote:
> On 3/19/19 4:13 AM, Serhiy Storchaka wrote:
> > 19.03.19 00:41, Raymond Hettinger пише:
> >> 4) Fix the tests in the third-party modules to be more focused on
> >> their actual test objectives, the semantics of the generated XML
> >> rather th
> On Mar 19, 2019, at 1:52 PM, MRAB wrote:
>
> Thinking ahead, could there ever be anything else that you might want also to
> attach to member objects?
Our experience with property object suggests that once docstrings are
supported, there don't seem to be any other needs. But then, you n
On 2019-03-19 18:55, Raymond Hettinger wrote:
I'm working on ways to make improve help() by giving docstrings to member
objects.
One way to do it is to wait until after the class definition and then make
individual, direct assignments to __doc__ attributes.This way widely the
separates docstr
On Wed, 20 Mar 2019 at 00:29, Serhiy Storchaka wrote:
> 19.03.19 15:10, Tim Delaney пише:
> > Now Calibre is definitely in the wrong here - it should be able to
> > import regardless of the order of attributes. But the fact is that there
> > are a lot of tools out there that are semi-broken in a
I have the impression that the line between variables and docs is a tidbit
too much blurred.
Yours,
Abdur-Rahmaan Janhangeer
Mauritius
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
ht
I'm working on ways to make improve help() by giving docstrings to member
objects.
One way to do it is to wait until after the class definition and then make
individual, direct assignments to __doc__ attributes.This way widely the
separates docstrings from their initial __slots__ definition.
Ned Batchelder schrieb am 19.03.19 um 12:53:
> I need to re-engineer my tests.
… or sort the attributes before serialisation, or use C14N always, or
change your code to create the attributes in sorted-by-name order. The new
behaviour allows for a couple of ways to deal with the issue of backwards
On Mon, Mar 18, 2019 at 7:22 PM Xin, Peixing
wrote:
> Hi, Experts:
>
>
>
> Seeing from the Python 3.8.0 schedule(
> https://www.python.org/dev/peps/pep-0569/#schedule), new features will
> not be allowed to submit after 3.8.0 beta1. For VxWorks RTOS platform
> supporting CPython, we are using bpo
On Tue, Mar 19, 2019 at 10:22 AM Guido van Rossum wrote:
> On Tue, Mar 19, 2019 at 10:14 AM Giampaolo Rodola'
> wrote:
>
>>
>> On Tue, 19 Mar 2019 at 17:47, Sebastian Rittau
>> wrote:
>>
>>> Am 19.03.19 um 17:23 schrieb Giampaolo Rodola':
>>> > @Sebastian
>>> >> If there are valid use cases for
Nathaniel Smith schrieb am 19.03.19 um 00:15:
> That seems potentially simpler to implement than canonical XML
> serialization
C14N is already implemented for ElementTree, just needs to be ported to
Py3.8 and merged.
https://bugs.python.org/issue13611
Stefan
On Tue, Mar 19, 2019 at 6:15 AM Serhiy Storchaka
wrote:
> 19.03.19 13:53, Ned Batchelder пише:
> > Option 4 is misleading. Is anyone here really offering to "fix the
> > tests in third-party modules"? Option 4 is actually, "do nothing, and
> > let a multitude of projects figure out how to fix t
You have to find someone to review your PRs. It takes time. We are all
volunteers. I looked and merged some VxWorks PRs.
Would it be possible to pay a core dev to do the reviews? That's an open
question for core devs and for WindRiver.
Victor
Le mardi 19 mars 2019, Xin, Peixing a écrit :
> Hi,
Hi,
I don't think that we can say that Python supports VxWorks yet. Many PRs
are not merged yet. You are free to disrribute a modified version with your
changes.
The PEP 11 lists conditions to fully support a platform:
https://www.python.org/dev/peps/pep-0011/
My summary is: all tests must pass
Guido van Rossum wrote:
> If all you need is a random name, why not just use a random number
> generator?
> E.g. I see code like this:
>
> binascii.hexlify(os.urandom(8)).decode('ascii')
I tend to use os.path.join(dir, str(uuid.uuid4())) if I need to
create a random filename to pass to anothe
On Tue, Mar 19, 2019 at 10:14 AM Giampaolo Rodola'
wrote:
>
> On Tue, 19 Mar 2019 at 17:47, Sebastian Rittau wrote:
>
>> Am 19.03.19 um 17:23 schrieb Giampaolo Rodola':
>> > @Sebastian
>> >> If there are valid use cases for mktemp(), I recommend renaming
>> >> it to mkname_unsafe() or something
On Tue, 19 Mar 2019 at 17:47, Sebastian Rittau wrote:
> Am 19.03.19 um 17:23 schrieb Giampaolo Rodola':
> > @Sebastian
> >> If there are valid use cases for mktemp(), I recommend renaming
> >> it to mkname_unsafe() or something equally obvious.
> > I'm -1 about adding an alias (there should be on
On Tue, 19 Mar 2019 at 16:47, Sebastian Rittau wrote:
> But I had another thought: If I understand correctly, the exploitability
> of mktemp() relies on the fact that between determining whether the
> file exists and creation an attacker can create the file themselves.
> Couldn't this problem be s
Am 19.03.19 um 17:23 schrieb Giampaolo Rodola':
@Sebastian
If there are valid use cases for mktemp(), I recommend renaming
it to mkname_unsafe() or something equally obvious.
I'm -1 about adding an alias (there should be one and preferably only
one way to do it). Also mkstemp() and mkdtemp() ar
On Tue, Mar 19, 2019 at 3:57 PM Antoine Pitrou wrote:
>
>
> Le 19/03/2019 à 15:52, Guido van Rossum a écrit :
> >
> > If all you need is a random name, why not just use a random number
> > generator?
> > E.g. I see code like this:
> >
> > binascii.hexlify(os.urandom(8)).decode('ascii')
>
> mkt
On Tue, Mar 19, 2019 at 2:06 PM Stéphane Wirtel wrote:
>
> Hi,
>
> Context: raise a warning or remove tempfile.mktemp()
> BPO: https://bugs.python.org/issue36309
>
> Since 2.3, this function is deprecated in the documentation, just in the
> documentation. In the code, there is a commented RuntimeW
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.
On Tue, 19 Mar 2019 15:12:06 +0100
Sebastian Rittau wrote:
> Am 19.03.19 um 14:53 schrieb Victor Stinner:
> >
> > When I write tests, I don't really care of security, but
> > NamedTemporaryFile caused me many troubles on Windows: you cannot
> > delete a file if it's still open in a another program
Le 19/03/2019 à 15:52, Guido van Rossum a écrit :
>
> If all you need is a random name, why not just use a random number
> generator?
> E.g. I see code like this:
>
> binascii.hexlify(os.urandom(8)).decode('ascii')
mktemp() already does this, probably in a better way, including the
notion o
On Tue, Mar 19, 2019 at 6:27 AM Antoine Pitrou wrote:
>
> -1. Please don't remove tempfile.mktemp(). mktemp() is useful to
> create a temporary *name*. All other tempfile functions create an
> actual file and impose additional burden, for example by making the
> file unaccessible by other proc
On Tue, 19 Mar 2019 15:10:40 +0100
Stéphane Wirtel wrote:
> totally agree with you but this function is deprecated (2002) since 2.3,
> with a simle comment about a security issue.
"Deprecated" doesn't mean anything here. It's just a mention in the
documentation. It doesn't produce actual warnin
I'm not sure the relationship with mkdir and mktemp here. I don't see
any uses of tempfile.mktemp in pip or setuptools, though they do use
os.mkdir (which is not deprecated).
Both pip and setuptools use pytest's tmpdir_factory.mktemp() in their
test suites, but I believe that is not the same thing
Am 19.03.19 um 14:53 schrieb Victor Stinner:
When I write tests, I don't really care of security, but
NamedTemporaryFile caused me many troubles on Windows: you cannot
delete a file if it's still open in a another program. It's way more
convenient to use tempfile.mktemp().
O_EXCL, open(tmpname,
totally agree with you but this function is deprecated (2002) since 2.3,
with a simle comment about a security issue.
2.3 -> 2.7, 3.0 -> 3.7, 13 releases and 17 years.
Maybe we could remove it with an official PendingDeprecationWarning.
Le 19/03/19 à 14:39, Antoine Pitrou a écrit :
> The fact th
Hi,
I would prefer to keep tempfile.mktemp(), remove the deprecation, but
better explain the risk of race condition affecting security.
Le mar. 19 mars 2019 à 14:41, Chris Angelico a écrit :
> Can't you create a NamedTemporaryFile and permit the other program to
> use it? I just tried that (with
On Wed, 20 Mar 2019 00:37:56 +1100
Chris Angelico wrote:
> On Wed, Mar 20, 2019 at 12:25 AM Antoine Pitrou wrote:
> >
> >
> > -1. Please don't remove tempfile.mktemp(). mktemp() is useful to
> > create a temporary *name*. All other tempfile functions create an
> > actual file and impose additi
and why not with a very long PendingDeprecationWarning? this warning
could be used in this case.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/py
On Tue, 19 Mar 2019 15:32:25 +0200
Serhiy Storchaka wrote:
> 19.03.19 15:03, Stéphane Wirtel пише:
> > Suggestion and timeline:
> >
> > 3.8, we raise a PendingDeprecationWarning
> > * update the code
> > * update the documentation
> > * update the tests
> >(check a PendingD
On Wed, Mar 20, 2019 at 12:25 AM Antoine Pitrou wrote:
>
>
> -1. Please don't remove tempfile.mktemp(). mktemp() is useful to
> create a temporary *name*. All other tempfile functions create an
> actual file and impose additional burden, for example by making the
> file unaccessible by other pr
19.03.19 15:03, Stéphane Wirtel пише:
Suggestion and timeline:
3.8, we raise a PendingDeprecationWarning
* update the code
* update the documentation
* update the tests
(check a PendingDeprecationWarning if sys.version_info == 3.8)
3.9, we change PendingDeprecationWarning
19.03.19 15:10, Tim Delaney пише:
Now Calibre is definitely in the wrong here - it should be able to
import regardless of the order of attributes. But the fact is that there
are a lot of tools out there that are semi-broken in a similar manner.
Is not Calibre going to seat on Python 2 forever?
-1. Please don't remove tempfile.mktemp(). mktemp() is useful to
create a temporary *name*. All other tempfile functions create an
actual file and impose additional burden, for example by making the
file unaccessible by other processes. But sometimes all I want is a
temporary name that an *oth
19.03.19 14:50, Antoine Pitrou пише:
2). Go into every XML module and add attribute sorting options to each function
that generate xml.
What do you mean with "every XML module"? Are there many of them?
ElementTree and minidom. Maybe xmlrpc. And perhaps we need to add
arguments in calls at h
19.03.19 13:53, Ned Batchelder пише:
Option 4 is misleading. Is anyone here really offering to "fix the
tests in third-party modules"? Option 4 is actually, "do nothing, and
let a multitude of projects figure out how to fix their tests, slowing
progress in those projects as they try to suppor
On Tue, 19 Mar 2019 at 23:13, David Mertz wrote:
> In a way, this case makes bugs worse because they are not only a Python
> internal matter. XML is used to communicate among many tools and
> programming languages, and relying on assumptions those other tools will
> not follow us a bad habit.
>
Hi,
Context: raise a warning or remove tempfile.mktemp()
BPO: https://bugs.python.org/issue36309
Since 2.3, this function is deprecated in the documentation, just in the
documentation. In the code, there is a commented RuntimeWarning.
Commented by Guido in 2002, because the warning was too annoyi
Hi Raymond,
As long as the new serialization order is deterministic (i.e. it's the
same every run and doesn't depend on e.g. hash randomization), then I
think it's fine to change it.
Some more comments / questions:
> 2). Go into every XML module and add attribute sorting options to each
> fun
In my opinion, any test that relied on a non-promised accident of
serialization is broken today. Very often, such bad tests mask bad
production code that makes the same unsafe assumptions.
This is similar to tests that assumed a certain dictionary order, before we
got guaranteed insertion order. O
On 3/19/19 4:13 AM, Serhiy Storchaka wrote:
19.03.19 00:41, Raymond Hettinger пише:
3) Add a standards compliant canonicalization tool (see
https://en.wikipedia.org/wiki/Canonical_XML ). This is likely to be
the right-way-to-do-it but takes time and energy.
4) Fix the tests in the third-part
19.03.19 00:41, Raymond Hettinger пише:
3) Add a standards compliant canonicalization tool (see
https://en.wikipedia.org/wiki/Canonical_XML ). This is likely to be the
right-way-to-do-it but takes time and energy.
4) Fix the tests in the third-party modules to be more focused on their actual
51 matches
Mail list logo
