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.
>
Marc-Andre Lemburg added the comment:
On 09.06.2016 10:07, Larry Hastings wrote:
>
> I +1 on new functions that are designated the best-practice places to get
> your pseudo-random numbers.
>
> (IDK if the best place for both is in random; maybe the crypto one should be
> in
Marc-Andre Lemburg added the comment:
Some resources:
* getrandom() man page:
http://man7.org/linux/man-pages/man2/getrandom.2.html
* nice readup on how getrandom() was introduced:
https://lwn.net/Articles/606141/
* random devices implementation on Linux:
http://lxr.free
Marc-Andre Lemburg added the comment:
On 09.06.2016 09:57, STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> I played with select() on Linux on a VM:
>
> * /dev/random: it works as expected
> * /dev/urandom: the device is already seen as readable even
Marc-Andre Lemburg added the comment:
Fleshing out the API signatures and implementation details will have to be done
in a PEP.
The topic is (as all the related ticket show) too complex for discussions on a
bug tracker.
I just opened this ticket for reference to the idea
Marc-Andre Lemburg added the comment:
I propose to deprecate os.urandom() altogether due to all the
issues we've discussed on all those recent tickets.
See #27279 for details.
On 09.06.2016 02:04, Nick Coghlan wrote:
> I'd also *STRONGLY* request that we avoid adding any new APIs in relat
Marc-Andre Lemburg added the comment:
Please also see #27279 for an alternative plan.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Marc-Andre Lemburg:
I propose to deprecate os.urandom() altogether due to all the
issues we've discussed on all those recent tickets, see e.g.
#26839, #27250, #25420.
Unlike what we've told people for many years, it's clear that in the
age of VMs/containers getting booted
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
Marc-Andre Lemburg added the comment:
Even though it may sound like a minor problem that os.urandom()
blocks on startup, I think the problem is getting more and more
something to consider given how systems are used nowadays.
Today, we no longer have the case where you keep a system up
Marc-Andre Lemburg added the comment:
On 07.06.2016 21:12, Cory Benfield wrote:
>
>> Python hash randomization only happens once. So it's not a matter of how
>> early we try the attack, it's a matter of how early we seed Python hash
>> randomization.
>
> Sorry
Marc-Andre Lemburg added the comment:
On 07.06.2016 16:59, Christian Heimes wrote:
>
> Christian Heimes added the comment:
>
> On 2016-06-07 16:49, Marc-Andre Lemburg wrote:
>> This gives people a clear choice and doesn't cause people
>> to have to reconsider using t
Marc-Andre Lemburg added the comment:
On 07.06.2016 16:18, Donald Stufft wrote:
>
> Donald Stufft added the comment:
>
>> I just don't understand why you are apparently not willing to even consider
>> compromises.
>
> I have one thing that I hold immutable here,
Marc-Andre Lemburg added the comment:
On 07.06.2016 15:21, Donald Stufft wrote:
>
> The patch causes a regression because I'm relying on the 3.5 behavior of
> getting secure randomness from ``os.urandom`` via the ``getrandom()`` system
> call (behavior that was documented in t
Marc-Andre Lemburg added the comment:
On 07.06.2016 15:12, Donald Stufft wrote:
>
> Since there's obviously contention about what the right answer here is, I
> suggest we should revert the patch (since the old behavior already exists in
> 3.5 and is shipped to thousands of pe
Marc-Andre Lemburg added the comment:
On 07.06.2016 14:41, Cory Benfield wrote:
>
> Uh, sorry, I meant #26839.
Ok, then perhaps "Add os.getrandom()" - also see the discussion
there :-)
--
___
Python tracker <rep...@bug
Marc-Andre Lemburg added the comment:
On 07.06.2016 14:40, Donald Stufft wrote:
>
> Donald Stufft added the comment:
>
> (Basically) nobody should ever use /dev/random (and cryptographers agree!).
> The thing you want to use is /dev/urandom and the fact that /dev/urandom on
Marc-Andre Lemburg 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.
--
nosy: +lemburg
___
Python tracker <rep...@bugs.pyth
Marc-Andre Lemburg added the comment:
On 07.06.2016 14:19, Donald Stufft wrote:
>
>> Note how the documentation emphasizes on os.urandom() not blocking.
>
> That line about not-blocking was added by the patch that Victor committed
> that we're objecting to.
Ah, so
Marc-Andre Lemburg added the comment:
On 07.06.2016 13:51, Donald Stufft wrote:
>
> Donald Stufft added the comment:
>
>> That's pretty much in line with what the implementation now does.
>
> Literally the first line of the os.urandom documentation is "Return a s
Marc-Andre Lemburg added the comment:
On 07.06.2016 13:36, Donald Stufft wrote:
> No where in the documentation of ``os.urandom`` does it ever promise it will
> not block. In fact, on systems like FreeBSD where their /dev/urandom is
> better than Linuxes it always blocked on start u
Marc-Andre Lemburg added the comment:
On 07.06.2016 13:27, Alex Gaynor wrote:
>
> This doesn't look correct to me. Despite what the Linux maintainers insist,
> it's a _bug_ that /dev/urandom will return immediately if the system's
> entropy pool has never been seeded; one of the
Marc-Andre Lemburg added the comment:
Just found this ticket and apparently late to the game...
Some comments:
It is already possible to selectively build Python C extension modules in the
stdlib via editing the Modules/Setup file and this is a lot better to maintain
than a long list
Marc-Andre Lemburg added the comment:
Ben, the methods on stings and Unicode objects in Python 2.x are direct
interfaces to the underlying codecs. The codecs can handle any number of input
and output types, so there are some which only work on 8-bit strings (bytes)
and others which take
Marc-Andre Lemburg added the comment:
Side note, as already indicated by Nick: pkgutil may well still not support
frozen modules in Python 3.4 and 3.5, since runpy, which pyrun uses, does not
rely on pkgutil in Python 3.4 and 3.5.
--
___
Python
Marc-Andre Lemburg added the comment:
We're not supporting Python 3.3 with PyRun, but I can confirm that it works
fine in Python 3.4 and 3.5.
In Python 2.7, it's still broken, as you can test with
pyrun2.7 -m wsgiref.simple_server
--
versions: +Python 2.7 -Python 3.4
Marc-Andre Lemburg added the comment:
On 04.05.2016 21:47, Chi Hsuan Yen wrote:
> 1. Should Android 4.1 supported? If not pass_fds and logics for deriving it
> can be removed.
According to http://www.droid-life.com/tag/distribution/ the Jelly
Bean versions (4.1, 4.2 and 4.3) stil
Marc-Andre Lemburg added the comment:
Some screenshots showing different file contents:
*
http://www1-lw.xda-cdn.com/files/2013/12/tweak-your-samsung-galaxy-s3s-performance-with-these-build-prop-android-hacks.w654.jpg
*
http://media.apcmag.com/wp-content/uploads/sites/20/2014/04/buildprop
Marc-Andre Lemburg added the comment:
If the file is guaranteed to exist on most modern Android platforms, this
sounds like a good approach.
Perhaps you could add support to fallback to running getprop instead, if the
file doesn't exist or cannot be parsed ?!
--
nosy: +lemburg
Marc-Andre Lemburg added the comment:
As mentioned on the other issue #25420, this is a regression and a change in
documented behavior of os.urandom(), which is expected to be non-blocking,
regardless of whether entropy is available or not.
The fix should be easy (from reading the man page
Marc-Andre Lemburg added the comment:
I still believe the underlying system API use should be fixed rather than all
the different instances where it gets used.
getrandom() should not block. If it does on a platform, that's a bug on that
platform and Python should revert to the alternative
Marc-Andre Lemburg added the comment:
On 19.04.2016 13:11, STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>> Could you perhaps check what's causing these slowdowns ?
>
> It's obvious, no? My patch causes the slowdown.
Well, yes, of course :-) I meant whe
Marc-Andre Lemburg added the comment:
On 19.04.2016 12:52, STINNER Victor wrote:
>
> As usual, I'm very skeptical on the pybench results which almost look like
> noise. I don't understand how my change can make any operation *faster*,
> whereas some benchmarks are faster wi
Marc-Andre Lemburg added the comment:
On 14.04.2016 10:39, Alecsandru Patrascu wrote:
>
> @Stefan and @Marc, you say that people don't want to wait for PGO to build
> when running ./configure && make, but why? Even though many developers use
> it, this mode is not inte
Marc-Andre Lemburg added the comment:
On 13.04.2016 21:50, Stefan Krah wrote:
>
> LTO is not stable on all platforms (according to doko), and people don't
> want to wait for PGO to build when they just run ./configure && make.
>
> --with-pgo and --with-lto is fine.
Marc-Andre Lemburg added the comment:
The idea is to have similar functionality implemented as a PyPI
package, which can be updated more often than the stdlib.
Unlike Windows and Mac OS X, the approach to finding out
the distribution version is changing too often on Linux (w/r to how
Python
Marc-Andre Lemburg added the comment:
Adding other Python versions as well, since this is a bug.
--
versions: +Python 2.7, Python 3.4, Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Marc-Andre Lemburg added the comment:
True. At the time the code was written, this was not an issue :-)
Is the libc version information documented somewhere ? If so, we could probably
add a better parser for it.
--
___
Python tracker <
Marc-Andre Lemburg added the comment:
Does Python 2.7.10 build fine ? If so, then perhaps xlc doesn't
like the computed gotos in ceval.c.
You could try compiling with:
./configure ... --without-computed-gotos ...
to check.
--
nosy: +lemburg
Marc-Andre Lemburg added the comment:
Serhiy: Removing the shortcut would slow down the tokenizer a lot since UTF-8
encoded source code is the norm, not the exception.
The "problem" here is that the tokenizer trusts the source code in being in the
correct encoding when you use on
Marc-Andre Lemburg added the comment:
On 04.02.2016 09:01, STINNER Victor wrote:
>
> "In a numerics heavy application it's like that all fast paths will trigger
> somewhere, but those will likely be better off using numpy or numba. For a
> text heavy application such as a web
Marc-Andre Lemburg added the comment:
On 04.02.2016 07:02, Yury Selivanov wrote:
> Attaching a second version of the patch. (BTW, Serhiy, I tried your idea of
> using a switch statement to optimize branches
> (https://github.com/1st1/cpython/blob/fastint2/Python/ceva
Marc-Andre Lemburg added the comment:
On 20.01.2016 09:37, Antoine Pitrou wrote:
> Let me add that downstream distributors already customize compilation options
> (Ubuntu's Python is compiled with both PGO and LTO enabled, AFAIR), so this
> change may only really affect the tiny subs
Marc-Andre Lemburg added the comment:
On 20.01.2016 11:38, Antoine Pitrou wrote:
>> If not, then the patch would also effect the not-so-tiny fraction
>> of Python users on Windows ;-)
>
> I don't see how enabling LTO for gcc and clang could ever affect our Windows
> users
Marc-Andre Lemburg added the comment:
On 15.01.2016 10:05, Mark Dickinson wrote:
>
> Mark Dickinson added the comment:
>
> ... and the way I read it, the NR licence applies specifically to their code,
> not to the basic numerical ideas set out in the text (which is all we're
Marc-Andre Lemburg added the comment:
The patch looks good. I only have one question:
Why are you removing this part ? ...
@@ -1684,13 +1688,8 @@
try:
ret = func(*args)
except ssl.SSLError as e:
-# Note that we get a spurious -1
Marc-Andre Lemburg added the comment:
Thanks, Brett. I'm too busy with other things at the moment.
--
assignee: -> brett.cannon
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.or
Marc-Andre Lemburg added the comment:
I think we can close this issue as "won't fix".
It's a bug, but one which is present in a lot of other systems as well, so we'd
potentially make it impossible to write GB2312 data which is supposed to be
read back by these other systems.
Ma L
Marc-Andre Lemburg added the comment:
On 04.01.2016 08:43, Martin Panter wrote:
>
> In the meantime, this patch changes the tests to use the new DST root
> certificate. This seems to be the minimum to make the tests pass again, but
> someone else should probably review it because
Marc-Andre Lemburg added the comment:
Thanks, Ma Lin.
--
resolution: -> wont fix
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Marc-Andre Lemburg added the comment:
So the use case is that you want to explicitly prevent the file system from
being used for imports ?
You might want to look at how eGenix PyRun works, since this does embed the
Python stdlib into the executable (including the encodings package). While
Marc-Andre Lemburg added the comment:
On 27.12.2015 02:05, Serhiy Storchaka wrote:
>
>> I wonder why this does not trigger the exception.
>
> Because in case of utf-8 and iso-8859-1 decoding and encoding steps are
> omitted.
>
> In general case the input is decoded
Marc-Andre Lemburg added the comment:
Please fold these cases into one:
if (strcmp(buf, "utf-8") == 0 ||
strncmp(buf, "utf-8-", 6) == 0)
return "utf-8";
else if (strcmp(buf, "utf8") == 0 ||
strncmp(buf,
Marc-Andre Lemburg added the comment:
On 26.12.2015 22:46, STINNER Victor wrote:
>
> In Python, there are multiple implementations of the utf-8 codec with many
> shortcuts. I'm not surprised to see bugs depending on the exact syntax of
> the utf-8 codec name. Maybe we need to sha
Marc-Andre Lemburg added the comment:
Regardless of the cert having expired, I think SSL tests either should use the
main python.org site, e.g. https://www.python.org/ or the domain we
specifically have for stdlib tests: http://pythontest.net/.
Benjamin: If you need a cert for pythontest.net
Marc-Andre Lemburg added the comment:
On 18.12.2015 20:25, R. David Murray wrote:
> I wonder if we originally only had UnicodeError and it got split later but
> these codecs were never updated. The codecs date back to the start of
> unicode support in python2, I think.
UnicodeDe
Marc-Andre Lemburg added the comment:
Same here. Thanks Martin.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25809>
___
___
Marc-Andre Lemburg added the comment:
> This deprecation and eventual removal, will result in a pypi module created
> with such functionality anyway, that everyone will try to pull in or
> falling that copying in.
That's the plan, right.
The stdlib is not the right place f
Marc-Andre Lemburg added the comment:
I see three options:
1. remove the French entry from the dict
2. enhance the test to accept multiple valid values
3. replace the French entry with a different locale that doesn't change the
mapping often
Marc-Andre Lemburg added the comment:
On 02.12.2015 20:16, Serhiy Storchaka wrote:
>
> Serhiy Storchaka added the comment:
>
>> If the StreamWriter/Reader cannot pickle the underlying stream (which is
>> probably always the case), why should the object itself be picklea
Marc-Andre Lemburg added the comment:
On 02.12.2015 21:29, Serhiy Storchaka wrote:
>
> Serhiy Storchaka added the comment:
>
>> I think all we need to do is add a .__reduce__()
>> method to StreamWriter and StreamReader, which then
>> raises a PickleError.
Marc-Andre Lemburg added the comment:
I wouldn't say this is a feature request.
What the code wanted to check is "if this is an iterable of two strings,
convert these to a locale string". I have no idea why the doc string uses
"iterable". IMO, a tuple of two strings
Marc-Andre Lemburg added the comment:
On 27.11.2015 23:50, STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>> BTW: Why did you use (_str, _unicode) instead of basestring ?
>
> Serhiy usually insists that technically, it's possible to compile Python 2.7
>
Marc-Andre Lemburg added the comment:
On 27.11.2015 23:11, STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> I don't see the benefit of supporting Unicode strings for setlocale()
> arguments: locale name are always encodable to ASCII, so loc.decode('ascii
Marc-Andre Lemburg added the comment:
On 28.11.2015 00:00, STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> Marc-Andre Lemburg added the comment:
>> Hmm, but basestring is always defined, even when Python is compiled
>> without Unicode support (...)
>
Marc-Andre Lemburg added the comment:
On 24.11.2015 02:30, Steven D'Aprano wrote:
>
> Steven D'Aprano added the comment:
>
> On Mon, Nov 23, 2015 at 09:48:46PM +, STINNER Victor wrote:
>
>> * the string has a cached UTF-8 byte string (ex: int(s) was called before
&g
Marc-Andre Lemburg added the comment:
On 20.11.2015 12:10, Cory Benfield wrote:
> Yeah, while generally speaking OpenSSL doesn't ship betas, it does provide
> them as tarballs. I have a beta of 1.0.2 floating around somewhere on my
> machine that I was using for ALPN testing bac
Marc-Andre Lemburg added the comment:
The release buffer mode bugs were fixed in 1.0.0m and 1.0.1h:
https://openssl.org/news/vulnerabilities.html#y2014
CVE-2014-0198 (OpenSSL advisory) 21st April 2014:
A flaw in the do_ssl3_write function can allow remote attackers to cause a
denial
Marc-Andre Lemburg added the comment:
I think Jan has a point there. An import should not cause the whole interpreter
to hang.
Wouldn't it be possible to have the getrandom() call be done lazily to avoid
this and only have it block when the RNG from the random is actually being used
Marc-Andre Lemburg added the comment:
Just to add some more background:
The LE and BE codecs are meant to be used when you already know the endianness
of the platform you are targeting, e.g. in case you work on strings that were
read after the initial BOM, or write to an output string
Marc-Andre Lemburg added the comment:
On 01.10.2015 04:35, Martin Panter wrote:
> For the record, because I was curious: Function codecs.escape_encode() is not
> documented, and barely tested. It was used for the documented “string_escape”
> codec in Python 2, but this codec wa
Marc-Andre Lemburg added the comment:
On 30.09.2015 15:11, Serhiy Storchaka wrote:
> May be better to test a condition "size > 0" before calling
> _PyBytes_Resize(), as in many other case where _PyBytes_Resize() is used.
>
> Or accept shared objects in _PyBytes_Resi
Marc-Andre Lemburg added the comment:
Thanks, Nick. The second version looks much better.
A few minor nits, which you may want to address:
* Order in the section should probably be alphabetic rather than
random time based (makes it easier to search for entries once the
list gets longer
Marc-Andre Lemburg added the comment:
The patch looks fine to me, but I still wonder how p - PyBytes_AS_STRING(v) can
be negative when size == 0...
Ah, now I get it: the new size is 0, but the refcount is not 1, since the
nullstring is shared. This causes the exception.
>From _PyBytes_Res
Marc-Andre Lemburg added the comment:
I'm not sure which kind of use for frozen modules you have in mind.
The freeze tool allows you to replace paths in source path prefixes using the
-r option. We use this in eGenix PyRun to set the prefix to "" since at
run-time, the source f
Marc-Andre Lemburg added the comment:
On 23.09.2015 02:33, Steve Dower wrote:
>
> Done.
Thanks.
> As this is (meant to be) a purely informational/diagnostic module, seems like
> a good idea to fix every version we're supporting in any way.
Yep, that's the intention behind
Marc-Andre Lemburg added the comment:
I like the idea, but the phrasings "disclosure" and "financial interests" sound
too negative, IMO.
Wouldn't it be better to put the emphasis on a) core devs who do this in their
free time, b) core devs who would be available for hired
Marc-Andre Lemburg added the comment:
Steve: Could you please merge your changes into platform.py ?
I think it should go into Python 2.7.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Marc-Andre Lemburg <m...@egenix.com>:
--
resolution: -> duplicate
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.
Marc-Andre Lemburg added the comment:
On 16.09.2015 13:22, Serhiy Storchaka wrote:
>
> A duplicate of issue19143?
I guess so.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Marc-Andre Lemburg added the comment:
On 05.09.2015 03:49, Alexander Belopolsky wrote:
>
> Alexander Belopolsky added the comment:
>
> Hmm, on Mac OSX "%" and "A%" are valid format strings:
>
>>>> time.strftime("%")
> '%'
Marc-Andre Lemburg added the comment:
On 02.09.2015 16:37, flying sheep wrote:
>
> hi mark, i’ve just lengthily replied to you on python-ideas.
>
> in short: nope! many command line tools that are relatively new (among them
> your examples git and pip) honor the specs, my ~/.c
Marc-Andre Lemburg added the comment:
On 03.09.2015 13:37, flying sheep wrote:
> all three OSs have stable, widely followed standards in place, and the idea
> of providing a python stdlib API for them received an almost unanimously
> positive response – with the sole exception being
Marc-Andre Lemburg added the comment:
The XDG standard seems to focus on desktop GUI applications and that's also
where it's mostly used. Python has it's own installation scheme, which is
documented at the top of sysconfig.py and which we've had ever since distutils
became part of the stdlib
Marc-Andre Lemburg added the comment:
FWIW: I still think that allowing to change .__class__ on instances of static
types if wrong and should be undone. If we want to make this a feature of the
language we should have a PEP and the associated discussion to be able to judge
and document
Marc-Andre Lemburg added the comment:
On 01.09.2015 04:38, Nathaniel Smith wrote:
> Mark Lemburg wrote:
>> Python code will generally assume that it can trust
>> builtin types. It doesn't expect 42 + 2 to clear out the root dir,
>> just because some package installed from
Marc-Andre Lemburg added the comment:
mktime() does change several global C runtime variables on Linux. See the man
page on http://linux.die.net/man/3/mktime
However, the Python documentation does not mention anything about having
time.tzname being tied to the C lib global:
https
Marc-Andre Lemburg added the comment:
BTW: The most portable way to access the timezone name of a given local time is
to use strftime() with %Z as format character.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Marc-Andre Lemburg added the comment:
On 31.08.2015 10:44, Nathaniel Smith wrote:
> Before anyone panics about security issues, do keep in mind that the patch
> you're talking about
reverting fixed a buffer overflow which I strongly suspect could be used to
accomplish arbitrary
code exe
Marc-Andre Lemburg added the comment:
On 31.08.2015 11:55, Antoine Pitrou wrote:
>
> __class__ assignment can definitely be useful for monkey-patching, or other,
> purposes.
The feature certainly has its place for user defined types (see the
unpickle example), but I don't think
Marc-Andre Lemburg added the comment:
I agree with Mark. This feature opens up a security hole large enough to drive
a train through.
Looking at the python-dev thread, the only motivation appears to be making
module look more like classes. I'd suggest to propose a PEP for making changes
Marc-Andre Lemburg added the comment:
If I understand you correctly, the only advantage of using /MT is
not require admin privileges for installation of the VC2015 runtime
libs.
Since VC2015 will be used by a lot of applications in a few months,
and it's likely that MS will ship the runtime
Marc-Andre Lemburg added the comment:
On 17.08.2015 18:24, Steve Dower wrote:
We can't have Python run VCredist because it requires administrative
privileges and installing Python does not require those. This is actually one
of the biggest complaints about the current installer
Marc-Andre Lemburg added the comment:
What effect does this static linking of the VC runtime have on libraries that
extension modules link at dynamically ?
E.g. say I have an extension which links against an ODBC driver DLL using a
different VC runtime than the one used to build Python
Marc-Andre Lemburg added the comment:
Please use encoding='utf-8' as definition for codecs.encode() and
codecs.decode().
There is no adjustable default encoding in Python 3 anymore.
For Python 3.6 this should probably be fixed everywhere
Marc-Andre Lemburg added the comment:
On 21.07.2015 22:15, dlroo wrote:
dlroo added the comment:
If you are using mx.DateTime make certain you do not use the .strftime
method. If you use .strftime method and have a 60th second in your DateTime
object it will crash python with no error
Marc-Andre Lemburg added the comment:
On 30.06.2015 20:52, Min RK wrote:
Thanks for the feedback, I thought it might be a long shot. I will go back to
removing the *use* of the feature everywhere I can find it, since it is so
problematic and rarely, if ever, desirable.
Could you please
301 - 400 of 1900 matches
Mail list logo
