New submission from Max :
Bytes objects when indexed provide integers, but do not accept them to many
functions, making them inconsistent with other sequences.
Basic example:
>>> test = b'012'
>>> n = test[1]
>>> n
49
>>> n in test
True
>>&g
Max added the comment:
"This set of commands with list, strings, tuples, but not bytes objects."
should read
"This set of commands works with list, strings, tuples, but not bytes objects."
--
___
Python tracker
<http://bug
Max added the comment:
Fair enough.
I think it would make sense for the string methods to also accept single ints
where possible as well:
For haystack and needles both strings:
[haystack.find(n) for n in needles]
For both bytes, it's a bit contortionist:
[haystack.find(needles[i:i+1])
Changes by Max :
--
type: -> behavior
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/issue12170>
___
___
Python-bugs-list mailing list
Un
New submission from Max :
The sample code explaining zip function is incorrect at
http://docs.python.org/py3k/library/functions.html?highlight=zip#zip:
def zip(*iterables):
# zip('ABCD', 'xy') --> Ax By
iterables = map(iter, iterables)
while iterables:
Max added the comment:
Personally, I find it impossible in some cases to understand exactly what a
function does just from reading a textual description. In those cases, I always
refer to the equivalent code if it's given. In fact that's the reason I was
looking going the zip
Max added the comment:
This is still occurring with the release version of Python 3.2, installed from
the 32-bit MSI, on Windows XP.
--
nosy: +max-alleged
___
Python tracker
<http://bugs.python.org/issue10
New submission from Max :
The build_opener() function of urllib2 is speciofied as:
urllib2.build_opener([handler, ...])
I think it should be:
urllib2.build_opener(handler, ...)
see
http://docs.python.org/library/urllib2.html?highlight=build_opener
--
assignee: georg.brandl
Change by Max :
--
keywords: +patch
pull_requests: +15979
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/16398
___
Python tracker
<https://bugs.python.org/issu
New submission from Max :
Nobody seems to have noticed this AFAICS:
If you type, e.g., help('+') to get help on operator precedence, the fist
column gives a lit of operators for each row corresponding to a given
precedence. However, the row for "not" (and similar for &qu
Max added the comment:
Thanks for fixing the typo, didn't knnow how to do that when I spotted it (I'm
new to this).
You also removed Python version 3.6, 3.7, 3.8, however, I just tested on
pythonanywhere,
>>> sys.version
'3.7.0 (default, Aug 22 2018, 20:50:05) \n[G
Max added the comment:
option 1 looks most attractive to me (and will also look most attractive in the
rendering, IMHO -- certainly better than "await" "x", in any case).
P.S.: OK, thanks for explanations concerning 3.6 - 3.8. I do understand that it
won't be fixe
New submission from Max :
I recently came across a bug during a pentest that's allowed me to perform some
really interesting attacks on a target. While originally discovered in
requests, I had been forwarded to one of the urllib3 developers after agreeing
that fixing it at it's lo
Max added the comment:
I agree that the solution is quite restrictive.
Restricting to ASCII characters alone would certainly work.
--
___
Python tracker
<https://bugs.python.org/issue39
Max added the comment:
I've just noticed an issue with the current version of the patch. It should
also include 0x20 (space) since that can also be used to manipulate the request.
--
___
Python tracker
<https://bugs.python.org/is
New submission from Max :
Currently -O optimizer flag disables assert statements.
I want to ask that more fine-grained control is offered to users over the
assert statements. In many cases, it would be nice to have the option of
keeping asserts in release code, while still performing
New submission from Max :
I believe in both cases below, the ouptu should be ['a', 'b']; the extra ' '
inserted in the list is incorrect:
python3.6
Python 3.6.2 (default, Aug 4 2017, 14:35:04)
[GCC 6.3.0 20170516] on linux
Type "help", "copyright&
New submission from Max:
It seems both me and many other people (judging from SO questions) are confused
about whether it's ok to write this:
from multiprocessing import Process, Queue
q = Queue()
def f():
q.put([42, None, 'hello'])
def main():
p = Process(target
Max added the comment:
How about inserting this text somewhere:
Note that sharing and synchronization objects (such as `Queue()`, `Pipe()`,
`Manager()`, `Lock()`, `Semaphore()`) should be made available to a new process
by passing them as arguments to the `target` function invoked by the `run
New submission from Max:
Using multiprocessing.Queue() with several processes writing very fast results
in a deadlock both on Windows and UNIX.
For example, this code:
from multiprocessing import Process, Queue, Manager
import time, sys
def simulate(q, n_results):
for i in range
Max added the comment:
Yes, this makes sense. My bad, I didn't realize processes might need to wait
until the queue is consumed.
I don't think there's any need to update the docs either, nobody should have
production code that never reads the queue (mine was a test of so
Max added the comment:
Somewhat related is this statement from Programming Guidelines:
> When using the spawn or forkserver start methods many types from
> multiprocessing need to be picklable so that child processes can use them.
> However, one should generally avoid sending share
Max added the comment:
Actually, never mind, I think one of the paragraphs in the Programming
Guidelines ("Explicitly pass resources to child processes") basically explains
everything already. I just didn't notice it until @noxdafox pointed it out to
me on SO
New submission from Max:
There's a known issue with `shutil.rmtree` on Windows, in that it fails
intermittently.
The issue is well known
(https://mail.python.org/pipermail/python-dev/2013-September/128353.html), and
the agreement is that it cannot be cleanly solved inside `shutil
New submission from Max:
I think collections.abc.Hashable.__subclasshook__ should check __eq__ method in
addition to __hash__ method. This helps detect classes that are unhashable due
to:
to __eq__ = None
Of course, it still cannot detect:
def __eq__: return NotImplemented
but it's b
Max added the comment:
Sorry, this should be just a documentation issue.
I just realized that __eq__ = None isn't correct anyway, so instead we should
just document that Hashable cannot check for __eq__ and that explicitly
deriving from Hashable suppresses hashability.
--
compo
Max added the comment:
I'm also concerned about this (undocumented) inconsistency between map and
Executor.map.
I think you would want to make your PR limited to `ThreadPoolExecutor`. The
`ProcessPoolExecutor` already does everything you want with its `chunksize`
paramater, and a
Max added the comment:
Correction: this PR is useful for `ProcessPoolExecutor` as well. I thought
`chunksize` parameter handles infinite generators already, but I was wrong.
And, as long as the number of items prefetched is a multiple of `chunksize`,
there are no issues with the chunksize
New submission from Max:
The documentation states that subprocess.STDOUT is:
Special value that can be used as the stderr argument to Popen and indicates
that standard error should go into the same handle as standard output.
However, when Popen is called with stdout=None, stderr
New submission from Max:
This probably shouldn't happen:
import enum
class E(enum.Enum):
A = enum.auto
B = enum.auto
x = E.B.value
print(x) #
print(E(x)) # E.A
The first print() is kinda ok, I don't really care about which value was us
Max added the comment:
Ah sorry about that ... Yes, everything works fine when used properly.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Max added the comment:
I propose to close this issue as fixed.
The first two problems in the OP are now resolved through patches to pickle.
The third problem is addressed by issue5370: it is a documented feature of
pickle that anyone who defines __setattr__ / __getattr__ that depend on an
New submission from Max:
In dev/reference/datamodel#object.__hash__, there are two paragraphs that seem
inconsistent. The first paragraph seems to say that a class that overrides
__eq__() *should* explicitly flag itself as unhashable. The next paragraph says
that a class that overrides __eq__
New submission from Max:
Quoting from
http://docs.python.org/reference/datamodel.html#the-standard-type-hierarchy:
NotImplemented
This type has a single value. There is a single object with this value. This
object is accessed through the built-in name NotImplemented. Numeric methods
and rich
Max added the comment:
I agree about reflected operation, although the wording could be clearer ("will
try reflected operation" is better worded as "will return the result of the
reflected operation called on the swapped arguments".)
But what does it mean "or some oth
New submission from Max:
http://docs.python.org/dev/glossary.html?highlight=hashable says:
Objects which are instances of user-defined classes are hashable by default;
they all compare unequal, and their hash value is their id().
Since x == x returns True by default, so "they all co
New submission from Max:
PEP8 doesn't verifies last line at all. Also W292 will never be checked.
Reproducible on PEP8 >= 1.5.0
--
messages: 216072
nosy: f1ashhimself
priority: normal
severity: normal
status: open
title: PEP8 doesn't verifies last line.
t
New submission from Max:
Currently, there's no clear statement as to what exactly the fallback is in
case `__eq__` returns `NotImplemented`. It would be good to clarify the
behavior of `NotImplemented`; at least for `__eq__`, but perhaps also other
rich comparison methods. For example:
Max added the comment:
Martin - what you suggest is precisely what I had in mind (but didn't phrase it
as well):
> to document the above sort of behaviour as being directly associated with
> operations like as == and !=, and only indirectly associated with the
> NotImplemented
New submission from Max:
Is it safe to use the _callback and _args attributes of asyncio.Handle? Is it
possible to officially expose them as public API?
My use case:
handle = event_loop.call_later(delay, callback)
# this function can be triggered by some events
def reschedule
Max added the comment:
@yselivanov I just wanted to use the handler to avoid storing the callback and
args in my own data structure (I would just store the handlers whenever I may
need to reschedule). Not a big deal, I don't have to use handler as a storage
space, if it's not suppor
New submission from Max:
According to the
[docs](https://docs.python.org/3/library/pickle.html#pickling-class-instances):
> Note: At unpickling time, some methods like `__getattr__()`,
> `__getattribute__()`, or `__setattr__()` may be called upon the instance. In
> case those method
Max Katsev added the comment:
Note that deepcopy doesn't work either, even though it looks like it does at
the first glance (which is arguably worse since it's harder to notice):
Python 3.8.6 (default, Jun 4 2021, 05:16:01)
>>> import copy, os, subprocess
>>&
New submission from Max Bachmann :
In my environment I installed the following two libraries:
```
pip install rapidfuzz
pip install python-Levenshtein
```
Those two libraries have the following structures:
rapidfuzz
|-distance
|- __init__.py (from . import Levenshtein)
|- Levenshtein.*.so
Max Bachmann added the comment:
It appears this only occurs when a C Extension is involved. When the so is
imported first it is preferred over the .py file that the user would like to
import. I could not find any documentation on this behavior, so I assume that
this is not the intended.
My
Max Bachmann added the comment:
Thanks Dennis. This helped me track down the issue in rapidfuzz.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
New submission from Max Skaller :
Not sure if this is a bug or not. I am unable to find libpython.so for Python3
on either my Mac or Ubuntu. Perhaps this is a packaging fault, however some
documentation in the Wiki suggests otherwise. It appears the builders have
reverted to an archaic
Max Skaller added the comment:
On Sat, Oct 30, 2010 at 6:40 PM, Martin v. Löwis wrote:
It may be there is none. You need to read the bit where I explain that I am
not building Python, I'm grabbing pre-made packages, for OSX and for Ubuntu.
The problem is that these packages don'
Max Skaller added the comment:
On Thu, Nov 4, 2010 at 5:19 PM, Ned Deily wrote:
>
> Ned Deily added the comment:
>
> For what it's worth, the python.org installers for Mac OS X do include a
> libpython shared library. As of Python 2.7 (and 3.2), the installer
> includ
Max Arnold added the comment:
Our region recently switched to another timezone and I've noticed similar issue
while using Mercurial. There is some (hopefully) useful details:
http://mercurial.selenic.com/bts/issue2511
--
nosy: +LwarX
___
P
New submission from Max Ischenko:
Function logging.basicConfig has a confusing and undocumented behaviour:
it does nothing if there are any handlers already present in root logger.
It could be more explicit, say, by giving a ValueError in such cases.
--
components: Library (Lib
New submission from Max Hailperin :
The documentation for random.uniform says that random.uniform(a,b)
should return a number strictly less than b, assuming ab.) Thus both of the following
expressions should always evaluate to False:
a
<http://bugs.python.org/issue4
New submission from Max Voss :
Hello all,
I've been trying to understand multiprocessing for a while, I tried multiple
times. The PR is a suggested enhancement to the example that made it "click"
for me. Or should I say, produced a working result that made sense to me.
D
New submission from Max Bachmann :
The documentation stated, that the PyUnicode_KIND macro has the following
interface:
- int PyUnicode_KIND(PyObject *o)
However it actually returns a value of the underlying type of the
PyUnicode_Kind enum. This could be e.g. an unsigned int as well
Change by Max Prokop :
--
components: +2to3 (2.x to 3.x conversion tool), Argument Clinic, Build, C API,
Cross-Build, Demos and Tools, Distutils, Documentation, asyncio, ctypes
nosy: +Alex.Willmer, asvetlov, dstufft, eric.araujo, larry, yselivanov
type: enhancement -> compile er
Change by Max Bélanger :
--
nosy: +maxbelanger
nosy_count: 18.0 -> 19.0
pull_requests: +24010
pull_request: https://github.com/python/cpython/pull/25274
___
Python tracker
<https://bugs.python.org/issu
Change by Max Bélanger :
--
nosy: +maxbelanger
nosy_count: 4.0 -> 5.0
pull_requests: +24011
pull_request: https://github.com/python/cpython/pull/25274
___
Python tracker
<https://bugs.python.org/issu
New submission from Max Marrone :
# Summary
Basic use of `asyncio.subprocess.Process.terminate()` can raise a
`ProcessLookupError`, depending on the timing of the subprocess's exit.
I assume (but haven't checked) that this problem extends to `.kill()` and
`.send_signal()`.
This
Change by Max Marrone :
--
title: Signaling an asyncio subprocess raises ProcessLookupError, depending on
timing -> Signaling an asyncio subprocess might raise ProcessLookupError, even
if you haven't called .wait() yet
___
Python tracker
New submission from Max Bachmann :
I noticed that when using the Unicode character \U00010900 when inserting the
character as character:
Here is the result on the Python console both for 3.6 and 3.9:
```
>>> s = '0𐤀00'
>>> s
'0𐤀00'
>>> ls = l
Max Bachmann added the comment:
This is the result of copy pasting example posted above on windows using
```
Python 3.7.8 (tags/v3.7.8:4b47a5b6ba, Jun 28 2020, 08:53:46) [MSC v.1916 64 bit
(AMD64)] on win32
```
which appears to run into similar problems:
```
>>> s
Max Bachmann added the comment:
> That is using Python 3.9 in the xfce4-terminal. Which xterm are you using?
This was in the default gnome terminal that is pre-installed on Fedora 34 and
on windows I directly opened the Python Terminal. I just installed
xfce4-terminal on my Fedora 34 mach
Max Bachmann added the comment:
As far as a I understood this is caused by the same reason:
```
>>> s = '123\U00010900456'
>>> s
'123𐤀456'
>>> list(s)
['1', '2', '3', '𐤀', '4', '5',
New submission from Max Coplan :
Trying to use new Python 3 `IPv4Address`s fails with the following error
```
File
"/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/asyncio/base_events.py",
line 1270, in _ensure_resolved
info = _ipaddr_info(
Change by Max Coplan :
--
keywords: +patch
pull_requests: +16913
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/17434
___
Python tracker
<https://bugs.python.org/issu
Change by Max Coplan :
--
title: asyncio cannot handle Python3 IPv4Address or IPv6 Address -> asyncio
cannot handle Python3 IPv4Address
___
Python tracker
<https://bugs.python.org/issu
Max Coplan added the comment:
Well I’ve submitted a fix for it. It isn’t perfect. Well, while it doesn’t
look perfect, it actually worked with everything I’ve thrown at it, and seems
to be a very robust and sufficient fix.
--
___
Python tracker
Change by Max Vorobev :
--
keywords: +patch
pull_requests: +17708
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/18336
___
Python tracker
<https://bugs.python.org/issu
New submission from Max Bachmann :
The documentation of PyObject_Call here:
https://docs.python.org/3/c-api/call.html#c.PyObject_Call
states, that it is the equivalent of the Python expression: callable(*args,
**kwargs).
so I would expect:
PyObject* args = PyTuple_New(0);
PyObject* kwargs
New submission from Max Parry :
The German alphabet has four extra characters (ä, ö, ü and ß) when compared to
the UK/USA alphabet. Until 2017 the character ß was normally only lower case.
Upper case ß was represented by SS. In 2017 upper case ß was introduced,
although SS is still often
Change by Max Bélanger :
--
keywords: +patch
nosy: +maxbelanger
nosy_count: 1.0 -> 2.0
pull_requests: +23495
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24719
___
Python tracker
<https://bugs.python.org/i
Max Bolingbroke added the comment:
As of Python 3.7.9 this also affects \xf9\xd6 which should be \u7881 in
Unicode. This character is the second character of 宏碁 which is the name of the
Taiwanese electronics manufacturer Acer.
You can work around the issue using big5hkscs just like with the
Change by Max Desiatov :
--
nosy: -MaxDesiatov
___
Python tracker
<https://bugs.python.org/issue41100>
___
___
Python-bugs-list mailing list
Unsubscribe:
Max Franks added the comment:
Issue 3 is not related to the other 2. See this post
http://bugs.python.org/issue5370. As haypo said, it has to do with unpickling
objects. The post above gives a solution by using the __setstate__ function.
--
nosy: +eliquious
Max Staff added the comment:
Yes I know about the errno. There would be two ways to resolve this:
One way would be by introducing a new exception class which would be nice
because it's almost impossible to reliably check the allowed filename length
(except for trial and error) and I
Max Staff added the comment:
...at least those are the only two ways that I can think of.
--
___
Python tracker
<http://bugs.python.org/issue30641>
___
___
Pytho
New submission from Max Ehrlich:
On line 393 of multiprocessing/connection.py, the size of the payload to be
sent is serialized as an integer. This fails for sending large payloads. It
should probably be serialized as a long or better yet a long long.
--
components: Library (Lib
New submission from Max Rothman:
For a function f with the signature f(foo=None), the following three calls are
equivalent:
f(None)
f(foo=None)
f()
However, only the first two are equivalent in the eyes of
unittest.mock.Mock.assert_called_with:
>>> with patch('__main__.f'
Max Rothman added the comment:
I'd be happy to look at submitting a patch for this, but it'd be helpful to be
able to ask questions of someone more familiar with unittest.mock's code.
--
___
Python tracker
<http://bugs.pyt
New submission from Max Vorobev:
Line terminator defaults to '\r\n' while detecting dialect in csv.Sniffer
--
components: Library (Lib)
messages: 297497
nosy: Max Vorobev
priority: normal
severity: normal
status: open
title: csv.Sniffer does not detect lineterminator
type
Changes by Max Vorobev :
--
pull_requests: +2595
___
Python tracker
<http://bugs.python.org/issue30825>
___
___
Python-bugs-list mailing list
Unsubscribe:
Max Rothman added the comment:
> Generally the called with asserts can only be used to match the *actual
> call*, and they don't determine "equivalence".
That's fair, but as unittest.mock stands now, it *does* check equivalence, but
only partially, which is more conf
Max Rothman added the comment:
Hi, just wanted to ping this again and see if there was any movement.
--
___
Python tracker
<http://bugs.python.org/issue30
New submission from Max Rothman:
In the case detailed below, argparse.ArgumentParser improperly parses the
argument string "-_":
```
import argparse
parser = argparse.ArgumentParser()
parser.add_argument('first')
print(parser.parse_args(['-_']))
```
Expected be
Max Rothman added the comment:
Martin: huh, I didn't notice that documentation. The error message definitely
could be improved.
It still seems like an odd choice given that argparse knows about the expected
spec, so it knows whether there are any options or not. Perhaps one could
e
Max Rothman added the comment:
I think that makes sense, but there's still an open question: what should the
correct way be to allow dashes to be present at the beginning of positional
arguments?
--
___
Python tracker
<http://bugs.py
New submission from Max Staff:
There are different ways to catch exceptions of the type "OSError": By using
"except OSError as e:" and then checking the errno or by using "except
FileNotFoundError e:" or "except FileExistsError e:" or whatever error one
Max Rees added the comment:
Actually the symlinks don't need to be broken. It fails for any kind of symlink
on musl.
$ ls -l /tmp/symtest
lrwxrwxrwx 1 mcrees mcrees 10 Apr 18 21:16 empty -> /var/empty
-rw-r--r-- 1 mcrees mcrees 0 Apr 18 21:16 regular
lrwxrwxrwx 1 mcrees mcrees 16 Apr
Max Rothman added the comment:
Hi, I'd like to wrap this ticket up and get some kind of resolution, whether
it's accepted or not. I'm new to the Python community, what's the right way to
prompt a discussion about this sort of thing? Should I have taken it to one o
Change by Max Bélanger :
--
keywords: +patch
pull_requests: +4148
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue31903>
___
___
Py
Change by Max Bélanger :
--
keywords: +patch
pull_requests: +4700
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32280>
___
___
Py
Change by Max Bélanger :
--
keywords: +patch
pull_requests: +4702
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32282>
___
___
Py
Change by Max Bélanger :
--
keywords: +patch
pull_requests: +4703
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32285>
___
___
Py
Change by Max Bélanger :
--
keywords: +patch
pull_requests: +9307
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35022>
___
___
Py
Change by Max Bélanger :
--
keywords: +patch
pull_requests: +9308
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35025>
___
___
Py
Change by Max Bélanger :
--
keywords: +patch
pull_requests: +9469
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35080>
___
___
Py
Change by Max Bélanger :
--
keywords: +patch
pull_requests: +9599
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35139>
___
___
Py
Change by Max Bowsher :
--
nosy: +Max Bowsher
___
Python tracker
<https://bugs.python.org/issue35203>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Max DeLiso:
hi.
if you cross compile the mercurial native extensions against python 2.7.5 (x64)
on 64 bit windows 7 and then try to clone something, it will crash.
I believe the reason for this is that the c runtime functions in the microsoft
crt will throw a win32
Changes by Max DeLiso :
--
hgrepos: -199
___
Python tracker
<http://bugs.python.org/issue18197>
___
___
Python-bugs-list mailing list
Unsubscribe:
1 - 100 of 124 matches
Mail list logo
