Marc Schlaich added the comment:
This could be even a security issue.
People might rely on a proxy as a privacy feature. In this case the proxy
should do forward/reverse DNS requests and not the client. Doing DNS lookups to
check for proxy bypass doesn't seem right. I don't think that major
Marc-Andre Lemburg added the comment:
New changeset 6059ce45aa96f52fa0150e68ea655fbfdc25609a by Marc-Andre Lemburg
(Matthias Bussonnier) in branch 'master':
bpo-27788 : synchronise platform.py version number (#246)
https://github.com/python/cpython/commit
Marc-Andre Lemburg added the comment:
The main purpose of the alias table is to support normalization and this is
used for getdefaultencoding() which was created to be able to determine the
default encoding based on what X.org uses as default without doing temporary
setlocale() tricks.
Now
Marc-Andre Lemburg added the comment:
On 10.03.2017 08:37, Benjamin Peterson wrote:
>
> Do you believe this program should work?
>
> import locale, os
> for l in open("/usr/share/i18n/SUPPORTED"):
> alias, encoding = l.strip().split()
> locale.setlocale(
Marc-Andre Lemburg added the comment:
On 10.03.2017 15:17, STINNER Victor wrote:
>
> The codecs.StreamReaderWriter() class still has old unfixed issues like the
> issue #12508 (open since 2011). This issue is even seen as a security
> vulnerability by the owasp-pysec proj
Marc-Andre Lemburg added the comment:
On 09.03.2017 11:47, Serhiy Storchaka wrote:
>
> The SUPPORTED file from glibc is used for determining the default encoding
> for locales that don't include it explicitly. For example en_IN uses UTF-8
> rather than ISO8859-1.
No, the glibc l
Marc-Andre Lemburg added the comment:
On 09.03.2017 08:15, Benjamin Peterson wrote:
>
> "eo_XX" is just something that appears in the X11 locale.alias file. My
> change doesn't add that; it was already there. (for Esperanto, which I
> suppose explains
Marc-Andre Lemburg added the comment:
Why was the PR merged while we were still discussing it ?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Marc-Andre Lemburg added the comment:
On 08.03.2017 10:37, Serhiy Storchaka wrote:
>
> The problem is that that table can get incorrect result for non-Linux
> platforms (or for Linux with old glibc).
Sure, it's a best effort approach.
Also note that on today's systems you often d
Marc-Andre Lemburg added the comment:
On 08.03.2017 07:27, Benjamin Peterson wrote:
>
> Why is the X11 locale alias map used at all? It seems like it can only create
> confusion with libc.
Because it was the only such maintained mapping available at the
time. It's also used for
Marc-Andre Lemburg added the comment:
On 08.03.2017 08:20, Serhiy Storchaka wrote:
>
> Serhiy Storchaka added the comment:
>
> Not all platforms use glibc 2.24 as libc.
True. Many don't even use glibc.
> Ideally most of entries should even not exist. We should ask libc for
Marc-Andre Lemburg added the comment:
On 07.03.2017 18:23, Serhiy Storchaka wrote:
>
> Serhiy Storchaka added the comment:
>
>> 'cy_GB.ISO8859-1' to 'cy_GB.ISO8859-14'
>
> Looks as just fixing an error. The default West-European ISO8859-1 is changed
> to Celtic cy_G
Marc-Andre Lemburg added the comment:
I agree that it's reasonable to have glibc's aliases override
the X.org ones, but this patch makes some pretty significant changes to
Python's default assumptions with respect to default encodings for several
locales.
While some changes obviously make
Marc-Andre Lemburg added the comment:
The localization using keyword parameters is a very old trick to avoid global
lookups. It does give a noticeable speedup, esp. when the localized variables
are used in tight loops or the function itself is used in such loops.
The 5% speedup Steven
Marc Guetg added the comment:
@ethan, didn't know about aenum, thanks for showing it to me. However it
doesn't seem to support the behavior I'm after (or I'm doing something wrong)
import aenum
try:
class Foo(aenum.Flag):
a = aenum.auto()
b
Marc-Andre Lemburg added the comment:
Hmm, not sure why the merge is not showing up on the ticket.
Here's the link:
https://github.com/python/cpython/commit/6059ce45aa96f52fa0150e68ea655fbfdc25609a
--
___
Python tracker <rep...@bugs.python.
Changes by Marc-Andre Lemburg <m...@egenix.com>:
--
assignee: -> lemburg
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http:/
Marc-Andre Lemburg added the comment:
The purpose of __version__ in the platform module is to be able to use it with
other Python as well (and then detect which version is available in
applications).
So I think it's good to keep it around
Marc-Andre Lemburg added the comment:
The term "linkage" is probably a misnomer... "execformat" would be more correct:
* https://en.wikipedia.org/wiki/Comparison_of_executable_file_formats
Too late to change, I guess.
--
___
Marc-Andre Lemburg added the comment:
I think there's a misunderstanding in what platform.architecture() is meant
for. The purpose is to find out more details about the executable you pass to
it, e.g. whether it's a 32-bit or 64-bit binary, or whether it's an ELF or PE
binary. And it's a best
Marc-Andre Lemburg added the comment:
Ok, thanks for the clarification. So if I understand correctly, the main change
in Python 3 is that points to the stub launcher, not the binary itself.
In any case, a new function would have to be added to the platform module to
query multiple
Marc-Andre Lemburg added the comment:
Thanks for the report, but there really isn't much we can do, since the API is
not geared up for handling executables which contain binaries for multiple
architectures.
AFAIK, the Python 3 binaries available from python.org are no longer built
New submission from Marc Culler:
On macOS, the 32 bit python 2.7 reports its architecture as '64bit' in
platform.architecture(). Note that the 32 bit Python versions 3.4, 3.5 and 3.6
all correctly report '32bit'.
$ python-32
Python 2.7.13 (v2.7.13:a06454b1afa1, Dec 17 2016, 12:39:47)
[GCC
Marc Guetg added the comment:
One made-up use-case would be:
class LogLevel(Flags):
start = auto()
log1 = start | auto()
log2 = start | auto()
def fun(flags, *args):
if start in flags:
# open log file
if log1 in flags:
# Log important thing 1
if log2
Changes by Marc Guetg <guetg.m...@gmail.com>:
--
title: implement __or__ in enum.auto -> implementation of __or__ in enum.auto
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
New submission from Marc Guetg:
At the moment it is only possible to combine flags that already exist:
from enum import *
class Foo(Flag):
A = auto() # 1
B = auto() # 2
AB = A | B # 3 (1 | 2)
AC = auto() | A # Fails, but should be 5 (1 | 4)
ABD = auto
Marc-Andre Lemburg added the comment:
I don't think rewriting party of site.py in C is a good idea. It's a rather
maintenance intense module.
However, optimizing access is certainly something that's possible, e.g. by
placing the few variables that are actually needed by site.py
Marc-Andre Lemburg added the comment:
While "functions" may not be accurate anymore, they are all callables.
Historically, those callables were functions. Later on some of the built-ins
were replaced with type objects.
Regarding your last comment: It is common in Python to w
Marc-Andre Lemburg added the comment:
Indeed, there are two issue with the .tgz file:
* it uses "staff" as group for all files (which will likely exist on some
systems), but this appears unrelated in you case
* all subdirs have go-x set, which prevents changing into the dir
Marc-Andre Lemburg added the comment:
On 14.02.2017 11:16, STINNER Victor wrote:
>
>> Please note that the two sets of APIs are not identical, e.g. you cannot
>> simply replace PyEval_CallObject() with PyObject_Call(), since the former
>> applies a few extra check
Marc-Andre Lemburg added the comment:
Looking through Python's history, it's interesting that PyObject_Call() did
apply the args == NULL checks up until Python 2.1.
In Python 2.2 this was replaced by a direct call to tp_call, without the
checks. However, the tp_call slots don't do this check
Marc-Andre Lemburg added the comment:
The PyEval_Call*() APIs indeed predate the PyObject_Call*() ones. The
PyObject_Call*() APIs came into existence when the abstract layer was added in
Python 1.3.
The PyObject_Call*() APIs lacked a way to call an object with keyword arguments
for a long
Marc-Andre Lemburg added the comment:
PyEval_CallObject wasn't removed. It's a macro now. And it was documented for a
long time in Extending Python... in fact, the documentation was removed, not
the API :-)
--
___
Python tracker <
Marc-Andre Lemburg added the comment:
Thanks, but you missed the main difference:
The argument tuple can be NULL for PyEval_CallObject() (it then gets replaced
with an empty tuple), but will raise a segfault for PyObject_Call().
Now, apart from looking at the use cases in the core, you also
Marc-Andre Lemburg added the comment:
Please note that the two sets of APIs are not identical, e.g. you cannot simply
replace PyEval_CallObject() with PyObject_Call(), since the former applies a
few extra checks and defaults, which the latter doesn't.
--
nosy: +lemburg
Marc-Andre Lemburg added the comment:
I'm still -1 on the approach taken by the OP, but +1 on Martin's approach of
making such configurations more easily possible via Modules/Setup.
--
___
Python tracker <rep...@bugs.python.org>
Marc-Andre Lemburg added the comment:
On 01.02.2017 13:03, INADA Naoki wrote:
> Maybe, we should remove Py_HASH_CUTOFF completely?
I think we ought to look for a better hash algorithm
for short strings, e.g. a CRC based one.
Some interesting investigations on this:
http://www.orthogonal.com
Marc-Andre Lemburg added the comment:
On 01.02.2017 11:07, Serhiy Storchaka wrote:
>
> The performance of hash algorithm shouldn't affect general benchmarks since
> hash value is cached inside string object. Almost all dict lookups in
> critical parts are lookups with inte
Marc-Andre Lemburg added the comment:
On 01.02.2017 10:50, INADA Naoki wrote:
>
>> it seems as if it would make sense to not use a fixed
>> hash algorithm for all strings lengths, but instead a
>> hybrid one to increase performance for short strings
>> (whi
Marc-Andre Lemburg added the comment:
On 24.01.2017 16:47, Eric N. Vander Weele wrote:
>
> I have a (large) patch that completely eliminates the need for ld_so_aix and
> makeexp_aix. I've applied and been using this with for Python 2.7 and 3.5+,
> but I still need to go back
Marc-Andre Lemburg added the comment:
On 24.01.2017 15:23, Michael Felt wrote:
> As far as issue10656 and this issue are concerned:
>
> Python-3.4 is out of context (but 3.4.6 was just released) - and does not
> work with 'out of tree' builds.
>
> The other versions: 2.7.1
Marc-Andre Lemburg added the comment:
BTW: Does the ticket still apply to 3.5+ ? From reading the ticket, it seems
that the problem is already fixed for those versions.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Marc-Andre Lemburg added the comment:
Hmm, looking at the patch again:
diff -r a089a8b1f93d Lib/sysconfig.py
--- a/Lib/sysconfig.py Fri Jun 21 18:37:02 2013 -0400
+++ b/Lib/sysconfig.py Fri Jun 21 22:33:15 2013 -0700
@@ -368,7 +368,7 @@
# -- these paths are relative to the Python source
Marc-Andre Lemburg added the comment:
Reading the ticket, it seems that there is some confusion about what LDSHARED
and BLDSHARED are used for. BLDSHARED is used to override the LDSHARED value
when building libpython and the shared modules (via setup.py).
LDSHARED is what is meant to be used
Marc-Andre Lemburg added the comment:
>> The only part that is not correct is "single string characters".
>> This should read "single bytes" or "bytes strings of length 1".
>
> This is not correct. Decoding mappings map not bytes strings, but
Marc-Andre Lemburg added the comment:
According to the datetime.h file, the valid range for year is 1-, so it's a
bit surprising that Python 3.6 allows dates outside this range.
Internally, the year is represented using 2 bytes, so you could represent years
outside the range and up
Marc-Andre Lemburg added the comment:
Adding Victor, who implemented the fs codec.
AFAIK, it's not possible to change the encoding after interpreter
initialization, since it will have been already used for many different things
by the time you get to executing code.
--
nosy: +haypo
Marc-Andre Lemburg added the comment:
On 13.01.2017 04:47, Nick Coghlan wrote:
> Accepting "UTF-8" and interpreting it as functionally equivalent to C.UTF-8
> will mean that this setting will at least work as desired on servers that
> offer C.UTF-8.
I don't think that
Marc-Andre Lemburg added the comment:
I think Ronald's patch issue18378-2015-07-25-py36.txt with added darwin check
would be the best way forward.
In the current form, it would allow using 'UTF-8' as locale string on all
platforms - which is not such a good idea.
--
nosy: +lemburg
Marc-Andre Lemburg added the comment:
On 11.01.2017 17:04, Xiang Zhang wrote:
> I am not sure it's worth to make it even optional in 3.7. Discarding tzinfo
> sounds weird, and worse, the behaviour is not deterministic, it could also
> fail with an exception.
Best practice is to store
Marc-Andre Lemburg added the comment:
On 11.01.2017 17:08, Serhiy Storchaka wrote:
>
> The naive datetime converter is registered under the name "timestamp". The
> aware datetime converter or the universal datetime converter (if it is
> needed) can be registered
Marc-Andre Lemburg added the comment:
I don't think this can be considered a bug fix, since it changes behavior for
applications that read data from SQLite databases which were not created by
Python.
Those application may now see datetime values with tz infos and will likely not
be prepared
Marc-Andre Lemburg added the comment:
While going for the full locale setting may be a good option,
perhaps just focusing on the FS encoding for now is a better
way forward (and also more in line with the ticket title).
So essentially go for the PEP 529 approach on Unix as well
(except that we
Marc-Andre Lemburg added the comment:
On 05.01.2017 10:26, Nick Coghlan wrote:
>
> Anything purely on the Python side of things doesn't work in a traditional C
> environment - CPython relies on the C lib to do conversions during startup,
> so we need the C locale to be set corre
Marc-Andre Lemburg added the comment:
As general comment, I think you'd have to check which operation modes SQLite
supports for the case of a transaction commit/rollback in the light of open
cursors.
ODBC defines the following cases and each data source can specify a different
behavior
Marc-Andre Lemburg added the comment:
I did some more research: setuptools didn't have this keyword either.
It was added to PyPI at some point and then probably got picked up by some
package authors as new "optional" keyword argument for setup():
http://stackoverflow.com/question
Marc-Andre Lemburg added the comment:
I believe you need to report this problem to the setuptools maintainers. The
stdlib distutils itself never defined a setup() argument 'bugtrack_url', so
raises a warning when seeing this argument.
--
nosy: +lemburg
Marc-Andre Lemburg added the comment:
time.time() is not quite UTC on Unix: it usually (*) doesn't include leap
seconds, which UTC does.
The Wikipedia page has a good definition and explanation:
https://en.wikipedia.org/wiki/Unix_time
(*) "usually" because POSIX defines time() to n
Marc-Andre Lemburg added the comment:
On 17.12.2016 08:56, Nick Coghlan wrote:
>
> Making an explicit note of this so I remember to mention it in the draft PEP:
> one of the biggest problems that arises in any attempt at a Python-only
> solution to overriding the locale is that w
Marc-Andre Lemburg added the comment:
Thanks for the patch.
Victor has implemented the function in C, AFAIK, so an even better approach
would be to expose that function at the Python level and use it in the
encodings package.
--
versions: +Python 3.7 -Python 3.4, Python 3.5
Marc-Andre Lemburg added the comment:
Please try to install this update from MS:
https://support.microsoft.com/en-us/kb/2999226
it includes the missing DLL.
--
nosy: +lemburg
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Marc-Andre Lemburg added the comment:
If we just restrict this to the file system encoding (and not the whole LANG
setting), how about:
* default the file system encoding to 'utf-8' and use the surrogate escape
handler as default error handler
* add a PYTHONFSENCODING env var to set
Marc-Andre Lemburg added the comment:
The codec code has a few (performance) issues:
* nonspacing_diacritical_marks should be a set for fast lookup
* ord(c) in range(0x00, 0xA0) should be rewritten using < and >=
* result += bytes([ord(c)]) has exponential timing (it copies
the
Marc-Andre Lemburg added the comment:
On 28.11.2016 12:24, Serhiy Storchaka wrote:
>> Why are you removing the introductory section on how mappings work ?
>
> Because it is not correct. I copied it to descriptions of concrete functions
> with correcting it according to
Marc-Andre Lemburg added the comment:
Why are you removing the introductory section on how mappings work ?
Also, this wording needs to be corrected: "bytes (integers in the range from 0
to 255)". Bytes are not integers. I'd suggest to use the more correct wording
"bytes stri
Marc-Andre Lemburg added the comment:
On 20.11.2016 00:59, STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>> I think we must use the reliable build time Android API level and
> implement sys.getandroidapilevel() (Victor patch) for knowing, in the
> standar
Marc-Andre Lemburg added the comment:
On 14.11.2016 13:03, STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> iso6937.py:
>
>> # from utf-8 to iso6937
>> def iso6937_encode(input,errors,encoding_map):
>
> Wait, is this code for Python 3? Decode
Marc-Andre Lemburg added the comment:
Just as reference, here's the wikipedia page for the encoding:
https://en.wikipedia.org/wiki/ISO/IEC_6937
and this is the ISO document (as preview):
http://webstore.iec.ch/preview/info_isoiec6937%7Bed3.0%7Den.pdf
(from the German wikipedia page
Marc-Andre Lemburg added the comment:
Another comment about coding style: please use \u hex code representations
for the decoding map. The stdlib source code is normally kept ASCII compatible
and, for codecs, the Unicode code point numbers make it easier to check the
mappings
Marc Garcia added the comment:
I agree that for my case, I was using the wrong quoting parameter, and if I
specify that my file has no quotes, it works as expected.
But I still think that in a different case, when a file do have quotes, but
they are not paired, it'd be better to raise
Marc Garcia added the comment:
I could research a bit more on the problem. This is a minimal code that
reproduces what happened:
from io import StringIO
import csv
csv_file = StringIO('''1\t"A
2\tB''')
reader = csv.reader(csv_file, delimiter='\t')
for i
Marc Garcia added the comment:
Sorry, my fault. It looks like having quotes in the file was the problem. As
mentioned, adding the quoting parameter fixes the problem.
I'd assume that if quotes are not paired, csv should raise an exception. And I
don't think that all the different chunks
New submission from Marc Garcia:
I'm using the csv module from Python standard library, to read a 1.4Gb file
with 11,157,064 of rows. The file is the Geonames dataset for all countries,
which can be freely downloaded [1].
I'm using this code to read it:
import csv
with open
Marc-Andre Lemburg added the comment:
On 25.10.2016 04:16, Xiang Zhang wrote:
> Marc-Andre, shouldn't the C API of unicode.encode() be
> PyUnicode_AsEncodedString instead of PyUnicode_AsEncodedUnicode now?
You're right. I got confused with all the slight variations.
> BTW Serhiy,
Marc-Andre Lemburg added the comment:
As I already mentioned, PyUnicode_AsEncodedUnicode() needs to stay, since it's
the C API for unicode.encode(). The others can be deprecated.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
New submission from Marc Culler:
Changes made to /Library/Python on macOSX Sierra cause the --with-ensurepip
compiler flag to fail, and lead to failures of pip after installing Python.
The new file that causes the problem on Sierra is:
/Library/Python/2.7/site-packages/Extras.pth
The current
Marc-Andre Lemburg added the comment:
Thanks, Ville.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28393>
___
___
Python-bugs-
Marc-Andre Lemburg added the comment:
On 13.10.2016 10:10, Serhiy Storchaka wrote:
> Shouldn't all these function be deprecated in favour of PyCodec_*() APIs?
Not all of them, since you still want to have a C API for
unicode.encode(). PyUnicode_AsEncodedUnicode() would have
to s
Marc-Andre Lemburg added the comment:
PyUnicode_AsDecodedObject() and PyUnicode_AsEncodedObject() were meant as C API
implementations of the unicode.decode() and unicode.encode() methods in
Python2. Not having PyUnicode_AsDecodedObject() documented was likely an
oversight on my part
Marc-Andre Lemburg added the comment:
The names are indeed case-insensitive.
However, something important is missing: the implementation details changed
between Python 3.5 and 3.6. Please check the implementation for details and
update the documentation with versionadded flags. Thanks
Marc-Andre Lemburg added the comment:
On 10.10.2016 15:08, Petr Viktorin wrote:
> If sys.setdefaultencoding('undefined') breaks parts of the standard library,
> it might be OK for smaller scripts but I fear it won't help big projects much.
That's true. It does break the stdlib (the
Marc-Andre Lemburg added the comment:
Nick, I think you've missed the "undefined" encoding that we've had for this
ever since Unicode was added to Python.
You put the needed code into your sitecustomize.py file and Python2 will then
behave just like Python3, i.e. raise an excepti
Marc-Andre Lemburg added the comment:
+1, but I'd name the env var PYTHON3WARNINGS.
Who knows, when Python 4 comes around the corner, we may need a
PYTHON4WARNINGS...
--
nosy: +lemburg
___
Python tracker <rep...@bugs.python.org>
Marc-Andre Lemburg added the comment:
> Marc-Andre: "Consensus then was to use the minimum as basis for benchmarking:
> (...) There are arguments both pro and con using min or avg values."
>
> To be honest, I expect that most developer are already aware that minim
Marc-Andre Lemburg added the comment:
We had a similar discussion a while back for pybench. Consensus
then was to use the minimum as basis for benchmarking:
https://mail.python.org/pipermail/python-dev/2006-June/065525.html
I had used the average before this discussion in pybench 1.0:
https
Marc-Andre Lemburg added the comment:
On 14.09.2016 15:20, STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>> I'd also like to request that you reword this dismissive line in the
>> performance package's readme: (...)
>
> Please report issues of th
Marc-Andre Lemburg added the comment:
Please add notes to the Tools/README pointing users to the performance suite.
I'd also like to request that you reword this dismissive line in the
performance package's readme:
"""
pybench - run the standard Python PyBench
Marc-Andre Lemburg added the comment:
> The real issue is that when setting the tzname tuple in the time module, we
> use a guess based on the value of tm_zone probed in June and January. I am
> not sure whether this is wise. Shouldn't we just use C tzname is it is
> availab
Marc-Andre Lemburg added the comment:
If you want to separately check for the definition of tzname,
I guess you have to add a AC_DEFINE() section specifically
for tzname.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Marc-Andre Lemburg added the comment:
Looking at the autoconf documentation, HAVE_TZNAME is only set iff struct tm
does not have a tm_zone member *and* the external array tzname is found:
https://www.gnu.org/software/autoconf/manual/autoconf-2.64/html_node/Particular-Structures.html
Marc-Andre Lemburg added the comment:
Yes, that's intended. See e.g. the mbcs codec.
If a search function gets an ImportError, it interprets this as "codec is not
available/working", and then gives other search functions a chance to find a
w
Marc-Andre Lemburg added the comment:
Shouldn't this ticket be closed ?
platform is using subprocess on both the 2.7 and trunk, so the issue should be
fixed - and indeed I cannot reproduce it anymore.
--
___
Python tracker <rep...@bugs.python.
Marc-Andre Lemburg added the comment:
Thinking about this some, we could go ahead and document somewhere that if a
codec wants to tell the search function that it cannot work due to some missing
dependency, it will have to raise an ImportError from the codec module level
(instead of just
Marc-Andre Lemburg added the comment:
Steve, this is not a correct patch. The purpose of skipping ImportErrors is to
give other search functions a chance to find and provide a working codec. Your
patch causes this to break.
--
nosy: +lemburg
resolution: fixed ->
status: clo
Marc-Andre Lemburg added the comment:
That must have been an oversight. __version__ should read '0.8.0'.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Marc:
Hello,
I've found an issue in python 2.7 and 3.4 and I don't if this is a bug or a
feature that acts strange to me.
The import of a module or method from a module creates a reference in the
package to that module only the first time, which could lead to unexpected
Marc-Andre Lemburg added the comment:
At the time the code was written, libc and glibc were in wide spread use, so
it's not surprising that it doesn't work well for other C libs.
Note that the routine returns the highest libc version number used and required
by the executable (usually
Marc-Andre Lemburg added the comment:
Resources for entropy gathering sources:
* Kernel based devices such as /dev/random:
https://en.wikipedia.org/wiki//dev/random
* EGD - old entropy gathering daemon; blocks when out of
entropy
http://egd.sourceforge.net/
(not maintained
Marc-Andre Lemburg added the comment:
Some more resources for FreeBSD:
* /dev/random and /dev/urandom (symlink to /dev/random) ma page:
https://www.freebsd.org/cgi/man.cgi?query=random=4
* Developer discussion about /dev/random and its future from 2013:
https://wiki.freebsd.org
Marc-Andre Lemburg added the comment:
On 09.06.2016 10:16, STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> Marc-Andre Lemburg:
>> I propose to deprecate os.urandom() altogether due to all the issues we've
>> discussed on all those recent tickets.
>
301 - 400 of 2192 matches
Mail list logo
