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
<http://bugs.python.org/issue29770>
___
___
Python-bugs-list m
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
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 the
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 a
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 0x
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 trac
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
<http://bugs.python.org/issue26
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
this
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:
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 c
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
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 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
<h
New submission from Wolfgang Langner <[EMAIL PROTECTED]>:
Some links still point to the sourceforge bug tracker.
(one from http://pypi.python.org/pypi bug reports).
Check if there are others and let them point to the new bug tracker.
--
components: None
messages: 69680
nosy:
New submission from Wolfgang Langner <[EMAIL PROTECTED]>:
References can be added case sensitive as .. _myRef:
but only used case insensitive with :ref:`myref`
usage of :ref:`myRef` doesn't generate a working reference.
Make this behavior consistent please, always case insensitiv
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
impr
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 Dict
23 matches
Mail list logo