New submission from Marc:
Hi,
We work in a school within a domain and pupils are using different restricted
account on this domain. We tried to install Python 3.4 and it's work with an
Administrator Account.
With Children account , we got the message IDLE's subprocess didn't make
Marc-Andre Lemburg added the comment:
On 15.01.2015 23:46, Martin Panter wrote:
I opened Issue 23231 about fixing iterencode() and iterdecode() in the
general case. I added a patch to Issue 13881 to fix StreamWriter for zlib and
bz2, and to fix StreamWriter.writelines() in general.
I
Marc-Andre Lemburg added the comment:
This addition is wrong as well:
The *stream* argument must be a file-like object open for reading
- text or binary data, as appropriate for the specific codec.
+ text or binary data, as appropriate for the specific codec. This stream is
+ assumed
Marc-Andre Lemburg added the comment:
On 14.01.2015 02:21, Martin Panter wrote:
Martin Panter added the comment:
I don’t think this is appropriate. If you want to flush the underlying
stream, then call its flush() method after calling reset(). The docstring
only says it flushes
Marc-Andre Lemburg added the comment:
On 09.01.2015 09:33, Raymond Hettinger wrote:
I'm withdrawing this one. After more work trying many timings on multiple
compilers and various sizes and kinds of datasets, it appears that the
unicode specialization is still worth it.
The cost
Marc-Andre Lemburg added the comment:
On 08.01.2015 15:46, Serhiy Storchaka wrote:
Sets of strings are very common when trying to create a unique set of
strings or optimizing name in set_of_names lookups.
This is not nearly so common as attributes or globals access, or passing
keyword
Marc-Andre Lemburg added the comment:
I'm not sure I follow:
Sets of strings are very common when trying to create a unique set of strings
or optimizing name in set_of_names lookups.
Regarding your benchmark numbers: I have a hard time following how they work. A
simply word
Marc Schlaich added the comment:
This issue is not fully fixed, there are some occasions where you can still run
into it. One example is if you want to spawn a new multiprocessing.Process as
sub process in a multiprocessing.Process:
pythonservice.exe
- multiprocessing.Process
Marc-Andre Lemburg added the comment:
Josh, you might want to have a look at the lightning talk on this page and the
associated slides...
http://www.egenix.com/library/presentations/PyCon-UK-2014-When-performance-matters/
After having done the tests, using __slots__ is what I consider
Marc-Andre Lemburg added the comment:
+1
--
nosy: +lemburg
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23071
___
___
Python-bugs-list mailing
Marc-Andre Lemburg added the comment:
Will this also fix http://bugs.python.org/issue23042 ?
--
nosy: +lemburg
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23085
Marc-Andre Lemburg added the comment:
I agree with Vajrasky: a patch for the documentation would probably be a good
idea.
Note that mixing line end conventions in a single text is never a good idea. If
you stick to one line end convention, there's no problem with the codec, AFAICT
Marc Abramowitz added the comment:
Testing a few common cases:
$ python setup.py check --restructuredtext --strict --metadata
running check
error: The docutils package is needed.
$ python setup.py check --restructuredtext --strict --metadata
running check
warning: check: Cannot analyze code
Marc Abramowitz added the comment:
Note that this patch does 2 things:
1. Improves the error message
2. Prevents check from failing when there are code-blocks
If I only did #1 and not #2, then output looks like this:
$ python setup.py check --restructuredtext --strict --metadata echo RST
Marc-Andre Lemburg added the comment:
On 16.12.2014 05:54, Steve Dower wrote:
Nobody seemed too bothered by it, so I committed a slightly simpler change
that only includes the most specific tag (that is, .cp35-win32.pyd or
.pyd). We can always add another tag easily enough if it seems
Marc Abramowitz added the comment:
OK, I added a test.
See:
*
https://bitbucket.org/msabramo/cpython/commits/9b8f6812ff6981b5f195b6bf73cefb0fea46fba6
*
https://bitbucket.org/msabramo/cpython/pull-request/1/fix-distutils-setuppy-check/diff
If you want, I can also update the diff attached
Changes by Marc Abramowitz msabr...@gmail.com:
Added file: http://bugs.python.org/file37472/issue23063.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23063
Marc Abramowitz added the comment:
What's the next step?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23063
___
___
Python-bugs-list mailing
Marc-Andre Lemburg added the comment:
On 16.12.2014 14:38, Steve Dower wrote:
Steve Dower added the comment:
I justified leaving out the ABI tag in an earlier post as well as in an email
to distutils-sig, where two of the PEPs you mention were developed, and
nobody had any comment
New submission from Marc Abramowitz:
`python setup.py check --restructuredtext --strict --metadata` fails with:
warning: check: Could not finish the parsing.
if the RST document uses `code` or `code-block` directives.
This is annoying because the document is valid, but it appears
Marc-Andre Lemburg added the comment:
Please always use PROTOCOL_SSLv23 since this is the only forward compatible way
of telling OpenSSL to use the best protocol available.
Any of the other options such as PROTOCOL_TLSv1 will fix the protocol version
to that one protocol version, whereas
Marc-Andre Lemburg added the comment:
STINNER Victor added the comment:
Any of the other options such as PROTOCOL_TLSv1 will fix the protocol
version to that one protocol version, whereas PROTOCOL_SSLv23 means to use
any protocol starting with SSLv2. In the context options you can
New submission from Marc-Andre Lemburg:
With Python 2.7.8, ctypes builds fine on FreeBSD x86, but with Python 2.7.9,
the build fails with:
*** WARNING: renaming _ctypes since importing it failed:
build/lib.freebsd-8.3-RELEASE-p3-i386-2.7/_ctypes.so: Undefined symbol
ffi_call_win32
Since
Marc-Andre Lemburg added the comment:
The cause seems to be these changes of the file (diff between the 2.7.8 and
2.7.9 version):
@@ -368,14 +374,21 @@ void ffi_call(ffi_cif *cif, void (*fn)(v
#ifdef X86_WIN64
case FFI_WIN64:
ffi_call_win64(ffi_prep_args, ecif, cif-bytes
Marc-Andre Lemburg added the comment:
Reopening the ticket, since I apparently missed the two important uses in the
Python 2.7.9 stdlib:
urllib2.py:
-- context = ssl._create_stdlib_context(cert_reqs=ssl.CERT_REQUIRED,
httplib.py:
-- context = ssl
Marc-Andre Lemburg added the comment:
On 11.12.2014 20:42, Benjamin Peterson wrote:
Usually you can pass your own context.
Yes, in new code, but not in existing Python 2.7 code that wasn't
written for the newly added SSL context feature.
BTW: Having a way to change the SSL options globally
Marc-Andre Lemburg added the comment:
Benjamin Peterson added the comment:
On Thu, Dec 11, 2014, at 15:24, Marc-Andre Lemburg wrote:
Marc-Andre Lemburg added the comment:
On 11.12.2014 20:42, Benjamin Peterson wrote:
Usually you can pass your own context.
Yes, in new code
New submission from Marc-Andre Lemburg:
Here's the traceback from one of the AIX buildbots:
[ 32/400] test_distutils
unable to execute './Modules/ld_so_aix': No such file or directory
[22429 refs]
test test_distutils failed -- Traceback (most recent call last):
File
/home/shager/cpython
Marc-Andre Lemburg added the comment:
The problem also still exists on Python 3.4 (and probably 3.3 and 3.5 as well),
even though these should have the patch from issue18235 applied:
* http://buildbot.python.org/all/builders/PPC64%20AIX%203.4/builds/707
*
http://buildbot.python.org/all
Marc-Andre Lemburg added the comment:
Note that the helper Modules/ld_so_aix is created during configure. Just the
path to the helper in the sysconfig data is wrong (relative to the current dir,
which will most likely always be wrong except for a few special situations such
as when building
Marc-Andre Lemburg added the comment:
Note that there's a difference between the platform's architecture (which is
what get_platform() returns) and the pointer size of the currently running
Python executable.
On 64-bit Linux, it's rather rare to have an application built as 32-bit
executable
Marc-Andre Lemburg added the comment:
On 02.12.2014 19:02, Antoine Pitrou wrote:
Sticking to bitness should be easy (although I wonder if it would be
desirable for platforms with fat binaries - Ned?). If we can go the extra
mile and include platform identification all the better, of course
Marc-Andre Lemburg added the comment:
On 02.12.2014 19:40, Steve Dower wrote:
I was more interested in source file resolution than bytecode caching. If
Python 3.5 would prefer spam.cpython-35.py or spam.cpython-3.py over
spam.py and Python 2 preferred spam.py, then I can more easily
Marc-Andre Lemburg added the comment:
On 02.12.2014 19:46, Antoine Pitrou wrote:
Note that on Linux, 32-bit and 64-bit versions are typically placed
into different directory trees
By whom? Our standard installer doesn't (it uses ../lib/python-X.Y for all
builds).
By the system vendors
Marc-Andre Lemburg added the comment:
On 02.12.2014 20:10, Antoine Pitrou wrote:
Antoine Pitrou added the comment:
Le 02/12/2014 19:59, Marc-Andre Lemburg a écrit :
My main point was that we shouldn't start adding tags for e.g.
PPC, Intel, ARM, etc. since platforms needing to support
Marc-Andre Lemburg added the comment:
The patch looks good.
One nit: the name buffer length should be NAME_MAXLEN instead of 100.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19676
Marc-Andre Lemburg added the comment:
I'm not sure I understand the bug report. What's the problem ? :-)
The codec is a charmap codec generated from the file
MAPPINGS/VENDORS/MICSFT/WINDOWS/CP874.TXT
(http://ftp.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP874.TXT)
This mapping does
Marc-Andre Lemburg added the comment:
BTW: The table on the wiki page shows the same undefined chars.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22929
Marc Schlaich added the comment:
AFAIS this would break all existing code for yield-based coroutine schedulers
(Tornado, Twisted, Trollius, monocle, ...) when a coroutine is exited with
`raise StopIteration` in client code.
And this seems like a lot, a quick GitHub code search gives various
Marc Schlaich added the comment:
Yes, all yield-based coroutines are generators. I know that there is a backward
compatible upgrade path, but this might have a huge impact on existing code.
Interestingly, I didn't know before researching this PEP that you can actually
use `return` without
Marc-Andre Lemburg added the comment:
On 14.11.2014 22:35, Terry J. Reedy wrote:
New stuff is marked New in version 2.7.9., etc. The Idle chapter
(reletively new in the Library Reference itself) has the same problem if new
or quasi-new features in micro-releases are added to the doc before
New submission from Marc-Andre Lemburg:
The documentation shown for Python 2.7.8 currently includes 2.7.9 parts, e.g.
for the ssl modules (https://docs.python.org/2.7/library/ssl.html).
Since there were so many changes to the ssl module for 2.7.9 which are not
available in 2.7.8, I think
New submission from Marc-Andre Lemburg:
With the backport of the Python 3 ssl module, the default context options of
the ssl module were changed.
While this provides better security in many cases, it also causes breakage with
servers or clients which do not support TLSv1 and later.
The ssl
Marc-Andre Lemburg added the comment:
On 13.11.2014 22:03, Benjamin Peterson wrote:
Benjamin Peterson added the comment:
Per http://legacy.python.org/dev/peps/pep-0476/#opting-out the only way to do
these things is horrednously ugly because it's hardly (if ever) a good idea.
The point
Marc-Andre Lemburg added the comment:
On 14.11.2014 01:29, Benjamin Peterson wrote:
But you can reenable SSLv3 by alerting the context and monkeypatching as
described in the PEP.
Well, I can monkeypatch the ssl module of course, but that's
not really the point here. I'm not talking about
Marc-Andre Lemburg added the comment:
Hmm, since neither create_default_context() nor _create_stdlib_context() are
used by any other stdlib modules, I guess the removal of SSLv3 doesn't really
make much difference for existing Python 2.7 applications.
I was irritated by the function names
Marc-Andre Lemburg added the comment:
Shouldn't this be fixed in the APSW setup.py ?
The patch is you are proposing looks harmless, but it can also
mask programming errors in setup.py.
--
nosy: +lemburg
___
Python tracker rep...@bugs.python.org
http
Marc-Andre Lemburg added the comment:
On 08.11.2014 10:28, Serhiy Storchaka wrote:
Compressing pyc files one by one wouldn't save much space because disk space
is allocated by blocks (up to 32 KiB on FAT32). If the size of pyc file is
less than block size, we will not gain anything. ZIP
Marc-Andre Lemburg added the comment:
Even though it may have been considered a private API (*), users certainly
won't understand that their application just broke because of a Python patch
level release upgrade, so if possible, I think the API should be added back and
flagged as private
Marc-Andre Lemburg added the comment:
On 07.11.2014 11:12, Arfrever Frehtes Taifersar Arahesis wrote:
Arfrever Frehtes Taifersar Arahesis added the comment:
_ssl has leading underscore.
Privateness is inherited, so both A._B.C and A._B._D are private.
No, the use of the underscore
Marc-Andre Lemburg added the comment:
On 07.11.2014 11:52, Arfrever Frehtes Taifersar Arahesis wrote:
Arfrever Frehtes Taifersar Arahesis added the comment:
No, the use of the underscore in _ssl is per convention that C
implementation part of stdlib modules are moved into modules
Marc-Andre Lemburg added the comment:
On 07.11.2014 11:30, Marc-Andre Lemburg wrote:
BTW: The sslwrap_simple() API was also removed in 2.7.9.
Scratch that. I was in the wrong work dir :-)
--
___
Python tracker rep...@bugs.python.org
http
Marc-Andre Lemburg added the comment:
On 07.11.2014 12:49, Marc-Andre Lemburg wrote:
BTW: The sslwrap_simple() API was also removed in 2.7.9.
Scratch that. I was in the wrong work dir :-)
Hmm, even though the API is still there, it uses _ssl.sslwrap() as
well, so it won't work anymore
Marc-Andre Lemburg added the comment:
On 07.11.2014 13:12, Antoine Pitrou wrote:
It's not a mere matter of putting back the code... The 3.x ssl implementation
which was backported uses a slightly different approach from the 2.x
implementation, so it's not obvious we can recreate
Marc-Andre Lemburg added the comment:
Looking at recent comments on the gevent ticket, the 2.7.9
changes are already causing problems for people since apparently
the changes were backported to 2.7.8 by some vendors.
https://github.com/gevent/gevent/issues/477
Marc-Andre Lemburg added the comment:
On 04.11.2014 10:41, Antoine Pitrou wrote:
Antoine Pitrou added the comment:
This is similar to the idea of loading the stdlib from a zip file (but less
intrusive and more debugging-friendly). The time savings will depend on
whether the filesystem
Marc-Andre Lemburg added the comment:
Jean Christophe: Please have a look at the patch for ticket
http://bugs.python.org/issue22681 as example of the doc patch.
Thanks.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21081
Marc Schlaich added the comment:
I've now run various and partially complex applications including SQLAlchemy
against SQLite 3.8.1 for months without having any issues. Right now I have run
extensive database test suites against the current SQLite release 3.8.6 without
any issues, too.
So I
Marc Schlaich added the comment:
Yes, but this is no practical solution. Telling *all* my clients to update the
sqlite3.dll after *every* Python update is just not feasible and will just not
work out in practice.
What would be the required steps to update the *.dll in the build? Just update
Marc Schlaich added the comment:
Well, OSX release ships with 3.8.3.1, too:
https://hg.python.org/cpython/file/2.7/Mac/BuildScript/build-installer.py#l290
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19450
Marc-Andre Lemburg added the comment:
I don't think we should add more EBCDIC codecs to Python's stdlib. It would be
better to put a Python package on PyPI which people using these encodings can
use.
--
___
Python tracker rep...@bugs.python.org
Marc-Andre Lemburg added the comment:
On 02.10.2014 10:24, STINNER Victor wrote:
STINNER Victor added the comment:
A lot of buildbot failed. Example:
http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.0%203.x/builds/2692/steps/test/logs/stdio
Marc-Andre Lemburg added the comment:
On 02.10.2014 10:38, Marc-Andre Lemburg wrote:
What I don't understand is why the above case failed. That mapping
wasn't changed by the patch, AFAICT.
Ah, the change is in the second patch round you applied, which
is not on the ticket as separate patch
Marc-Andre Lemburg added the comment:
On 02.10.2014 11:13, Serhiy Storchaka wrote:
Serhiy Storchaka added the comment:
Test failed due to mismatch between glibc and X11 locale.alias (issue20087).
In X11 locale.alias ca_ES is mapped to ca_ES.ISO8859-1, and in glibc 2.19
it is mapped
Marc-Andre Lemburg added the comment:
Thanks, Serhiy.
The patch looks good, except for one nit: the makelocalealias.py normaly also
generates a list of changes and these are put at the top of the locale_alias
dictionary.
Could you add that as well
Marc-Andre Lemburg added the comment:
Thanks, Serhiy
The patch looks good. Please apply.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20076
Marc-Andre Lemburg added the comment:
On 01.10.2014 09:52, Serhiy Storchaka wrote:
The makelocalealias.py generates only a list of removes and updates, not
additions.
Ah, ok.
I recommend first apply issue20076, it will eliminate most additions.
Agreed. Please apply both patches.
Thanks
Marc-Andre Lemburg added the comment:
I think it's better to keep pybench speed performance oriented and rather use a
new tool for memory performance tests.
I've recently done a lightning talk at PyCon UK on the subject and found the
current tools we have for memory testing a bit
Marc-Andre Lemburg added the comment:
Don't like the function name :-)
How about codecs.filter_non_utf8_data(), since that's closer
to what the function is really doing and doesn't require
knowledge about what surrogateescape is.
--
nosy: +lemburg
Marc-Andre Lemburg added the comment:
On 23.09.2014 13:12, Nick Coghlan wrote:
Nick Coghlan added the comment:
Draft docstring for that version
def convert_surrogates(data, errors='replace'):
Convert escaped surrogates by applying a different error handler
Uses
Marc-Andre Lemburg added the comment:
On 15.09.2014 15:19, STINNER Victor wrote:
STINNER Victor added the comment:
IMO test_codecs_fix1.patch is still needed.
Review of Nick's change:
+interp = PyThreadState_GET()-interp;
+if (interp-codec_search_path == NULL
Marc-Andre Lemburg added the comment:
On 11.09.2014 01:04, Nick Coghlan wrote:
Nick Coghlan added the comment:
Just as a recap of at least some of the *current* ways to do a bytes - hex
conversion:
import codecs
codecs.encode(babc, hex)
b'616263'
import binascii
binascii.hexlify
Marc-Andre Lemburg added the comment:
On 06.09.2014 15:03, Nick Coghlan wrote:
A codecs._forget_codec helper in the C module would be all that was needed
to handle it. Other implementations could then also use that to clear their
own internal cache (if they have one).
If you want to take
Marc-Andre Lemburg added the comment:
On 06.09.2014 21:14, Nick Coghlan wrote:
This investigation also showed why the original tests that used a
non-unique name didn't work: the codec was getting cached the first time
through and hence not seeing the different codecs registered by other
Marc-Andre Lemburg added the comment:
On 31.08.2014 11:34, Wilberto Morales wrote:
New submission from Wilberto Morales:
I know that issues like this one are usually on the users(my) fault, but I
think pip might be broken this time for real.
Every time I run pip install, a 404 error
Marc-Andre Lemburg added the comment:
On 20.08.2014 09:28, Georg Brandl wrote:
We know, but this will happen to any sites that have content hosted by a CDN
such as Fastly.
I think we should have additional fallback domains setup
that go to frontend.python.org and then also get mapped
Marc-Andre Lemburg added the comment:
On 20.08.2014 19:14, Donald Stufft wrote:
For now I think Fastly has sufficiently handled the issue to not require some
sort of backup system to need to be put in place. They are going to let me
know how they are going to handle it long term and what
Marc-Andre Lemburg added the comment:
It looks like the IP address is being used by some viruses/trojans:
https://www.virustotal.com/en/ip-address/185.31.17.175/information/
It may help using e.g. b.global-ssl.fastly.net as CNAME for docs.python.org
(e.g. by adding it to the /etc/hosts
Marc-Andre Lemburg added the comment:
Pointing people to io.open() as alternative to codecs.open() is a good idea,
but that doesn't make codecs.open() less useful.
The reason why codecs.open() uses binary mode is to avoid issues with automatic
newline conversion getting in the way
Marc-Andre Lemburg added the comment:
Why are you removing guarantees like these from the str docs:
The original string is returned if *width* is less than or equal to
``len(s)``.
?
This doesn't seem to have anything to do with documenting bytes and bytearrays.
--
nosy: +lemburg
Marc-Andre Lemburg added the comment:
The patch would have to be updated to 3.5 (part of it no longer applies), but
other than that I think it's fine.
It may make sense to readd the comment for .getstate() to keep the state as
simple as possible (The implementation should make sure that ``0
Marc-Andre Lemburg added the comment:
The two functions serve a different purpose.
getdefautltlocale() specifically avoids calling setlocale() and is thread-safe
on Unix. It's purpose is to return the default locale string, not only the
encoding.
getpreferredencoding() only returns
Marc-Andre Lemburg added the comment:
On 24.06.2014 11:44, Serhiy Storchaka wrote:
Note that 'raw-unicode-escape' is used in pickle protocol 0. Changing it can
break compatibility.
Indeed. unicode-escape was also designed to be able to read back
raw-unicode-escape encoded data, so changing
Marc-Andre Lemburg added the comment:
On 20.06.2014 16:38, Nick Coghlan wrote:
Nick Coghlan added the comment:
MAL - agreed on the version numbering implications of treating OpenSSL CVE's
as CPython CVE's, but I think Guido pretty much answered that when he
extended the 2.7 EOL to 2020
Marc-Andre Lemburg added the comment:
The unicode-escape codec was used in Python 2 to convert Unicode literals in
source code to Unicode objects. Before PEP 263, Unicode literals in source code
were interpreted as Latin-1. See http://legacy.python.org/dev/peps/pep-0263/
for details
marc added the comment:
I think the problem was a combination of two issues.
First, the warning in 16.17.2.2 is a bit hidden. Kind of squeezed in
between CDLL, etc and PyDLL. In contrast, 16.17.2.4 does a much better
job, because it restates the fact that the GIL is released at each
Marc-Andre Lemburg added the comment:
On 20.06.2014 09:26, Nick Coghlan wrote:
2.7.8 will likely be earlier than expected in order to address the latest
OpenSSL update for the Windows installers. So while the likely time frame for
this hasn't changed (i.e. November'ish 2014), that release
Marc-Andre Lemburg added the comment:
I'm not sure whether using os.fsencoding() is a good idea. The encoding used by
uname is not defined anywhere and it's possible that Python using a wrong
encoding may cause the call to fail (e.g. in case the host name includes
non-ASCII chars
Marc-Andre Lemburg added the comment:
On 17.06.2014 11:21, STINNER Victor wrote:
STINNER Victor added the comment:
I'm not sure whether using os.fsencoding() is a good idea. The encoding used
by uname is not defined anywhere and it's possible that Python using a wrong
encoding may
Marc-Andre Lemburg added the comment:
On 17.06.2014 15:03, M.-A. Lemburg wrote:
On 17.06.2014 15:00, Jan Varho wrote:
New submission from Jan Varho:
When trying to run a file with non-ASCII symbols without declaring an
encoding, python 2.7 gives the following error:
File foo.py, line
Marc-Andre Lemburg added the comment:
On 17.06.2014 15:00, Jan Varho wrote:
New submission from Jan Varho:
When trying to run a file with non-ASCII symbols without declaring an
encoding, python 2.7 gives the following error:
File foo.py, line 2
SyntaxError: Non-ASCII character
Marc-Andre Lemburg added the comment:
On 15.06.2014 01:53, Nick Coghlan wrote:
Can we just drop __file__ and set the origin for frozen modules to
something that includes the original file name?
This wouldn't really help, because too much code out there uses
the __file__ attribute
New submission from Marc-Andre Lemburg:
This leads to problems when using runpy, since it relies on pkgutil to find
importers.
In Python 2, ImpLoader is used by ImpImporter which is used as fallback
importer by get_importer(). get_importer() is used by runpy to implement e.g.
the -m option
Marc-Andre Lemburg added the comment:
On 13.06.2014 18:49, Jim Jewett wrote:
As best I can tell, this renames the original get_code to _get_code, and then
delegates to it after handling the imp.PY_FROZEN case ... why not just add
imp.PY_FROZEN to the if/elif chain in the original method
Marc-Andre Lemburg added the comment:
Here's an updated patch for Python 3.4.1 that doesn't use the awkward style :-)
--
Added file:
http://bugs.python.org/file35619/pkgutil-frozen-modules-support.patch
___
Python tracker rep...@bugs.python.org
http
Changes by Marc-Andre Lemburg m...@egenix.com:
Removed file:
http://bugs.python.org/file35617/pkgutil-frozen-modules-support.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21749
Marc-Andre Lemburg added the comment:
FWIW: This still happens with the Python 3.4.1 release version.
Here's a similar error report for Fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=622060
They patched the compiler, so I guess I'll have to find a more recent gcc for
the build box
New submission from Marc-Andre Lemburg:
The missing __file__ attribute on frozen modules causes lots of issues with the
stdlib (see e.g. Issue21709 and the stdlib test suite) and other tools that
expect this attribute to always be present.
The attached patch for 3.4.1 adds this attribute
Changes by Marc-Andre Lemburg m...@egenix.com:
--
keywords: +patch
Added file: http://bugs.python.org/file35595/__file__-for-frozen-modules.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21736
Marc-Andre Lemburg added the comment:
While the current patch does not resolve the issue, I'm leaving the issue
closed and have instead opened a new Issue21736 which tracks the idea to add a
__file__ attribute to frozen modules per default
601 - 700 of 2192 matches
Mail list logo
