Re: Find the path of a shell command

[Joe Pfeiffer]

Cameron Simpson  writes:

> On 12Oct2022 20:54, Jon Ribbens  wrote:
>>On 2022-10-12, Jon Ribbens  wrote:
>>> On 2022-10-12, Joe Pfeiffer  wrote:
>>>> Jon Ribbens  writes:
>>>>> on Amazon Linux:
>>>>>
>>>>> $ which rm
>>>>> /usr/bin/rm
>>>>> $ sudo which rm
>>>>> /bin/rm
>>>>
>>>> Have some major Linux distributions not done usrmerge yet?  For any that
>>>> have, /bin is a symbolic link to /usr/bin
>
> The above example may just be a different ordering in $PATH.

Sure, but the point is OP can use either /bin/rm or /usr/bin/rm on the
vast majority of systems and execute the same command.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Find the path of a shell command

[Joe Pfeiffer]

Jon Ribbens  writes:

> On 2022-10-12, Michael F. Stemper  wrote:
>> On 12/10/2022 07.20, Chris Green wrote:
>>> ... and rm will just about always be in /usr/bin.
>>
>> On two different versions of Ubuntu, it's in /bin.
>
> It will almost always be in /bin in any Unix or Unix-like system,
> because it's one of the fundamental utilities that may be vital in
> fixing the system when it's booted in single-user mode and /usr may
> not be available. Also, the Filesystem Hierarchy Standard *requires*
> it to be in /bin.
>
> Having said that, nothing requires it not to be elsewhere *as well*,
> and in Ubuntu and other Linux systems it is in /usr/bin too. And because
> PATH for non-root users will usually contain /usr/bin before /bin (or
> indeed may not contain /bin at all), 'command -v rm' or 'which rm' will
> usually list the version of rm that is in /usr/bin.
>
> e.g. on Amazon Linux:
>
> $ which rm
> /usr/bin/rm
> $ sudo which rm
> /bin/rm

Have some major Linux distributions not done usrmerge yet?  For any that
have, /bin is a symbolic link to /usr/bin
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: SyntaxError: multiple statements found while compiling a single statement

[Joe Pfeiffer]

Sohail Ahmad  writes:

> kindly please help me about issues
>  SyntaxError: multiple statements found while compiling a single statement 
> how to solve this issues

Please post the code that got the error.  Preferably several lines
before the actual error, and the line with the error itself.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functionality like local static in C

[Joe Pfeiffer]

Cecil Westerhof  writes:

> In C when you declare a variable static in a function, the variable
> retains its value between function calls.
> The first time the function is called it has the default value (0 for
> an int).
> But when the function changes the value in a call (for example to 43),
> the next time the function is called the variable does not have the
> default value, but the value it had when the function returned.
> Does python has something like that?

Others (in particular mirko) have given ways to emulate that
functionality.

I'll mention that local statics are frequently not found in object
oriented languages because member variables can serve much the same
function in a more general way.  If you think you need a static local
variable, ask yourself if what you really need is a class.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue47198] os.stat on windows doesn't take an open file even though os.stat in os.supports_fd

[Joe Cool]

New submission from Joe Cool :

os.stat on windows doesn't take an open file even though os.stat in 
os.supports_fd

>>> fd = open('tmp.tmp', 'w')
>>> fd
<_io.TextIOWrapper name='tmp.tmp' mode='w' encoding='cp1252'>
>>> os.stat(fd)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: stat: path should be string, bytes, os.PathLike or integer, not 
TextIOWrapper
>>> os.stat in os.supports_fd
True

--
messages: 416535
nosy: snoopyjc
priority: normal
severity: normal
status: open
title: os.stat on windows doesn't take an open file even though os.stat in 
os.supports_fd
type: behavior
versions: Python 3.10

___
Python tracker 
<https://bugs.python.org/issue47198>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46947] unicodedata.name gives ValueError for control characters

[Joe Cool]

Joe Cool  added the comment:

My recommendation would be to add a keyword parameter, defaulting to False, to 
name(), something like give_full_alias, or maybe errors=“give_full_alias” like 
the IO functions.

In the meantime, as the author of perllib, I had to make my own dict to return 
to the user the same thing perl does, which is the full alias for these.

--

___
Python tracker 
<https://bugs.python.org/issue46947>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46947] unicodedata.name gives ValueError for control characters

[Joe Cool]

Joe Cool  added the comment:

Note: This is an issue for all chars in the ordinal range 0 thru 31.

--

___
Python tracker 
<https://bugs.python.org/issue46947>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46947] unicodedata.name gives ValueError for control characters

[Joe Cool]

New submission from Joe Cool :

unicodedata.name gives ValueError for control characters, for example:

>>> unicodedata.name('\x00')
Traceback (most recent call last):
  File "", line 1, in 
ValueError: no such name
>>> unicodedata.name('\t')
Traceback (most recent call last):
  File "", line 1, in 
ValueError: no such name


Where unicodedata.lookup clearly knows the names for these characters:
>>> unicodedata.lookup('NULL')
'\x00'
>>> unicodedata.lookup('TAB')
'\t'

--
components: Library (Lib)
messages: 414672
nosy: snoopyjc
priority: normal
severity: normal
status: open
title: unicodedata.name gives ValueError for control characters
type: behavior
versions: Python 3.10

___
Python tracker 
<https://bugs.python.org/issue46947>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46931] zipfile library will raise uncaught oserror when reading length incorrect zip file

[Vertu Joe]

New submission from Vertu Joe :

I intentionally made some corrupted zip archive files for testing.
If some contents were removed from the archive instead of changing the bits. 
when trying to read such files, the zipfile will raise an uncaught  OSError, 
instead of a badzipfile error as expected.

os is windows 10 x64 not sure if this also happens on the UNIX system or it's 
intended to be happen.

code:

import zipfile
with zipfile.ZipFile(r'damaged.zip') as dmg:
dmg.testzip()

result:
OSError
[Errno 22] Invalid argument
  File "test.py", line 20, in 
file = dmg.testzip()

--
components: Library (Lib)
files: damaged.zip
messages: 414590
nosy: ultimalium
priority: normal
severity: normal
status: open
title: zipfile library will raise uncaught oserror when reading length 
incorrect zip file
type: behavior
versions: Python 3.10
Added file: https://bugs.python.org/file50658/damaged.zip

___
Python tracker 
<https://bugs.python.org/issue46931>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40467] subprocess: replacement shell on windows with executable="..." arg

[Joe Cool]

Joe Cool  added the comment:

Proposed solution:

if comspec.endswith('sh.exe') or comspec.endswith('sh'):# 
issue 40467
args = '{} -c "{}"'.format (comspec, args)  # 
issue 40467
else:   # 
issue 40467
args = '{} /c "{}"'.format (comspec, args)

--
nosy: +snoopyjc

___
Python tracker 
<https://bugs.python.org/issue40467>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: doubt About import machine

[Joe Pfeiffer]

Daniel Eduardo Almeida Correa  writes:

> Hello, I'm trying to use the machine library in python 3.10 version, but I
> can't import it with the pip install machine, could you tell me a way to
> solve it  or a python version compatible with the library? Thank you a lot
> for your answer.

The "machine" package on pypi appears to only be an example of best
practices for a python package, and doesn't actually contain anything
useful.  Installing it doesn't actually give you a package called
"machine" that you can import; it lets you import something called
"sample" instead, which contains

def main():
"""Entry point for the application script"""
print("Call your main application code here")

as its __init__()

I'll note that I'm sort of a beginner with python so I may be speaking
out of turn, but it strikes me as really unlikely that the "best
practice" for a package named "machine" would put its code in a
directory named "sample".

Following the home page link for the project leads to a 404 on github
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.

[Joe Wells]

Joe Wells  added the comment:

Some quick comments on Martin's pull request.

1. The changes are sufficient to let the user make things work the way it is 
requested that they work and anyone who does not start using the new 
format_locals parameter will get the old behavior.

2. A side comment: I just noticed that the docstring for FrameSummary.__init__ 
does not document the filename, lineno, and name parameters.  Perhaps this 
could be fixed at the same time?

3. The new parameter format_locals is slightly confusingly named, because it 
does not format a single string from all the locals but instead gives a 
dictionary of strings with one string for each local.

4. I personally think it would be better to include something like the example 
value for format_locals as an extra attribute of the traceback module so 
everybody doesn't have to write the same function.  That said, the documented 
example is sufficient.

5. It is not clear to me why this stringify-ing of the locals can't be done in 
StackSummary._extract_from_extended_frame_gen.  It passes the dictionary of 
locals and also the function to transform it to FrameSummary.  It would make 
more sense to transform it first.  I suppose there might be some user somewhere 
who is directly calling FrameSummary so the interface needs to stay.

6. I fantasize that the new format_locals parameter would have access to the 
frame object.  In order for this to happen, the frame object would have to be 
passed to FrameSummary instead of the 3 values (locals, name, filename) that 
are extracted from it.  I think the current interface of FrameSummary was 
designed to interoperate with very old versions of Python.  Oh well.

7. If anyone wanted to ever refactor FrameSummary (e.g., to enable my fantasy 
in point #6 just above), it becomes harder after this.  This change has the 
effect of exposing details of the interface of FrameSummary to users of 
StackSummary.extract and TracebackException.  The four parameters that the new 
parameter format_locals takes are most of the parameters of FrameSummary.

--

___
Python tracker 
<https://bugs.python.org/issue43656>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.

[Joe Wells]

Joe Wells  added the comment:

1. As background, it is worth remembering that a major motivation for why 
FrameSummary.__init__ stringifies the local variable values in its parameter 
locals is to prevent the resulting data structure from keeping those values 
live.  This enables them to be garbage collected.

2. It has been suggested that TracebackException.__init__ or 
StackSummary.extract could be given a function parameter.  This could either be 
a new parameter or could involve using the existing capture_locals parameter 
with a non-bool.  The purpose of this suggestion is to allow customizing the 
use of repr to stringify local variable values.  If this suggestion is 
followed, it would be quite useful if this function parameter was given not 
just the local variable values, but also the name of the local variable and 
maybe also the stack frame it is in.  This would enable filtering out undesired 
variables.  For example, I would usually prefer to filter most of the variables 
from the __main__ module frame, because they are just noise that makes it hard 
to see the important details.  Some ability to filter would also help with the 
security issue that is discussed in issue 23597 that Irit pointed to.

3. I doubt that new students will be setting up calls to TracebackException or 
modifying sys.excepthook on their own.  Although a simple interface is clearly 
good, it might be more important to have an interface that maximizes the 
usefulness of the feature.

4. I no longer have the tracebacks my students were getting.  You can look at 
the traceback from the example in msg 404319 for a traceback.  While I was 
debugging this, I got much more complicated tracebacks because two of the 
classes in traceback.py also throw exceptions during their __init__ method that 
leave the not-yet-initialized object in a repr-will-raise-an-exception state.  
Despite having decades of programming experience, it actually took me a long 
time before I realized that the exceptions I was debugging were junk exceptions 
due to attempts to call repr on not-yet-initialized objects.  I think figuring 
this out would be extremely challenging for my second-year undergraduate 
students.

5. If one of the calls to repr in FrameSummary.__init__ raises an exception, 
this prevents all the other local variable values from being inspected.  If it 
is desired to report local variable values that cause repr to raise an 
exception, then it would be good to collect all such exceptions, which requires 
handling each exception and then continuing to traverse the traceback stack.  
Because of point 1 above, it might often be best to turn each such exception 
into a string.  To avoid infinite loops in the debugging/logging tools, it 
would often be best not to attempt to traverse the traceback stack of each of 
these extra exceptions.  If this argument is a good argument, this seems to 
mean that my most recent proposed fix is a good balance.

6. It is not clear if there is a reliable way to detect whether repr raises an 
exception due to an object's initialization having been interrupted, but all of 
the failures that I observed of this sort were for the variable name “self”.  
In one case, the repr failure was for a normal local variable of an __new__ 
method which was not a parameter of this method; the variable was named “self” 
by convention, but this convention would be difficult to automatically verify.  
In the two other cases, the repr failure was for a parameter named “self” which 
was the first parameter of an __init__ method.  So it would help to give 
special treatment to the first parameter of __init__ methods, but this would 
not solve the problem for __new__ methods.

7. In some cases, it might be a bit complicated to ensure the object is always 
in a safe state for repr-ing during initialization.  This is because there may 
be many attributes that need to be modified and this is not generally done 
atomically.  One attribute could be designated to indicate that initialization 
is done, so that repr will be extra careful if that attribute does not have an 
expected value.  Given that this is only (so far) an issue for debuggers and 
traceback inspection tools, it is not clear how to motivate everyone who writes 
a __new__, __init__, or __repr__ method to do this safely.  Documentation can 
of course help.

--

___
Python tracker 
<https://bugs.python.org/issue43656>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.

[Joe Wells]

Joe Wells  added the comment:

In the hopes of convincing someone to install a fix to this bug, I will mention 
a few additional points.

When I mention “the capture_locals feature”, I mean calls of the form 
traceback.TracebackException(..., capture_locals=True) and 
traceback.StackSummary.extract(..., capture_locals=True).

1. Right now, the capture_locals feature is unreliable.  If any frame on the 
entire stack has a single local variable for which repr raises an exception, 
the user gets no information whatsoever back for the entire stack except for 
that exception, and that exception does not identify the offending stack frame 
or local variable.  Also, every use of the capture_locals feature must be 
inside a try-except statement.

2. The exceptions raised by the capture_locals feature will often be junk 
exceptions carrying no useful information.  The meaning of these exceptions 
will often be “there is an incompletely initialized object in a variable 
somewhere on the stack”.  Because this is a fairly normal state of affairs, 
this will often not be useful information.

3. Although it is a excellent idea to encourage Python coders to ensure that 
__repr__ method never raise exceptions, it seems unlikely this will cause many 
__repr__ methods to be fixed in the near future.  My impression is that 
__repr__ methods that raise exceptions on incompletely initialized objects are 
common.  One reason for this might be that authors of __repr__ methods rarely 
suffer from this problem personally, because they will generally supply correct 
arguments to their own class constructors, and even when they don't (e.g., 
while building unit tests), they are unlikely to try to format to strings all 
the local variable values on the stack in the exception traceback.

4. Right now, the caller of traceback.FrameSummary(..., locals=x) needs to go 
through the entire dict x and for every value v in x test whether repr(v) 
raises an exception and if so either remove the key/value pair or change the 
value to something which can be safely repr-ed.  Then FrameSummary.__init__ 
will repeat this work and run repr on every value in x again.  So using 
FrameSummary safely requires duplicating the work, i.e., running repr on every 
value in the dict both before and during the call to FrameSummary.

5. Anyone who is using the capture_locals feature on an exception traceback has 
already caught an exception, and therefore decided not to let that exception 
“bubble up”.  Their attempts to log or otherwise cope with the exception will 
be spoiled by the capture_locals feature raising an unrelated exception.  This 
is even worse when the exception raised by the capture_locals feature is a junk 
exception that merely indicates there is an incompletely initialized object on 
the stack.  This is likely to happen because exceptions will often happen 
during the initialization of an object.

6. The most recent suggested fix does in fact report the extra repr exception 
discovered by the capture_locals feature in the string that represents the 
local variable's value.  The main effect of the current code propagating this 
repr exception is to make it harder to deal with the original exception.

I hope these points are useful.

--

___
Python tracker 
<https://bugs.python.org/issue43656>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.

[Joe Wells]

Joe Wells  added the comment:

Andrei, thanks very much for the pointer to bug/issue 
https://bugs.python.org/issue39228.  I had not noticed the earlier comment by 
Irit pointing to that bug.  (Is there some way to merge bugs so that someone 
visiting one of the bugs will see the merged stream of comments?)

The remarks in that bug are precisely why my recommended fix has this line:

d[k] = ''

instead of this:

d[k] = object.__repr__(v)

Does this not meet the concern expressed there?  Something that would more 
thoroughly meet that would be the following:

if locals:
d = {}
self.locals = d
for k, v in locals.items():
try:
d[k] = repr(v)
except Exception as e:
d[k] = ''
else:
self.locals = None

I use object.__repr__ instead of repr because when repr(v) has already failed 
it is likely that repr(e) on the exception e would also be likely to fail.  
Although we could also try repr(e) first to see if it raises an exception.

Your suggested reaction to this bug (documenting Python best practice) is 
something that should be done regardless.  I completely agree.  Unfortunately, 
better documentation of how to write good Python does not address the point of 
this bug which is that debugging tools should not fail when used to debug buggy 
code.  The purpose of a debugging tool is to help with badly written code, not 
to work only with well written code.  Right now the capture_locals=True feature 
is not safe to use without wrapping it with an exception handler.  As a result 
of this bug, I have been forced to rewrite this:

def format_exception_chunks(exception):
return (traceback.TracebackException.from_exception(exception, 
capture_locals=True).format())

to instead be this:

def format_exception_chunks(exception):
try:
tbe = (traceback.TracebackException
   . from_exception(exception, capture_locals=True))
return tbe.format()
except Exception:
pass
# the traceback module fails to catch exceptions that occur when
# formatting local variables' values, so we retry without
# requesting the local variables.
try:
tbe = traceback.TracebackException.from_exception(exception)
return ('WARNING: Exceptions were raised while trying to'
' format exception traceback with local variable'
' values,\n'
'so the exception traceback was formatted without'
' local variable values.\n',
*tbe.format())
except Exception:
return ('WARNING: Exceptions were raised while trying to format'
' exception traceback,\n'
'so no formatted traceback information is being'
' provided.\n',)

My argument is that it is better to fix the bug once in traceback.py instead of 
every user of the capture_locals=True feature having to discover the hard way 
(with hours of painful bug investigation) that they need to write lots of 
exception handling and bug workarounds around their use of the 
capture_locals=True feature.

--

___
Python tracker 
<https://bugs.python.org/issue43656>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.

[Joe Wells]

Joe Wells  added the comment:

I'm sorry Andrei: I misread your alteration of my example and misunderstood its 
purpose.

For anyone else reading these messages: In my most recent comment above, please 
ignore the part of my comment about Andrei's example.

So yes, Andrei, that is how people should write their code!  Your code does not 
trigger the bug because it is written in a better way.  Agreed completely.

However, this bug still needs fixed because it is currently not possible to use 
the capture_locals=True feature of the traceback module when debugging code 
written by people who do not follow Andrei's example of best practice.

--

___
Python tracker 
<https://bugs.python.org/issue43656>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.

[Joe Wells]

Joe Wells  added the comment:

Here are my thoughts inspired by Andrei's insightful comments.

1. In response to the major issue Andrei raises, I agree that it is desirable 
that repr would never raise an exception.  The reasons Andrei mentions seem 
quite correct to me.  However, I think the only practical way to make that 
change would be the change the code of the repr builtin.  (Expecting the 
authors of every class in all Python code ever written to make sure that their 
__repr__ method will never raise an exception is unrealistic.)

The bug that is the topic of the issue in this bug report can be fixed by 
merely handling exceptions raised by one particular call to repr in the code of 
FrameSummary.__init__.  That change can only affect code that uses the 
traceback module to get nicer tracebacks, and only if the capture_locals=True 
feature is requested

Changing the implementation of the repr builtin could conceivably cause 
unexpected problems for lots of deployed 3rd party code during normal use, 
because repr is widely used in deployed code, and hence more care and thought 
is needed.  In contrast, changing FrameSummary.__init__ as I propose in this 
bug report will only affect code using the capture_locals=True feature of the 
traceback module, and is likely to make such code more reliable because right 
now that feature is failure-prone due to this bug.

So I propose that making repr never raise exceptions should be a different bug. 
 This bug does not need to wait for that bug to be fixed.

2. In response to a minor point of Andrei, I would like to mention that I 
encountered this because I had given students a coursework template containing 
this code:

import traceback, sys

def format_exception_chunks(exception):
return (traceback.TracebackException.from_exception(exception, 
capture_locals=True).format())

def print_exception(_ignored_type, exception, _ignored_traceback):
for chunk in format_exception_chunks(exception):
print(chunk, file=sys.stderr, end="")

# This change to sys.excepthook adds local variables to stack traces.
sys.excepthook = print_exception

This had the unfortunate effect that when a class constructor decided that it 
did not like its arguments, the students were overwhelmed by a baffling cascade 
of exception tracebacks.  So while this was indeed “for convenience of 
interactive debugging”, it had the actual effect of making it nearly impossible 
for these beginner Python programmers to do any debugging at all.  The overall 
effect of this bug is that it makes it potentially unwise to routinely rely on 
the capture_locals=True feature.  A feature that could be useful for beginners 
actually makes it worse for them.

3. In response to Andrei's suggested change to my minimal example to reproduce 
the bug, I have a few comments.  First, his minimal example is just as good as 
mine for reproducing the bug.  Second, my example is inspired by the two 
classes I mention whose constructors trigger the bug: both of them do it by 
leaving the incompletely initialized object missing an attribute that repr 
depends on, so they both raise a missing attribute exception when an attempt is 
made to print the incompletely initialized object.  I suspect this is a quite 
common pattern in deployed Python code.  I suspect that people have not made 
efforts to avoid this pattern because it only triggers a bug when exception 
tracebacks are investigated, because the only reference to the incompletely 
initialized object is in the stack frame of the constructor method (either 
__new__ or __init__) which in turn is only referenced from the traceback.  
Third, my example deliberately has as little code as possible in the __repr__ 
method to convey the key issue.  Fourth, one of these two examples (mine or 
Andrei's) should go into the unit tests when the bug is fixed.

4. I notice that the code of unittest.util.safe_repr gives an example of how to 
use object.__repr__(obj) to get something formatted for an object whose normal 
__repr__ method has raised an exception.  So I alter my recommended fix to the 
following:

if locals:
d = {}
self.locals = d
for k, v in locals.items():
try:
d[k] = repr(v)
except Exception:
d[k] = ''
else:
self.locals = None

5. Can someone please change the Stage of this issue to something other than 
“resolved” and the Resolution of this issue to something other than “not a bug”?

I hope these comments are helpful and this bug gets somehow fixed.

--

___
Python tracker 
<https://bugs.python.org/issue43656>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.

[Joe Wells]

Joe Wells  added the comment:

I would like to request that this bug be repopened and fixed.

I've changed (or at least tried to change, I'm not sure if it will let me) the 
title of the bug to point out that the failure happens in 
FrameSummary.__init__.  It does not happen in StackSummary.format.

This problem makes the capture_locals=True feature of TracebackException and 
StackSummary and the "locals" parameter of FrameSummary unreliable.  If any one 
of the local variables in any frame on the stack is in an inconsistent state 
such that repr will raise an exception, the processing of the traceback fails.  
This kind of inconsistent state is of course likely to happen during debugging, 
which is precisely when you would want the capture_locals feature to actually 
work so you can see what is going wrong.

Just one example of an exception traceback being created with an unsafe local 
variable value in one of the stack frames is in the following line:

  from _pydecimal import Decimal as D; D(None)

The _pydecimal.Decimal.__new__ method raises an exception when it sees a value 
it doesn't know how to convert to Decimal.  When it does this, the new object 
it was creating is left in an inconsistent state missing the _sign attribute.  
When you try to inspect the resulting exception traceback with 
traceback.TracebackException(..., capture_locals=True), this raises an 
exception.

While I was tracking this bug down, I discovered that the 
traceback.TracebackException.__init__ method has the same problem: it 
initializes the _str attribute used by the __str__ method quite late and when 
it raised an exception before this point, the incompletely initialized 
TracebackException object caused repr to fail.  There's at least one more class 
in traceback.py that also has this problem, but I don't remember which one it 
is.

The cascade of exceptions causing exceptions causing exceptions makes the 
capture_locals feature difficult to use and debug.

Here is a short snippet that reproduces the bug on Python 3.9.7:

import traceback
class TriggerTracebackBug:
def __init__(self):
raise RuntimeError("can't build a TriggerTracebackBug object for some 
reason")
self._repr = 'if we reached this line, this object would have a repr 
result'
def __repr__(self):
return self._repr
try:
TriggerTracebackBug()
except Exception as e:
# this method call fails because there is a stack frame with a local
# variable (self) such that repr fails on that variable's value:
traceback.TracebackException.from_exception(e, capture_locals=True)

It's clear that it is too much to expect every class to implement a safe 
__repr__ method.  So it also seems clear to me that 
traceback.FrameSummary.__init__ is the place to fix it.

My suggested fix is to replace this line in the latest Lib/traceback.py:

self.locals = {k: repr(v) for k, v in locals.items()} if locals else 
None

with something like this code (written in a somewhat awkward way because that 
helped while I was debugging it):

if locals:
d = {}
self.locals = d
for k, v in locals.items():
try:
d[k] = repr(v)
except Exception:
d[k] = ''
else:
self.locals = None

I've tested this code in an older version of Python and it fixed the problem 
for me.

--
nosy: +jbw
title: StackSummary.format fails if repr(value) fails -> TracebackException or 
StackSummary.extract with capture_locals=True fail to catch exceptions raised 
by repr() on value of frame local variable in FrameSummary.__init__.

___
Python tracker 
<https://bugs.python.org/issue43656>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: XML Considered Harmful

[Joe Pfeiffer]

r...@zedat.fu-berlin.de (Stefan Ram) writes:

> - S expressions (i.e., LISP notation)

If you're looking at hierarchical data and you don't have some good
reason to use something else, this is very likely to be your simplest
option.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: XML Considered Harmful

[Joe Pfeiffer]

Eli the Bearded <*@eli.users.panix.com> writes:

> In comp.lang.python, Michael F. Stemper  wrote:
>> I've heard of JSON, but never done anything with it.
>
> You probably have used it inadvertantly on a regular basis over the
> past few years. Websites live on it.

If the user has any interaction whatever with the formats being used to
transfer data then something is very, very wrong.  Someone using a
website built on JSON isn't using JSON in any meaningful sense of the
term.

>> How does CSV handle hierarchical data? For instance, I have
>> generators[1], each of which has a name, a fuel and one or more
>> incremental heat rate curves. Each fuel has a name, UOM, heat content,
>> and price. Each incremental cost curve has a name, and a series of
>> ordered pairs (representing a piecewise linear curve).
>> 
>> Can CSV files model this sort of situation?
>
> Can a string of ones and zeros encode the sounds of Bach, the images
> of his sheet music, the details to reproduce his bust in melted plastic
> extruded from nozzle under the control of machines?
>
> Yes, CSV files can model that. But it would not be my first choice of
> data format. (Neither would JSON.) I'd probably use XML.
>
> I rather suspect that all (many) of those genomes that end up in
> Microsoft Excel files get there via a CSV export from a command line
> tool. Once you can model life in CSV, everything seems possible.

Whenever someone asks "can this be done?" in any sort of computer
related question, the real question is "is this practical?"  I have hazy
memories of seeing a Turing Machine implemented in an Excel spreadsheet,
so *anything* can, with sufficiently ridiculous amounts of work.  That's
not really helpful here.

>> [1] The kind made of tons of iron and copper, filled with oil, and
>> rotating at 1800 rpm.
>
> Those are rather hard to model in CSV, too, but I'm sure it could be
> done.

So let's try to point him at representations that are easy.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Friday Finking: Contorted loops

[Joe Pfeiffer]

r...@zedat.fu-berlin.de (Stefan Ram) writes:

> Alan Gauld  writes:
>>OK, That's a useful perspective that is at least consistent.
>>Unfortunately it's not how beginners perceive it
> ...
>
>   Beginners perceive it the way it is explained to them by
>   their teacher.

My life as a professor would have been *so* much easier if that were
true...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Friday Finking: Contorted loops

[Joe Pfeiffer]

2qdxy4rzwzuui...@potatochowder.com writes:

> On 2021-09-10 at 15:08:19 -0600,
> Joe Pfeiffer  wrote:
>
>> r...@zedat.fu-berlin.de (Stefan Ram) writes:
>
>> >   The existence of statements like "break" renders 
>> >   proof techniques for loops (such as Hoare's) with
>> >   their invariants and inference rules unapplicable.
>> 
>> Also the reason to avoid repeat-until loops:  the loop "invariant" isn't
>> the same on the first iteration as on subsequent iterations.
>
> I am by no means an expert, nor likely even a neophyte, but why would
> the loop invariant not be the same on the first iteration?
>
> I can certainly see that the exit condition may not make sense at the
> beginning of the first iteration (e.g., there is not yet any data to
> compare to the sentinel), but ISTM that claiming that the exit condition
> is a loop invariant isn't kosher (because all you're claiming is that
> the compiler works).

Precisely because you've got knowledge of the exit condition on
iterations after the first, but not the first one.  So, unlike a while
loop, you don't have the same knowledge on every pass.

> I can also see that certain state information may not be captured until
> the end of the first iteration.  But presumably said state information
> can change from iteration to iteration, so I can't see how you'd derive
> an invariant involving it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Friday Finking: Contorted loops

[Joe Pfeiffer]

r...@zedat.fu-berlin.de (Stefan Ram) writes:

> r...@zedat.fu-berlin.de (Stefan Ram) writes:
>>can be misleading, because the "..." part can still contain
>>"break", "raise", "continue", and "return" statement. So one
>>better should always be on the watch when reading source code
>>of a language like Python than relying only on the condition 
>>behind the "while".
>
>   The existence of statements like "break" renders 
>   proof techniques for loops (such as Hoare's) with
>   their invariants and inference rules unapplicable.

Also the reason to avoid repeat-until loops:  the loop "invariant" isn't
the same on the first iteration as on subsequent iterations.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: on floating-point numbers

[Joe Pfeiffer]

Hope Rouselle  writes:
> Christian Gollwitzer  writes:
>>
>> I believe it is not commutativity, but associativity, that is
>> violated. 
>
> Shall we take this seriously?  (I will disagree, but that doesn't mean I
> am not grateful for your post.  Quite the contary.)  It in general
> violates associativity too, but the example above couldn't be referring
> to associativity because the second sum above could not be obtained from
> associativity alone.  Commutativity is required, applied to five pairs
> of numbers.  How can I go from
>
>   7.23 + 8.41 + 6.15 + 2.31 + 7.73 + 7.77
>
> to 
>
>   8.41 + 6.15 + 2.31 + 7.73 + 7.77 + 7.23?
>
> Perhaps only through various application of commutativity, namely the
> ones below. (I omit the parentheses for less typing.  I suppose that
> does not create much trouble.  There is no use of associativity below,
> except for the intented omission of parentheses.)
>
>  7.23 + 8.41 + 6.15 + 2.31 + 7.73 + 7.77
>= 8.41 + 7.23 + 6.15 + 2.31 + 7.73 + 7.77
>= 8.41 + 6.15 + 7.23 + 2.31 + 7.73 + 7.77
>= 8.41 + 6.15 + 2.31 + 7.23 + 7.73 + 7.77
>= 8.41 + 6.15 + 2.31 + 7.73 + 7.23 + 7.77
>= 8.41 + 6.15 + 2.31 + 7.73 + 7.77 + 7.23.

But these transformations depend on both commutativity and
associativity, precisely due to those omitted parentheses.  When you
transform

7.23 + 8.41 + 6.15 + 2.31 + 7.73 + 7.77

into

8.41 + 6.15 + 2.31 + 7.73 + 7.77 + 7.23.

it isn't just assuming commutativity, it's also assuming associativity
since it is changing from

(7.23 + 8.41 + 6.15 + 2.31 + 7.73) + 7.77

to

(8.41 + 6.15 + 2.31 + 7.73 + 7.77) + 7.23.

If I use parentheses to modify the order of operations of the first line
to match that of the last, I get
7.23 + (8.41 + 6.15 + 2.31 + 7.73 + 7.77)

Now, I get 39.61 evaluating either of them.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue39232] asyncio crashes when tearing down the proactor event loop

[Joe]

Joe  added the comment:

We are running into this all the time, ever since the Proactor became the 
default on Windows in 3.8. 

Usually it comes up when the program terminates due to an unhandled exception 
during a highly concurrent operation. The resulting cascade of RuntimeErrors 
often obscures the real reason for failure, which makes debugging more painful 
than it should be. But sometimes this cascade of RuntimeErrors will occur even 
when the program otherwise executes successfully. So it can be difficult to 
know if the program actually blew up or if it's just benign event loop vomit.

Converting this particular error to a warning would be great, but eliminating 
the call to the event loop in __del__ would be even better. I understand that's 
easier said than done, or else ProactorBasePipeTransport wouldn't be leaning on 
__del__ in the first place.

--
nosy: +lawsonjl.ornl

___
Python tracker 
<https://bugs.python.org/issue39232>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44114] Incorrect function signatures in dictobject.c

[Joe Marshall]

Change by Joe Marshall :


--
keywords: +patch
pull_requests: +24703
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/26062

___
Python tracker 
<https://bugs.python.org/issue44114>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44114] Incorrect function signatures in dictobject.c

[Joe Marshall]

New submission from Joe Marshall :

There's a couple of wrong function signatures in dictobject.c,

dictkeys_reversed and dictitems_reversed are defined as single arg functions 
like so: PyObject *(PyObject *), and are then passed around and called as 
PyCFunctions, which should be PyObject *(PyObject *self,PyObject *args). 
dictvalues_reversed is correct.

This works fine on most C compilers as the extra arg is just ignored, but on 
things that use strict function pointer type checking (e.g. webassembly), it 
crashes (and hence any of the tests that happen to use these functions fails, 
which is a surprising number)

I've got a fix in my pyodide repo, which I'll chuck in as a pull request on 
github.

--
components: Interpreter Core
messages: 393506
nosy: joemarshall
priority: normal
severity: normal
status: open
title: Incorrect function signatures in dictobject.c
type: behavior

___
Python tracker 
<https://bugs.python.org/issue44114>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Bloody rubbish

[Joe Pfeiffer]

Skip Montanaro  writes:

>>
>> Machine language is so much simpler, and you can code with just a hexpad.
>>
>
> Pshaa... All you need are front panel switches. ;-) (Yes, I had a professor
> who required is to 'key' in our programs on the front panel, of a rack
> mounted PDP-11 as I recall. Needless to say, we didn't use an assembler
> either. We just wrote raw opcodes and their arguments on paper. This was in
> the late 70s.)

That's right about whn I had to do that for one assignment (on a Nova).
Hand-assembling, toggling in, and debugging a program on the front panel
was a valuable learning exercise.  Doing it a second time wouldn't have
been helpful...

One nice thing was the computer had core memory, and the students made
an agreement as to who got which part.  You could work for a while, shut
the machine down, come back the next day, power it up, and your program
would still be there.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Bloody rubbish

[Joe Pfeiffer]

Mr Flibble  writes:

> Python is slow and significant whitespace is patently absurd.

Why am I not surprised to learn your "fast" implementation turns out to
be something other than python?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: all versions of python fail to indent after conditional statement

[Joe Pfeiffer]

It's not a bug, it's a design choice you are disagreeing with:  managing
indentation is your job, not the interpreter's.  For anything other than
an absolutely trivial three-line script, I write in an editor that does
a good job helping me manage indentation (in my case, emacs in Python
mode).

 writes:

>The following snap shot of system prompt illustrates my problem. I have
>tried 3.8, 3.92 and 3.10 with the same result. When I run in the window
>interface it doesn't even display one row of ... but does print if I hit
>return twice. I'm new to Python and was excited about learning it but am
>becoming very frustrated over a bug in such a simple conditional statement
>- please help as I would really like to master Python.
>
>Regards,
>
>Michael Terry
>
>
>
>Microsoft Windows [Version 10.0.19041.867]
>
>(c) 2020 Microsoft Corporation. All rights reserved.
>
>C:\WINDOWS\system32>py
>
>
>
>Python 3.8.8 (tags/v3.8.8:024d805, Feb 19 2021, 13:18:16) [MSC v.1928 64
>bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for
>more information.
>
>
>
>>>> dog_has_fleas=True
>
>>>> if dog_has_fleas:
>
>... print('too bad')
>
>  File "", line 2
>
>print('too bad')
>
>^
>
>IndentationError: expected an indented block
>
>>>> Microsoft Windows [Version 10.0.19041.867]
>
>
>
>
>
>Sent from [1]Mail for Windows 10
>
>
>
> References
>
>Visible links
>1. https://go.microsoft.com/fwlink/?LinkId=550986
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: name for a mutually inclusive relationship

[Joe Pfeiffer]

Ethan Furman  writes:

> On 2/24/21 1:54 PM, 2qdxy4rzwzuui...@potatochowder.com wrote:
>> Ethan Furman wrote:
>
>>> I didn't say it was a good example.  ;-)  Hopefully it gets the idea across.
>> Ditto.  ;-)
>> IMO, the whole idea of "my program has two options, and the user has
>> to
>> specify both or neither," isn't a question of whether or not the
>> argument parsing library supports it, but a question of whether or not
>> it's a good API.
>
> Like I said, at this moment I don't have a good example, only an awareness 
> that such a thing could exist and I don't know the name for it (if it has 
> one).
>
> So far I have seen that there are even fewer good use-cases than I might have 
> guessed, and that no one seems to have a name for the general idea.

Do you have a specific problem you're trying to solve?  That might help
us understand the question better.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: name for a mutually inclusive relationship

[Joe Pfeiffer]

Ethan Furman  writes:

> I'm looking for a name for a group of options that, when one is specified, 
> all of them must be specified.

I don't fully understand the question (yes, I read the part I snipped).

Why is this not just a single option?  Or is it hierarchical or
something so option 1 implies options 2 and 3, but option 2 does not
imply option 1?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Review, suggestion etc?

[Joe Pfeiffer]

Grant Edwards  writes:


> On 2020-12-18, Joe Pfeiffer  wrote:
>
>> Recursion has very limited application, but where it's the right
>> tool it's invaluable (top-down parsers, some graph algorithms...).
>> We teach it primarily because by the time a student has a good
>> handle on how to write a recursive function they understand
>> functions in general really well.
>
> Yep, there are definitly cases where it's pretty much the only right
> answer. If you try to avoid it, you end up writing what turns into a
> simulation of recursion -- and doing that correctly isn't easy.

Decades ago I had to write a binary tree search in FORTRAN IV.  It
wasn't pretty.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Review, suggestion etc?

[Joe Pfeiffer]

Bischoop  writes:

> On 2020-12-17, Dennis Lee Bieber  wrote:
>>>
>>
>>  The main concern is that you are using a RECURSIVE call. It is much
>> better for such input checking to use an ITERATIVE (loop) scheme.
>>
>>  def marriage():
>>  #loop forever
>>  while True:
>>  #get response from user
>>  maritals = input("Married: Yes/No ?").title()
>>  #if response is good, exit (break) the loop
>>  if maritals in ["Yes", "No"]: break
>>  #otherwise display error message and repeat loop
>>  print("Try again. Please respond with Yes or No")
>>  #return valid response
>>  return maritals
>>  
>>
> It makes sense for me now, better logic used here than mine. 
> I've never met that way used in * if maritals in ['Yes', No']: * ,
> it makes code elegant. 
> So it's not good to use calling function itself (recursive call), I get it 
> now.

Recursion has very limited application, but where it's the right tool
it's invaluable (top-down parsers, some graph algorithms...).  We teach
it primarily because by the time a student has a good handle on how to
write a recursive function they understand functions in general really well.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Function returns old value

[Joe Pfeiffer]

Bischoop  writes:

> On 2020-12-12, Joe Pfeiffer  wrote:
>> Bischoop  writes:
>>
>>> I've function asking question and comparing it, if is not matching 'yes'
>>> it does call itself to ask question again. The problem is that when
>>> function is called second time it returns old value or with additional
>>> else statement it returns none.
>>>
>>> Code: https://bpa.st/KVGA
>>
>> It calls itself again, but what does it return in that case?
>
> I've stated it returns old value that I've input first time, anyway
> output is also inluded in a paste but since you've asked:

Sorry, my question wasn't clear.  What I meant was, "in your return
statement, what are you returning"?

You need to be returning the value from the recursive call.

> def question():
> ask = input("Are you OK?:").lower()
> if ask != 'yes':
>   question()
>   return ask
>
>   print (question())
>
>   #output:
>   Are you OK?:no
>   Are you OK?:no
>   Are you OK?:yes
>   no
>
>   ---
>   #Another way with 'elif' statment returns none
>
>
>   def question():
>   ask = input("Are you OK?:").lower()
>   if ask != 'yes':
>   question()
>   elif ask == 'yes':
>   return ask
>
>   print (question())
>
>   #output:
>   Are you OK?:no
>   Are you OK?:yes
>   None
>
>   #Tried also nested
>   functions, same results:
>
>   def question():
>   ask = input("Are you
>   OK?:").lower()
>
>   def
>   check_question(n):
>   if ask
>   !=
>   'yes':
>   
> question()
>   
> else:
>   
> return
>   
> ask
>
>   
> m
>   
> =
>   
> check_question(ask)
>   
> print
>   
> (m)
>   
> question()
>
>   
> #output:
>   
> Are
>   
> you
>   
> OK?:no
>   
> Are
>   
> you
>   
> OK?:yes
>   
> None
>
>   

Re: Function returns old value

[Joe Pfeiffer]

Bischoop  writes:

> I've function asking question and comparing it, if is not matching 'yes'
> it does call itself to ask question again. The problem is that when
> function is called second time it returns old value or with additional
> else statement it returns none.
>
> Code: https://bpa.st/KVGA

It calls itself again, but what does it return in that case?
-- 
https://mail.python.org/mailman/listinfo/python-list

For Creatives and Developers Only

[Joe Mayami]

We are recruiting Developers, and Creatives to join our community into building 
personal portfolios, personal development skills, work on Open Source Projects, 
Devops, Collaboration, User Testing and Supports.

Community members include experts in product designs, python programming, data 
science, creative writers, graphics and designs, artificial intelligence and a 
lot more.

Link to join: https://chat.whatsapp.com/Geld8FNt4QCLGhYpA8DxkG
-- 
https://mail.python.org/mailman/listinfo/python-list

Fwd: Python 3..9.0

[Joe via Python-list]

Hi,
I just downloaded the above for Windows but am unable to get it to run.  I have 
gone to the directory and double-clicked the "python.exe" file but that just 
brings me to the command prompt.
Any suggestions as to what I am doing wrong?
Thank you.
Joe
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Use of a variable in parent loop

[Joe Pfeiffer]

Stephane Tougard  writes:

> On 2020-09-27, Stefan Ram  wrote:
>>>Is there any other instruction to end a if than pass and ensure Emacs
>>>does not break the indentation during a copy paste or an indent-region ?
>>
>>   We usually do not wish to tie our code to a defective editor.
>>   I use vi, and can assure you that there is no such restriction
>>   in a real editor.
>
> You do not answer the question. I consider that indentation alone is not
> enough to make the end of a block. It's not a question of editor and I
> had some issues with vim as well because of that.
>
> pass looks good to me to end a if block, continue is good to end a for
> block and return is good to end a def block. If that's NOT good, just
> tell me why and give me another solution to end a block who is not the
> indentation because an indentation is not good enough for me to end a
> block and it may trigger some problem when using different editors or
> tools on the code.

The language designers appear to disagree with you.

Decades ago I learned C after having first become proficient in Pascal,
and *really* didn't like the terseness of the block beginning and ending
symbols.

So, I went through a phase in which I wrote lots of macroes like
#define begin {
#define end }

and so forth.  What I discovered in fairly short order was that it made
it easier for me to read my own code, but did absolutely nothing for
either me reading other people's code, nor for them reading mine.  I
eventually concluded my best move was to just suck it up and learn to
program in the language as intended.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Where read() is documented

[Joe Pfeiffer]

Chris Green  writes:

> Stefan Ram  wrote:
>> Chris Green  writes:I can't find the documentation for
>> >read().  It's not a built-in function and it's not documented with
>> >(for example) the file type object sys.stdin.
>> 
>> |read() (asyncio.StreamReader method), 894
>> |read() (chunk.Chunk method), 1385
>> |read() (codecs.StreamReader method), 164
>> |read() (configparser.ConfigParser method), 537
>> |read() (http.client.HTTPResponse method), 1276
>> |read() (imaplib.IMAP4 method), 1291
>> |read() (in module os), 578
>> |read() (io.BufferedIOBase method), 622
>> |read() (io.BufferedReader method), 625
>> |read() (io.RawIOBase method), 621
>> |read() (io.TextIOBase method), 626
>> |read() (mimetypes.MimeTypes method), 1146
>> |read() (mmap.mmap method), 1053
>> |read() (ossaudiodev.oss_audio_device method), 1388
>> |read() (ssl.MemoryBIO method), 1024
>> |read() (ssl.SSLSocket method), 1005
>> |read() (urllib.robotparser.RobotFileParser method), 1268
>> |read() (zipfile.ZipFile method), 499
>> Index of "The Python Library Reference, Release 3.9.0a3"
>> 
>> 
> But none of those is the documentation for read(), they're just places
> that refer to read().

There is no single read() method, so there can be no single place to
find its documentation.  To take one of Stefan's examples,

https://docs.python.org/3/library/io.html?highlight=io%20bufferedreader#io.BufferedReader.read

says

read([size])
Read and return size bytes, or if size is not given or negative, until
EOF or if the read call would block in non-blocking mode.

That's the documentation.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Fwd: [BUG] missing ')' causes syntax error on next line

[Joe Pfeiffer]

Jeff Linahan  writes:
>
> See attached image.  Would be nice if it printed "SyntaxError: unbalanced
> parens" as it can difficult to see the problem if code like this is run in
> an environment that only prints the problematic line, which in this case
> the compiler is confused and one line off.

It would be indeed be nice, but it's reporting the error when it finds
it.  Suppose you were typing the program in at the console -- how could
it possibly go back and report the error on the previous line?  Given
python's syntax, does the error even really exist yet on that
previous line?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: FW: Pycharm Won't Do Long Underscore

[Joe Pfeiffer]

"Peter J. Holzer"  writes:

> On 2020-06-24 15:33:16 -0600, Joe Pfeiffer wrote:
>> One other note -- while you may want various good-looking fonts with
>> ligatures in other domains, for writing code a monospace font with no
>> ligatures lets you see exactly what's there and saves a host of
>> problems.  My personal favorite for these purposes is called "Terminus
>> Regular", but which specific one you pick is much less important than
>> that you use one.
>
> I agree. Although there are some fonts with special ligatures for
> programming. I have never used one, but that seems like an interesting
> concept.

I've never heard of that before.  I'd be curious to try one.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: FW: Pycharm Won't Do Long Underscore

[Joe Pfeiffer]

One other note -- while you may want various good-looking fonts with
ligatures in other domains, for writing code a monospace font with no
ligatures lets you see exactly what's there and saves a host of
problems.  My personal favorite for these purposes is called "Terminus
Regular", but which specific one you pick is much less important than
that you use one.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue39661] TimedRotatingFileHandler doesn’t handle DST switch with daily rollover

[Joe Cool]

Joe Cool  added the comment:

Never mind. I was looking for the DST code in computeRollover, and I found it 
in doRollover.

--
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue39661>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39661] TimedRotatingFileHandler doesn’t handle DST switch with daily rollover

[Joe Cool]

New submission from Joe Cool :

TimedRotatingFileHandler doesn’t handle the switch to/from DST when using 
daily/midnight rotation. It does not adjust the rollover time so the rollover 
will be off by an hour. 

Parameters: when=‘midnight’, utc=False

--
components: Library (Lib)
messages: 362140
nosy: snoopyjc
priority: normal
severity: normal
status: open
title: TimedRotatingFileHandler doesn’t handle DST switch with daily rollover
type: behavior
versions: Python 3.7

___
Python tracker 
<https://bugs.python.org/issue39661>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39196] json fails to encode dictionary view types

[Joe Gordon]

New submission from Joe Gordon :

Python 3 fails to encode dictionary view objects. Assuming this is an expected 
behavior, what is the thinking behind it? I was unable to find any 
documentation around this.

> import json; json.dumps({}.values())
"TypeError: Object of type dict_values is not JSON serializable"

--
components: Library (Lib)
messages: 359212
nosy: jogo
priority: normal
severity: normal
status: open
title: json fails to encode dictionary view types
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue39196>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37270] Manage memory lifetime for all type-related objects.

[Joe Jevnik]

Change by Joe Jevnik :


--
keywords: +patch
pull_requests: +13925
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/14066

___
Python tracker 
<https://bugs.python.org/issue37270>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37270] Manage memory lifetime for all type-related objects.

[Joe Jevnik]

New submission from Joe Jevnik :

When using PyType_FromSpec, the memory for PyType_Spec.name, Py_tp_methods, and 
Py_tp_members needs to somehow outlive the resulting type. This makes it hard 
to use this interface to generate types without just leaking the memory for 
these arrays, which is bad if you are programatically creating short-lived 
types.

I posted about this on capi-sig, and the response seemed to be that it would be 
to replace the things that currently hold pointers into the array with copies 
of the data.

Remove internal usages of PyMethodDef and PyGetSetDef.

For PyMethodDef, change PyCFunctionObject to replace the PyMethodDef* member
with a PyCFunctionBase member. The PyCFunctionBase is a new struct to hold the
managed values of a PyMethodDef. This type is shared between PyCFunction and the
various callable descriptor objects. A PyCFunctionBase is like a PyMethodDef but
replaces the char* members with PyObject* members.

For PyGetSetDef, inline the members on the resulting PyGetSetDescrObject,
replacing all char* members with PyObject* members. The memory for the closure
is *not* managed, adding support for that would likely require an API change and
can be done in a future change.

For the tp_name field, instead of setting it directly to the value of
PyType_Spec.name, set it to the result of PyUnicode_AsUTF8(ht_name), where
ht_name is the PyUnicode object created from the original spec name. This is the
same trick used to properly manage this pointer for heap types when the __name__
is reassigned.

--
components: Extension Modules
messages: 345539
nosy: ll
priority: normal
severity: normal
status: open
title: Manage memory lifetime for all type-related objects.
versions: Python 3.9

___
Python tracker 
<https://bugs.python.org/issue37270>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: problem in installing packages

[Joe Pfeiffer]

Joel Goldstick  writes:

> On Wed, May 29, 2019 at 1:17 AM Sri Tharun  wrote:
>>
>> Problem not resolved.Yet
>>
>> On Wed 29 May, 2019, 6:39 AM Tharun,  wrote:
>>
>> >
>> > >>> sudo apt-get update
>> >
>> >   File "", line 1
>> >
>> > sudo apt-get update
>> >^
>> > SyntaxError: invalid syntax
>> >
>> > This was the problem
>> >
>> > Sent from Mail  for
>> > Windows 10
>
> It appears you are trying to execute a linux shell command while in
> the python repl.  exit python, and try again

And, if he is posting from the same computer as he is seeing the problem
on, it's a Windows box so neither "sudo" nor "apt-get" is going to
work anyway.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue36760] subprocess.run fails with capture_output=True and stderr=STDOUT

[Joe Borg]

New submission from Joe Borg :

Reading from 
https://docs.python.org/3/library/subprocess.html#subprocess.CompletedProcess

"""
If you ran the process with stderr=subprocess.STDOUT, stdout and stderr will be 
combined in this attribute, and stderr will be None.
"""

But, if you run `run()` with `capture_output=True`, you get the following 
exception:

"""
ValueError: stdout and stderr arguments may not be used with capture_output.
"""

So, it seems impossible to get the combined outputs of stdout and stderr with 
`run()`.

--
components: Library (Lib)
messages: 341158
nosy: Joe.Borg
priority: normal
severity: normal
status: open
title: subprocess.run fails with capture_output=True and stderr=STDOUT
type: behavior
versions: Python 3.7

___
Python tracker 
<https://bugs.python.org/issue36760>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36068] Make _tuplegetter objects serializable

[Joe Jevnik]

Joe Jevnik  added the comment:

Thank you for reviewing this so quickly!

--

___
Python tracker 
<https://bugs.python.org/issue36068>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36068] Make _tuplegetter objects serializable

[Joe Jevnik]

Change by Joe Jevnik :


--
keywords: +patch
pull_requests: +12006
stage:  -> patch review

___
Python tracker 
<https://bugs.python.org/issue36068>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36068] Make _tuplegetter objects serializable

[Joe Jevnik]

New submission from Joe Jevnik :

The new _tuplegetter objects for accessing fields of a namedtuple are no longer 
serializable with pickle. Cloudpickle, a library which provides extensions to 
pickle to facilitate distributed computing in Python, depended on being able to 
pickle the members of namedtuple classes. While property isn't serializable, 
cloudpickle has support for properties allowing us to serialize the old 
property(itemgetter) members.

The attached PR adds a __reduce__ method to _tuplegetter objects which will 
allow serialization without special support. Another option would be to expose 
`index` as a read-only attribute, allowing cloudpickle or other libraries to 
provide the pickle implementation as a third-party library.

--
components: Library (Lib)
messages: 336251
nosy: ll
priority: normal
severity: normal
status: open
title: Make _tuplegetter objects serializable
type: enhancement
versions: Python 3.8

___
Python tracker 
<https://bugs.python.org/issue36068>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Why float('Nan') == float('Nan') is False

[Joe Pfeiffer]

Chris Angelico  writes:
>
> Or even better, use None instead of nan. There's nothing in Python
> says you have to (ab)use a floating-point value as a signal. Or use
> "while True" and add a break if the exception isn't thrown.

Good point.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why float('Nan') == float('Nan') is False

[Joe Pfeiffer]

ast  writes:

> Le 13/02/2019 à 14:21, ast a écrit :
>> Hello
>>
>>  >>> float('Nan') == float('Nan')
>> False
>>
>> Why ?
>>
>> Regards
>>
>
> Thank you for answers.
>
> If you wonder how I was trapped with it, here
> is the failing program.
>
>
> r = float('Nan')
>
> while r==float('Nan'):
> inp = input("Enter a number\n")
> try:
>   r = float(inp)
> except ValueError:
>   r = float('Nan')

import math
while math.isnan(r) :

will do what you're looking for.

If you're using python 3.5 or higher, you can also use math.nan instead
of float('nan').
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why float('Nan') == float('Nan') is False

[Joe Pfeiffer]

u...@speedy.net writes:

> There are more integers than odd numbers, and more odd numbers than prime
> numbers. An infinite set may be a subset of another infinite set although
> they may both have the same cardinality. Or in other words, the number of
> elements in each set is not equal. One has more elements than the other.
> AND, by induction you can also prove that the other one has more elements
> than the first one. So the number of elements in two infinite sets can't be
> equal. Even, if you compare the same set to itself.

You would expect that to be true, but it is not.  There are in fact the
same number of odd integers as integers, and the same number of primes
as integers.  Counterintuitive but true.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why float('Nan') == float('Nan') is False

[Joe Pfeiffer]

songbird  writes:

> Chris Angelico wrote:
>> On Thu, Feb 14, 2019 at 7:12 AM Test Bot  wrote:
>>>
>>> This definition of NaN is much better in mentally visualizing all the so
>>> called bizarreness of IEEE. This also makes intuitive that no 2 NaN will be
>>> equal just as no 2 infinities would be equal. I believe in a hypothesis(of
>>> my own creation) that any arithmetic on a data type of NaN would be similar
>>> to any set of operations on the set of Infinities.
>>>
>>
>> Why would no two infinities be equal? In mathematics, there's one
>> best-known infinity (aleph null, aka the number of counting numbers),
>> and many many infinities are provably equal to it. (Others are
>> provably NOT equal to it, like the number of real numbers.) There's
>> nothing wrong with saying "there are as many prime numbers as there
>> are odd numbers", or equivalently that "the size/cardinality of the
>> set of primes is equal to the size of the set of odd numbers" [1]. And
>> both Python and IEEE agree:
> ...
>> [1] I'm sure someone will point out something pedantically wrong in
>> what I said, but certainly the sets have the same cardinality.
>
>   all such proofs i have ever seen are based upon the 
> assumptions that there are infinite numbers of such
> things like primes.
>
>   this only makes sense in theory.
>
>   alas, we don't really know if the universe is infinitely
> subdivisible (as the reals seem to represent) or infinitely
> large (even if it isn't infinitely subdivisible)...  so to
> me every one of those proofs is conditional upon assumptions
> (which also drags the p = np question into such assumptions).
>
>   it's fun to think about.  :)

It doesn't depend upon assumptions, it depends on definitions and
logic.  You don't need to assume there are an infinite number of primes,
it's been proven.  It doesn't matter whether the universe is infinitely
subdivisible or infinitely large, the set of real number is (assuming
I'm interpreting your "subdivisible" correctly).  I've got no idea what
P and NP have to do with this.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why float('Nan') == float('Nan') is False

[Joe Pfeiffer]

ast  writes:

> Hello
>
 float('Nan') == float('Nan')
> False
>
> Why ?
>
> Regards

Others have given the real answer -- IEEE says so, and the people who
wrote the standard are smarter than me.  All the same, this is my take
on the reason for it:  NaN is specifically a representation for "this
has no value".  The == operator compares the values of its operands;
something that has no value can't == anything, including itself.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: 03 digression by brute force

[Joe Pfeiffer]

"Avi Gross"  writes:

> SYNOPSIS: One way to solve math puzzle by brute force. (message sent earlier 
> disappeared)
>
>  
>
> Quick note. Jack started by asking why python does not like decimal
> numbers with leading zeroes. When asked to explain, he said he was
> trying to solve word problems using python. Someone mentioned problems
> like solving SEND + MORE = MONEY and I decided to quickly write a
> function that would solve anything of that sort that only has addition
> on either side of the equals.
>
>  
>
> What amused me was that I had 25 solutions to the above when I was
> told there would be one. Closer examination showed that 24 of those
> had the ‘M’ in MONEY set to zero which the logicians claimed was not a
> sensible solution.

What amuses me is the solution to the problem that started the whole
thread had at least one number with a leading 0.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why Python don't accept 03 as a number?

[Joe Pfeiffer]

jf...@ms4.hinet.net writes:

> MRAB at 2018/12/8 UTC+8 AM10:04:51 wrote:
>> Before Python 3, a leading 0 in an integer literal would indicate an 
>> octal (base 8) number.
>
> So, the reason is historical.
>
>> The old form is now invalid in order to reduce the chance of bugs.
>
> I encounter this problem on trying to do something like this:
> eval('03 + 00 + 15')
> It takes me some efforts to get rid of those leading zeros:-(
>
> Hope someday 03 can be accepted as a valid decimal number in Python 3.
>
> Thank you for explaining.
>
> --Jach

I'd say we *really* don't want that.  We'd have old C programmers (like
me) expecting 010 to mean 8, and getting really confused...
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue34944] Update _dirnameW to accept long path names

[Joe Pamer]

Change by Joe Pamer :


--
keywords: +patch
pull_requests: +9157
stage:  -> patch review

___
Python tracker 
<https://bugs.python.org/issue34944>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34944] Update _dirnameW to accept long path names

[Joe Pamer]

New submission from Joe Pamer :

The fix for issue 32557 updated os__getdiskusage_impl to use _dirnameW for 
obtaining the parent directory of a file. This would cause a regression if the 
path exceeded 260 characters, since _dirnameW currently returns -1 if given a 
path >= MAX_PATH in length.

As suggested in the issue's comments, _dirnameW should be updated to use 
PathCchRemoveFileSpec when available (on Win8.1 or greater) to avoid throwing 
an unnecessary error on a long path.

Note:
If PathCchRemoveFileSpec isn't available, we can call through 
PathRemoveFileSpecW, which is otherwise deprecated. What's interesting there is 
that while the docs say it expects a buffer of size MAX_PATH, analysis of the 
function shows that it doesn't make assumptions about the size of the path 
other than it's less than 32k characters in length. It calls through 
PathCchRemoveFileSpec under the hood on Win8 and greater, passing in 0x8000h as 
the Cch argument. PathCchRemoveFileSpec then scans through the path for '\' via 
wcschr, stops when it hits the last one and inserts a NULL. (Analysis of 
PathRemoveFileSpecW on a Win7 VM shows that it does basically the same thing, 
and is also resilient to paths greater than MAX_PATH in length.)

--
components: Windows
messages: 327402
nosy: jopamer, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Update _dirnameW to accept long path names
versions: Python 3.8

___
Python tracker 
<https://bugs.python.org/issue34944>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32557] allow shutil.disk_usage to take a file path on Windows also

[Joe Pamer]

Joe Pamer  added the comment:

Awesome - thanks, Steve - this is all super helpful! If you're cool with it I'd 
like to stick to using _dirnameW for now, and then follow up with another set 
of PRs for the fixes you've recommended.

--

___
Python tracker 
<https://bugs.python.org/issue32557>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32557] allow shutil.disk_usage to take a file path on Windows also

[Joe Pamer]

Joe Pamer  added the comment:

Just to loop back, I updated the PR to avoid MAX_PATH and only allocate  in the 
"not a directory" case. Thanks for getting back to me so quickly!

One question, though, is that it *does* seem like MAX_PATH is still referenced 
in several places in posixmodule.c. Is the ultimate goal to remove those 
references as well?

--

___
Python tracker 
<https://bugs.python.org/issue32557>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32557] allow shutil.disk_usage to take a file path on Windows also

[Joe Pamer]

Joe Pamer  added the comment:

Got it - thanks! That sounds good to me, so I'll take a look at how other 
functions are working around MAX_PATH and update the diff to also avoid the 
copy when possible.

--

___
Python tracker 
<https://bugs.python.org/issue32557>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32557] allow shutil.disk_usage to take a file path on Windows also

[Joe Pamer]

Joe Pamer  added the comment:

Hi!

I decided to try fixing this one as a way to get acquainted with the code base. 
I went ahead and updated the backing NT C function, but please let me know if 
you'd prefer I update disk_usage as proposed.

Thanks!

--
nosy: +jopamer

___
Python tracker 
<https://bugs.python.org/issue32557>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Looking for a Scrapy cheatsheet

[Joe Gulizia]

I just goolged  for SANS Scrapy Cheatsheetthey have several


SANS.org


From: Python-list  on 
behalf of Jim 
Sent: Friday, September 14, 2018 8:15:05 AM
To: python-list@python.org
Subject: Re: Looking for a Scrapy cheatsheet

On 09/14/2018 01:27 AM, Danyelle Davis wrote:
> The one that sans provides seems pretty decent. Did you not like it?

What is sans? Do you have a url.

Thanks,  Jim

> On Thu, Sep 13, 2018 at 4:05 PM Jim  wrote:
>
>> I'm in the process of learning Scrapy. I've read through the docs and a
>> couple of tutorials, but I am getting bogged down because I can't find a
>> page/table/chart that gives a nice concise overview of the available
>> commands and methods.
>>
>> Googling hasn't found anything usable. So does anyone know of a
>> cheatsheet I can download.
>>
>> Thanks,  Jim
>>
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>


--
https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue23927] getargs.c skipitem() doesn't skip 'w*'

[Joe Jevnik]

Change by Joe Jevnik :


--
pull_requests: +7946

___
Python tracker 
<https://bugs.python.org/issue23927>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Kindness

[Joe Pfeiffer]

I notice a correlation:  the less people have interacted with Bart, the
more tolerant they are.

He once went on for *weeks* about C's (yes, this was in c.l.c) failure
to have what he regards as a "proper" for-loop.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue34078] Broken CRL functionality in ssl.py

[Joe N]

New submission from Joe N :

CRLs in ssl.py or at the documentation is broken. Specifically I think the 
documentation here is wrong: 
https://docs.python.org/3/library/ssl.html#ssl.SSLContext.load_verify_locations

Here is a stackoverflow post: 
https://stackoverflow.com/questions/51196492/how-to-use-crls-in-pyopenssl?noredirect=1#comment89407186_51196492
 

I made a very user friendly test suite of files to show how it is broken. 

Run the code in here (follow readme instructions) to see the bug.
https://github.com/nettijoe96/bugInSSL

--
assignee: christian.heimes
components: SSL
messages: 321343
nosy: Joe N, christian.heimes, docs@python
priority: normal
severity: normal
status: open
title: Broken CRL functionality in ssl.py
type: behavior
versions: Python 3.6

___
Python tracker 
<https://bugs.python.org/issue34078>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23926] skipitem() in getargs.c still supports 'w' and 'w#', and shouldn't

[Joe Jevnik]

Change by Joe Jevnik :


--
pull_requests: +7754

___
Python tracker 
<https://bugs.python.org/issue23926>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: File names with slashes [was Re: error in os.chdir]

[Joe Pfeiffer]

Mikhail V  writes:

> [Steven D'Aprano]
>
>> (The same applies to Unix/Linux systems too, of course.) But while you're
>> using Python to manipulate files, you should use Python rules, and that
>> is "always use forward slashes".
>>
>> Is that reasonable?
>>
>> Under what circumstances would a user calling open(pathname) in Python
>> need to care about backslashes?
>
> Cough cough
>
> On Windows a path is e.g.:
> C:\programs\util\
>
> So why should I use forward slashes in a Python literal?
> I don't remember any problem caused by using backslashes in paths in Python -
> are there problems?
> (Apart from the fact that Python dos not have true raw string literals)
>
> So what is reasonable about using forward slashes?
> It happens to me that I need to copy-paste real paths like 100 times
> a day into scripts - do you propose to convert to forward slashes each time?

That's what started the thread -- using backslashes caused a \a to be
interpreted as a special character instead of two characters in the
path.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Folk etymology, was Re: Python list vs google group

[Joe Pfeiffer]

Peter Otten <__pete...@web.de> writes:

> Grant Edwards wrote:
>
>> On 2018-06-18, Joe Pfeiffer  wrote:
>>> Peter Otten <__pete...@web.de> writes:
>>>
>>>> Gene Heskett wrote:
>>>>
>>>>> This biggest single thing wrong with any of those old scsi interfaces
>>>>> is the bus's 5 volt isolation diode, the designer speced a shotkey(sp)
>>>>> diode, and some damned bean counter saw the price diff and changed it
>>>>> to
>>>>
>>>> Is this a case of <https://en.wikipedia.org/wiki/Folk_etymology> ?
>>>>
>>>> https://en.wikipedia.org/wiki/Walter_H._Schottky
>>>
>>> I'm missing why the claim that management changed the spec on a diode
>>> from Schottky to conventional would be folk etymology?  Or why Gene
>>> being unsure of his spelling would?  What does any of this have to do
>>> with etymology, folk or genuine?
>> 
>> I was wondering the same thing...
>
> "folk etymology" would be the retrofitting of the exotic "Schottky" into two 
> familiar words "shot" and "key". Sometimes the writer assumes that these 
> words are somehow related to the labeled object.

This would only be a folk etymology if (1) the spelling were really
"shotkey", and (2) someone thought it was because of some tortured
derivation from "shot" and "key".

Most of the best-known examples in English are backronyms like Port
Outboard Starboard Home and For Unlawful Carnal Knowledge.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python list vs google group

[Joe Pfeiffer]

Peter Otten <__pete...@web.de> writes:

> Gene Heskett wrote:
>
>> This biggest single thing wrong with any of those old scsi interfaces is
>> the bus's 5 volt isolation diode, the designer speced a shotkey(sp)
>> diode, and some damned bean counter saw the price diff and changed it to
>
> Is this a case of  ?
>
> https://en.wikipedia.org/wiki/Walter_H._Schottky

I'm missing why the claim that management changed the spec on a diode
from Schottky to conventional would be folk etymology?  Or why Gene
being unsure of his spelling would?  What does any of this have to do
with etymology, folk or genuine?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Joe Pfeiffer]

Mikhail V  writes:

> On Mon, May 21, 2018 at 1:41 PM, Chris Lindsay via Python-list
>  wrote:
>
>> If a block of static data is large enough to start to be ugly, a common
>> approach is to load the data from some other file, in a language which is
>> designed around structured data.
>
>
> Maybe it is common in industrial applications but not in smaller production,
> and according to my observation not common at all in all occasional scripts.

It is absolutely standard in all applications that have a configuration
file.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Entering a very large number

[Joe Pfeiffer]

Steven D'Aprano  writes:

> On Mon, 26 Mar 2018 02:37:44 +0100, bartc wrote:
>
>> If I instead initialise C using 'C = int("288712...")', then timings
>> increase as follows:
>
> Given that the original number given had 397 digits and has a bit length 
> of 1318, I must admit to some curiosity as to how exactly you managed to 
> cast it to a C int (32 bits on most platforms).
>
> It is too big for an int, a long (64 bits), a long-long (128 bits) or 
> even a long-long-long-long-long-long-long-long-long-long-long-long-long-
> long-long-long (1024 bits), if such a thing even exists.
>
> So what exactly did you do?

Curiously, the first time I read the original post I also somehow
confused it with C code.  But no, the variable is named C, it isn't
written in the C language.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Entering a very large number

[Joe Pfeiffer]

bartc <b...@freeuk.com> writes:

> On 25/03/2018 15:53, Joe Pfeiffer wrote:
>> ast <n...@gmail.com> writes:
>
>>> C = int(
>>> "28871482380507712126714295971303939919776094592797"
>>> "22700926516024197432303799152733116328983144639225"
>>> "94197780311092934965557841894944174093380561511397"
>>> "4215424169339729054237110027510420801349667317"
>>> "5515285922696291677532547505856101949404200039"
>>> "90443211677661994962953925045269871932907037356403"
>>> "22737012784538991261203092448414947289768854060249"
>>> "76768122077071687938121709811322297802059565867")
>
>> After following the thread for a while...  you will, of course, simply
>> have to do a string to int conversion no matter what approach you take
>> to writing it.
>
> What, even with you write this:
>
>   C = 12
>
> ?

I'm having a hard time parsing that sentence.  If you're pointing out
that when someone writes an int of reasonable length they don't mess
with strings and explicit int conversions, of course you're right.  This
question is specficially about "very large" numbers.

>> The number is a string of digits; it has to be converted
>> to the internal representation.
>
> Which is usually done by a compiler, and it will only do it once not
> each time the line is encountered in a running program. (Although a
> compiler will also do the conversion when the line is never executed!)

If you're using compiled python, yes (though I don't really know how the
bytecode represents long numbers like this, or whether it would optimize
away the explicit int conversion).  Since it's a constant string, it
would be a *really* easy optimization.

>> Even if you write
>>
>> C =
>> 28871482380507712126714295971303939919776094592797227009265160241974323037991527331163289831446392259419778031109293496555784189494417409338056151139742154241693397290542371100275104208013496673175515285922696291677532547505856101949404200039904432116776619949629539250452698719329070373564032273701278453899126120309244841494728976885406024976768122077071687938121709811322297802059565867
>>
>> the conversion happens.
>
> But not at runtime.

If it's not in a loop, only once at runtime in any case.  Does the
interpreter save away constants as it goes, so it would only have to be
done once in any case?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Entering a very large number

[Joe Pfeiffer]

ast  writes:

> Hi
>
> I found this way to put a large number in
> a variable.
>
> C = int(
> "28871482380507712126714295971303939919776094592797"
> "22700926516024197432303799152733116328983144639225"
> "94197780311092934965557841894944174093380561511397"
> "4215424169339729054237110027510420801349667317"
> "5515285922696291677532547505856101949404200039"
> "90443211677661994962953925045269871932907037356403"
> "22737012784538991261203092448414947289768854060249"
> "76768122077071687938121709811322297802059565867")
>
> It works but is it not optimal since there is a
> string to int conversion.
>
> I was not able to put an integer directly because
> character '\' for line cut doesnt work inside an
> integer
>
> C = \
> 28871482380507712126714295971303939919776094592797\
> 22700926516024197432303799152733116328983144639225\
> ...
> 76768122077071687938121709811322297802059565867

After following the thread for a while...  you will, of course, simply
have to do a string to int conversion no matter what approach you take
to writing it.  The number is a string of digits; it has to be converted
to the internal representation.  Even if you write

C = 
28871482380507712126714295971303939919776094592797227009265160241974323037991527331163289831446392259419778031109293496555784189494417409338056151139742154241693397290542371100275104208013496673175515285922696291677532547505856101949404200039904432116776619949629539250452698719329070373564032273701278453899126120309244841494728976885406024976768122077071687938121709811322297802059565867

the conversion happens.  Of all the variations people have proposed to
try to make the number more readable, the one you started with above
seems clearest to me.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue31951] import curses is broken on windows

[joe m]

joe m <iheartpewd...@gmail.com> added the comment:

I would much prefer the curses module to be supported in newer versions  since 
I believe that curses is installed as a built in module (not sure about that).

Anyhow, thank you for your help but I have found a replacement module called 
"asciimatics" which for fills all the functions that I really need.

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31951>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31951] import curses is broken on windows

[joe m]

New submission from joe m <iheartpewd...@gmail.com>:

Importing curses on Windows install calls the following:

Traceback (most recent call last):
  File "", line 1, in 
  File "C:\Users\user 
name\AppData\Local\Programs\Python\Python36-32\lib\curses\__init__.py", line 
13, in 
from _curses import *
ModuleNotFoundError: No module named '_curses'

Importing curses as "_curses" does the same thing. I have tried the "repair" 
function and it has not worked.

--
components: Windows
messages: 305610
nosy: joe m2, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: import curses is broken on windows
versions: Python 3.6

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31951>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

IDLE help.

[Joe Wilde]

Hello,


I am having trouble getting IDLE (Python 3.6 - 64-bit) to open for Windows 10. 
When I try and run IDLE, nothing happens. It works fine for Python 2.7, but 
won't open for Python 3.6.

I have tried repairing the install but to no avail.

I'm fairly new at this kind of thing, so I don't have a lot of technical 
knowledge.


Thanks in advance,

Joe.

-- 
https://mail.python.org/mailman/listinfo/python-list

[issue31557] tarfile: incorrectly treats regular file as directory

[Joe Tsai]

Joe Tsai <joet...@google.com> added the comment:

It creates a number of nested directories only because GNU (and BSD) tar 
implicitly create missing parent directories. If you cd into the bottom-most 
folder, you will see "foo.txt".

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31557>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31557] tarfile: incorrectly treats regular file as directory

[Joe Tsai]

Joe Tsai <joet...@google.com> added the comment:

This bug is not platform specific.

I've attached a reproduction:
$ python
>>> import tarfile
>>> tarfile.open("test.tar", "r").next().isdir()
True

$ tar -tvf test.tar
-rw-rw-r-- 0/0   0 1969-12-31 16:00 
123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/foo.txt
$ tar --version
tar (GNU tar) 1.27.1

For some background, this bug was original filed against the Go standard 
library (for which I am the maintainer of the Go implementation of tar). When I 
investigated the issue, I discovered that Go was doing the right thing, and 
that the discrepancy was due to the check I pointed to earlier. The GNU tool 
indicates that this is a regular file as well.

--
Added file: https://bugs.python.org/file47188/test.tar

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31557>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31557] tarfile: incorrectly treats regular file as directory

[Joe Tsai]

New submission from Joe Tsai:

The original V7 header only allocates 100B to store the file path. If a path 
exceeds this length, then either the PAX format or GNU formats must be used, 
which can represent arbitrarily long file paths. When doing so, most tar 
writers just store the first 100B of the file path in the V7 header.

When reading, a proper reader should disregard the contents of the V7 field if 
a previous and corresponding PAX or GNU header overrode it.

This currently not the case with the tarfile module, which has the following 
check 
(https://github.com/python/cpython/blob/c7cc14a825ec156c76329f65bed0d0bd6e03d035/Lib/tarfile.py#L1054-L1057):
# Old V7 tar format represents a directory as a regular
# file with a trailing slash.
if obj.type == AREGTYPE and obj.name.endswith("/"):
obj.type = DIRTYPE

This check should be further constrained to only activate when there were no 
prior PAX or GNU records that override that value of obj.name. This check was 
the source of a bug that caused tarfile to report a regular as a directory 
because the file path was extra long, and when the tar write truncated the path 
to the first 100B, it so happened to end on a slash.

--
messages: 302778
nosy: Joe Tsai
priority: normal
severity: normal
status: open
title: tarfile: incorrectly treats regular file as directory

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31557>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28638] Optimize namedtuple creation

[Joe Jevnik]

Joe Jevnik added the comment:

I added a benchmark suite (using Victor's perf utility) to cnamedtuple. The 
results are here: https://github.com/ll/cnamedtuple#benchmarks

To summarize: type creation is much faster; instance creation and named 
attribute access are a bit faster.

--
nosy: +ll

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28638>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30859] Can't install Python for Windows 3.6.1 on multiple profiles

[Joe Jacobs]

Joe Jacobs added the comment:

So, with the feedback, i uninstalled everything and tried installing again, but 
in the %appdata% folder for both users and everything worked fine.  Both users 
have python installed.  If i run the web launcher, the first time it installs 
on the second account and subsequent running of the launcher ask me to 
uninstall or repair as expected.

I'm unable to find logs for the failed installs in the %temp% folder.  If i'm 
able to duplicate the issue, i'll open a new bug report.

Please go ahead and close this report.

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30859>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30859] Can't install Python for Windows 3.6.1 on multiple profiles

[Joe Jacobs]

Joe Jacobs added the comment:

I checked, there are no install logs.

Just realized, maybe an issue with the web installer rather than the base 
installer.

python-3.6.1-amd64-webinstall

Had downloaded this file and tried to run it.  I wouldn't even get to the 
screen that asks you to do a standard or custom install.  The only screen that 
popped up said python was already installed.

I run it now after i uninstalled and re-installed for "All Users" and i don't 
have that issue.

Are the logs for the web installer stored somewhere else?  If not, maybe i'll 
try again and see if i can replicate again.

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30859>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30859] Can't install Python for Windows 3.6.1 on multiple profiles

[Joe Jacobs]

New submission from Joe Jacobs:

Windows 7 Ultimate: SP1.  Fully pathed as of July 4th, 2017

My Windows 7 install has multiple user accounts.  The main install account is 
set up with "Administrator" privledges.

Some point in the past I had installed Python 3.6.1 on the main account.  Did 
not install for all users.  That put the python files inside the %appdata% 
folder.

I was then trying to go through the Python Minecraft book with my daughter.  We 
had logged in as my daughters login and tried to install Python 3.6.1 for her.  
Got an error stating Python was already installed, even though she couldn't 
access it for her Windows login.

Ultimately, had to uninstall Python 3.6, and reinstall for "All users".  

Would think that multiple users could install Python in their own folder 
regardless of versions that other people have installed.

--
components: Windows
messages: 297776
nosy: Joe Jacobs, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Can't install Python for Windows 3.6.1 on multiple profiles
type: behavior
versions: Python 3.6

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30859>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13349] Non-informative error message in index() and remove() functions

[Joe Jevnik]

Changes by Joe Jevnik <j...@quantopian.com>:


--
pull_requests: +1919

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue13349>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30477] tuple.index error message improvement

[Joe Jevnik]

Joe Jevnik added the comment:

As a more meta question: I have noticed that many error messages in the stdlib 
use PyErr_SetString, or choose to use the type name instead of the repr of the 
object. Is there a reason for this? I normally try to fill the error message 
with as much context as possible to make debugging easier. Is it a performance 
worry?

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30477>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30477] tuple.index error message improvement

[Joe Jevnik]

Joe Jevnik added the comment:

I agree, "%R in tuple" is enough information for me. This would also remove the 
need to manually repr the object.

--
type: enhancement -> 

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30477>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30477] tuple.index error message improvement

[Joe Jevnik]

New submission from Joe Jevnik:

The old error of tuple.index(x): x not in tuple seemed very confusing to me. It 
was also harder to quickly understand what the program was doing wrong. This 
saves people a second pass through the program under the debugger because they 
can just see what the invalid value was.

The reason I am explicitly calling repr instead of using %R is that I didn't 
want to call repr twice if I didn't need to. If people think that is fine the 
format can just be tuple.index(%R): %R not in tuple instead.

--
messages: 294516
nosy: brett.cannon, ll
priority: normal
pull_requests: 1906
severity: normal
status: open
title: tuple.index error message improvement
versions: Python 3.7

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30477>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30180] PyArg_ParseTupleAndKeywords supports required keyword only arguments

[Joe Jevnik]

New submission from Joe Jevnik:

I opened a pr to remove a line in the docs about $ needing to follow | in 
PyArg_ParseTupleAndKeywords. In practice, you can just use a $ to create 
required keyword arguments which intuitively makes sense. I was told this 
should raise a SystemError; however, you can create required keyword only 
arguments in Python so I am not sure why we would want to fail when this is 
done with PyArg_ParseTupleAndKeywords.

--
messages: 292385
nosy: ll, serhiy.storchaka
priority: normal
pull_requests: 1417
severity: normal
status: open
title: PyArg_ParseTupleAndKeywords supports required keyword only arguments

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30180>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30180] PyArg_ParseTupleAndKeywords supports required keyword only arguments

[Joe Jevnik]

Changes by Joe Jevnik <j...@quantopian.com>:


--
assignee:  -> docs@python
components: +Documentation
nosy: +docs@python

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30180>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: [ANN] New Slack Group Dedicated to learning Python

[Joe Anonimist]

On Wednesday, 22 February 2017 08:07:01 UTC+1, Joe Anonimist  wrote:
> Hello all!
> 
> Me and a few other Python enthusiasts started a Slack group dedicated to 
> learning Python. All of us know the basics of Python and our goal is to 
> acquire new skills that would help us get jobs as Python developers. Our plan 
> is to collaborate on Python projects to get experience and become Python 
> professionals.
> 
> If you are interested send me your email address and I'll send you an 
> invitation to join the group. If you have a Reddit account you can visit our 
> subreddit https://www.reddit.com/r/pystudygroup/ and PM me your mail for an 
> invitation.

Invitation sent :)
-- 
https://mail.python.org/mailman/listinfo/python-list

[ANN] New Slack Group Dedicated to learning Python

[Joe Anonimist]

Hello all!

Me and a few other Python enthusiasts started a Slack group dedicated to 
learning Python. All of us know the basics of Python and our goal is to acquire 
new skills that would help us get jobs as Python developers. Our plan is to 
collaborate on Python projects to get experience and become Python 
professionals.

If you are interested send me your email address and I'll send you an 
invitation to join the group. If you have a Reddit account you can visit our 
subreddit https://www.reddit.com/r/pystudygroup/ and PM me your mail for an 
invitation.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue29468] zipfile should catch ValueError as well as OSError to detect bad seek calls

[Joe Jevnik]

New submission from Joe Jevnik:

In zipfile.py only OSError is checked to see if seek fails:

```
def _EndRecData64(fpin, offset, endrec):
"""
Read the ZIP64 end-of-archive records and use that to update endrec
"""
try:
fpin.seek(offset - sizeEndCentDir64Locator, 2)
except OSError:
# If the seek fails, the file is not large enough to contain a ZIP64
# end-of-archive record, so just return the end record we were given.
return endrec
```

I belive that this should also catch ValueError so that other file-like objects 
may be passed to ZipFile. The particular case I ran into was passing an mmap 
object:

```
"""
$ python p.py
sys.version_info(major=3, minor=6, micro=0, releaselevel='final', serial=0)
[]
Traceback (most recent call last):
  File "p.py", line 34, in 
with mmap_shared_raw_zipfile(f.name) as zf:
  File "/usr/lib64/python3.6/contextlib.py", line 82, in __enter__
return next(self.gen)
  File "p.py", line 23, in mmap_shared_raw_zipfile
ZipFile(mm) as zf:
  File "/usr/lib64/python3.6/zipfile.py", line 1100, in __init__
self._RealGetContents()
  File "/usr/lib64/python3.6/zipfile.py", line 1163, in _RealGetContents
endrec = _EndRecData(fp)
  File "/usr/lib64/python3.6/zipfile.py", line 264, in _EndRecData
return _EndRecData64(fpin, -sizeEndCentDir, endrec)
  File "/usr/lib64/python3.6/zipfile.py", line 196, in _EndRecData64
fpin.seek(offset - sizeEndCentDir64Locator, 2)
ValueError: seek out of range
"""
from contextlib import contextmanager
import mmap
import sys
from tempfile import NamedTemporaryFile
from zipfile import ZipFile


print(sys.version_info)


@contextmanager
def mmap_shared_raw_zipfile(path):
"""Open a zipfile with mmap shared so the data can be shared in multiple
processes.

Parameters
--
path : str
The path the zipfile to open.

Notes
-
The context manager returns a :class:`zipfile.ZipFile` on enter.
"""
with open(path) as f, \
mmap.mmap(f.fileno(), 0, mmap.MAP_SHARED, mmap.PROT_READ) as mm, \
ZipFile(mm) as zf:
yield zf


with NamedTemporaryFile() as f:
ZipFile(f, mode='w').close()
print(ZipFile(f.name).infolist())


with NamedTemporaryFile() as f:
ZipFile(f, mode='w').close()
with mmap_shared_raw_zipfile(f.name) as zf:
print(zf.infolist())
```

--
components: Library (Lib)
messages: 287185
nosy: ll
priority: normal
severity: normal
status: open
title: zipfile should catch ValueError as well as OSError to detect bad seek 
calls
versions: Python 3.6

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29468>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29096] Signal Handlers reliably cause UnboundLocalErrors

[Joe Jevnik]

Joe Jevnik added the comment:

The issue appears to be in ceval.c:unicode_concatenate (or the py2 equivalent)

The code sets the local variable on the lhs to NULL before doing a potentially 
inplace append to the string. This means that if a signal is raised during the 
concat, we never hit the STORE_FAST instruction following the INPLACE_ADD so 
the local or cell still holds NULL, triggering an error.

I am not really sure what can be done to prevent the failure while still 
allowing the optimization.

--
components: +Interpreter Core
nosy: +ll
type: crash -> 

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29096>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28254] Add C API for gc.enable, gc.disable, and gc.isenabled

[Joe Jevnik]

Joe Jevnik added the comment:

I definitely could have used PyImport_Import and PyObject_Call to accomplish 
this task; however, when I looked at at the implementation of these functions 
it seemed like a lot of overhead and book keeping just to set a boolean. Since 
I was already in a C extension it would be nicer to not need to worry about 
PyObjects and ref counts just to set this value so I thought it would be nice 
to expose these small functions to users. Since this is equivalent to gc.enable 
or gc.disable I don't think there is a deep can of worms here. The only 
difference in the implementation is that it doesn't return None. There is 
already PyGC_Collect, so I figured these were just omitted because no one 
thought to add them. I don't have a burning desire to get this in, I just 
thought it would be a nice to have.

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28254>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28254] Add C API for gc.enable, gc.disable, and gc.isenabled

[Joe Jevnik]

New submission from Joe Jevnik:

I was writing an extension module that was working with weakrefs and wanted to 
ensure that the GC would not run for a block of code. I noticed that 
gc.enable/gc.disable are not exposed to C and the state of the gc is in a 
static variable so it cannot be mutated from an extension.

This change adds an easier way to access this functionality in the C api 
without going through an import or PyObject_Call.

I am wondering where to document these functions as well as PyGC_Collect. I 
didn't see that function anywhere in the docs (and didn't know about it) so I 
would like to make them more visible. My first thought was 
Doc/c-api/gcsupport.rst but this is not in service of supporting the GC, it is 
about the state of the GC itself. If that seems like a decent place I could add 
a small section at the bottom about interacting with the GC and document these 
new functions and PyGC_Collect.

I'm sorry if this is exposed elsewhere. If it is I can try to add some links to 
i

--
components: Extension Modules
files: gc-capi.patch
keywords: patch
messages: 277245
nosy: ll
priority: normal
severity: normal
status: open
title: Add C API for gc.enable, gc.disable, and gc.isenabled
versions: Python 3.7
Added file: http://bugs.python.org/file44787/gc-capi.patch

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28254>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com