Marc-Andre Lemburg added the comment:
Note that the config command also uses a .compiler instance for actually
doing work, rather than as command option.
--
___
Python tracker
<http://bugs.python.org/issue6
Marc-Andre Lemburg added the comment:
Added Python 2.7 since it fails there as well.
--
versions: +Python 2.7
___
Python tracker
<http://bugs.python.org/issue6
Marc-Andre Lemburg added the comment:
Marc-Andre Lemburg wrote:
> Tarek, the .compiler attribute is needed by bdist_ext, so cannot just be
> removed or renamed to .compiler_obj. There's a lot of bdist_ext
> distutils code out there relying on having the .compiler object availabl
Marc-Andre Lemburg added the comment:
Roumen Petrov wrote:
> Roumen Petrov added the comment:
>
> Trunk may be is not affected. I successfully cross-compile with GNU
> compiler for windows (see issue 3871).
It is affected in the sense that .compile was changed
to .compile_obj and
Marc-Andre Lemburg added the comment:
Tarek Ziadé wrote:
> Tarek Ziadé added the comment:
>
> I'll set back the compiler attribute when compiler_obj is set too,
> so third-party code will be able to work with it as before.
>
> The current code will deprecate this
Marc-Andre Lemburg added the comment:
Tarek Ziadé wrote:
> Tarek Ziadé added the comment:
>
> The build_ext command cannot be run twice, because the first time, the
> "compiler" option may be set to "unix" for example, or left to None, and
> then is transfo
Marc-Andre Lemburg added the comment:
FWIW: I've changed our mxSetup code to use a method for accessing
the compiler instance.
Perhaps that's the better way to go for standard distutils commands
as well ?! E.g. .get_compiler_object()
--
Marc-Andre Lemburg added the comment:
Tarek Ziadé wrote:
>> The "compiler" option on the build_ext and config commands
>> are not really needed. Their .finalize_options() methods could
>> easily pull in the build option value and place it into
>> an .compiler_t
Marc-Andre Lemburg added the comment:
Raymond Hettinger wrote:
> Raymond Hettinger added the comment:
>
> In Py3.x, this fails:
> "%s.%s.%s-%s-%s" % sys.version_info
>
> The reason is that PyUnicode_Format() expects a real tuple, not a tuple
> lookal
Marc-Andre Lemburg added the comment:
On which Windows platform would that be ?
Both internal helper functions bypass using an external command for
Windows and DOS platforms.
--
___
Python tracker
<http://bugs.python.org/issue6
Marc-Andre Lemburg added the comment:
I've checked in patch r74005 to address the problem.
Could you check whether the current SVN version of platform.py works on
your Portuguese Windows version ?
Thanks.
--
___
Python tracker
Marc-Andre Lemburg added the comment:
John Burnett wrote:
> John Burnett added the comment:
>
> I'm not sure how you're seeing that those functions bypass external
> commands?
Both functions use this bypass mechanism:
if sys.platform in ('dos','
Marc-Andre Lemburg added the comment:
Ezio Melotti wrote:
>
> New submission from Ezio Melotti :
>
> The decimal codec only handles characters in the Nd (Number, decimal)
> Unicode category and whitespaces [a]. It is used by int(), float(),
> complex() and indirectly by D
Marc-Andre Lemburg added the comment:
Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
> Some comments:
> - since there is already a weekday() method, the new method should be
> called yearday() rather than yday()
> - ditto for fromyday(): fromyear
Marc-Andre Lemburg added the comment:
Hmm, looks like there's a bug in roundup's email interface... the code
snippet should have read:
>>> from mx.DateTime import *
>>> today().day_of_year
217
>>> Date(2009, 1, 1) + (217 - 1)
--
_
Marc-Andre Lemburg added the comment:
Mark Dickinson wrote:
> Python's current support for localization in int and float seems largely
> accidental, as far as I can tell.
Not at all. The support for non-ASCII numeric characters
in int() and float() is by design - however, I did
Marc-Andre Lemburg added the comment:
Mark Dickinson wrote:
>
> I'm less concerned about decimal points and the like, and more bothered by
> the fact that e.g., int(x, 16) accepts some, but not all, characters with
> the Hex_Digit property. This seems counter to the inte
Marc-Andre Lemburg added the comment:
Two things:
* The globals should get a comment explaining what their purpose is and
where they are being initialized.
* The get*() functions should only initialize the globals if they are
set to None. In the patch, they are initialized every time the
Marc-Andre Lemburg added the comment:
Amaury Forgeot d'Arc wrote:
>
> Amaury Forgeot d'Arc added the comment:
>
> The problem is actually wider::
> >>> getattr(None, "\udc80")
> Segmentation fault
> An idea would be to change _PyU
Marc-Andre Lemburg added the comment:
Amaury Forgeot d'Arc wrote:
>
> Amaury Forgeot d'Arc added the comment:
>
> Do you suggest to remove all usages of _PyUnicode_AsString() and
> _PyUnicode_AsStringAndSize()?
In the short-term, I suggest that all uses that do n
Marc-Andre Lemburg added the comment:
>From the quoted page:
"""
Notice that spelling alternatives that only differ in case or use a
hyphen instead of an underscore are also valid aliases.
"""
--
nosy: +lemburg
resolution:
Marc-Andre Lemburg added the comment:
Ryan McGuire wrote:
>
> New submission from Ryan McGuire :
>
> Opening a UTF-8 encoded file with unix newlines ("\n") on Win32:
>
> codecs.open("whatever.txt","r","utf-8").read()
>
>
Marc-Andre Lemburg added the comment:
The patch looks fine, the idea is good as well.
I'm just a little worried about the performance impact this might have
(not much though).
Could you run a quick comparison of before applying the patch compared
to after the patch is applied,
Marc-Andre Lemburg added the comment:
The patch looks good. Thanks.
Aside: This is what you get when using too many single character
variable names in a function...
The function should really do just one cast to (unsigned char *) at the
very top and then work with that variable all along
Marc-Andre Lemburg added the comment:
Perfect. Thanks for checking.
Benjamin, could you please check this in ? Thanks.
--
assignee: -> benjamin.peterson
___
Python tracker
<http://bugs.python.org/iss
Marc-Andre Lemburg added the comment:
Jeff Bradberry wrote:
>
> Jeff Bradberry added the comment:
>
> Ok, fixed. I am kind of vague, though, on the usefulness of str.encode
> and unicode.decode.
codecs can work on any combination of types. Here's an example of
a codec
Marc-Andre Lemburg added the comment:
Martin v. Löwis wrote:
>
> Martin v. Löwis added the comment:
>
>> int()/float() use the decimal codec for numbers - this only supports
>> base-10 numbers. For hex numbers, we'd need a new hex codec (only
>> the encoder pa
Marc-Andre Lemburg added the comment:
Martin v. Löwis wrote:
>
> Martin v. Löwis added the comment:
>
>> The codec currently doesn't look at the base at all - and shouldn't
>> need to:
>>
>> It simply converts input characters that have a decimal
Marc-Andre Lemburg added the comment:
Stef Walter wrote:
>
> New submission from Stef Walter :
>
> In Lib/distutils/util.py in the get_platform() function there's OS
> specific code to create a string which describes the current platform.
> This usually includes
Marc-Andre Lemburg added the comment:
Stef Walter wrote:
>
> Stef Walter added the comment:
>
> I agree with your comments, and the solution you're proposing solves the
> problem (and several others) for the long term.
>
> However in the short term, could thi
Marc-Andre Lemburg added the comment:
Amaury Forgeot d'Arc wrote:
>
> Amaury Forgeot d'Arc added the comment:
>
> (Presented this way, "my opinion" becomes difficult to stand...
> OTOH the docs say that the module does not support Unicode, s
Marc-Andre Lemburg added the comment:
Stef Walter wrote:
> Other OSs have special cases in get_platform() to specifically limit the
> amount of code, and make proper decisions with regard to package
> compatibility.
>
> Here's an example this commit for Mac OS X: http:/
Marc-Andre Lemburg added the comment:
Guido van Rossum wrote:
> What's a realistic use case for .title() anyway?
The primary use is when converting a string to be used as
title or sub-title of text - mostly inspired by the way
English treats titles.
The implementation follows the ru
Marc-Andre Lemburg added the comment:
Marc-Andre Lemburg wrote:
>
> Regarding the apostrophe: the Unicode standard doesn't appear to
> include any rule regarding that character and its use in titles
> or upper-case versions of text. The apostrophe itself is a
> non-cased c
Marc-Andre Lemburg added the comment:
The patch looks good, but it doesn't include the few extra characters
that are also considered case-ignorable:
* U+0027 APOSTROPHE
* U+00AD SOFT HYPHEN (SHY)
* U+2019 RIGHT SINGLE QUOTATION MARK
Could you add those as well ?
Thanks.
--
Marc-Andre Lemburg added the comment:
Ezio Melotti wrote:
>
> Ezio Melotti added the comment:
>
>> Patches to enhance the code to support those additional rules
> are welcome.
>
> #6412 has a patch.
That patch looks promising.
--
__
Marc-Andre Lemburg added the comment:
Christoph Burgmer wrote:
>
> Christoph Burgmer added the comment:
>
>> * U+0027 APOSTROPHE
> hardcoded (see below)
>> * U+00AD SOFT HYPHEN (SHY)
> has the "Format (Cf)" property and thus is included automatically
&g
Marc-Andre Lemburg added the comment:
Christoph Burgmer wrote:
>
> Christoph Burgmer added the comment:
>
> I admit I don't fully understand the semantics of capwords().
string.capwords() is an old function from the days before Unicode.
The function is basical
Marc-Andre Lemburg added the comment:
Most of the meta data is parsed by humans, so I don't see any
complication with adding multiple authors to the author field using
standard email format: "Anatoli , Tarek ".
We already have authors and maintainers (which causes confusion)
Marc-Andre Lemburg added the comment:
Tarek Ziadé wrote:
>
> Tarek Ziadé added the comment:
>
>> We already have authors and maintainers (which causes confusion),
>> adding yet another field for contributors is overkill,
>
> Not on the Metadata side though. That&
Marc-Andre Lemburg added the comment:
Tarek Ziadé wrote:
>
> Tarek Ziadé added the comment:
>
>> In order to clear up the inconsistency with maintainer
>> not being a possible meta-data field, I think "Maintainer"
>> should be added to the meta-data.
Marc-Andre Lemburg added the comment:
anatoly techtonik wrote:
>> What does changing the type of the "author" field make clearer exactly?
>> It is a field for human beings to read, and a human being is perfectly
>> able to parse "AP , Tarek " without
&
Marc-Andre Lemburg added the comment:
Tarek Ziadé wrote:
> So at the end, the changes on distutils setup() side would be:
>
> - authors (goes in Author field - with "," separations )
> - contact_email (goes in Author-email field)
> - deprecation of th
Marc-Andre Lemburg added the comment:
Tarek Ziadé wrote:
>
> Tarek Ziadé added the comment:
>
>> The meta-data is only used by PyPI and perhaps a handful
>> of other tools.
> [...]
>> The addition of the maintainer meta-data field would
>> not hur
Marc-Andre Lemburg added the comment:
Kristján Valur Jónsson wrote:
>
Thanks for the patch. Here's a quick review (a bit terse, but
hope you don't mind)...
> The attached patch contains suggested fixes to pybench.py:
> 1) add a processtime timer for windows
I'm not
Marc-Andre Lemburg added the comment:
Tarek Ziadé wrote:
>
> Tarek Ziadé added the comment:
>
>> I'm just suggesting to add the meta-data field in order to recreate
>> consistency - not advocating that setup() parameter or its use.
>
> Yes but fixing this in
Marc-Andre Lemburg added the comment:
Adam Olsen wrote:
>
> Adam Olsen added the comment:
>
> Surrogates aren't optional features of UTF-16, we really need to get
> this fixed. That includes .isalpha().
We use UCS2 on narrow Python builds, not UTF-16.
> We might
Marc-Andre Lemburg added the comment:
Amaury Forgeot d'Arc wrote:
>
> Amaury Forgeot d'Arc added the comment:
>
>> No, but changing the APIs from 16-bit integers to 32-bit integers
>> does require a recompile of all code using it.
>
> Is it acceptable
Marc-Andre Lemburg added the comment:
Amaury Forgeot d'Arc wrote:
>
> Amaury Forgeot d'Arc added the comment:
>
>> we should make sure that it's not possible to load an extension
>> compiled with 3.1 in 3.2 to prevent segfaults and buffer overruns.
&
Marc-Andre Lemburg added the comment:
This is off-topic for the tracker item, but I'll reply anyway:
Ezio Melotti wrote:
>
> Ezio Melotti added the comment:
>
>>> We might keep the old public API for compatibility, but it should be
>>> clearly marked as
Marc-Andre Lemburg added the comment:
Amaury Forgeot d'Arc wrote:
>
> Amaury Forgeot d'Arc added the comment:
>
> Marc-Andre, could you comment on this patch?
> The comments above were made by inspecting the generated code, comparing
> with the previous version
Marc-Andre Lemburg added the comment:
Amaury Forgeot d'Arc wrote:
>
> Amaury Forgeot d'Arc added the comment:
>
>> We'd need to expose the UCS4 APIs *in addition*
>> to those APIs and have the UCS2 APIs redirect to the UCS4 ones.
>
> Why have two
Marc-Andre Lemburg added the comment:
Adam Olsen wrote:
>
> Adam Olsen added the comment:
>
> On Mon, Oct 5, 2009 at 03:03, Marc-Andre Lemburg
> wrote:
>> We use UCS2 on narrow Python builds, not UTF-16.
>>
>>> We might keep the old public API
Marc-Andre Lemburg added the comment:
Thanks for reporting this.
It appears that Benjamin tried to undo the .compiler attribute renaming
Tarek had applied and r72586, but forgot to change back line 303 to the
original version:
{{{
# Setup the CCompiler object that we'll use to d
Marc-Andre Lemburg added the comment:
anatoly techtonik wrote:
>
> anatoly techtonik added the comment:
>
>>> Tarek Ziadé added the comment:
>
>>> Yes but fixing this inconsitency can be done on either side:
>>> A - remove the maintainer and maintain
Marc-Andre Lemburg added the comment:
anatoly techtonik wrote:
>
> anatoly techtonik added the comment:
>
> On Tue, Oct 6, 2009 at 4:04 PM, Marc-Andre Lemburg
> wrote:
>>>
>>> Please, be specific. PyPi maintainer or trac-plugin package maintainer
>&g
Marc-Andre Lemburg added the comment:
It's not as easy as that.
The functions for case conversion are used in a way that assumes they
never fail (and indeed, the existing functions cannot fail).
What we can do is change the input parameter to Py_UCS4, but not the
Py_UNICODE output para
Marc-Andre Lemburg added the comment:
Kristján Valur Jónsson wrote:
>
> Kristján Valur Jónsson added the comment:
>
> Here is an updated patch with the superfluous timing function removed.
> Please advise me on how you "don't like the implementation"
The re
Marc-Andre Lemburg added the comment:
Just a note on the style of the msvc9compiler_stripruntimes_revised.diff
patch:
* please try to use lines with at most 80 chars only
* it would be better to use regexps to do the search&replace and
perhaps add wildcards to catch future SP-version
Marc-Andre Lemburg added the comment:
Christoph Gohlke wrote:
>
> Christoph Gohlke added the comment:
>
> The attached patch uses a regular expression.
Much better, thanks.
--
title: Do not embed manifest files in *.pyd when compiling with MSVC -> Do not
embed ma
Marc-Andre Lemburg added the comment:
Hirokazu Yamamoto wrote:
> This issue is related to issue1571184, I think.
Assuming that you're using the SVN version of Python, I agree,
that's likely.
This is the line in question:
case 0x5146:
return (double) 1;
L
Changes by Marc-Andre Lemburg :
--
assignee: -> amaury.forgeotdarc
nosy: +amaury.forgeotdarc
___
Python tracker
<http://bugs.python.org/issue7112>
___
___
Py
Marc-Andre Lemburg added the comment:
Looking at the description of manifest files, it appears that just
removing the assemblyIdentity-element results in an invalid manifest file:
http://msdn.microsoft.com/en-us/library/aa374219(VS.85).aspx
It appears that the entire dependency-element
Marc-Andre Lemburg added the comment:
Amaury Forgeot d'Arc wrote:
>
> Amaury Forgeot d'Arc added the comment:
>
> Fixed with r75396 (trunk) and r75397 (py3k)
Thanks, Amaury.
> I'll check with the buildbots before I close this issue.
Marc-Andre Lemburg added the comment:
Jeff Senn wrote:
>
> Jeff Senn added the comment:
>
> Yikes! I just noticed that u''.title() is really broken!
>
> It doesn't really pay attention to word breaks --
> only characters that "have case
Marc-Andre Lemburg added the comment:
Jeff Senn wrote:
> However .capitalize() is a bit weird; and I'm not sure it isn't
> incorrectly implemented now:
>
> It UPPERCASES the first character, rather than TITLECASING, which is
> probably wrong in the very few cases wh
Marc-Andre Lemburg added the comment:
Jeff Senn wrote:
>
> Jeff Senn added the comment:
>
> So, is it not considered a bug that:
>
>>>> "This isn't right".title()
> "This Isn'T Right"
>
> !?!?!?
That's http://b
Marc-Andre Lemburg added the comment:
Zooko O'Whielacronx wrote:
> >
> > Looking at http://bugs.python.org/setuptools/issue1 and reading the
> > source of Lib/platform.py, it appears to me that uname() returns
> > different strings identifying the amd64 a
Marc-Andre Lemburg added the comment:
Tarek Ziadé wrote:
>
> Tarek Ziadé added the comment:
>
> I like ~/.python very much too (that was my initial proposal IIRC).
+1 on that name as well.
One thing to note though: it is well possible that a user uses
multiple Python version
Marc-Andre Lemburg added the comment:
Mark Summerfield wrote:
>
> Mark Summerfield added the comment:
>
> Glenn Linderman's fix pretty well works for me on XP Home. I can print
> every Unicode character up to and including U+D7FF (although most just
> come out as recta
Marc-Andre Lemburg added the comment:
Ned Deily wrote:
>
> Ned Deily added the comment:
>
> /etc is definitely not the right place to put files for OS X framework
> builds; if necessary, an etc directory could be added under the
> framework version directory as a sibl
Marc-Andre Lemburg added the comment:
Perhaps we can get some movement regarding this problem again, as it
also applies to other platforms that require special gcc options for the
compiler and linker.
A common case where such settings were needed is Mac OS X - in the case
of building universal
Marc-Andre Lemburg added the comment:
Christoph Gohlke wrote:
>
> Christoph Gohlke added the comment:
>
> Apparently the msvc9compiler_stripruntimes_regexp2 patch causes problems
> for MinGW users. The following C program is using the Python C API to
> import the testpyd e
Marc-Andre Lemburg added the comment:
Martin v. Löwis wrote:
>
> Martin v. Löwis added the comment:
>
> [...]
>> As second step, I think that the CFLAGS environment variable passed to
>> configure should be made to init the BASECFLAGS Makefile variable, since
>&
Marc-Andre Lemburg added the comment:
[Adding Jack Jansen to the nosy list, since he added the LDFLAGS parts
for Mac OS X]
Jack, could you please comment on why the LDFLAGS are added to LDSHARED
by configure, rather than using LDFLAGS as extra argument to LDSHARED ?
Thanks.
--
nosy
Marc-Andre Lemburg added the comment:
Bob Atkins wrote:
>
> As usual Martin is just flat wrong in his insistence that a defined
> CFLAGS must overide any generated CFLAGS by configure to be consistent
> with other OSS. But of course that is just his excuse for not accepting
> t
Marc-Andre Lemburg added the comment:
Bob Atkins wrote:
> My money is that the fanatically 'correct' method will be implemented
> that will require hundreds of lines of code, possibly re-engineering the
> entire build process, introducing more problems and take a few more
&
Marc-Andre Lemburg added the comment:
Antoine Pitrou wrote:
> Second, the patch allows me to do a 32-bit build (under 64-bit Linux) by
> doing:
> CFLAGS=-m32 LDFLAGS=-m32 ./configure
> rather than:
> CC="gcc -m32" ./configure
> However, if I omit LDFLAGS it d
Marc-Andre Lemburg added the comment:
Roumen Petrov wrote:
>
> Roumen Petrov added the comment:
>
> Marc-Andre,
> Thanks for the reference but what about to open manual for AC_PROG_CC ?
Could you please elaborate a bit ?
> Antoine,
> please don't mess kind of c
Marc-Andre Lemburg added the comment:
Jack Jansen wrote:
>
> Jack Jansen added the comment:
>
>> Jack, could you please comment on why the LDFLAGS are added to
> LDSHARED
>> by configure, rather than using LDFLAGS as extra argument to LDSHARED
> ?
>
> Be
Marc-Andre Lemburg added the comment:
Amaury Forgeot d'Arc wrote:
>
> Amaury Forgeot d'Arc added the comment:
>
> The docs say::
> Files are always opened in binary mode, even if no binary mode was
> specified. This is done to avoid data loss due to encodings
Marc-Andre Lemburg added the comment:
Eric pointed me to this ticket after having raised the question on
python-dev: http://www.mail-archive.com/python-...@python.org/msg43841.html
I think the discussion should be continued there instead of on this ticket.
Just for completeness, I'm co
Marc-Andre Lemburg added the comment:
The reason this call fails is that there's no locale alias defined for
"ml_IN" in the local_alias dictionary.
While the patch is probably a good idea, it also hides the missing mapping.
I think a better approach would be to check the
Marc-Andre Lemburg added the comment:
Could you provide some official reference defining the alias ?
Thanks.
--
___
Python tracker
<http://bugs.python.org/issue6
Marc-Andre Lemburg added the comment:
Nevermind, I found this reference:
http://msdn.microsoft.com/en-us/library/system.text.encoding(VS.80).aspx
Looks like we could add a few more aliases for other encodings as well.
--
___
Python tracker
<h
Marc-Andre Lemburg added the comment:
Martin v. Löwis wrote:
>
> Martin v. Löwis added the comment:
>
>> http://msdn.microsoft.com/en-us/library/system.text.encoding(VS.80).aspx
>>
>> Looks like we could add a few more aliases for other encodings as well.
>
Marc-Andre Lemburg added the comment:
Here's a script for IronPython 2.6 that checks a few encoders.
Since IronPython doesn't appear to come with the full set of Python
codecs and it's also not clear whether the implemented codecs actually
match the default Python ones, I
Marc-Andre Lemburg added the comment:
Martin v. Löwis wrote:
>
> Martin v. Löwis added the comment:
>
> These are not encodings, in that they don't convert characters to bytes.
> It was a mistake that they were integrated into the codecs interfaces in
> Python 2.x; th
Marc-Andre Lemburg added the comment:
Reopening the ticket.
--
status: closed -> open
___
Python tracker
<http://bugs.python.org/issue7475>
___
___
Python-
Marc-Andre Lemburg added the comment:
Martin v. Löwis wrote:
>
> Martin v. Löwis added the comment:
>
> It's not possible to add these codecs back. Bytes objects (correctly)
> don't have an encode method, and string objects (correctly) don't have a
> decode
Changes by Marc-Andre Lemburg :
--
resolution: invalid ->
___
Python tracker
<http://bugs.python.org/issue7475>
___
___
Python-bugs-list mailing list
Unsubscri
Marc-Andre Lemburg added the comment:
Benjamin Peterson wrote:
>
> Benjamin Peterson added the comment:
>
> I agree with Martin. gzip and bz2 convert bytes to bytes. Encodings deal
> strictly with unicode -> bytes.
Sorry, Bejamin, but that's simply not true.
Codecs
Marc-Andre Lemburg added the comment:
Benjamin Peterson wrote:
>
> Benjamin Peterson added the comment:
>
> 2009/12/11 Marc-Andre Lemburg :
>> codecs.encode()/.decode() provide access to all codecs, regardless
>> of their supported type combinations and of cou
Marc-Andre Lemburg added the comment:
Martin v. Löwis wrote:
>
> Martin v. Löwis added the comment:
>
>> So, after reading the above comments, I think we may end up with
>> following changes:
>> * restore the "bytes-to-bytes" codecs in the "enc
Marc-Andre Lemburg added the comment:
flox wrote:
>
> flox added the comment:
>
> This patch removes implicit encoding in binascii functions:
> - a2b_hex (=unhexlify)
> - a2b_qp
> - rledecode_hqx
>
> * Tests module "test_binascii" is reviewed
Marc-Andre Lemburg added the comment:
flox wrote:
>
> flox added the comment:
>
>> Are you sure that this patch is correct (which RFC says
>> that quoted printable should use our raw-unicode-escape
>> codec ?):
>
> I am not sure of anything. It is an &quo
Marc-Andre Lemburg added the comment:
The email interface ate part of the code snippet. Here's the complete
version:
>>> import base64
>>> base64.b64decode('äöü'.encode('raw-unicode-escape'))
b''
>>> base64.b64decode('äöü
Marc-Andre Lemburg added the comment:
Gregory, this patch should not have been backported to Python 2.7. See issue
Could you please revert the change on trunk ? Thanks.
A much better solution would be to issue a -3 warning in case a Unicode
object is passed to the hash functions. However
Marc-Andre Lemburg added the comment:
AFAIR, Barry likes these. Not sure exactly why ;-)
--
nosy: +barry, lemburg
___
Python tracker
<http://bugs.python.org/issue7
Marc-Andre Lemburg added the comment:
flox wrote:
>
> New submission from flox :
>
> ~ $ ./python -3 Lib/test/regrtest.py -j2 test_py3kwarn
> ./Lib/encodings/__init__.py:100: DeprecationWarning:
> the 'hex' codec has been remov
1301 - 1400 of 1946 matches
Mail list logo