This is exactly how signals are implemented in Python :-)
Victor
Le lundi 9 février 2015, Robert Collins a
écrit :
> On 9 February 2015 at 09:11, Maciej Fijalkowski > wrote:
> > Hi Francis
> >
> > Feel free to steal most of vmprof code, it should generally work
> > without requiring to patch c
Hi,
2015-02-09 22:06 GMT+01:00 Neil Girdhar :
> The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/) is
> implemented now based on some early work by Thomas Wouters (in 2008) and
> Florian Hahn (2013) and recently completed by Joshua Landau and me.
I don't like this PEP. IMO it makes t
2015-02-10 0:51 GMT+01:00 Antoine Pitrou :
>> The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/) is
>> implemented now based on some early work by Thomas Wouters (in 2008) and
>> Florian Hahn (2013) and recently completed by Joshua Landau and me.
>
> To be clear, the PEP will probably
2015-02-10 1:29 GMT+01:00 Neil Girdhar :
> For some reason I can't seem to reply using Google groups, which is is
> telling "this is a read-only mirror" (anyone know why?) Anyway, I'm going
> to answer as best I can the concerns.
>
> Antoine said:
>
>> To be clear, the PEP will probably be useful
Le 10 févr. 2015 03:07, "Ethan Furman" a écrit :
> That line should read
>
> return func(*(args + fargs), **{**keywords, **fkeywords})
>
> to avoid the duplicate key error and keep the original functionality.
To me, this is just ugly. It prefers the original code which use .update().
Maybe t
To be logic, I expect [(*item) for item in mylist] to simply return mylist.
[*(item for item in mylist] with mylist=[(1, 2), (3,)] could return [1, 2,
3], as just [*mylist], so "unpack" mylist.
Victor
___
Python-Dev mailing list
Python-Dev@python.org
ht
Le 10 févr. 2015 06:48, "Greg Ewing" a écrit :
> It could potentially be a little more efficient by
> eliminating the construction of an intermediate list.
Is it the case in the implementation? If it has to create a temporary
list/tuple, I will prefer to not use it.
After long years of developme
Hi,
TL;DR: on POSIX, is it useful to know the inode number (st_ino)
without the device number (st_dev)?
While reading feedback on the Python 3.5 alpha 1 release, I saw a
comment saying that the current design of os.scandir() (PEP 471)
doesn't fit a very specific usecase where the inode number is
Hi,
TL,DR: are you ok to add 800 lines of C code for os.scandir(), 4x
faster than os.listdir() when the file type is checked?
I accepted the PEP 471 (os.scandir) a few months ago, but it is not
implement yet in Python 3.5, because I didn't make a choice on the
implementation.
Ben Hoyt wrote diff
2015-02-13 11:19 GMT+01:00 Paul Moore :
> On 13 February 2015 at 10:07, Victor Stinner wrote:
>> => IMO the best option is to take the C implementation. What do you think?
>
> FWIW (as I'm not a core dev) I agree. The Windows speedup is huge, and
> well worth adding t
2015-02-13 12:27 GMT+01:00 Serhiy Storchaka :
> On 13.02.15 12:07, Victor Stinner wrote:
>>
>> * C implementation: scandir is at least 3.5x faster than listdir, up
>> to 44.6x faster on Windows
>
>
> Results on Windows was obtained in the becnhmark that doesn't
2015-02-13 11:52 GMT+01:00 Serhiy Storchaka :
> You can try to make Python implementation faster if
>
> 1) Don't set attributes to None in constructor.
The class uses __slots__. Setting attributes in the class body is
forbidden when __slots__ is used.
> 3) Or pass DirEntry to _scandir:
>
> def sc
2015-02-13 15:36 GMT+01:00 Steve Dower :
> I think posixmodule is a great candidate for splitting up by platform rather
> than function, as the whole file is packed with ifdef. It's really only
> lacking a volunteer to do it, but we could start here (ie. make
> posixmodule_nt.c for the Windows impl
Le samedi 14 février 2015, Stephen J. Turnbull a
écrit :
>
> IMO: Document the limitation (if no extra syscall) or inefficiency
> (with the syscall), and let the user choose.
Hum, by the way, I don't know if we should dd the method on Windows. As I
said, I don't want to cache The result of the
2015-02-14 11:57 GMT+01:00 Victor Stinner :
> I propose something else: a DirEntry.inode read-only property (...)
Full DirEntry API:
- name (str) attribute
- path (str) read-only property, created at the first call
- inode (int or None) attribute <=== my proposition
- is_dir(*, follow_sy
Le 14 févr. 2015 18:47, "Gregory P. Smith" a écrit :
> I think the "or None" semantics are a bad idea.
Oh, in fact it shouldn't be None but 0 onWindows to be consistent with
DirEntry.stat().st_ino which is also equal to 0.
The value 0 is not a valid inode number.
Victor
2015-02-16 17:34 GMT+01:00 Stefan Krah :
>
> On Mon, Feb 16, 2015 at 11:35:52AM +, serhiy.storchaka wrote:
>> diff --git a/Modules/_testbuffer.c b/Modules/_testbuffer.c
>> --- a/Modules/_testbuffer.c
>> +++ b/Modules/_testbuffer.c
>> @@ -850,7 +850,7 @@
>> Py_ssize_t *dest;
>> Py_ssiz
Le 21 févr. 2015 15:27, "Nick Coghlan" a écrit :
> int expected, but found str
> float expected, but found int
>
> 'int' expected, but found 'str'
> 'float' expected, but found 'int'
I would prefer quotes with the word type:
'float' type expected, but got 'int' type
Or no quotes
Hi,
It looks like new tests are required to check that the behaviour will not
change again.
Victor
Le mardi 24 février 2015, Gregory P. Smith a écrit :
> While porting some code from 2.7 to 3.4 I discovered that
> command.getstatusoutput() (renamed to subprocess.getstatusoutput() in 3.x)
> had
Hum, it's probably an attack of the Python 2 mafia who fight against Python 3!
Victor
2015-02-27 13:51 GMT+01:00 Geoffrey Spear :
> The download button (for Windows anyway) on the python.org Download dropdown
> menu is broken; there's a small gray square where the 3.4.3 button should
> be, with t
Where is the patch?
Victor
Le lundi 2 mars 2015, Neil Girdhar a écrit :
> Hi everyone,
>
> The patch is ready for review now, and I should have time this week to
> make changes and respond to comments.
>
> Best,
>
> Neil
>
> On Wed, Feb 25, 2015 at 2:42 PM, Guido van Rossum > wrote:
>
>> I'm b
2015-03-03 6:25 GMT+01:00 Chris Barker :
> As far as I can tell, the math module is entirely a C extension. So I can:
> (...)
> 2) Write it in Python, and monkey-patch it in to the math module -- I
> honestly have no idea how to do that, but as I can add a new name to the
> math module after import
2015-03-03 10:17 GMT+01:00 Victor Stinner :
> Maybe it's time to rename the math module to _math and create a
> math.py module, like _decimal/decimal? math.py should end with "from
> _math import *".
Since the idea looks to be well accepted, I proposed a pat
Hi,
=> I propose to ignore BrokenPipeError on Popen.__exit__(), what do you think?
A recent issue fixed subprocess.Popen.__exit__() to read the exit
status of the child process, even if stdin.close() raised a
BrokenPipeError:
http://bugs.python.org/issue21619
When I saw the issue, I was surprise
Hi,
FYI I commited the implementation of os.scandir() written by Ben Hoyt.
I hope that it will be part of Python 3.5 alpha 2 (Ben just sent the
final patch today).
Please test this new feature. You may benchmark here.
http://bugs.python.org/issue22524 contains some benchmark tools and
benchmark r
2015-03-08 3:31 GMT+01:00 Ben Hoyt :
> Thanks for committing this, Victor! And fixing the d_type issue on funky
> platforms.
You're welcome.
> Note that the actual CPython version of os.walk() doesn't yet use
> os.scandir(). I intend to open a separate issue for that shortly (or Victor
> can). Bu
Le 11 mars 2015 18:29, "Brett Cannon" a écrit :
> I'm going to propose a somewhat controversial idea: let's deprecate the
ctypes module.
In the past I tried to deprecate many functions or modules because they are
rarely or never used. Many developers prefered to keep them. By the way, I
still wan
2015-03-18 16:46 GMT+01:00 Orion Poplawski :
> We're starting a discussion in Fedora about setting the default shbang for
> system python executables and/or daemons to python -s or python -Es (or ?).
Python 3.4 has -I which is more strict than -Es.
It remembers me "Perl suid", /usr/bin/sperl. May
2015-03-19 21:47 GMT+01:00 Toshio Kuratomi :
> I think I've found the Debian discussion (October 2012):
>
> http://comments.gmane.org/gmane.linux.debian.devel.python/8188
>
> Lack of PYTHONWARNINGS was brought up late in the discussion thread
Maybe we need to modify -E or add a new option to only
Le samedi 21 mars 2015, Serhiy Storchaka a écrit :
>
> For example binascii.crc32(). It has two positional parameters, one is
mandatory, and one is optional with default value 0. With Argument Clinic
its signature is crc32(data, crc=0, /).
The \ is useful, it indicates that you cannot use keyw
Hi Paul,
Please open an issue, I can take a look. Please describe a scenario to
reproduce the issue.
Victor
2015-03-22 15:44 GMT+01:00 Paul Moore :
> Something that hit me today, which might become a more common issue
> when the Windows installers move towards installing to the user
> directory,
2015-03-26 11:52 GMT+01:00 Andrew Svetlov :
> There is another issue: exception chain is not set up on exception
> creation in python code, only on throwing.
I'm not suprised of that.
> Thus I have to assign `__context__` and `__cause__` attributes
> manually if I want to call `future.set_excepti
on returns NULL without an exception set, or if a C
function returns a result with an exception set.
Victor
PEP: 490
Title: Chain exceptions at C level
Version: $Revision$
Last-Modified: $Date$
Author: Victor Stinner
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 25-Ma
Thanks Serhiy for your review, I modified the PEP. I just sent a first
draft (including your suggestions) to python-dev.
Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://ma
2015-03-19 10:28 GMT+01:00 Serhiy Storchaka :
> https://bugs.python.org/issue23681
> Have -b warn when directly comparing ints and bytes
closed
> https://bugs.python.org/issue23676
> Add support of UnicodeTranslateError in standard error handlers
commented
> https://bugs.python.org/issu
Hi,
Can you please take a look at the following issue and try to reproduce it?
http://bugs.python.org/issue23771
The following tests sometimes hang on "x86 Ubuntu Shared 3.x" and
"AMD64 Debian root 3.x" buildbots:
- test_notify_all() of test_multiprocessing_spawn
- test_double_close_on_error() o
Hi,
The buildbot AMD64 OpenIndiana 3.x is always red since at least 6
months. Almost always, tests fail because the buildbot has not enough
memory. Well, it's fun to see how Python handles MemoryError (it's
pretty good, there is no hard crash! my work on failmalloc was maybe
useful ;-)), but it do
Hi,
The buildbot x86 XP-4 3.x doesn't compile anymore since 3 months or
more (maybe when Steve upgraded the Visual Studio project to VS 2015?
I don't know).
Would it be possible to fix this buildbot, or to turn it off?
By the way, do we seriously want to support Windows XP? I mean, *who*
will ma
Hi,
The OpenBSD buildbot always fail with the same failures since many
months (ex: test_socket). Is someone interested to fix them? If no,
would it be possible to turn it off to get a better view of
regressions? Currently, they are too many red buildbots to quickly see
regressions introduced by re
Hi,
There are many failures on the AIX buildbot. Can someone try to fix
them? Or would it be possible to turn off the buildbot to quickly see
regressions?
http://buildbot.python.org/all/builders/PPC64%20AIX%203.x/builds/3426/steps/test/logs/stdio
The buildbot has not enough memory, and some test
Le samedi 28 mars 2015, Tim Golden a écrit :
>
> For myself I'm quite willing for someone to ping me with: "there's a
> Windows buildbot gone red; can you have a look?" But I have precious little
> time, and if the failure requires me to garner an understanding of a
> deep-level code change, a ver
Mar 28, 2015 at 8:39 PM, Victor Stinner
> > > wrote:
> >> Are you able to reproduce these issues? I'm unable to reproduce them
> >> on Fedora 21. Maybe they are more likely on Debian-like operating
> >> systems?
> >
> > I just tried it on my Deb
Le 28 mars 2015 21:15, "David Bolen" a écrit :
> I'm assuming you aren't suggesting turning off the XP buildbot
> entirely, correct?
I'm talking about the 3.x slave, so only python 3.5.
Would it be possible to specify in What's New In Python 3.5 which Windows
versions are no more supported?
Vi
Hi,
2015-03-28 12:26 GMT+01:00 Chris Angelico :
> It seems to be stalling out. I'm not sure exactly what's happening
> here. Running just that one file doesn't do it, but running the full
> test suite results in a stall.
Ok, I reproduced the issue on David's buildbot. A (child) process was
stuck
Hi Serhiy,
2015-03-28 17:40 GMT+01:00 Serhiy Storchaka :
> Just run tests with low memory limit.
>
> (ulimit -v 6; ./python -m test.regrtest -uall -v
> test_multiprocessing_spawn;)
>
> test_io also hangs.
I confirm that some tests using threads hang under very low memory
condition. At bootstr
Hi,
2015-03-30 8:06 GMT+02:00 Serhiy Storchaka :
>> +What's New in Python 3.5.0 alpha 4?
>> +===
>
> Return time machine back Victor. Current version is 3.5.0a2+.
Larry Hastings and Ned Deily told me that Larry is releasing Python
3.5 alpha 3. You can see their rep
Hi,
2015-03-30 10:46 GMT+02:00 Larry Hastings :
> On behalf of the Python development community and the Python 3.5 release
> team, I'm thrilled to announce the availability of Python 3.5.0a3. Python
> 3.5.0a3 is the third alpha release of Python 3.5, which will be the next
> major release of Pyt
Le mercredi 1 avril 2015, Davin Potts a écrit :
>
> I am personally interested in seeing all tests pass on OpenBSD and am
> willing to put forth effort to help that be so.
Great!
> I would be happy to be added to any issues that get opened against
> OpenBSD.
You can do a search in bugs.pytho
Hi,
2015-03-29 21:03 GMT+02:00 Jesus Cea :
> I have contacted the machine manager and he has said to me that 16GB
> were taken in the "/tmp" directory by buildbot user. He has deleted them
> and everything should be fine now. Lets see.
>
> Anyway if buildbot is leaving garbage behind we should tak
Hi,
2015-04-01 12:47 GMT+02:00 Tim Golden :
> On the back of Victor's recent emails re buildbots, I've knocked
> something up which can be scheduled to email the status of some or all
> buildbots:
>
> https://github.com/tjguk/buildbotinfo
Are you aware of this previous project?
https://code.goo
Hi,
I reworked the socket and ssl modules to better handle signals (to
implement the PEP 475, retry on EINTR). These changes require to
recompute timeout because syscalls are calling in a loop until it
doesn't with EINTR (or EWOULDBLOCK or EGAIN). Most socket methods exit
when the underlying sysca
he same timeout, and it always fail
with EINTR.
Victor
2015-04-03 13:56 GMT+02:00 Victor Stinner :
> Hi,
>
> I reworked the socket and ssl modules to better handle signals (to
> implement the PEP 475, retry on EINTR). These changes require to
> recompute timeout because syscalls
Le samedi 4 avril 2015, Ludovic Gasc a écrit :
>
> From a user's point of view, it should count for the total time, IMO.
>> If people want a timeout for each syscall, they should call send()
>> iteratively.
>
>
> I'm agree with Antoine for a global timeout.
>
Ok, I also agree. I will modify send
Hi,
Guido van Rossum python.org> writes:
> I'm slowly warming up to Greg's notion that you can't call a coroutine (or
whatever it's called) without a special keyword.
A huge part of the asyncio module is based on "yield from fut" where fut is
a Future object.
How do you write this using the PEP
Greg Ewing canterbury.ac.nz> writes:
> I still don't like the idea of hijacking the generic
> term "coroutine" and using it to mean this particular
> type of object.
There are only two hard things in Computer Science: cache invalidation
and naming things.
-- Phil Karlton
:-)
When revie
(I prefer to start a new thread, the previous one is too long for me :-))
Hi,
I'm still trying to understand how the PEP 3152 would impact asyncio.
Guido suggests to replace "yield from fut" with "cocall fut()" (add
parenthesis) and so add a __cocall__() method to asyncio.Future.
Problem: PEP 315
2015-04-23 17:22 GMT+02:00 :
> I can live with `cocall fut()` but the difference between `data = yield from
> loop.sock_recv(sock, 1024)` and `data = cocall (loop.sock_recv(sock,
> 1024))()` frustrates me very much.
You didn't answer to my question. My question is: is it possible to
implement Fut
Hi,
2015-04-23 17:54 GMT+02:00 Yury Selivanov :
> Greg wants to implement __cocall__ on futures. This way
> you'll be able to write
>
>cocall fut() # instead of "await fut"
Oh, I missed something in the PEP 3152: a obj__cocall__() method can
be an iterator/generator, it can be something dif
Hi,
2015-04-24 19:03 GMT+02:00 Guido van Rossum :
> 1. precise syntax of `async def`
>
> Of all the places to put `async` I still like *before* the `def` the best.
So do I.
> 2. do we need `async for` and `async with`
>
> Yes we do.
I agree.
> 3. syntactic priority of `await`
>
> Yury, could
Hi Greg,
2015-04-25 7:02 GMT+02:00 Greg Ewing :
>> I accept the compromise of creating a coroutine object without wait
>> for it (obvious and common bug when learning asyncio). Hopefully, we
>> keep the coroutine wrapper feature (ok, maybe I suggested this idea to
>> Yury because I suffered so muc
2015-04-25 8:23 GMT+02:00 Greg Ewing :
> But how is an awaitable supposed to raise StopIteration
> if it's implemented by a generator or async def[*] function?
> Those things use StopIteration to wrap return values.
>
> I like the idea of allowing StopIteration to be raised
> in an async def functi
Le 25 avr. 2015 23:02, "Yury Selivanov" a écrit :
> I agree. I plan to update the PEP with some new
> semantics (prohibit passing coroutine-objects to iter(),
> tuple() and other builtins, as well as using them in
> 'for .. in coro()' loops). I'll add a section with
> a more detailed explanation
Hi,
2015-04-27 16:02 GMT+02:00 Petr Viktorin :
> A macro like this would reduce boilerplate in stdlib and third-party C
> extensions. It would ease porting C extensions to Python 3, where rich
> comparison is mandatory.
It would be nice to have a six module for C extensions. I'm quite sure
that m
Le 29 avr. 2015 10:36, "Adam Bartoš" a écrit :
> Why I'm talking about PyCF_SOURCE_IS_UTF8? eval(u"u'\u03b1'") ->
u'\u03b1' but eval(u"u'\u03b1'".encode('utf-8')) -> u'\xce\xb1'.
There is a simple option to get this flag: call eval() with unicode, not
with encoded bytes.
Victor
_
Hi,
2015-05-06 1:53 GMT+02:00 Guido van Rossum :
> In order to save myself a major headache I'm hereby accepting PEP 492.
Great! Congrats Yury.
> I've given Yury clear instructions to focus on how to proceed -- he's to
> work with another core dev on getting the implementation ready in time for
I always wanted this feature (no kidding).
Would it be possible to add support for the context manager?
with noop(): ...
Maybe noop can be an instance of:
class Noop:
def __enter__(self, *args, **kw): return self
def __exit__(self, *args): pass
def __call__(self, *args, **kw): return self
;nope'
---
Example:
---
noop = Noop()
print(noop)
print(noop())
with noop() as nope:
print(nope)
with noop as well:
print(well)
---
Output:
---
nope
nope
nope
nope
---
IHMO the real question is if we need a Noop.nope() method?
Victor
2017-09-09 12:54 GMT-07:00 Victor Stinner :
> I alway
Previous discussion: https://bugs.python.org/issue10049
Issue closed as rejected.
Victor
2017-09-09 14:33 GMT-07:00 Victor Stinner :
> I was able to find a real keyboard, so here is a more complete code:
> ---
> class Noop:
> def __call__(self, *args, **kw):
> return
2017-09-10 11:42 GMT+02:00 Skip Montanaro :
> I chair ISO/IEC/JTC1/SC22/WG23 Programming Language Vulnerabilities. We
> publish an international technical report, ISO IEC TR 24772 Guide to
> avoiding programming language vulnerabilities through language selection
> use. Annex D in this document add
2017-09-11 19:00 GMT+02:00 Chris Barker :
> I wish there were a property feature available almost very time I encounter
> a "get*" method in the stdlib (or any where):
>
> There are a heck of a lot in the os module:
>
> In [4]: [s for s in dir(os) if s.startswith('get')]
> Out[4]:
>
> ['get_blockin
Hi,
In March 2015, I proposed the PEP 490 to chain implicitly C exceptions
by default:
https://www.python.org/dev/peps/pep-0490/
The discussion on python-dev was quickly in favor of keeping the
status quo: don't chain C exceptions by default, but only do that
explicitly where it makes sense.
I
Hi,
Last week, the National Security Authority of Slovakia contacted the
Python Security Response Team (PSRT) to report that the Python Package
Index (PyPI) was hosting malicious packages. Installing these packages
send user data to a HTTP server, but also install the expected module
so it was an
but don't provide any download file?
With no download file, the user will likely understand his/her error,
no?
Note: I don't think that Benjamin Bach and Hanno Böck are related to
the PSRT nor PyPI administrators.
Victor
2017-09-15 22:28 GMT+02:00 Victor Stinner :
> Hi,
>
>
An idea for typo squatting would be to compute the Levenshtein
distance with package names of standard library and top 100 most
popular PyPI packages, and require to contact a moderation team if the
name is too close to an existing package. The moderation team will
review the email, but also watch
Hi,
Python 3 added a __traceback__ attribute to exception objects. I guess
that it was added to be able to get the original traceback when an
exception is re-raised. Artifical example (real code is more complex
with subfunctions and conditional code):
try:
...
except Exception as exc:
...
Hum, my email is long. Maybe an short example is simpler to understand:
---
import gc
class VerboseDestructor:
# Imagine an object using many limited resources like memory,
# sockets and/or files
def __del__(self):
print("VerboseDestructor")
def create_ref_cycle():
obj = V
2017-09-18 12:07 GMT+02:00 Nick Coghlan :
> I wonder if it might be reasonable to have tracebacks only hold a weak
> reference to their frame objects when "__debug__ == False".
Please don't change the Python behaviour depending on __debug__, or it
will be a nightmare to debug it :-( ("Why does it
mailing list to stay tuned!
https://mail.python.org/mailman/listinfo/security-announce
Victor
2017-09-15 22:28 GMT+02:00 Victor Stinner :
> Hi,
>
> Last week, the National Security Authority of Slovakia contacted the
> Python Security Response Team (PSRT) to report that the Python Pac
Hi,
In bpo-29400, it was proposed to add the ability to trace not only
function calls but also instructions at the bytecode level. I like the
idea, but I don't see how to extend sys.settrace() to add a new
"trace_instructions: bool" optional (keyword-only?) parameter without
breaking the backward
2017-09-28 3:54 GMT+02:00 Ezio Melotti :
> This update included ~300 changesets from upstream and required an
> additional ~30 to update our instances and our fork of Roundup. A number of
> features that we added to our fork over the years have been ported upstream
> and they have now been removed
2017-10-02 13:10 GMT+02:00 INADA Naoki :
> https://github.com/python/cpython/pull/3796
> In this PR, lazy loading only happens when uuid1 is used.
> But uuid1 is very uncommon for nowdays.
Antoine Pitrou added a new C extension _uuid which is imported as soon
as uuid(.py) is imported. On Linux at
Please start a new thread on python-dev. It's unrelated to
"deterministic pyc files".
Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/pytho
2017-10-02 16:48 GMT+02:00 Christian Heimes :
> That approach could work, but I think that it is the wrong approach. I'd
> rather keep Python optimized for long-running processes and introduce a
> new mode / option to optimize for short-running scripts.
"Filling caches on demand" is an old pattern
> * RegexFlag.__and__ and __new__ is called very often.
Yeah, when the re module was modified to use enums for flags,
re.compile() became slower:
https://pyperformance.readthedocs.io/cpython_results_2017.html#slowdown
https://speed.python.org/timeline/#/?exe=12&ben=regex_compile&env=1&revs=200&eq
Hi,
Good news: Python 3.6.3 has no more known security vulnerabilities ;-)
Python 3.6.3 fixes two security vulnerabilities:
"urllib FTP protocol stream injection"
https://python-security.readthedocs.io/vuln/urllib_ftp_protocol_stream_injection.html
"Expat 2.2.3" (don't impact Linux, since Linux
Hi,
Python uses a few categories to group bugs (on bugs.python.org) and
NEWS entries (in the Python changelog). List used by the blurb tool:
#.. section: Security
#.. section: Core and Builtins
#.. section: Library
#.. section: Documentation
#.. section: Tests
#.. section: Build
#.. section: Wind
2017-10-04 14:36 GMT+02:00 Antoine Pitrou :
> If there's a crash in socket.sendmsg() that affects mainly
> multiprocessing, should it be in "Networking", "Security" or
> "Parallelism"?
bugs.python.org allows you to select zero or *multiple* categories :-)
It's common that categories of a bug evol
I concur with Antoine, please don't add a special case for -E. But it seems
like you already agreed with that :-)
Victor
Le 5 oct. 2017 05:33, "Barry Warsaw" a écrit :
> On Oct 4, 2017, at 21:52, Nick Coghlan wrote:
> >
> >> Unfortunately we probably won’t really get a good answer in practice
> What if make the default value depending on the debug level? In debug mode
> it is "pdb.set_trace", in optimized mode it is "0". Then in production
> environments you can use -E -O for ignoring environment settings and disable
> breakpoints.
I don't know what is the best option, but I dislike ad
Hi,
2017-10-10 21:49 GMT+02:00 Richard Hinerfeld :
> test_gdb skipped -- gdb not built with embedded python support
> (...)
> Please note I have downloaded a new version of GDB and compiled it with
> the config option --with-python.
> I then installed it on my system.
Python looks for "gdb" progr
picoseconds?
The PEP 564 will be shortly online at:
https://www.python.org/dev/peps/pep-0564/
Victor
PEP: 564
Title: Add new time functions with nanosecond resolution
Version: $Revision$
Last-Modified: $Date$
Author: Victor Stinner
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created
I read again the discussions on python-ideas and noticed that I forgot
to mention the "time_ns module" idea. I also added a section to give
concrete examples of the precision loss.
https://github.com/python/peps/commit/a4828def403913dbae7452b4f9b9d62a0c83a278
Issues caused by precision loss
-
2017-10-16 17:06 GMT+02:00 Antoine Pitrou :
>> This PEP adds five new functions to the ``time`` module:
>>
>> * ``time.clock_gettime_ns(clock_id)``
>> * ``time.clock_settime_ns(clock_id, time: int)``
>> * ``time.perf_counter_ns()``
>> * ``time.monotonic_ns()``
>> * ``time.time_ns()``
>
> Why not ``
2017-10-16 17:37 GMT+02:00 Ben Hoyt :
> I've read the examples you wrote here, but I'm struggling to see what the
> real-life use cases are for this. When would you care about *both* very
> long-running servers (104 days+) and nanosecond precision? I'm not saying it
> could never happen, but would
2017-10-16 17:42 GMT+02:00 Antoine Pitrou :
> Restricting this PEP to the time module would be fine with me.
Maybe I should add a short sentence to keep the question open, but
exclude it from the direct scope of the PEP? For example:
"New nanosecond flavor of these functions may be added later, i
2017-10-16 18:14 GMT+02:00 Ben Hoyt :
> Got it -- fair enough.
>
> We deploy so often where I work (a couple of times a week at least) that 104
> days seems like an eternity. But I can see where for a very stable file
> server or something you might well run it that long without deploying. Then
> a
2017-10-16 18:28 GMT+02:00 Antoine Pitrou :
>> What do you think?
>
> It sounds fine to me!
Ok fine, I updated the PEP. Let's start simple with the few functions
(5 "clock" functions) which are "obviously" impacted by the precission
loss.
Victor
___
Pyt
Oh, now I'm confused. I misunderstood your previous message. I understood
that you changed you mind and didn't want to add process_time_ns().
Can you elaborate why you consider that time.process_time_ns() is needed,
but not the nanosecond flavor of os.times() nor resource.getrusage()? These
functi
Hi,
FYI I just merged two pull requests into Python 2.7, each add a new
environment variable changing the behaviour in debug mode:
bpo-31733: don't dump "[xxx refs]" into stderr by default anymore
Set PYTHONSHOWREFCOUNT=1
commit 3c082a7fdb472f02bcac7a7f8fe1e3a34a11b70b
bpo-31692, bpo-19527: don'
> Since the ``time.clock()`` function was deprecated in Python 3.3, no
> ``time.clock_ns()`` is added.
FYI I just proposed a change to *remove* time.clock() from Python 3.7:
https://bugs.python.org/issue31803
This change is not required by, nor directly related to, the PEP 564.
Victor
__
101 - 200 of 3215 matches
Mail list logo
