Wolfgang Langner added the comment:
I think this pep is related to the issue and could be a solution:
https://www.python.org/dev/peps/pep-0582/
--
nosy: +tds333
___
Python tracker
<https://bugs.python.org/issue35
Wolfgang Langner added the comment:
Thanks for fixing this so fast. Good work.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Wolfgang Langner:
The output for "python --help" for the option -B is wrong.
It contains also the old pyo files. But they were removed.
Output is:
-B : don't write .py[co] files on import; also PYTHONDONTWRITEBYTECODE=x
should be:
-B : don't write
Wolfgang Langner added the comment:
Also verified on CentOS 6.8 with devtoolset2 installed, gcc 4.8.2
Python 3.6b2 builds fine, all unittest ok.
This is the same devtoolset as used on CentOS 5 manylinux1.
Have no CentOS 5 VM available to do more tests. But gcc 4.8 is able to build
Python 3.6
Wolfgang Langner added the comment:
Please check if you have enabled the compiler as default by enabling the
devtoolset on CentOS 5.
I have compiled Python 3.6b2 on Ubuntu 14.04 with gcc 4.8.4 without any
problems.
Therefore gcc 4.8.2 should not be that different.
Also keep in mind
Wolfgang Langner added the comment:
But this is nearly the same as a *.pth file.
Using the same logic and extension then does not confuse more users.
Why not doing the same as with a .pth file?
Using something like a _sys.pth file if it is there it will be used for path
handling. In all cases
Wolfgang Langner added the comment:
If this is only for the use case of embedded distribution we are now only to
steps away to provide a easy custom shipping of applications for Windows.
1. Take the file name of the executable to load a custom EXECUTABLENAME.path
file
2. Allow to specify
Wolfgang Langner added the comment:
This can be related to building manylinux1 binaries where the Centos 5.11 is
used.
There can be a possibility to break manaylinux1 builds for Python 3.6, they are
used to distribute packages for every Linux distribution.
https://www.python.org/dev/peps/pep
Wolfgang Langner added the comment:
Yes this is the cause. If it is renamed to python36.zip everything works fine.
For the test I have only extracted the distributed zip and executed python.exe.
Had not looked further into the issue. So only the simple report something did
not work.
Thanks
New submission from Wolfgang Langner:
Tried to extract Windows x86-64 embeddable zip file and execute it.
But following error happened (3.6.0a1):
Fatal Python error: Py_Initialize: unable to load the file system codec
ImportError: No module named 'encodings'
Current thread 0x17c4 (most
Wolfgang Langner added the comment:
Ok, I implemented point 3.
Check if it is a dir or file and makepath only in this case.
All other entries are added unmodified to the set.
Added a test case also for an URL path.
I think duplicate detection is now improved and it should break nothing
Wolfgang Langner added the comment:
I think a fix for 3.6 only is ok, because it changes behaviour.
But this is only an internal function with a "_".
Should I add a test with a temporary created pth file?
--
___
Python tr
Wolfgang Langner added the comment:
Extended unit test for the issue and patch for site.py.
--
Added file: http://bugs.python.org/file42225/site.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Wolfgang Langner:
In site.py there is the internal function _init_pathinfo() This function builds
a set of path entries from sys.path. This is used to avoid duplicate entries in
sys.path.
But this function has a check if it is a directory with os.path.isdir(...). All
Wolfgang Langner added the comment:
As a note, I had problems installing Python 3.5 on a computer at work.
The redist package could not install with access denied error.
But the workaround installing the Universal CRT update helped.
After this I was able to install Python 3.5 without problems
New submission from Wolfgang Langner:
The Windows x86-64 embeddable zip file (and possible the one for 32bit)
includes some unnecessary test folders in python35.zip with test scripts.
python35.zip\distutils\tests\
python35.zip\unittest\test\
python35.zip\lib2to3\tests\
python35.zip\ctypes\test
New submission from Wolfgang Langner:
In the Windows x86-64 embeddable zip file in
python35.zip\distutils\command\
are a lot of big EXE files. Possible during build for different
VC compilers.
I don't know the exact structure but thing there should only be EXE's
for the actual used compiler
Wolfgang Langner added the comment:
expandvars(), and expanduser() is part of os.path.
Boot functions are needed for path objects and very useful.
And yes it is a simple string substitution but very common.
--
nosy: +tds333
___
Python tracker rep
Wolfgang Langner added the comment:
Why not implement this pattern with
def dirs(pattern)
and
def files(pattern)
where both are a simple shortcut for
(p for p in mypath.glob(pattern) if p is_file())
or is_dir()
?
--
nosy: +tds333
___
Python
Wolfgang Langner [EMAIL PROTECTED] added the comment:
In this cases it is not really possible to sniff the right delimiter.
To not allow digits or letters is not a good solution.
I think the behavior as now is ok, and at this time I see now way to
improve
Wolfgang Langner [EMAIL PROTECTED] added the comment:
The sniffer returns an dialect that is not really correct. Because the
delimiter is set to value and in this case there is no delimiter.
See it as, it returns a random delimiter if there is not really one.
But your usage of the DictReader
Hello,
Is anyone truly attached to nested tuple function parameters; 'def
fxn((a,b)): print a,b'? /.../
Would anyone really throw a huge fit if they went away? I am willing
to write a PEP for their removal in 2.6 with a deprecation in 2.5 if
people are up for it.
Hello Jochen,
I started embedding python into a 3D graphics App and I came
across this linking problem.
SO.lib(ScnGlobal.obj) : error LNK2001: unresolved external symbol
__imp__Py_InitModule4TraceRefs
SO.lib(ScnNode.obj) : error LNK2001: unresolved external symbol
__imp___Py_RefTotal
23 matches
Mail list logo
