Re: [Python-Dev] Use utf-8 charset for tracker summaries?

[Ezio Melotti]

On Sat, Mar 12, 2016 at 12:09 AM, Terry Reedy  wrote:
> The weeky 'Summariy of Python tracker Issues' ('tracker' should be
> capitalized if 'Issues' is) starts with
>
> Content-Type: text/plain; charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
>
> Names sometimes have not-ascii chars, and they do not get properly displayed
> for me with Thunderbird on Windows.  For instance,
>   Raúl Núñez de Arenas (Raúl Núñez de Arenas)
> is transmitted as
>   Ra=C3=BAl N=C3=BA=C3=B1ez de= Arenas
> and displayed as
>   Raúl Núñez de Arenas
>

This already looks like UTF-8 -- you should be able to verify this by
manually selecting UTF-8 as encoding from the menu.
If the Content-Type still uses us-ascii though, it should be fixed to
specify UTF-8 instead.

Best Regards,
Ezio Melotti

> I am rather sure that this does not happen with email sent to me by the
> tracker itself.
>
> --
> Terry Jan Reedy
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Bug in build system for cross-platform builds

[Martin Panter]

On 11 March 2016 at 23:16, Russell Keith-Magee  wrote:
>
> On Sat, Mar 12, 2016 at 6:38 AM, Martin Panter  wrote:
>> make clean  # Work around confusion with existing in-source build
>> mkdir native
>> (cd native/ && ../configure)
>> make -C native/ Parser/pgen
>> mkdir mingw
>> (cd mingw/ && ../configure --host=i486-mingw32 --build=x86)
>> make -C mingw/ PGEN=../native/Parser/pgen
>>
>> Actually it was not as smooth as the above commands, because pgen
>> tends to get overwritten with a cross-compiled version. Perhaps we
>> could add a PGEN_FOR_BUILD override, like HOSTPGEN in the patch used
>> at
>> .
>>
> That might fix the pgen problem,  but _freeze_importlib still remains. I
> suppose the same thing might be possible for _freeze_importlib as well…

Yes. I never got up to it failing in my experiments, but I think I
would propose a FREEZE_IMPORTLIB override variable for that too.

>> Would it be more correct to say instead that in 3.4 you did a separate
>> native build step, precompiling pgen and _freeze_importlib for the
>> native build host? Then you hoped that the child Make was _not_
>> invoked in the cross-compilation stage and your precompiled
>> executables would not be rebuilt?
>
>
> Yes - as far as I can make out (with my admittedly hazy understanding), that
> appears to be what is going on. Although it’s not that I “hoped” the build
> wouldn’t happen on the second pass - it was the behavior that was previously
> relied, and on was altered.

Do you have a copy/patch/link/etc to the actual commands that you
relied on? It’s hard to guess exactly what you were doing that broke
without this information.

>> > As best as I can work out, the solution is to:
>> >
>> > (1) Include the parser generator and _freeze_importlib as part of the
>> > artefacts of local platform. That way, you could use the version of pgen
>> > and
>> > _freeze_importlib that was compiled as part of the local platform build.
>> > At
>> > present, pgen and _freeze_importlib are used during the build process,
>> > but
>> > aren’t preserved at the end of the build; or
>>
>> I don’t understand. After I run Make, it looks like I get working
>> executables leftover at Programs/_freeze_importlib and Parser/pgen. Do
>> you mean to install these programs with “make install” or something?
>
>
> Making them part of the installable artefacts would be one option, but they
> don’t have to be installed, just preserved.

What commands are you running that cause them to not be preserved at
the end of the build?

> For example, as a nasty hack, I’ve been able to use this approach to get the
> build working for 3.5. After the native build, I copy _freeze_importlib to a
> “safe” location. I then copy it back into place prior to the target build.
> It works, but it’s in no way suitable for a final build.
>
>>
>> > (2) Include some concept of the “local compiler” in the build process,
>> > which
>> > can be used to compile pgen and _freeze_importlib; or
>>
>> On the surface solution (2) sounds like the ideal fix. But I guess the
>> local native compiler might also require a separate set of CPPFLAGS,
>> pyconfig.h settings etc. In other words it is sounding like a whole
>> separate “configure” run. I am thinking it might be simplest to just
>> require this native “configure” run to be done manually.
>
>
> That run is going to happen anyway, since you have to compile and build for
> the native platform.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Bug in build system for cross-platform builds

[Russell Keith-Magee]

On Sat, Mar 12, 2016 at 6:38 AM, Martin Panter  wrote:

> Hi Russell. Sorry for the minor ~1 month delay in replying :)
>
> I have been doing some experimenting to see what is involved in
> cross-compiling Python (Native host = Linux, target = Windows via
> mingw and some patches). So I have a slightly better understanding of
> the problem than before.
>
> On 16 February 2016 at 01:41, Russell Keith-Magee
>  wrote:
> > In order to build for a host platform, you have to compile for a local
> > platform first - for example, to compile an iOS ARM64 binary, you have to
> > compile for OS X x86_64 first. This gives you a local platform version of
> > Python you can use when building the iOS version.
> >
> > Early in the Makefile, the variable PYTHON_FOR_BUILD is set. This points
> at
> > the CPU-local version of Python that can be invoked, which is used for
> > module builds, and for compiling the standard library source code. This
> is
> > set by —host and —build flags to configure, plus the use of CC and
> LDFLAGS
> > environment variables to point at the compiler and libraries for the
> > platform you’re compiling for, and a PATH variable that provides the
> local
> > platform’s version of Python.
>
> So far I haven’t succeeded with my Min GW cross build and am
> temporarily giving up due to incompatibilities. But my attempts looked
> a bit like this:
>
> make clean  # Work around confusion with existing in-source build
> mkdir native
> (cd native/ && ../configure)
> make -C native/ Parser/pgen
> mkdir mingw
> (cd mingw/ && ../configure --host=i486-mingw32 --build=x86)
> make -C mingw/ PGEN=../native/Parser/pgen
>
> Actually it was not as smooth as the above commands, because pgen
> tends to get overwritten with a cross-compiled version. Perhaps we
> could add a PGEN_FOR_BUILD override, like HOSTPGEN in the patch used
> at <
> https://wayback.archive.org/web/20160131224915/http://randomsplat.com/id5-cross-compiling-python-for-embedded-linux.html
> >.
>
> That might fix the pgen problem,  but _freeze_importlib still remains. I
suppose the same thing might be possible for _freeze_importlib as well…

> There are two places where special handling is required: the compilation
> and
> > execution of the parser generator, and _freeze_importlib. In both cases,
> the
> > tool needs to be compiled for the local platform, and then executed.
> > Historically (i.e., Py3.4 and earlier), this has been done by spawning a
> > child MAKE to compile the tool; this runs the compilation phase with the
> > local CPU environment, before returning to the master makefile and
> executing
> > the tool. By spawning the child MAKE, you get a “clean” environment, so
> the
> > tool is built natively. However, as I understand it, it causes problems
> with
> > parallel builds due to race conditions on build rules. The change in
> > Python3.5 simplified the rule so that child MAKE calls weren’t used, but
> > that means that pgen and _freeze_importlib are compiled for ARM64, so
> they
> > won’t run on the local platform.
>
> You suggest that the child Make command happened to compile pgen etc
> natively, rather than with the cross compiler. But my understanding is
> that when you invoke $(MAKE), all the environment variables, configure
> settings, etc, including the cross compiler, would be inherited by the
> child.
>
> Would it be more correct to say instead that in 3.4 you did a separate
> native build step, precompiling pgen and _freeze_importlib for the
> native build host? Then you hoped that the child Make was _not_
> invoked in the cross-compilation stage and your precompiled
> executables would not be rebuilt?
>

Yes - as far as I can make out (with my admittedly hazy understanding),
that appears to be what is going on. Although it’s not that I “hoped” the
build wouldn’t happen on the second pass - it was the behavior that was
previously relied, and on was altered.


> > As best as I can work out, the solution is to:
> >
> > (1) Include the parser generator and _freeze_importlib as part of the
> > artefacts of local platform. That way, you could use the version of pgen
> and
> > _freeze_importlib that was compiled as part of the local platform build.
> At
> > present, pgen and _freeze_importlib are used during the build process,
> but
> > aren’t preserved at the end of the build; or
>
> I don’t understand. After I run Make, it looks like I get working
> executables leftover at Programs/_freeze_importlib and Parser/pgen. Do
> you mean to install these programs with “make install” or something?
>

Making them part of the installable artefacts would be one option, but they
don’t have to be installed, just preserved.

For example, as a nasty hack, I’ve been able to use this approach to get
the build working for 3.5. After the native build, I copy _freeze_importlib
to a “safe” location. I then copy it back into place prior to the target
build. It works, but it’s in no way suitable for a final 

Re: [Python-Dev] Bug in build system for cross-platform builds

[Martin Panter]

Hi Russell. Sorry for the minor ~1 month delay in replying :)

I have been doing some experimenting to see what is involved in
cross-compiling Python (Native host = Linux, target = Windows via
mingw and some patches). So I have a slightly better understanding of
the problem than before.

On 16 February 2016 at 01:41, Russell Keith-Magee
 wrote:
> In order to build for a host platform, you have to compile for a local
> platform first - for example, to compile an iOS ARM64 binary, you have to
> compile for OS X x86_64 first. This gives you a local platform version of
> Python you can use when building the iOS version.
>
> Early in the Makefile, the variable PYTHON_FOR_BUILD is set. This points at
> the CPU-local version of Python that can be invoked, which is used for
> module builds, and for compiling the standard library source code. This is
> set by —host and —build flags to configure, plus the use of CC and LDFLAGS
> environment variables to point at the compiler and libraries for the
> platform you’re compiling for, and a PATH variable that provides the local
> platform’s version of Python.

So far I haven’t succeeded with my Min GW cross build and am
temporarily giving up due to incompatibilities. But my attempts looked
a bit like this:

make clean  # Work around confusion with existing in-source build
mkdir native
(cd native/ && ../configure)
make -C native/ Parser/pgen
mkdir mingw
(cd mingw/ && ../configure --host=i486-mingw32 --build=x86)
make -C mingw/ PGEN=../native/Parser/pgen

Actually it was not as smooth as the above commands, because pgen
tends to get overwritten with a cross-compiled version. Perhaps we
could add a PGEN_FOR_BUILD override, like HOSTPGEN in the patch used
at 
.

> There are two places where special handling is required: the compilation and
> execution of the parser generator, and _freeze_importlib. In both cases, the
> tool needs to be compiled for the local platform, and then executed.
> Historically (i.e., Py3.4 and earlier), this has been done by spawning a
> child MAKE to compile the tool; this runs the compilation phase with the
> local CPU environment, before returning to the master makefile and executing
> the tool. By spawning the child MAKE, you get a “clean” environment, so the
> tool is built natively. However, as I understand it, it causes problems with
> parallel builds due to race conditions on build rules. The change in
> Python3.5 simplified the rule so that child MAKE calls weren’t used, but
> that means that pgen and _freeze_importlib are compiled for ARM64, so they
> won’t run on the local platform.

You suggest that the child Make command happened to compile pgen etc
natively, rather than with the cross compiler. But my understanding is
that when you invoke $(MAKE), all the environment variables, configure
settings, etc, including the cross compiler, would be inherited by the
child.

Would it be more correct to say instead that in 3.4 you did a separate
native build step, precompiling pgen and _freeze_importlib for the
native build host? Then you hoped that the child Make was _not_
invoked in the cross-compilation stage and your precompiled
executables would not be rebuilt?

> As best as I can work out, the solution is to:
>
> (1) Include the parser generator and _freeze_importlib as part of the
> artefacts of local platform. That way, you could use the version of pgen and
> _freeze_importlib that was compiled as part of the local platform build. At
> present, pgen and _freeze_importlib are used during the build process, but
> aren’t preserved at the end of the build; or

I don’t understand. After I run Make, it looks like I get working
executables leftover at Programs/_freeze_importlib and Parser/pgen. Do
you mean to install these programs with “make install” or something?

> (2) Include some concept of the “local compiler” in the build process, which
> can be used to compile pgen and _freeze_importlib; or

On the surface solution (2) sounds like the ideal fix. But I guess the
local native compiler might also require a separate set of CPPFLAGS,
pyconfig.h settings etc. In other words it is sounding like a whole
separate “configure” run. I am thinking it might be simplest to just
require this native “configure” run to be done manually.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Use utf-8 charset for tracker summaries?

[Terry Reedy]

The weeky 'Summariy of Python tracker Issues' ('tracker' should be 
capitalized if 'Issues' is) starts with


Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Names sometimes have not-ascii chars, and they do not get properly 
displayed for me with Thunderbird on Windows.  For instance,

  Raúl Núñez de Arenas (Raúl Núñez de Arenas)
is transmitted as
  Ra=C3=BAl N=C3=BA=C3=B1ez de= Arenas
and displayed as
  Raúl Núñez de Arenas

I am rather sure that this does not happen with email sent to me by the 
tracker itself.


--
Terry Jan Reedy


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support

[anais timaure]

Por favor quiero descargar este programa para mi teléfono Windows 8

Anais'Timaure♡___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Summary of Python tracker Issues

[Michael Felt]

I guess I should have never changed the title - apparently the tracker 
loses track - there are more than 5 messages.


On 2016-03-04 18:08, Python tracker wrote:

#26439: ctypes.util.find_library fails when ldconfig/glibc not availab
http://bugs.python.org/issue264395 msgs
And, while I do not want to ping the list in a rude way, I submitted a 
patch - not perfect of course (seems to work as expected stand-alone, 
but not in a 'build' attempt (a previous 'half' patch that was the 'work 
in progress' did build) - so as I hope to have time in the coming days 
to dig further - some hints on how to debug the failed 'build moment 
during 'make install' would be greatly appreciated.


Basically, the make install ends with:

...

Compiling 
/var/aixtools/aixtools/python/2.7.11.2/opt/lib/python2.7/xml/sax/xmlreader.py 
...
Compiling /var/aixtools/aixtools/python/2.7.11.2/opt/lib/python2.7/xmllib.py ...
Compiling /var/aixtools/aixtools/python/2.7.11.2/opt/lib/python2.7/xmlrpclib.py 
...
Compiling /var/aixtools/aixtools/python/2.7.11.2/opt/lib/python2.7/zipfile.py 
...
make: 1254-004 The error code from the last command is 1.


Stop.
root@x064:[/data/prj/aixtools/python/python-2.7.11.2]


So, my question: how do I make the 'compile' of 
/var/aixtools/aixtools/python/2.7.11.2/opt/lib/python2.7/zipfile.py more 
verbose?

I tried "make V=1 DESTDIR=/var/aixtools/aixtools/python/2.7.11.2 install". but 
the output was identical.

Thanks,
Michael
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2016-03-04 - 2016-03-11)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open5454 (+19)
  closed 32842 (+40)
  total  38296 (+59)

Open issues with patches: 2373 


Issues opened (39)
==

#16851: Hint about correct ismethod and isfunction usage
http://bugs.python.org/issue16851  reopened by haypo

#26481: unittest discovery process not working without .py source file
http://bugs.python.org/issue26481  opened by stefan

#26483: docs unclear on difference between str.isdigit() and str.isdec
http://bugs.python.org/issue26483  opened by ethan.furman

#26488: hashlib command line interface
http://bugs.python.org/issue26488  opened by palaviv

#26491: Defer DECREFs until enum object is in a consistent state for r
http://bugs.python.org/issue26491  opened by rhettinger

#26492: Exhausted array iterator should left exhausted
http://bugs.python.org/issue26492  opened by serhiy.storchaka

#26493: Bad formatting in WinError 193 when using subprocess.check_cal
http://bugs.python.org/issue26493  opened by Raúl Núñez de Arenas

#26494: Double deallocation on iterator exhausting
http://bugs.python.org/issue26494  opened by serhiy.storchaka

#26495: super() does not work in nested functions, genexps, listcomps,
http://bugs.python.org/issue26495  opened by ztane

#26496: Exhausted deque iterator should free a reference to a deque
http://bugs.python.org/issue26496  opened by serhiy.storchaka

#26499: http.client.IncompleteRead from HTTPResponse read after part r
http://bugs.python.org/issue26499  opened by maubp

#26500: Document of star operator missing. It must be documented for b
http://bugs.python.org/issue26500  opened by janonymous

#26503: argparse with required field , not having new line separator i
http://bugs.python.org/issue26503  opened by mohankumar

#26506: hex() documentation: mention "%x" % int
http://bugs.python.org/issue26506  opened by haypo

#26507: Use highest pickle protocol in multiprocessing
http://bugs.python.org/issue26507  opened by ebehn

#26509: spurious ConnectionAbortedError logged on Windows
http://bugs.python.org/issue26509  opened by sebastien.bourdeauducq

#26510: [argparse] Add required argument to add_subparsers
http://bugs.python.org/issue26510  opened by memeplex

#26511: Add link to id() built-in in comparison operator documentation
http://bugs.python.org/issue26511  opened by Mike Vertolli

#26512: Vocabulary: Using "integral" in library/stdtypes.html
http://bugs.python.org/issue26512  opened by sizeof

#26513: platform.win32_ver() broken in 2.7.11
http://bugs.python.org/issue26513  opened by Florian Roth

#26515: Update extending/embedding docs to new way to build modules in
http://bugs.python.org/issue26515  opened by brett.cannon

#26516: Add PYTHONMALLOC env var and add support for malloc debug hook
http://bugs.python.org/issue26516  opened by haypo

#26517: Crash in installer
http://bugs.python.org/issue26517  opened by jools

#26519: Cython doesn't work anymore on Python 3.6
http://bugs.python.org/issue26519  opened by haypo

#26523: multiprocessing ThreadPool is untested
http://bugs.python.org/issue26523  opened by pitrou

#26524: document what config directory is used for
http://bugs.python.org/issue26524  opened by jbeck

#26525: Documentation of ord(c) easy to misread
http://bugs.python.org/issue26525  opened by gladman

#26526: In parsermodule.c, replace over 2KLOC of hand-crafted validati
http://bugs.python.org/issue26526  opened by A. Skrobov

#26527: CGI library - Using unicode in header fields
http://bugs.python.org/issue26527  opened by Olivier.Le.Moign

#26528: NameError for built in function open when re-raising stored ex
http://bugs.python.org/issue26528  opened by reidfaiv

#26530: tracemalloc: add C API to manually track/untrack memory alloca
http://bugs.python.org/issue26530  opened by haypo

#26531: KeyboardInterrupt while in input() not catchable on Windows 10
http://bugs.python.org/issue26531  opened by jecanne

#26533: logging.config does not allow disable_existing_loggers=True
http://bugs.python.org/issue26533  opened by Grazfather x

#26534: subprocess.check_output with shell=True ignores the timeout
http://bugs.python.org/issue26534  opened by Daniel Shaulov

#26535: Minor typo in the docs for struct.unpack
http://bugs.python.org/issue26535  opened by Antony.Lee

#26536: Add the SIO_LOOPBACK_FAST_PATH option to socket.ioctl
http://bugs.python.org/issue26536  opened by Daniel Stokes

#26537: ConfigParser has optionxform, but not sectionxform
http://bugs.python.org/issue26537  opened by Anaphory

#26538: regrtest: setup_tests() must not replace module.__path__ (_Nam
http://bugs.python.org/issue26538  opened by haypo

#26539: frozen executables should have an empty path
http://bugs.python.org/issue26539  opened by Daniel Shaulov



Most recent 15 issues with no replies (15)