[issue27267] memory leak in _ssl.c, function load_cert_chain

Roundup Robot added the comment: New changeset 66cd109f3f21 by Benjamin Peterson in branch '2.7': stop leaking certfile_bytes (closes #27267) https://hg.python.org/cpython/rev/66cd109f3f21 -- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Larry Hastings added the comment: AFAICT, the history is, Linux added /dev/urandom, then all the other UNIXes followed suit. I've read a lot of man pages for /dev/urandom (or equivalent) on a lot of different platforms and most of them say "this was added to Linux, so we added our own version

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

STINNER Victor added the comment: IHMO we only need two functions. os.urandom() is now documented as the reference for security. So we need a new function. I proposed a new urandom() parameter, but a new function without parameter would also be ok. If os.getrandom() is directly a binding of Linu

[issue27276] FileFinder.find_spec() incompatible with finder specification

Changes by Paul Marinescu : -- resolution: -> not a bug status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue27276] FileFinder.find_spec() incompatible with finder specification

New submission from Paul Marinescu: importlib.machinery.FileFinder.find_spec is incompatible with importlib.abc.MetaPathFinder.find_spec (different number of arguments). The following leads to a runtime error: loader = (importlib.machinery.SourceFileLoader, importlib.machinery.SOURCE_SUFFIXES

[issue27275] KeyError thrown by optimised collections.OrderedDict.popitem()

Serhiy Storchaka added the comment: Could you please provide short example? -- nosy: +serhiy.storchaka stage: -> test needed ___ Python tracker ___ _

[issue16132] ctypes incorrectly encodes .format attribute of memory views

Martin Panter added the comment: In Python 3.5 (since Issue 15944), you can now cast normal C-contiguous memoryviews (including ones from ctypes) to bytes: >>> a = (ctypes.c_double * 3)(1,2,3) >>> m = memoryview(a) >>> m.format '>> byteview = m.cast("B") >>> byteview.format 'B' >>> byteview[0]

[issue27272] random.Random should not read 2500 bytes from urandom

Tim Peters added the comment: Donald, it does matter. The code you found must be using some older version of Python, because the Python 3 version of randint() uses _randbelow(), which is an accept/reject method that consumes an _unpredictable_ number of 32-bit Twister outputs. That utterly d

[issue27275] KeyError thrown by optimised collections.OrderedDict.popitem()

New submission from William Pitcock: The C-based optimised version of collections.OrderedDict occasionally throws KeyErrors when deleting items. See https://github.com/mailgun/expiringdict/issues/16 for an example of this regression. Backporting 3.6's patches to 3.5.1 does not resolve the iss

[issue26955] Implement equivalent to `pip.locations.distutils_scheme` in distutils

Sylvain Corlay added the comment: We use it in the pybind11 project. I am not sure that homebrew does anything wrong. It is just that it is the only case I am aware of where the `install_headers` command does not install headers in a subdirectory of `sysconfig.get_path('include')`. On the oth

[issue27272] random.Random should not read 2500 bytes from urandom

Donald Stufft added the comment: Tim, If MT is used in any of the security sensitive contexts that paper mentions, then it doesn't matter if you seed it with a static zero or a billion bytes read from the purest of purestrain randomness, your application is broken. In other words, it doesn't

[issue27274] [ctypes] Allow from_pointer creation

Memeplex added the comment: I would like to add some information about my use case. Many c structs have pointers to arrays of data plus some field indicating the length of those arrays. Sometimes I need to pickle that kind of structs and a bytes object has to somehow be created from each point

[issue26565] [ctypes] Add value attribute to non basic pointers.

Memeplex added the comment: Related: http://bugs.python.org/issue27274. Maybe ptr.toaddress? As opposed to addressof(ptr). I think ptr.address might be confusing as it's intutive meaning is closer to addressof(ptr). -- ___ Python tracker

[issue27272] random.Random should not read 2500 bytes from urandom

Tim Peters added the comment: Didn't anyone here follow the discussion about the `secrets` module? PHP was crucified by security wonks for its horridly naive ways of initializing its PRNGs: https://media.blackhat.com/bh-us-12/Briefings/Argyros/BH_US_12_Argyros_PRNG_WP.pdf Please don't even t

[issue27274] [ctypes] Allow from_pointer creation

New submission from Memeplex: This real life example is pretty terrible: (ct.c_float * self._nfeats).from_address( ct.addressof(self._vals.contents)) The alternative of casting the pointer to pointer-to-array, then pick ptr.contents is not really better. What about a from_pointer(ptr) meth

[issue27272] random.Random should not read 2500 bytes from urandom

Martin Panter added the comment: If the seed is to be based on time.time(), why not use something based on hash(time.time()) to avoid the 1/256 s resolution? If there is a practical way to get pseudo-random data from the platform, it would be better to use that, rather than cooking up our own

[issue27271] asyncio lost udp packets

valdemar pavesi added the comment: thanks Guido I will keep working with it. I am not able to debug between socket and asyncio-read-udp. There is no bottleneck on cpu/memory or network card. I cannot write debug with this heavy udp load. if I decrease the UDP per second then this problem go

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Larry Hastings added the comment: Victor: just to confirm, would "os.getrandom(n, block=True)" be okay with you? Do you strongly prefer adding the "block" parameter to os.urandom(), or do you not care much? -- ___ Python tracker

[issue27066] SystemError if custom opener returns -1

Changes by Berker Peksag : -- stage: patch review -> resolved ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: h

[issue27179] subprocess uses wrong encoding on Windows

Changes by Dāvis : Added file: http://bugs.python.org/file43316/subprocess_fix_encoding_v4fixed.patch ___ Python tracker ___ ___ Python-bugs-

[issue27179] subprocess uses wrong encoding on Windows

Changes by Dāvis : Removed file: http://bugs.python.org/file43315/subprocess_fix_encoding_v4.patch ___ Python tracker ___ ___ Python-bugs-list

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

STINNER Victor added the comment: About the "add block=False parameter to os.urandom()" part of the issue title: I don't really care of the exact API. It can be a new function. The parameter can be named differently. The idea is to give access to users to Linux non-blocking /dev/urandom, and d

[issue27179] subprocess uses wrong encoding on Windows

Dāvis added the comment: > Note that patch 3 requires setting `encoding` for even python.exe as a child > process, because sys.std* default to ANSI when isatty(fd) isn't true. I've updated my patch so that Python outputs in consoles encoding for pipes too. So now in PowerShell >[Console]::Out

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Donald Stufft added the comment: > Again, I cite #25003: he implicitly ruled there that it's not permissible for > os.urandom() to block on Solaris, so I think he agrees with me. To be clear, that's an entirely different kind of blocking. That made os.urandom on Solaris behave similarly to /de

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Larry Hastings added the comment: > Larry, I'm sorry but I think you're just flat wrong here and I don't know > what else to say about it. Yeah, I think maybe asking Guido to make a ruling would be the right thing here. Again, I cite #25003: he implicitly ruled there that it's not permissibl

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Larry Hastings added the comment: > As a process comment: I agree with what Victor wrote in > http://haypo-notes.readthedocs.io/pep_random.html#status-of-python-3-5-2, > when he suggests that we leave 3.5.2 as is for now [...] I agree in principle. Certainly we all agree it'd be inappropriate

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Larry Hastings added the comment: > I'd also *STRONGLY* request that we avoid adding any new APIs in relation to > this that mean "Use os.urandom" is no longer the preferred option to obtain > cryptographically strong random numbers in Python. According to the documentation, os.urandom() does

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Nick Coghlan added the comment: As a process comment: I agree with what Victor wrote in http://haypo-notes.readthedocs.io/pep_random.html#status-of-python-3-5-2, when he suggests that we leave 3.5.2 as is for now (i.e. reverted to be consistent with 2.7 and 3.4, which favours a risk of subtle

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Donald Stufft added the comment: Python should strive do the right thing, and the right thing for something as security sensitive as accessing a CSPRNG is to use the interface that most strongly promises to in fact, give cryptographically secure random numbers. Obsessing over the purity of mat

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Larry Hastings added the comment: > Regardless of the behavior of os.urandom (and 'import random'), is it agreed > that the current state of _PyRandom_Init is acceptable for 3.5.2? I'll get back to you with a specific yes or no. What I want is that it the behavior removed where "import random

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Nick Coghlan added the comment: Transferring a comment I previously made on #27250: One request I'd make in these discussions is that we avoid using the term "block" - it makes people think of the /dev/random behaviour (i.e. blocking intermittently and unhelpfully), rather than the usually-des

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Larry Hastings added the comment: > I don't think most people calling os.urandom have any idea how /dev/urandom > behaves on their machine nor do I think most people have any idea how > /dev/urandom behaves on other people's machines. Here I invoke the "consenting adults" rule. In Python deve

[issue27273] subprocess.run(cmd, input='text') should pass universal_newlines=True to Popen

New submission from Akira Li: At the moment, subprocess.run(cmd, input='text') raises TypeError. It would be nice if universal_newlines=isinstance(input, str) if *input* is set. I've attached a corresponding patch with the necessary changes to the docs, tests and the subprocess.run() code. ---

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Larry Hastings added the comment: Wait a minute. If I read the code correctly, currently os.urandom() is implemented strictly using getrandom() *on all platforms*. And if block=false, it... returns an empty buffer? Am I reading that right? And what does it do on platforms that don't have a

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Donald Stufft added the comment: > The block= parameter confuses the matter greatly, which is why I oppose it. I don't like the block= parameter. > I assert that people are calling os.urandom() because they expect it to > behave like /dev/urandom on their machine. I don't think most people ca

[issue27250] Add os.urandom_block()

Nick Coghlan added the comment: Victor, given the assumption that internal hashing and the random module will change to no longer depend on os.urandom, are you happy to close this one in favour of #27250? -- ___ Python tracker

[issue27250] Add os.urandom_block()

Nick Coghlan added the comment: One request I'd make in these discussions is that we avoid using the term "block" - it makes people think of the /dev/random behaviour (i.e. blocking intermittently and unhelpfully), rather than the usually-desired "wait for sufficient entropy on system startup"

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Larry Hastings added the comment: Let me make one more thing clear. I'm willing for os.urandom() to try to use getrandom(GRND_NOBLOCK) (or whatever the flag is called). This will not block unless the entropy pool is low--which almost never happens. So 99.% of the time, os.urandom() shou

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Changes by Nick Coghlan : -- nosy: +ncoghlan ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Larry Hastings added the comment: > There are a number of functions in os.py that add additional logic ontop of > the system calls, like: All the functions you name don't have POSIX equivalents, except popen and scandir. popen provides a lot of functionality around popen (which internally doe

[issue27250] Add os.urandom_block()

Changes by Nick Coghlan : -- nosy: +ncoghlan ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Changes by Nick Coghlan : -- nosy: +ncoghlan ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue27271] asyncio lost udp packets

Guido van Rossum added the comment: You have not convinced anyone that this is asyncio's fault. I'm closing the issue. If you need help debugging this please use the python-tulip Google Group; if in the end it is found to be an asyncio issue we'll help you file a useful bug report on the async

[issue27271] asyncio lost udp packets

valdemar pavesi added the comment: hi, I did made a change, removing the queue and calling corotine. and now lost udp is bigger. def datagram_received(self, data, addr): asyncio.ensure_future(process_report(data)) @asyncio.coroutine def process_report(data): tcmpdump got 38122

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Donald Stufft added the comment: > > there is a lot of code out there using os.urandom for it's security > > properties > > This is exactly why we should not change the behavior of os.urandom(). > os.urandom() must not block on Linux. So defaulting to block=True on Linux > is a non-starter.

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Larry Hastings added the comment: os.getrandom() would be a thin shell around what the local OS provides, and has the advantage of behaving in a predictable manner. If you provide block=, its implementation and semantics will vary wildly between platforms. * On Linux, block=False should be th

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Donald Stufft added the comment: I also contest the idea that os functions must only be thin shells around system provided calls (even though I don't think that using getrandom instead of reading from /dev/urandom violates that assertion). There are a number of functions in os.py that add addi

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Donald Stufft added the comment: I think a new function is a bad idea TBH, os.urandom provides 99% of the right interface on Linux, and 100% of the right interface on other OSes and there is a lot of code out there using os.urandom for it's security properties, and a lot of people educating us

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Donald Stufft added the comment: It would still be a thin shell around what the OS provides, it'd just be a thin wrapper around getrandom() instead of around /dev/urandom specifically-- but accessing the same content. -- ___ Python tracker

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Larry Hastings added the comment: This is why I'm unwilling to accept this change in 3.5.2. This sort of "we think it's right" behavior is only appropriate in a point release like 3.6. I think odds are better than even that I'm going to get an os.getrandom(n, block=True) call in 3.5.2. It so

[issue27136] sock_connect fails for bluetooth (and probably others)

A. Jesse Jiryu Davis added the comment: The asyncio fix was proposed and reviewed here: https://github.com/python/asyncio/pull/357 -- ___ Python tracker ___

[issue27250] Add os.urandom_block()

STINNER Victor added the comment: IMHO "Should os.urandom() block before the kernel collected enough entropy?" is the last major question in the large discussion around random: https://haypo-notes.readthedocs.io/pep_random.html#os-urandom It became clear that Python at startup should use a weak

[issue27250] Add os.urandom_block()

STINNER Victor added the comment: > Should this ticket be named "Add os.random()" ? After all, blocking in case > of missing entropy is what /dev/random is all about. In short, /dev/random must not be used :-) See: https://haypo-notes.readthedocs.io/pep_random.html#rng-denial-of-service --

[issue27249] Add os.urandom_info

STINNER Victor added the comment: The current trend in the random discussion (see https://haypo-notes.readthedocs.io/pep_random.html and the issue #26839) is more to use weak entropy to start Python (hash seed and random constructor) and os.urandom() blocks until the kernel collected enough en

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

STINNER Victor added the comment: > Second, unless you can guarantee you support blocking / non-blocking behavior > on all platforms, this is a bad move. Well, there are two options: * Detect when os.urandom() is going to block, and falls back to weaker entropy (Linux: /dev/urandom in non-blo

[issue27256] header indentation destroyed

R. David Murray added the comment: Hmm. There appear to be at least two bugs here, using the SMTP policy. I thought I had test cases like this, but clearly I don't :( -- ___ Python tracker __

[issue27272] random.Random should not read 2500 bytes from urandom

Donald Stufft added the comment: One of the key take aways though is that MT doesn't really *need* to be initialized with a CSPRNG, all it needs it some moderately random data. So we can eliminate the case all together by just not using it. Though a sticking point is that it's documented to se

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

STINNER Victor added the comment: > The current behavior (as of 9de508dc4837) is that it will never block on > Linux, but could still block on other OS if called before /dev/urandom is > initialized. In practice, only Linux is impacted. See the rationale: https://haypo-notes.readthedocs.io/pep

[issue27239] Make idlelib.macosx self-contained.

Terry J. Reedy added the comment: I ran into this issue again with the test I am writing for another issue, so I pushed it as is, after testing. Ned, neither of the working OSX buildbots run gui tests. I am presuming that you run the test suite occasionally and will notice if test_idle fails.

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

STINNER Victor added the comment: I opened the issue #27272: "random.Random should not read 2500 bytes from urandom". -- ___ Python tracker ___ _

[issue27272] random.Random should not read 2500 bytes from urandom

Donald Stufft added the comment: To be clear, that was a minimal patch using a method that already existing. It could be made a lot better by mixing in other sources of entropy like PID#, id(self), etc. -- ___ Python tracker

[issue27272] random.Random should not read 2500 bytes from urandom

STINNER Victor added the comment: Donald Stufft proposed the patch no-urandom-by-default.diff in the issue #26839 which replaces os.urandom() with int(time.time()*256) in random.Random constructor. I dislike this change because it becomes more likely that two Python processes produce the same

[issue27272] random.Random should not read 2500 bytes from urandom

STINNER Victor added the comment: PHP uses GENERATE_SEED() to initialize mt_rand(): https://github.com/php/php-src/blob/1c295d4a9ac78fcc2f77d6695987598bb7abcb83/ext/standard/php_rand.h#L50 This macro uses: time() (resolution of 1 second), process identifier, php_combined_lcg() php_combined_lcg

[issue27239] Make idlelib.macosx self-contained.

Roundup Robot added the comment: New changeset cc7f63b6847e by Terry Jan Reedy in branch 'default': Issue #27239: idlelib.macosx.isXyzTk functions initialize as needed. https://hg.python.org/cpython/rev/cc7f63b6847e -- nosy: +python-dev ___ Python tra

[issue27257] get_addresses results in traceback with an addrspec with an empty local part.

R. David Murray added the comment: Yeah, it never occurred to me that the local part could be empty, so I never made a test case for that. The correct behavior should indeed to be to register a defect and set the local part to blank. I will not be surprised if there are other bits of the cod

[issue27272] random.Random should not read 2500 bytes from urandom

STINNER Victor added the comment: Related issue #26839. Don't read this very long issue! You can read my summary :-D https://haypo-notes.readthedocs.io/pep_random.html#bug-reports -- ___ Python tracker ___

[issue27066] SystemError if custom opener returns -1

Changes by Barry A. Warsaw : -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue27272] random.Random should not read 2500 bytes from urandom

New submission from STINNER Victor: Reading more than 256 bytes from os.urandom() is different than reading 256 bytes or less. For example, see getrandom() and getentropy() manual pages for more details. random.Random doesn't need a very high quality entropy. The glib library only reads 128 b

[issue27066] SystemError if custom opener returns -1

Roundup Robot added the comment: New changeset 4af64ab34eef by Barry Warsaw in branch '3.5': Issue #27066: Fixed SystemError if a custom opener (for open()) returns https://hg.python.org/cpython/rev/4af64ab34eef New changeset 84c91d7d4667 by Barry Warsaw in branch 'default': Issue #27066: Fixed

[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)

Michael Felt added the comment: aixutil.py renamed as _aixutil.py and other changes in response to Martin's comments of 4 June delta of changes to __init__.py, util.py, and test/test_loading.py -- Added file: http://bugs.python.org/file43312/python.Lib.ctypes.160608.patch

[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)

Michael Felt added the comment: aixutil.py renamed as _aixutil.py and other changes in response to Martin's comments of 4 June -- Added file: http://bugs.python.org/file43311/_aixutil.py ___ Python tracker ___

[issue27270] 'parentheses-equality' warnings when building with clang and ccache

Raymond Hettinger added the comment: I like this suggestion. -- nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing

[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)

aixtools added the comment: Answering this again - now that the new patch is ready. On 04-Jun-16 16:24, Martin Panter wrote: > Martin Panter added the comment: > > Okay here are some more thoughts about your latest patch: > > ## Automatic RTLD_MEMBER ## > > I was still uneasy about the automatic

[issue26826] Expose new copy_file_range() syscall in os module.

Marcos Dione added the comment: I added a couple of unit tests, which lead me to fix a couple of bugs (yay!). I discarded the idea of removing any reference to flags. -- Added file: http://bugs.python.org/file43310/copy_file_range.diff ___ Python tra

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Colm Buckley added the comment: Larry - Regardless of the behavior of os.urandom (and 'import random'), is it agreed that the current state of _PyRandom_Init is acceptable for 3.5.2? The current behavior (as of 9de508dc4837) is that it will never block on Linux, but could still block on other

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Changes by ppperry : -- title: Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing /arguinthe random module on getrandom() -> Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() _

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing /arguinthe random module on getrandom()

Marc-Andre Lemburg added the comment: On 08.06.2016 22:49, Larry Hastings wrote: > > Third, because the os module is in general a thin wrapper over what the OS > provides, I disapprove of "cryptorandom()" and "pseudorandom()" going into > the os module. There are no functions with these names

[issue27271] asyncio lost udp packets

Guido van Rossum added the comment: How do you know the OS kernel isn't dropping them? -- ___ Python tracker ___ ___ Python-bugs-list

[issue27271] asyncio lost udp packets

valdemar pavesi added the comment: I do understand the possibility to lose on udp. and I am monitoring all machines involved. I am not losing on network, I am losing between our network-card-dumpcap and read udp from socket. is it possible that read will be blocked and not able to read ? dur

[issue27271] asyncio lost udp packets

Yury Selivanov added the comment: Even if you increase buffers you will lose data over UDP. The reason can be the network, or the kernel may simply skip sending the data. To work with buffer sizes use transport.set_write_buffer_limits -- ___ Python

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing /arguinthe random module on getrandom()

Larry Hastings added the comment: I am increasingly convinced that I'm right. -- First, consider that the functions in the os module, as a rule, are a thin shell over the equivalent function provided by the operating system. If Python exposes a function called os.XYZ(), and it calls the OS,

[issue27271] asyncio lost udp packets

Yury Selivanov added the comment: > I think we could lose inside the network, but we cannot lose inside of our > application. UDP is fundamentally unreliable. It *will* lose data even over UNIX sockets. -- ___ Python tracker

[issue27271] asyncio lost udp packets

valdemar pavesi added the comment: I am not getting any pause, or any message about buffer full. def pause_reading(self): print('pause_reading') def resume_reading(self): print('resume_reading') and I cannot find a way to increase the receive buffer by asyncio. -- _

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing /arguinthe random module on getrandom()

Colm Buckley added the comment: @pitti - We already discussed this; there are cases where it's not practical to set an environment variable. The discussion eventually converged on "it is not desirable that Python should block on startup, regardless of system RNG status". Re: the triggering bu

[issue27271] asyncio lost udp packets

valdemar pavesi added the comment: thanks Yury, I think we could lose inside the network, but we cannot lose inside of our application. regards! Valdemar -- ___ Python tracker __

[issue26955] Implement equivalent to `pip.locations.distutils_scheme` in distutils

Tim Smith added the comment: As a Homebrew maintainer I'm happy to consider improving Homebrew's configuration if someone can point me to an extant package that uses this mechanism. -- nosy: +tdsmith ___ Python tracker

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing /arguinthe random module on getrandom()

Martin Pitt added the comment: > you could give some kind of command-line flag That already exists -- set PYTHONHASHSEED=0. > But I'll let someone else have the joys of negotiating with Lennart, and I > won't blame the Python devs if using GRND_NONBLOCK unconditionally is less > painful than

[issue27257] get_addresses results in traceback with a valid? header

Hans-Peter Jansen added the comment: Dear Stephen, thanks for your care. I'm glad, that you're able to reproduce it. This header is added from the email provider (the biggest here in Germany), so yes, it deserves an entry in the defects list, but must not traceback, of course. It is not expec

[issue27271] asyncio lost udp packets

Yury Selivanov added the comment: Isn't it normal for UDP to lose some packets? -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue27271] asyncio lost udp packets

New submission from valdemar pavesi: hello, I am using asyncio to handle 165 udp-packet per second everything received by (datagram_received) will be put into a queue. +++ 124605 UDP packets send from client. and received by server network: dumpcap ( filter "port 5 and len > 100" ) Pa

[issue7063] Memory errors in array.array

Changes by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Larry Hastings added the comment: > getentropy() is non-blocking. By the way, os.urandom() is now implemented > with getentropy() on OpenBSD. I quote issue #25003: > You can not substitute getentropy() for getrandom(), if you need randomness > then entropy does not suffice. -- _

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

STINNER Victor added the comment: Larry Hastings added the comment: > > First, DO NOT merge this change into 3.5.2 without my explicit permission. > I explicitly removed Python 3.5 from this issue to follow your request. See my previous comment :-) -- __

[issue27270] 'parentheses-equality' warnings when building with clang and ccache

New submission from Xavier de Gaye: Building Python with clang and ccache produces about 200 'parentheses-equality' warnings with the message: warning: equality comparison with extraneous parentheses [-Wparentheses-equality] It seems that clang does not recognize that these extraneous pare

[issue27129] Wordcode, part 2

Serhiy Storchaka added the comment: Here is a patch that just refactors the code. It renames OPCODE and OPCODE to _Py_OPCODE and _Py_OPCODE and moves them to code.h for reusing in other files. Introduces _Py_CODEUNIT as an alias to unsigned short (if it is 16-bit, otherwise a compile error is

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Theodore Tso added the comment: Larry, at least on FreeBSD, it sounds like the implementation could just the kern.random.sys.seeded sysctl, and return . (Note: what is the proposed behaviour if the PRNG is not seeded? Return Null?) As far as OpenBSD is concerned, it's true that it's getentro

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Larry Hastings added the comment: First, DO NOT merge this change into 3.5.2 without my explicit permission. Second, unless you can guarantee you support blocking / non-blocking behavior on all platforms, this is a bad move. -- ___ Python tracker <

[issue27262] IDLE: move Aqua context menu code to maxosx

Roundup Robot added the comment: New changeset 09ec7f7322b5 by Terry Jan Reedy in branch 'default': Issue #27262: move Aqua unbinding code, which enable context menus, to maxosx. https://hg.python.org/cpython/rev/09ec7f7322b5 -- nosy: +python-dev ___

[issue27262] IDLE: move Aqua context menu code to maxosx

Terry J. Reedy added the comment: [The light dawns, as the pieces connect together] The pseudoclass 'MyButton' would then consist of all widgets with 'MyButton' inserted into its bindtags list. Similarly for 'Editor'. I presume that a) tk has the equivalent of a master bind dict mapping bindt

[issue27268] Incorrect error message on float('')

Changes by Serhiy Storchaka : -- nosy: +mark.dickinson, serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list Unsu

  1   2   >