New submission from Mahmoud :
Odd behaviour with str.encode or codecs.Codec.encode or simailar
functions, when dealing with uncode objects above
with 2.6
>>> u'\u10380'.encode('utf')
'\xe1\x80\xb80'
with 3.x
'\u10380'.encode('utf'
New submission from Mahmoud :
When using a class instance as a mapping for the right hand value in a
sting format expression without conversion specifier, it seems logical
that the class has a __getitem__ method. Therefore following format
expression should raise an exception.
>>> cla
New submission from Mahmoud Abdelkader :
Given a string, encoding it with .encode('base64') is not the same as using
base64's b64encode function. I think this is very unclear and unintuitive.
Here's some example code to demonstrate the problem. Before I attempt to subm
Mahmoud Abdelkader added the comment:
Thanks for the clarification Terry. This is indeed not a bug. For reference,
the pieces of code I pasted line-wrapped after the 76th character, which was my
main source of confusion.
After reading RFC3548, I am now informed that the behavior of
New submission from Mahmoud Harmouch :
While I was browsing in the source code of the logging package, I've
encountered missing implementations for formatHeader and formatFooter methods
of the BufferingFormatter class(in __init__ file). Therefore, I'm going to
implement them and
Change by Mahmoud Harmouch :
--
keywords: +patch
pull_requests: +24735
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/26095
___
Python tracker
<https://bugs.python.org/issu
Changes by Mahmoud Hashemi :
--
nosy: +mahmoud
___
Python tracker
<http://bugs.python.org/issue12949>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Mahmoud Hashemi :
On Python 3.1.4, attempting to create a code object will apparently result in a
TypeError (must be str, not tuple), even when you're creating a code object
from another, working code object:
# co_what.py
def foo():
return 'bar'
co
Mahmoud Hashemi added the comment:
And here's the working Python 2 version (works fine on Python 2.7, and likely a
few versions prior).
--
Added file: http://bugs.python.org/file24240/co_what2.py
___
Python tracker
<http://bugs.py
Mahmoud Hashemi added the comment:
Yes, I knew it was an issue with crossed wires somewhere. The Python 2 code
doesn't translate well to Python 3 because the function signature changed to
add kwargonlycount. And I guess the argument order is substantially different,
too, as describ
Mahmoud Hashemi added the comment:
Hey all, great to see this being worked on so diligently for so long. Having
worked in this area for a while (at home and at PayPal), we've got a few
learnings to share:
1) linecache is textbook not-threadsafe. For example,
https://hg.python.org/cp
New submission from Mahmoud Hashemi:
While porting some old code, I found some interesting misbehavior in the
new-style string formatting. When formatting objects which support int and
float conversion, old-style percent formatting works great, but new-style
formatting explodes hard.
Here&#
Changes by Mahmoud Hashemi :
--
nosy: +Mark.Williams
___
Python tracker
<http://bugs.python.org/issue23479>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mahmoud Hashemi added the comment:
Well, thank you for the prompt and helpful replies everyone. Can't say I didn't
wish the default behavior were more intuitive, but at least I think I have an
idea how to work this. Thanks again!
--
resolution: not a bug ->
status: c
Changes by Mahmoud Hashemi :
--
nosy: +mahmoud
___
Python tracker
<http://bugs.python.org/issue25341>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mahmoud Hashemi added the comment:
Got bit by this, and since it's not a bug, here's "not" a fix:
http://boltons.readthedocs.org/en/latest/mboxutils.html#boltons.mboxutils.mbox_readonlydir
Been in production for a while, working like a charm. Might there be interest
in i
New submission from Mahmoud Lababidi:
The json.dumps()/encode functionality will raise an Error when an object that
cannot be json-encoded is encountered. The current Error message only shows the
Object itself. I would like to enhance the error message by also providing the
Type. This is
Changes by Mahmoud Lababidi :
--
keywords: +patch
Added file: http://bugs.python.org/file42258/json_encode.patch
___
Python tracker
<http://bugs.python.org/issue26
Mahmoud Lababidi added the comment:
Is there a use case where the representation is too long? I think it may be
useful to see the representation, but perhaps you are correct.
--
___
Python tracker
<http://bugs.python.org/issue26
Mahmoud Lababidi added the comment:
Serhiy,
I've attached a patch without the Object representation. Choose whichever you
feel is better.
--
Added file: http://bugs.python.org/file42366/json_encode.patch
___
Python tracker
<http://bugs.py
New submission from Mahmoud Hashemi:
The encoding keyword argument to the Python 3 str() and Python 2 unicode()
constructors is excessively constraining to the practical use of these core
types.
Looking at common usage, both these constructors' primary mode is to convert
various objects
Mahmoud Hashemi added the comment:
Python already has one approach that fails to decode non-bytestrings: the
.decode() method.
This is about removing unicode barriers to entry and making the str constructor
in Python 3 as succinctly useful as possible. There are several problems the
helper
Mahmoud Hashemi added the comment:
Martin, it sounds that way because that is what is being proposed: "Merging and
simplifying the two modes". Given the existence of .decode() on bytestrings,
the only objects that generally need decoding in Python 2 and 3, the existence
of str
Mahmoud Hashemi added the comment:
I would urge you all take a stronger look at usability, rather than parroting
the current state of the design and docs. Python gained renown over the years
for its ability to stay flexible while maturing. Focusing on purity and
ignoring the needs of
New submission from Mahmoud Hashemi:
The resource module's description of resource.getpagesize is woefully
misguiding. Reproduced in full for convenience:
resource.getpagesize()
Returns the number of bytes in a system page. (This need not be the same as
the hardware page size.)
Mahmoud Al-Qudsi added the comment:
Attaching file2
--
Added file: https://bugs.python.org/file47165/file2
___
Python tracker
<https://bugs.python.org/issue31
New submission from Mahmoud Al-Qudsi:
While using the icdiff command line interface to difflib, I ran into an
interesting issue where difflib took 47 seconds to compare two simple text
documents (a PHP source code file that had been refactored via phptidy).
On subsequent analysis, it turned
Mahmoud Al-Qudsi added the comment:
@tim.peters
No, `icdiff` is not part of core and probably should be omitted from the
remainder of this discussion.
I just checked and it's actually not a mix of line endings in each file, it's
just that one file is \n and the other is \r\
28 matches
Mail list logo
