New submission from Marc-Andre Lemburg:
Trying to use .get_msvc_path() on an distutils.msvccompiler.MSVCCompiler()
instance raises an AttributeError:
MSVCCompiler instance has no attribute '_MSVCCompiler__root'
The reason seems to be that self.__root is not set for Win x64 in
Marc-Andre Lemburg added the comment:
I checked the registry to find the correct root. This would be
Software\Microsoft\VisualStudio\.
However, VC 9.0 no longer seems to set the variables the method is looking for,
so even if the .__root attribute problem gets fixed, the method would not find
Marc-Andre Lemburg added the comment:
Adding Hye-Shik who wrote the codec.
--
nosy: +hyeshik.chang
___
Python tracker
<http://bugs.python.org/issue24117>
___
___
Marc-Andre Lemburg added the comment:
On 05.05.2015 21:24, levkivskyi wrote:
>
> Links to Python library documentation such as:
> http://docs.python.org/library/functions.html
> http://docs.python.org/library/itertools.html
> http://docs.python.org/library/functools.ht
Marc-Andre Lemburg added the comment:
Thanks, Berker, your patch looks fine.
--
___
Python tracker
<http://bugs.python.org/issue1322>
___
___
Python-bugs-list m
Marc-Andre Lemburg added the comment:
Here's a patch which I have tested on Linux, FreeBSD and Mac OS X.
It solves the problem with compiling in Windows calls on non-Windows platforms
and resynchronizes the ffi_raw_call() function with the ffi_call()
implementation. Both functions ha
Marc-Andre Lemburg added the comment:
Changing the title to reflect that the solution to how to configure Python is
still up in the air.
I also started a thread on python-dev to get some more feedback.
--
title: Make default HTTPS certificate verification setting configurable via
Marc-Andre Lemburg added the comment:
Those are nice ideas, but you are forgetting two important points:
* browsers are typically only being used by single users,
applications by potentially hundreds or thousands of users
* how should the poor sys admin who's task it is to keep P
Marc-Andre Lemburg added the comment:
I like the idea of adding a free list of longs in Python 3, but I think we
should extend this somewhat to cover more ground, e.g. by pre-allocating a
block of 1 digit long objects, like we did for Python 2 ints, and perhaps
allocate up to 4k (= 1 memory
Marc-Andre Lemburg added the comment:
On 11.05.2015 11:42, Serhiy Storchaka wrote:
>
> Pre-allocating a block has a disadvantage. It is hard to free allocated
> block. The program can create a lot of integers, then drop most of them, and
> request the memory for other needs, but
Marc-Andre Lemburg added the comment:
Why are you removing the mcvs9compiler.py file when at the same time your are
referencing it in the msvccompiler.py doc string ?
--- a/Lib/distutils/msvccompiler.py
+++ b/Lib/distutils/msvccompiler.py
@@ -1,201 +1,120 @@
"""distuti
Marc-Andre Lemburg added the comment:
On 11.05.2015 21:03, Steve Dower wrote:
>
> Steve Dower added the comment:
>
> Simply because I didn't update the doc string :)
>
> I don't really want to put a version number on this file, since it isn't MSVC
>
Marc-Andre Lemburg added the comment:
On 11.05.2015 23:20, Steve Dower wrote:
>
> I guess we need a third opinion.
>
> For me, the subclasses of CCompiler are undocumented and not a guaranteed
> interface (people using them directly are consenting adults). They're also an
Marc-Andre Lemburg added the comment:
On 11.05.2015 23:50, Paul Moore wrote:
>
> I agree with Steve, we shouldn't be constrained to preserve all the
> undocumented internals of distutils - doing that in the past is what has made
> distutils essentially unmaintainable.
&
Marc-Andre Lemburg added the comment:
Looks good. Thanks, Serhiy.
--
___
Python tracker
<http://bugs.python.org/issue22682>
___
___
Python-bugs-list mailin
Changes by Marc-Andre Lemburg :
--
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue17762>
___
___
Pyth
Marc-Andre Lemburg added the comment:
See issue1322
--
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Marc-Andre Lemburg added the comment:
See issue1322 for why we're closing this.
--
___
Python tracker
<http://bugs.python.org/issue17762>
___
___
Pytho
Marc-Andre Lemburg added the comment:
On 13.05.2015 16:18, Petr Viktorin wrote:
>
> Issues #17762 and #9514 had patches to improve these functions. Time to close
> them?
Yes. I just did. Thanks for the reminder.
--
___
Python track
Marc-Andre Lemburg added the comment:
On 14.05.2015 13:29, Petr Viktorin wrote:
>
> Marc-Andre, Barry, you expressed interest in the macro on the mailing list;
> do you still think it's a good idea?
Yes.
The fact that the macro can save us more than a hundred lines
of code in
Marc-Andre Lemburg added the comment:
issue23042 is fixed now. libffi 3.2.1 apparently has the same issue, so the
issue23042 patch would probably have to be reapplied (slightly modified,
though).
Seeing that libffi has had a major compilation problem breaking it on at least
FreeBSD and most
Marc-Andre Lemburg added the comment:
On 18.05.2015 15:46, Stefan Krah wrote:
>
> Stefan Krah added the comment:
>
> The problem with this macro is that most of the time it takes the
> standard cmp return value {-1,0,1} and converts that into a bool.
>
> For this use c
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:
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:
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
<http://bugs.py
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
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
If the
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
<http://bugs.python.org/issue28
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
> av
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:
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 is
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:
> 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:
+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
<http://bugs.python.org/is
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
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
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:
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.
In
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 stay.
As
Marc-Andre Lemburg added the comment:
Thanks, Ville.
--
___
Python tracker
<http://bugs.python.org/issue28393>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
<http://bugs.python.org/is
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.
> BT
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 for
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
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:
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
1901 - 1946 of 1946 matches
Mail list logo
