David Rebbe added the comment:
Thank you for referencing the PEP, I just managed to read through it and I
still don't have a very good understanding why it needs to default to 1. PEP
435 states:
"The reason for defaulting to 1 as the starting number and not 0 is that 0 is
David Rebbe added the comment:
Seems like there is a misunderstanding here as to why this is an issue. I can
write an example up that would expand on the file I attached, but I feel like
anyone that has experience in the above situations would identify this as an
issue.
Can I ask why
David Rebbe added the comment:
Definition of equivalent
1: equal in force, amount, or value
Are you referring to memory space as what is actually stored in RAM? If so,
that seems to be outside the scope here. I don't think anyone expected an
interpreted language to have the same memory
David Rebbe added the comment:
Welcome to enums, they don't matter until they do. I'm personally not a fan of
enums for APIs but they exist all the time.
Indexing was an example case that nothing starts at 1.
See the attached file to demonstrate differences.
--
Added file: https
David Rebbe added the comment:
I only created this issue because its a deviation from any standard that exists
AFAIK. Nothing I know of starts at 1 in programming and I more than likely
won't be the last one to make this mistake. If indexing in Python started at 1
or any other accessor
David Rebbe added the comment:
Understandable and I do believe IntEnum should default as zero as its the
default type most will choose when trying to mimic other languages.
C/C++ has the same problem where the value isn't suppose to matter but as soon
as you go across the compiled
New submission from David Rebbe :
enum.auto() By default, the initial value starts at 1. Per the documentation
here: https://docs.python.org/3/library/enum.html#enum.auto
This doesn't really follow expected behavior in majority of programming
languages nor python. Most will expect starting
David Gilman added the comment:
Reflecting on this a bit I wonder if the best of all worlds is to have an
EpollExclusiveSelector whose modify() implementation just unregisters and
registers the file descriptor.
--
___
Python tracker
<ht
David Gilman added the comment:
I also played with making another whole subclass that has it on by default, see
this package https://github.com/dgilman/selector-epoll-exclusive
That class could have EPOLLEXCLUSIVE on by default but could raise
NotImplemented if you try and modify
Change by David Gilman :
--
keywords: +patch
pull_requests: +26284
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/27819
___
Python tracker
<https://bugs.python.org/issu
New submission from David Gilman :
Note that this is a different approach from the one taken in
https://bugs.python.org/issue35517 although the issue is still the same.
I've written a patch that allows users of selector.EpollSelector to enable
EPOLLEXCLUSIVE on their file descriptors
R. David Murray added the comment:
Mentioning ids would be pretty much redundant with mentioning pickle. If it is
pickled its id is going to change. I think Davin was suggesting that while the
use of serialization is documented, it is not documented *consistently*.
Everywhere
New submission from David Duffy :
https://ai.googleblog.com/2006/06/extra-extra-read-all-about-it-nearly.html
led me to change to lo+(lo+hi)/2 - would this affect bisect.py???
--
components: Library (Lib)
messages: 398337
nosy: David.Duffy
priority: normal
severity: normal
status
R. David Murray added the comment:
That file appears to be a binary file? By itself it isn't enough to reproduce
the problem. Can you provide a complete script as well as the email message
you are parsing that demonstrates the problem?
By "looks like any other eml file", are you
R. David Murray added the comment:
I suspect maxheaderlen=0 works because it causes the original lines to be
re-emitted without any folding or other processing. Without that, lines longer
than the default max_line_length get refolded.
Can you provide an example of an input message
R. David Murray added the comment:
Having looked at the cited part of the RFC (but not tried to analyze it in
detail), I think you are correct. I've also glanced at your PR, and I think
your approach is correct in broad outline, but I haven't looked at the details.
For full message/global
R. David Murray added the comment:
My apologies, I did not think about the possibility of an English issue. I was
reacting to the "security report speak", which I find often makes a security
issue sound worse than it is :) Thank you for reporting this problem, and I do
think we
R. David Murray added the comment:
Yes, compat32 uses a different parser and folder (the legacy ones), that have a
lot of small bugs relative to the RFCs (which is why I rewrote it).
--
___
Python tracker
<https://bugs.python.org/issue44
R. David Murray added the comment:
Forget what I said about my different error, I made a mistake running the test
script.
Interesting. If it is related to the length of the name, then the problem is
most likely in the folding algorithm, specifically in what happens when the
"display
R. David Murray added the comment:
There is definitely a problem here, though I see a different problem when I run
it (AttributeError: 'Group' object has no attribute 'local_part', presumably
because of the ':' not getting escaped correctly). I believe it applies to any
address header
R. David Murray added the comment:
s/header injection/command injection/
--
___
Python tracker
<https://bugs.python.org/issue43124>
___
___
Python-bugs-list m
R. David Murray added the comment:
This bug report starts with "a malicious user with direct access to
`smtplib.SMTP(..., local_hostname, ..)", which is a senseless supposition.
Anyone with "access to" the SMTP object could just as well be talking directly
to th
David Goncalves added the comment:
PR 25480 passes checks and awaits core review. All comments thus far have been
addressed.
--
___
Python tracker
<https://bugs.python.org/issue33
Change by David Hoyes :
--
nosy: +David Hoyes
___
Python tracker
<https://bugs.python.org/issue44594>
___
___
Python-bugs-list mailing list
Unsubscribe:
R. David Murray added the comment:
Ah, yes, the problem is more subtle than I thought.
The design here is that we should be starting with the largest lexical unit,
seeing if that fits on the current line, or a line by itself, and if so, using
that, and if not, move down to the next smaller
R. David Murray added the comment:
How are you encountering this error? The following program runs without
exception for me on master:
from email import message_from_binary_file
from email.policy import SMTP
msg = message_from_binary_file(open('mail.eml', 'rb'), policy=SMTP)
print(msg
R. David Murray added the comment:
I can't tell tell for sure if this behavior is intentional or not from a quick
glance at the code (though like you I wouldn't think it would be).
That's part of the legacy api, at this point. The new api will just use utf8:
from email.message import
David Lambert added the comment:
Hi Ray,
I'm glad this was a conscious choice. I found a person confused by the
output of print(abs(3), math.fabs(3))
Perhaps the manual would mention return values->that's not an annotation.
Thanks for considering,
Dave
On 6/27/21 12:42 PM, Raym
New submission from David Lambert :
math.fabs returns float.
The documentation should say so, and help(math.fabs) should include the
expected return type -> float
fabs(x, /) -> float
Return the absolute value of the float x.
I did not check, but expect these annotations recommend
New submission from David Gene :
Using os.environ[KEY] with a non-existent environment variable key only gives a
simple KeyError, which may be fine for a developer to understand, but if a user
of a Python program were to come across it, it may not indicate what they
needed to do to avoid
David Bolen added the comment:
Oddly, it turns out it's the "--junit-xml" parameter during buildbot tests that
is making it reproducible there.
Pass: python_d -m test.regrtest test_ssl
Fail: python_d -m test.regrtest --junit-xml out.xml test_ssl
The latter consistently
David Bolen added the comment:
The win10 buildbot appears to have this failure consistently (100%) on the 3.10
branch. The first such failure appears to be yesterday
(https://buildbot.python.org/all/#/builders/600/builds/79), following commit
da8097aaf5a55c23f5b5ddbeffc2d90d06e00d93 - GC
David Edelsohn added the comment:
It seems that PyOS_AfterFork_Child() needs to do something like
PyThreadState *tstate = PyThreadState_Get();
PyObject *wr = _PyObject_CAST(tstate->on_delete_data);
PyObject *obj = PyWeakref_GET_OBJECT(wr);
lockobject *lock;
if (obj != Py_None) {
l
Change by David Edelsohn :
--
nosy: +David.Edelsohn
___
Python tracker
<https://bugs.python.org/issue43665>
___
___
Python-bugs-list mailing list
Unsubscribe:
David Chen added the comment:
After some investigation, i almost finally identified the root cause - it was
caused by the following line in `Server` class in `manager.py` file:
```
self.listener = Listener(address=address, backlog=16)
```
i'm not sure where the magic number `16` came from
David Edelsohn added the comment:
How could release_sentinel() be structured to not call PyThread_release_lock()?
This seems to be a situation where _PyThreadState_DeleteExcept() is deleting
all thread states. thread__set_sentinel() sets release_sentinel() as its
on_delete hook. The thread
Change by David Edelsohn :
--
nosy: +David.Edelsohn
___
Python tracker
<https://bugs.python.org/issue40068>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by David Edelsohn :
--
nosy: +David.Edelsohn
___
Python tracker
<https://bugs.python.org/issue40092>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from David Hariri :
In some languages, one may declare a dictionary's key and its value like so:
```
foo = "bar"
my_dict = { foo }
>> { "foo" : "bar" }
```
In Python, one must instead write:
```
foo = "bar"
my_dict = {
&
R. David Murray added the comment:
Actually, I'm wrong. The body of a part can be a string, and that's what's
going to happen with a malformed body of something claiming to be a multipart.
The problem is that there is code that doesn't guard against this possibility.
The following patch
R. David Murray added the comment:
Yes, that's the real question. That's what needs to be fixed, otherwise we'll
just keep finding new bugs. For example, try calling iter_parts() on that
message. It isn't pretty :)
--
___
Python tracker
New submission from David Chen :
could someone help me out? i spent a lot of time to debug a race condition i
have encountered when using BaseManager, Pool within multiprocessing library.
here is the simplified code:
```
import sys, time
from multiprocessing.managers import BaseManager
R. David Murray added the comment:
As far as I know the only resources are the context manager docs and the source
code. The stdlib content manager can serve as a model. I have to admit that
it was long enough ago that I wrote that code that I'd have to re-read the docs
and code myself
R. David Murray added the comment:
Since python is doing the right thing here, I don't see a particularly good
reason to put a hack into the stdlib to fix the failure of third party software
to adhere to standards. (On the output side. We do follow Postel's rule on
input and try hard
Change by David Felsen :
--
nosy: +davfelsen
___
Python tracker
<https://bugs.python.org/issue38119>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from David Alvarez Lombardi :
As of now the best way to filter a str is to convert to list, filter, then join
back to a str. I think a a string comprehension would be very useful for this.
So to get only ascii_lower case chars given this string,
s = "a1b2c3d4&quo
New submission from David Alvarez Lombardi :
I frequently find myself doing the following for lists, sets, and dicts.
passes = [x for x in seq if cond(x)]
fails = [x for x in seq if not cond(x)]
The proposed function would behave similarly to `filter`, but it would return a
tuple
Change by David Goncalves :
--
nosy: +dpg
nosy_count: 11.0 -> 12.0
pull_requests: +24205
pull_request: https://github.com/python/cpython/pull/25480
___
Python tracker
<https://bugs.python.org/issu
Change by David Goncalves :
--
keywords: +patch
nosy: +dpg
nosy_count: 6.0 -> 7.0
pull_requests: +24204
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/25480
___
Python tracker
<https://bugs.python.org/i
David Heffernan added the comment:
@Steve as a user of Python rather than a Python developer, I don't know what
the process here. I understand the need for a test, and then a fix. And I would
not be surprised if the act of fixing the issue led to a broadening of the test
if the scope
Change by David Mandelberg :
--
nosy: +dseomn
___
Python tracker
<https://bugs.python.org/issue24959>
___
___
Python-bugs-list mailing list
Unsubscribe:
David Bolen added the comment:
No longer needed after commit c368ce74d2c9bcbf1ec320466819c2d4768252f7
--
resolution: -> out of date
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
David Ellsworth added the comment:
Thanks, I didn't realize. I thought it was an official module that wasn't
included as part of the main package due to being unfinished.
Reported the bug here:
https://bitbucket.org/mrabarnett/mrab-regex/issues/408/regex-fails-with-a-quantified
New submission from David Ellsworth :
The regex /^((x*)\2{3}(?=\2$))*x$/ matches powers of 5 in unary, expressed as
strings of "x" characters whose length is the number.
The following command line should print "1", but prints nothing:
python -c 'import regex; regex.matc
David Bolen added the comment:
Based on further information in issue #27129 as well as issue #43719 it appears
a source of the problem prompting this fix was a failure to update the magic
number in the original commit for #27129.
The windows clean script does still leave more artifacts than
David Bolen added the comment:
Dennis, just to make sure I wasn't too literal, some of the __pycache__ folders
are in subdirectories (at least in Tools), so just to double check, you did a
recursive search beneath Tools and Parser right
David Bolen added the comment:
Terry, it's not clear to me if this is the same issue (at first blush it
appears different) but could you see if you have any pyc files in __pycache__
folders within the Tools or Parser directories in your tree that could be from
prior builds? If so, remove
David Bolen added the comment:
I don't think reverting the commit at this point would necessarily be helpful.
While it might fix some systems, it could newly break anyone who happened to do
their first build since the commit was in place.
I didn't want to bug anyone over the weekend
Change by David Bolen :
--
keywords: +patch
pull_requests: +23904
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/25157
___
Python tracker
<https://bugs.python.org/issu
David Bolen added the comment:
Something like this is a quick 'n dirty minimal fix - at least it seems to
solve the problem that arose in issue #27129 on the Win10 buildbot:
--- a/Tools/buildbot/clean.bat
+++ b/Tools/buildbot/clean.bat
@@ -11,6 +11,8 @@ call "%pcbuild%\build.bat" -
David Bolen added the comment:
I've opened issue #43709 for fixing the buildbot clean script under Windows.
It needs to clean the Tools and Parser trees, not just Lib (and there are a few
other folders involved besides clinic)
--
___
Python
New submission from David Bolen :
The Tools\buildbot\clean.bat script used on Windows only removes pyc/pyo files
from the Lib tree, leaving some files beneath Tools (clinic and peg_generator)
and Parser (asdl). This can cause failures following commits that affect those
files
David Bolen added the comment:
I'm out of time for a bit, but it appears that the root issue is old pyc files
in Tools/clinic/__pycache__ that aren't removed during a clean process, and
appear to be the source of all of the errors. Manually pruning that folder
fixes things.
I believe
David Bolen added the comment:
Ah, Victor, that helps. I was having trouble reproducing the problem on a
different system. I was suspecting a small difference in compiler version, but
I hadn't considered it being because I started fresh.
>From what I can see, a particular build tree
David Bolen added the comment:
Unfortunately, not at the moment - what's in the buildbot log is what's
available. The RTL assertion aborts the process.
The tests involved (such as test_clinic) do seem reproducible in a few separate
tries, though again, all they do is terminate
David Bolen added the comment:
Note that this commit appears to be causing exceptions for the Win10 buildbot,
failing the PyCode_Addr2Line assertion in codeobject.c line 1252.
The assertion seems to pop up at differing points during each test run, but the
builder has yet to complete a full
David Bolen added the comment:
In lieu of the patch in #25191, what about a pair of skips to deal with the
issues at hand without killing the test entirely? I'm including OpenBSD since
those issues were closed in favor of this one, and am assuming that skipping
there is also appropriate
Change by William (David) Wilcox :
--
resolution: -> rejected
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by William (David) Wilcox :
--
components: Library (Lib)
nosy: wdwilcox
priority: normal
severity: normal
status: open
title: Missing stub for logging attribute manager
type: enhancement
versions: Python 3.10
___
Python tracker
<ht
David Bolen added the comment:
I don't have much of a horse in the race, but since the test has historically
been skipped on Windows, and the test hasn't and doesn't work on Windows,
modifications to restore the skip behavior seem reasonable to me. The trigger
for this issue was Windows
David Bolen added the comment:
The test has also begun failing on the Win10 buildbot (after updating to 20H2
from an older 1803).
--
nosy: +db3l
___
Python tracker
<https://bugs.python.org/issue37
David Brochart added the comment:
Regarding the initial message in this issue, and enabling recursive event
loops, this has proved to be very useful when an event loop is already running
and some non-async code needs to run async code. This situation is very
frequent when e.g. a library
David Lukeš added the comment:
> You can use TemporaryDirectory.
That was actually the first approach I tried :) I even thought this could be
used to make `mktemp` safe -- just create the name in a `TemporaryDirectory`.
However, after reading through the mailing list thread, I reali
David Lukeš added the comment:
> A secure `mktemp` could be as simple as ...
Though in practice, I'd rather be inclined to make the change in
`tempfile._RandomNameSequence`, so as to get the same behavior across the
entire module, instead of special-casing `mktemp`. As Guido van Ros
New submission from David Lukeš :
I recently came across a non-testing use case for `tempfile.mktemp()` where I
struggle to find a viable alternative -- temporary named pipes (FIFOs):
```
import os
import tempfile
import subprocess as sp
fifo_path = tempfile.mktemp()
os.mkfifo(fifo_path
R. David Murray added the comment:
Parsing and newlines have nothing to do with this bug, actually. I don't think
your foldfix post-processing is going to do what you want in the general case.
The source of the bug here is in the folding algorithm in _header_value_parser.
It has checks
New submission from David Elmakias :
It might be my lack of knowledge in python, however I find this behavior a bit
strange.
By declaring a private variable in a class, python creates an attribute with
the name '___'.
Both are located on a different location in memory.
I found
Change by David Wood :
Removed file: https://bugs.python.org/file49861/crypt.tar.gz
___
Python tracker
<https://bugs.python.org/issue43435>
___
___
Python-bugs-list m
David E. Franco G. added the comment:
How is that clutter?
Even the most basic text editor (window notepad) have it, and knowing that
yours or whoever code you are looking at extend horizontally beyond the size of
your current windows size is a relevant information.
--
Added file
New submission from David E. Franco G. :
I noticed that the horizontal scroll bar is missing, I think it was present in
previous version, regardless it would be nice if its be present.
Thanks.
--
assignee: terry.reedy
components: IDLE
files: no scroll bar.PNG
messages: 388469
nosy
David Wood added the comment:
Christian/Eric -
Thank you both so much for taking time on this. Christian had pointed out the
use of memcpy vs strncpy. It turns out that while strncpy is designed to copy
a specific number of chars, it turns out that it stops on null. I did make
Change by David Tucker :
--
nosy: +tucked
___
Python tracker
<https://bugs.python.org/issue43465>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by David Wood :
Removed file: https://bugs.python.org/file49862/crypt.tar.gz
___
Python tracker
<https://bugs.python.org/issue43435>
___
___
Python-bugs-list m
David Wood added the comment:
Attached are the basic files. As you can see in the example test9.py, I am
generating a random string, encrypting it, decrypting it, and comparing the
decrypted result with the original value.
This is intended to run on linux and requires the mcrypt library
Change by David Wood :
Added file: https://bugs.python.org/file49862/crypt.tar.gz
___
Python tracker
<https://bugs.python.org/issue43435>
___
___
Python-bugs-list mailin
Change by David Wilson :
--
keywords: +patch
pull_requests: +23570
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24802
___
Python tracker
<https://bugs.python.org/issu
New submission from David Wilson :
When viewing docs for classes that use annotations, pydoc's rendering of
argument lists is regularly truncated at the terminal edge (if using `less
-S`), or wrapped in a manner where quickly scanning the output is next to
impossible.
My 'classic' example
David Wood added the comment:
Still no bueno.
--
___
Python tracker
<https://bugs.python.org/issue43435>
___
___
Python-bugs-list mailing list
Unsubscribe:
David Wood added the comment:
Christian -
Thank you for this. I did as you suggested however, I still have the same
problem. As I pointed out in my original message, the problem does not exist
if I insert a sleep(1) statement prior to returning from the function.
Additional to that, I
David Wood added the comment:
I have not gone to the extent of comparing the direct output against what
python gets, although it appears to be incomplete. The following is my encrypt
function which has been used successfully for many years in a separate c
program, so I have high confidence
New submission from David Wood :
I have a c function to encrypt values which returns an array of bytes. The
function returns proper values outside of python. When used as a python
function, the result is incomplete usually 10-20% of the time. If I add a
sleep(1) call before returning from
David Bolen added the comment:
The win10 buildbot is green again, so I think this can be closed.
--
___
Python tracker
<https://bugs.python.org/issue43
Change by David Bolen :
--
keywords: +patch
pull_requests: +23510
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24739
___
Python tracker
<https://bugs.python.org/issu
David Bolen added the comment:
Yes, that was the idea (revert the PyDEBUG condition only); it sounds like
everyone is on the same page.
I've been doing buildbot duties only for a while (no code contributions since
long before the current process), so there may be a short delay while I
David Bolen added the comment:
Steve, where is that configured? If reducing that further would resolve the
crashes while retaining ceval debugging, maybe that's a reasonable trade-off,
though based on my testing, reverting still seems simpler.
Right now the debug build on the buildbot
David Bolen added the comment:
I hadn't tested release mode earlier, since the commit only removed the pragma
in debug builds, but I just built a release build with the commit in place on
the worker and it seems fine.
So barring stack changes (enlarging or improving usage) it appears
David Bolen added the comment:
I don't think it's actually any change in ceval per se, or any new buffers,
just how the compiler code generation has changed due to this commit.
Based on some local testing, the triggering issue is the exclusion of the
optimization pragma entirely in debug
David Edelsohn added the comment:
Christian,
The Python Community Code of Conduct also states:
Being respectful of differing viewpoints and experiences.
Showing empathy towards other community members.
Various developers are passionate about this topic and the entire series of
comments has
Change by David Bolen :
--
nosy: +db3l
___
Python tracker
<https://bugs.python.org/issue43166>
___
___
Python-bugs-list mailing list
Unsubscribe:
David Bordeynik added the comment:
I would appreciate a code review - thank you
--
___
Python tracker
<https://bugs.python.org/issue42643>
___
___
Python-bug
101 - 200 of 12771 matches
Mail list logo
