New submission from Marc-Andre Lemburg:
The logic in runpy.run_path() assumes that removing the __main__ entry from
sys.modules is enough to be able to use the module search logic for e.g.
importing packages and ZIP files (with embedded __main__.py files).
In Python 3.4 (and probably also 3.3
Changes by Marc-Andre Lemburg m...@egenix.com:
--
keywords: +patch
Added file:
http://bugs.python.org/file35596/FrozenImporter-without-__main__-support.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21737
Marc-Andre Lemburg added the comment:
On 12.06.2014 18:35, Barry A. Warsaw wrote:
I'm -0 on this patch. I can understand that in some sense, frozen modules do
semantically have an associated file, but OTOH, once they're frozen the
connection to their file is broken. Also, I think
Marc-Andre Lemburg added the comment:
Hi Vinaj,
thanks for the patch, but it doesn't really help outside of py2exe. The
sys.frozen flag is not an official Python API and it's unlikely to become one,
since you can freeze the whole application or just parts of it, which
sys.frozen would
Marc-Andre Lemburg added the comment:
On 11.06.2014 11:25, Vinay Sajip wrote:
Vinay Sajip added the comment:
Could you please use a fix that works for Python tools in general?
I suggested an alternative implementation altogether in Issue #16778, but it
was suggested that we wait
Marc-Andre Lemburg added the comment:
On 11.06.2014 12:32, Vinay Sajip wrote:
Vinay Sajip added the comment:
_srcfile is only used to identify the caller's stack frame
Not quite. It's also used to indicate whether findCaller() should be called
at all: setting it to None avoids calling
Marc-Andre Lemburg added the comment:
On 11.06.2014 13:22, Vinay Sajip wrote:
Vinay Sajip added the comment:
Please also add some comment explaining why this is done in this way.
Natürlich :-)
Prima :-)
it may be worthwhile introducing some generic helper to the stdlib
Wouldn't
Marc-Andre Lemburg added the comment:
I don't have a Windows 8.1 handy, but if ver reports the correct version, why
not have platform.win32_ver() use _syscmd_ver() in case the other APIs report
6.2.9200 and then have win32_ver() the higher version ?!
FWIW: I don't think we should add anything
New submission from Marc-Andre Lemburg:
Here's the code:
def replace_paths_in_code(self, co):
...
return types.CodeType(co.co_argcount, co.co_nlocals, co.co_stacksize,
co.co_flags, co.co_code, tuple(consts), co.co_names
Marc-Andre Lemburg added the comment:
The fix is easy. Simply change the call to:
return types.CodeType(co.co_argcount, co.co_kwonlyargcount,
co.co_nlocals, co.co_stacksize,
co.co_flags, co.co_code, tuple(consts
Marc-Andre Lemburg added the comment:
On 10.06.2014 18:28, Steve Dower wrote:
The one concession that the Windows dev is willing to make is for logging, in
which case the version number should be read as a string from a standard DLL
like kernel32.dll. This would be appropriate
New submission from Marc-Andre Lemburg:
It is not when freezing the logging package, so any use of the logging package
fails:
import logging
Traceback (most recent call last):
File console, line 1, in module
File pyrun/importlib/_bootstrap.py, line 2237, in _find_and_load
File pyrun
Marc-Andre Lemburg added the comment:
The issue is similar to Issue20884.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21709
___
___
Python
Marc Schlaich added the comment:
Your statement is not correct, it does work on Windows (where fork is not
available) if you register the hook on module level instead of in `__main__`.
--
___
Python tracker rep...@bugs.python.org
http
Marc-Andre Lemburg added the comment:
Some comments:
* Python 2.7 ships with OpenSSL 0.9.8 on Windows, so the Python version will
always get used on that platform, so it needs to be fast.
* The iterations loop should use xrange instead of range
* The .encode('ascii') in _long_to_bin
Marc-Andre Lemburg added the comment:
On 19.05.2014 12:24, Christian Heimes wrote:
How about you take my back port from
https://bitbucket.org/tiran/backports.pbkdf2/ and remove all Python 3.x
related code? :) I spent a lot of time to make the code as fast as possible.
Could you perhaps
Marc-Andre Lemburg added the comment:
neologix:
According to man rand(3ssl), OpenSSL uses an internal state of 1023 bytes for
the RNG.
You only see it reading 32 bytes from /dev/urandom in the strace because it has
already loaded 1024 bytes from the RNG state file ~/.rng before adding
Marc-Andre Lemburg added the comment:
On 13.05.2014 11:06, Antoine Pitrou wrote:
Is ~/.rnd any kind of serious? It hasn't been modified since two weeks on my
system (which is rebooted every day).
The file is apparently only updated if you use one the OpenSSL commands
which needs random
Marc-Andre Lemburg added the comment:
Caelyn: Thanks for the patch.
Some comments:
* Please use aliased=False instead of aliased=0 in the patch.
* It would be great if you could enhance the test a bit to actually check the
return value. This would need a mock of the os.uname API for the test
Marc-Andre Lemburg added the comment:
Removing 2.7 as target, since this is a new feature.
--
versions: -Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7850
New submission from Marc Schlaich:
multiprocessing.util.register_after_fork does not behave consistently on
Windows because the `_afterfork_registry` is not transferred to the subprocess.
The following example fails on Windows while it works perfectly on Linux:
import multiprocessing.util
Marc-Andre Lemburg added the comment:
FWIW: I don't think we need to manage the news entries in the NEWS
file. Instead, we could simply add a field to the bug tracker
called news entry and populate that as necessary.
During release, this information can then be used to create a
NEWS file per
Marc-Andre Lemburg added the comment:
Some comments:
* Please provide some background information how widely the encoding is used. I
get less than 1000 hits in Google when looking for TCVN 5712:1993. Now, the
encoding was a standard in Vietnam, but it has been updated in 1999 to TCVN
5712
Marc-Andre Lemburg added the comment:
Retargeting to 3.5, since all other releases don't allow addition of new
features.
--
versions: +Python 3.5 -Python 2.7, Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21081
Marc-Andre Lemburg added the comment:
Thanks for your answers. I think the best way forward would be to some
up with an official encoding map of the TCVN 5712:1999 encoding,
translate that into a format that gencodec.py can use and then
add the generated codec to Python 3.5.
We can then add
Marc-Andre Lemburg added the comment:
Christian, please open a separate ticket for your problem.
This ticket is about getting freeze, the tool itself, working,
not any other issue you may find with the resulting frozen binary.
Thanks,
--
Marc-Andre Lemburg
eGenix.com
Marc-Andre Lemburg added the comment:
On 25.03.2014 11:37, Christian Bachmaier wrote:
Martin: this is clearly a bug, as it is now (Python 3.3 onwards) impossible
to use an external module (in a .so) from a frozen binary.
Are you sure about this ?
If you freeze an application which
Marc-Andre Lemburg added the comment:
On 25.03.2014 13:02, Christian Bachmaier wrote:
Christian Bachmaier added the comment:
# ldd hello
linux-vdso.so.1 = (0x7fffd677e000)
libpython3.4m.so.1.0 =
/usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0 (0x7f968c6c2000
Marc-Andre Lemburg added the comment:
On 25.03.2014 16:21, Christian Bachmaier wrote:
Sorry I forgot: PyRun seems only support Python 2.x.
Right, because PyRun uses freeze and freeze currently does not work
for Python 3. Which is what this ticket is all about and why
I opened it.
To test
Marc-Andre Lemburg added the comment:
On 25.03.2014 17:47, Christian Bachmaier wrote:
Christian Bachmaier added the comment:
To test what I asked for, please run freeze on this script:
import _psycopg2
Sorry. The above should have read import _psycopg.
print ('Works.')
$ xxx
Marc-Andre Lemburg added the comment:
On 25.03.2014 19:27, Brett Cannon wrote:
Brett Cannon added the comment:
OK, so trying to import around the package was definitely why the first
instance didn't work so that's all expected.
As for the failure when importing psycopg2, my guess
Marc-Andre Lemburg added the comment:
On 25.03.2014 19:41, M.-A. Lemburg wrote:
I'll have to have a look at how the pyscopg2 package normally
imports its C extension. It's likely that they will have to use
something like this to make things work for frozen apps as well:
try:
from
Marc-Andre Lemburg added the comment:
Wait, Brett :-)
The issue that Christian mentioned was just a side discussion.
We still need to fix the main problem.
--
resolution: invalid -
status: closed - open
___
Python tracker rep...@bugs.python.org
Marc Schlaich added the comment:
I can reproduce this one. There are a few conditions which needs to be met:
- Linux line endings
- File needs to have at least x lines (empty lines are fine). I guess this is
the point why no one could reproduce it. The attached file has 19 lines but
probably
Marc-Andre Lemburg added the comment:
On 21.03.2014 00:10, Donald Stufft wrote:
We shouldn't do this in Python for the same reason we're not including
a predefined set of CA root certificates with the distribution.
The difference here is that there are properly maintained alternatives
Marc-Andre Lemburg added the comment:
On 21.03.2014 12:42, Donald Stufft wrote:
If we enforce a specific set of ciphers per default and a user finds
that a server he wants to communicate with for example only supports
RC4 ciphers, because that's the server admins were told to use after
Marc-Andre Lemburg added the comment:
Just to clarify a few things:
On 20.03.2014 00:50, Graham Wideman wrote:
I think part of the ambiguity problem here is that there are two subtly but
importantly different ideas here:
1. Python string (capable of representing any unicode text
Marc-Andre Lemburg added the comment:
On 20.03.2014 11:49, Graham Wideman wrote:
An encoding is a mapping of characters to ordinals, nothing more or less.
In unicode, the mapping from characters to ordinals (code points) is not the
encoding. It's the mapping from code points to bytes
Marc-Andre Lemburg added the comment:
On 20.03.2014 15:11, Donald Stufft wrote:
The compatibility of this is pretty good. The only time this should cause a
connection to *fail* is if a server is using an insecure cipher and in that
case you can re-enable it by simply passing the original
Marc-Andre Lemburg added the comment:
On 20.03.2014 23:36, Donald Stufft wrote:
Donald Stufft added the comment:
I'm still looking into what HIGH entails across all the various OpenSSLs
that are in production that I can access. That FUD was responding to the
attitude that it's
Marc-Andre Lemburg added the comment:
On 20.03.2014 21:52, Alex Gaynor wrote:
It's also worth noting that users appear to be FAR more likely to have an up
to date Python than they are an up to date OpenSSL, meaning that if a change
needs to be made, we're much better situated to get
Changes by Marc Schlaich marc.schla...@googlemail.com:
--
nosy: +ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20954
___
___
Python-bugs
Marc Schlaich added the comment:
This was fixed in #19284 for Python 3.4 (without having possible consequences
in mind). I have updated my patch accordingly.
Maybe it's worth to port my test case to Python 3.4.
Removed Python 3.3 as it isn't in bugfix maintenance anymore.
--
versions
New submission from Marc Schlaich:
Steps to reproduce:
- clone pytest-cov at
https://bitbucket.org/schlamar/pytest-cov/commits/ac14225a67d715b6649f8158e05d2389b78620d2
- remove `@pytest.mark.skipif` from `test_multiprocessing_subprocess` in
test_pytest_cov.py
- run: `tox --develop -e py27
Marc Schlaich added the comment:
Patch added.
--
keywords: +patch
Added file: http://bugs.python.org/file34453/Issue20954.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20954
Marc Schlaich added the comment:
This comes from http://bugs.python.org/issue12098. Python 3.3 is affected, too.
Reproduction can be minimized by running the following script:
import multiprocessing
def main():
p = multiprocessing.Process(target=lambda: None)
p.start()
p.join
Marc Schlaich added the comment:
Added TestCase.
--
Added file: http://bugs.python.org/file34459/20954_test.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20954
Marc Schlaich added the comment:
BTW, patches are for 2.7 branch.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20954
___
___
Python-bugs-list
Marc Schlaich added the comment:
Merged test case and fix in a single commit/patch.
--
Added file: http://bugs.python.org/file34460/Issue20954.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20954
Changes by Marc Schlaich marc.schla...@googlemail.com:
--
nosy: -schlamar
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11949
___
___
Python-bugs
Marc-Andre Lemburg added the comment:
On 06.03.2014 10:30, Antoine Pitrou wrote:
Antoine Pitrou added the comment:
I agree that having midnight evaluate to false is completely unexpected and
unintuitive. I can imagine situations where it bites people in production use
in the uncommon
Marc-Andre Lemburg added the comment:
On 25.02.2014 15:29, Felipe Sateler wrote:
I'm sorry but I definitely don't have time or knowledge about python
to propose a patch (simply removing pyconfig.h clearly doesn't work).
As to the question, please clarify. I have a python module, which
Marc-Andre Lemburg added the comment:
On 03.02.2014 02:24, STINNER Victor wrote:
STINNER Victor added the comment:
Ever used recode ?
No, what is it? I once used iconv for short tests, but I never required iconv
to convert a real document.
It's a command line tool to convert
Marc-Andre Lemburg added the comment:
On 27.01.2014 11:00, STINNER Victor wrote:
STINNER Victor added the comment:
I agree with Antoine, I dislike the idea of BinaryTransformWrapper, it
remembers me the evil codecs.EncodedFile thing.
What are the usecases?
Ever used recode
Marc-Andre Lemburg added the comment:
I'd be +1 on such a patch if we were to officially support Android, but we'd
need a volunteer to champion for this (which would be a good thing, IMO).
Otherwise, such changes need to be maintained externally
New submission from Marc Tamlyn:
platform.mac_ver() triggers the following deprecation warning:
python3.4 -Wall
Python 3.4.0b2 (v3.4.0b2:ba32913eb13e, Jan 5 2014, 11:02:52)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type help, copyright, credits or license for more information
Marc-Andre Lemburg added the comment:
None of the linked patch URLs work anymore.
Could someone please upload a current patch to the ticket for review ?
As mentioned before, I don't believe that changing the function to first try
the lsb-release will result in the same results as what
Marc-Andre Lemburg added the comment:
Another example on openSUSE 12.3:
# lsb-release -a
LSB Version:n/a
Distributor ID: openSUSE project
Description:openSUSE 12.3 (x86_64)
Release:12.3
Codename: Dartmouth
This would result in ('openSUSE project', '11.4', 'x86_64'). I
Marc-Andre Lemburg added the comment:
On 06.01.2014 11:53, Vajrasky Kok wrote:
Here is the patch to deprecate platform.dist and platform.linux_distribution.
--
nosy: +vajrasky
Added file: http://bugs.python.org/file33324/deprecate_platform_dist.patch
Thanks. I think we'll need
Marc-Andre Lemburg added the comment:
On 26.12.2013 19:59, Serhiy Storchaka wrote:
Could you please make a decision about last patch, Marc-Andre?
Looks good. Thanks, Serhiy.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Marc-Andre Lemburg added the comment:
On 26.12.2013 21:19, Serhiy Storchaka wrote:
Here is updated patch. It doesn't include any additions to locale alias table
(including devanagari). Added several tests cases (many other test cases for
removed aliases already exist). optimize
Marc-Andre Lemburg added the comment:
On 26.12.2013 22:43, Serhiy Storchaka wrote:
Serhiy Storchaka added the comment:
Could you add a test for the optimization function ?
I have no ideas. The optimization function is a part of the
makelocalealias.py
which ran manually very rarely
Marc-Andre Lemburg added the comment:
On 26.12.2013 23:19, Serhiy Storchaka wrote:
Serhiy Storchaka added the comment:
I probably wasn't clear: I meant some tests that show that the
alias definitions (on the left) from the X11 file are actually mapped to the
correct alias locales
Marc-Andre Lemburg added the comment:
I thought some more about this approach. I'm +1 on it. The locale
lookup is not time critical, so the table optimization makes sense.
Nice idea, Serhiy !
On 22.12.2013 00:38, Serhiy Storchaka wrote:
Serhiy Storchaka added the comment:
* the patch
Marc-Andre Lemburg added the comment:
On 21.12.2013 16:31, Christian Heimes wrote:
All VMS code has been removed except for some code in Lib/platform.py.
MAL:
Do you want to keep the code in the platform module?
The platform.py module is intended to be usable by several Python versions
Changes by Marc-Andre Lemburg m...@egenix.com:
--
assignee: lemburg - christian.heimes
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16136
Marc-Andre Lemburg added the comment:
On 21.12.2013 20:33, Serhiy Storchaka wrote:
Serhiy Storchaka added the comment:
Example.
'br_fr':'br_FR.ISO8859-1',
-'br_fr.iso88591': 'br_FR.ISO8859-1',
-'br_fr.iso885914
Marc-Andre Lemburg added the comment:
On 20.12.2013 12:36, Serhiy Storchaka wrote:
Proposed patch updates locale alias table to most recent locale.alias file
(from X.org 7.7 distribution).
Looks good.
BTW, regarding the devanagari cases:
There is some recent activity in glibc related
Marc-Andre Lemburg added the comment:
On 20.12.2013 12:19, Serhiy Storchaka wrote:
Added file: http://bugs.python.org/file33231/locale_devanagari_2.patch
See my message on issue20034:
There is some recent activity in glibc related to these. Here's a
patch that adds the sd_IN@devanagari
Marc-Andre Lemburg added the comment:
On 20.12.2013 15:55, Serhiy Storchaka wrote:
After applying the patch Python supports all ks_IN and sd_IN locales.
Well, yes, but only because you are removing the @-modifiers. I don't
think that's correct, since e.g. the string formatting used
Marc-Andre Lemburg added the comment:
On 20.12.2013 16:12, Serhiy Storchaka wrote:
Serhiy Storchaka added the comment:
Looks good.
Should these patch be applied only to 3.4 or to all maintained
releases? I suppose the later, because alias table which is not
conform recent systems
Marc-Andre Lemburg added the comment:
On 20.12.2013 16:24, Serhiy Storchaka wrote:
Serhiy Storchaka added the comment:
Well, yes, but only because you are removing the @-modifiers. I don't
think that's correct, since e.g. the string formatting used for
numbers is different
Marc-Andre Lemburg added the comment:
Closing, since there's nothing much we can do about the problem.
--
resolution: - invalid
status: open - closed
versions: +3rd party -Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Changes by Marc Schlaich marc.schla...@googlemail.com:
--
nosy: -schlamar
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue777588
___
___
Python
Marc-Andre Lemburg added the comment:
On 18.12.2013 22:57, Serhiy Storchaka wrote:
Marc-Andre, do you have comments or objections?
Your last patch looks fine, but I don't have time to test it.
Regarding the broken *devanagari* entries in the alias table:
I think we should remove or correct
Marc-Andre Lemburg added the comment:
I have tried this with a stock Python 2.7.6 version and don't get an error:
platform._sys_version('2.7.5 (default, Sep 12 2013, 21:33:34) \n[GCC 4.2.1
Compatible Apple LLVM 5.0 (clang-500.0.68)]')
('CPython', '2.7.5', '', '', 'default', 'Sep 12 2013 21
Marc-Andre Lemburg added the comment:
On 19.12.2013 00:39, Wes wrote:
Marc
Thanks for getting back to me so quickly on this. I'm running an apple
version of python from the looks of it. I was running an Anaconda version
at the time I posted this script, but I just reset my $PATH
Marc-Andre Lemburg added the comment:
On 19.12.2013 00:52, Wes wrote:
Marc,
Here was the initial output:
platform.__file__
'/Users/wesmadrigal/anaconda/lib/python2.7/platform.pyc'
import sys
sys.version
'2.7.6 |Anaconda 1.8.0 (x86_64)| (default, Nov 11 2013, 10:49:09) \n[GCC
4.0.1
Marc-Andre Lemburg added the comment:
On 16.12.2013 10:02, STINNER Victor wrote:
Maybe we should modify Py_FatalError() to call exit(1) in release mode, and
only call abort() in debug mode? Dumping a core dump, opening a Windows fatal
error popup, calling Fedora ABRT handler, etc
Marc-Andre Lemburg added the comment:
On 16.12.2013 10:30, STINNER Victor wrote:
STINNER Victor added the comment:
2013/12/16 Marc-Andre Lemburg rep...@bugs.python.org:
I don't think changing Py_FatalError() is a good idea. However,
its use in this particular case (streams
Marc-Andre Lemburg added the comment:
The C locale is part of the ANSI C standard. The POSIX locale is an alias
for the C locale and a POSIX standard, so we cannot just replace the ASCII
encoding with UTF-8 as we wish, so Antoine's patch won't work.
See e.g. http://pubs.opengroup.org
Marc-Andre Lemburg added the comment:
On 09.12.2013 11:19, STINNER Victor wrote:
STINNER Victor added the comment:
Marc-Andre AFAIK, Python 3 does work with ASCII data in the C locale, so I'm
not sure whether this is a bug at all.
What do you mean? Python uses the surrogateescape
New submission from Marc-Andre Lemburg:
Not sure whether this can be considered a bug, but Python 2.6.7 for example
showed the build revision in the sys.version:
sys.version
'2.6.7 (r267:88850, Feb 9 2012, 18:56:05) \n[GCC 4.5.0 20100604
[gcc-4_5-branch revision 160292]]'
whereas Python
Marc-Andre Lemburg added the comment:
Anatoly, please read http://www.python.org/dev/peps/pep-0012/
The process you are describing is not correct. In particular, the discussion
happens before sending in a pull request.
As for discussion of the PEP process: that should happen on python-dev
Marc-Andre Lemburg added the comment:
I'm not sure whether changing the errno module to use enums would be
conceptually correct:
enums declare a fixed set of permitted values, but errno values can be any
integer, are platform dependent and are sometimes not unique (e.g. EWOULDBLOCK
= EAGAIN
Marc-Andre Lemburg added the comment:
On 28.11.2013 15:45, anatoly techtonik wrote:
anatoly techtonik added the comment:
The process you are describing is not correct. In particular, the discussion
happens before sending in a pull request.
Post the link to correct process
Marc-Andre Lemburg added the comment:
Nick: I've had a look at your second patch. A couple of notes:
* I think you should add the flag to the constructor of the CodecInfo
tuple subclass and then set this in the resp. codecs. The extra
constructor class method looks too much like a hack
Marc-Andre Lemburg added the comment:
On 22.11.2013 12:24, Marc-Andre Lemburg wrote:
Nick: I've had a look at your second patch. A couple of notes:
* I think you should add the flag to the constructor of the CodecInfo
tuple subclass and then set this in the resp. codecs. The extra
Marc-Andre Lemburg added the comment:
On 22.11.2013 12:43, STINNER Victor wrote:
STINNER Victor added the comment:
If _is_text_encoding may change in Python 3.5, you should add a comment to
warn users to not use it and explain its purpose, maybe with a reference to
this issue.
+1
Marc-Andre Lemburg added the comment:
Victor, please accept the fact that the codec sub-system in Python
doesn't only have the Unicode implementation as target. It's
true that most codecs were added for the Unicode implementation,
but I deliberately designed the system to be open for other
Marc-Andre Lemburg added the comment:
On 22.11.2013 23:03, STINNER Victor wrote:
I'm not sure that multibyte encodings other than UTF-8 are used in the world.
I'm not convinced that we should support them. If the changes are small, it's
maybe not a bad thing. Do you know which
Marc-Andre Lemburg added the comment:
On 21.11.2013 09:34, Serhiy Storchaka wrote:
No, it is not official Microsoft codepage (it was introduced by IBM in its
PC-DOS). AFAIK this encoding yet widely used in banking software. My old text
files were written in this encoding, ;)
+1
Marc-Andre Lemburg added the comment:
On 19.11.2013 12:38, Nick Coghlan wrote:
Given the time frame, how about we just go with Serhiy's suggestion of a
known non-Unicode codec internal blacklist for both 3.3 and 3.4?
+1
--
___
Python tracker
Marc-Andre Lemburg added the comment:
On 16.11.2013 10:16, Nick Coghlan wrote:
Nick Coghlan added the comment:
The full input/output type specifications can't be implemented sensibly
without also defining at least a ByteSequence ABC. While I think it's a good
idea in the long run
Marc-Andre Lemburg added the comment:
On 16.11.2013 13:44, Nick Coghlan wrote:
Nick Coghlan added the comment:
Now that I understand Victor's proposal better, I actually agree with it, I
just think the attribute names need to be encodes_to and decodes_to.
With Victor's proposal
Marc-Andre Lemburg added the comment:
On 16.11.2013 14:25, Nick Coghlan wrote:
Nick Coghlan added the comment:
Another big one: the encodings module API is not documented in the prose
docs, and nor is the interface between the default search function and the
individual encoding
Marc-Andre Lemburg added the comment:
On 16.11.2013 14:37, Nick Coghlan wrote:
Such codecs can be represented (for 3.4) by simply not setting the attribute
and leaving the output types unspecified. We don't need that complexity for
the standard library, and the not specified escape hatch
Marc-Andre Lemburg added the comment:
On 16.11.2013 15:03, Mark Lawrence wrote:
Mark Lawrence added the comment:
Could they be documented with a massive warning in red Cpython
implementation detail - subject to change without notice? Or documented in
a place that is only accessible
Marc-Andre Lemburg added the comment:
On 16.11.2013 15:52, Nick Coghlan wrote:
The only reasonable way to accurately represent anything that exposes a
buffer memoryview can read as a type check is to write an appropriately
duck-typed ABC. You can't enumerate all the types that the binary
Marc-Andre Lemburg added the comment:
Then I don't understand changes such as:
-'chinese-s':'zh_CN.eucCN',
+'chinese-s':'zh_CN.gb2312',
or
-'sp': 'sr_CS.ISO8859-5',
-'sp_yu
701 - 800 of 2192 matches
Mail list logo
