[issue45517] TarFile.add skips files when tarfile name matches a directory

[Jesse Kinkead]

New submission from Jesse Kinkead :

tarfile.open has a "name" parameter that can be used to open a file for reading 
or writing in the local filesystem. The documentation is unclear what the 
purpose is if providing a "fileobj" parameter as well, but it has very 
surprising behavior when the name matches an existing directory.

Specifically, when you provide a "fileobj" for writing and provide a "name" 
that matches an existing directory, calling .add() on that directory will have 
it (and any child files) to be silently skipped.

The desired behavior is either to have the files be added (consistent with 
"name" being totally ignored), or to have it be an error to provide such a 
"name" value (either one that matches an existing directory, or to provide one 
at all when using "fileobj").

--
components: Library (Lib)
files: repro.py
messages: 404217
nosy: jkinkead
priority: normal
severity: normal
status: open
title: TarFile.add skips files when tarfile name matches a directory
versions: Python 3.8
Added file: https://bugs.python.org/file50367/repro.py

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

[issue44925] [docs] Confusing deprecation notice for typing.IO

[Jesse Rittner]

Jesse Rittner  added the comment:

@kj I'm not sure if I'll have the time, but for reference, is this what the PR 
would be raised against? 
https://raw.githubusercontent.com/python/cpython/main/Doc/library/typing.rst

--

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

[issue44925] Confusing deprecation notice for typing.IO

[Jesse Rittner]

New submission from Jesse Rittner :

The docs for typing.IO, typing.TextIO, and typing.BinaryIO include a confusing 
deprecation notice. https://docs.python.org/3/library/typing.html#typing.IO

> Deprecated since version 3.8, will be removed in version 3.12: These types 
> are also in the typing.io namespace, which was never supported by type 
> checkers and will be removed.

As per the discussion on https://github.com/python/typing/issues/834, this 
deprecation notice only refers to the typing.io package, which is confusing. It 
would be helpful to rephrase it for clarity.

--
components: Library (Lib)
messages: 399655
nosy: rittneje
priority: normal
severity: normal
status: open
title: Confusing deprecation notice for typing.IO
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9

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

[issue44275] Is there a mojibake problem rendering interactive help in the REPL on Windows?

[Jesse Silverman]

Jesse Silverman  added the comment:

As Andre noted, it is good in IDLE.
I also realize how convenient it is to read the real docs from there.
I learned a lot about the state of console programming on Windows, in and out 
of Python, but I have no problem using IDLE when on Windows.

--

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

[issue44275] Is there a mojibake problem rendering interactive help in the REPL on Windows?

[Jesse Silverman]

Jesse Silverman  added the comment:

"more.com" uses the console input codepage to decode the file, so a workaround 
is to run `chcp.com 65001` and run Python in UTF-8 mode, e.g. `py -X utf8=1`. 
Since reading non-ASCII UTF-8 is broken, you'll have to switch back to the old 
input codepage if you need to enter non-ASCII characters in an app that reads 
from the console via ReadFile or ReadConsoleA.

Confirmed that this workaround done in Windows Terminal causes all mojibake to 
immediately evaporate, leaving me with the most readable and enjoyable 
more/console experience I have ever had since first hitting a spacebar on 
MS-DOS.
(Windows Terminal and the open-sourcing of the CONSOLE code is in a three-way 
tie with open-sourcing of .Net Core and the C++ STL for changing how I feel 
about Windows.  I keep finding new reasons to love it, except for reading 
non-ASCII UTF-8 being broken which I just learned about today.)

--

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

[issue44275] Is there a mojibake problem rendering interactive help in the REPL on Windows?

[Jesse Silverman]

Jesse Silverman  added the comment:

Thank you so much Inada and Eryk and Steve!

I was one of the people who mistakenly thought that Python 3 operating in the 
new Windows Terminal was going to magically leave us sitting happily in 
completely UTF-8 compatible territory on Windows, not realizing the complex 
long-term dependencies and regressions that still remain problematic.

I had spent a lot of time paying attention to the Python 2 vs. 3 debates with 
people shouting "I don't care about Unicode!" and mistook dedication to 
preventing regressions and breakages for a lesser appreciation of the value of 
UTF-8 support.  I have been schooled.  We all want the same thing, but getting 
there on Windows from where we are at the moment remains non-trivial.

Heartfelt appreciation to all on the front lines of dealing with this complex 
and sticky situation. ❤️❤️❤️

Also, much love to those who had put in the work to have much more help than I 
realized existed even when one finds oneself isolated on a single disconnected 
machine with only the standard docs as a guide吝 -- I didn't realize the pages I 
found mojibake on even existed until this weekend.

--

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

[issue44275] Is there a mojibake problem rendering interactive help in the REPL on Windows?

[Jesse Silverman]

Jesse Silverman  added the comment:

I looked around some more and it definitely is not just one isolated instance.  
I noted a similar issue on the lines from CLASSES topic pasted here.  I think 
it is all usages of the ellipsis in the context of the help text?  Maybe also 
fancy quote marks that didn't survive the jump from ASCII to Unicode?  And some 
fancy dashes.
The theme of my day was excitement at how much more docs and help ship than I 
had realized with the most basic Python install and thus are at my fingertips 
anywhere, everywhere, internet access or not.  This mars that exuberance only 
slightly.
help> CLASSES
The standard type hierarchy
***

Below is a list of the types that are built into Python.  Extension
modules (written in C, Java, or other languages, depending on the
implementation) can define additional types.  Future versions of
Python may add types to the type hierarchy (e.g., rational numbers,
efficiently stored arrays of integers, etc.), although such additions
will often be provided via the standard library instead.

Some of the type descriptions below contain a paragraph listing
ΓÇÿspecial attributes.ΓÇÖ  These are attributes that provide access to the
...
methodΓÇÖs documentation (same as "__func__.__doc__"); "__name__"
...
dictionary containing the classΓÇÖs namespace; "__bases__" is a tuple
   containing the base classes, in the order of their occurrence in
   the base class list; "__doc__" is the classΓÇÖs documentation string,

ΓÇ£ClassesΓÇ¥.  See section Implementing Descriptors for another way

--

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

[issue44275] Is there a mojibake problem rendering interactive help in the REPL on Windows?

[Jesse Silverman]

New submission from Jesse Silverman :

I didn't know whether to file this under DOCUMENTATION or WINDOWS.
I recently discovered the joys of the interactive help in the REPL, rather than 
just help(whatever).
I was exploring the topics and noticed multiple encoding or rendering errors.
I realized I stupidly wasn't using the Windows Terminal program but the default 
console.  I addressed that and they persisted in Windows Terminal.
I upgraded from 3.9.1 to 3.9.5...same deal.

I tried running:
Set-Item -Path Env:PYTHONUTF8 -Value 1

before starting the REPL, still no dice.

I confirmed this worked in the same session:
>>> ustr2='ʑʒʓʔʕʗʘʙʚʛʜʝʞ'
>>> ustr2
'ʑʒʓʔʕʗʘʙʚʛʜʝʞ'
It does.

The help stuff that doesn't render correctly is under topic COMPARISON:
lines 20, 21 and 25 of this output contain head-scratch-inducing mystery 
characters:
help> COMPARISON
Comparisons
***

Unlike C, all comparison operations in Python have the same priority,
which is lower than that of any arithmetic, shifting or bitwise
operation.  Also unlike C, expressions like "a < b < c" have the
interpretation that is conventional in mathematics:

   comparison::= or_expr (comp_operator or_expr)*
   comp_operator ::= "<" | ">" | "==" | ">=" | "<=" | "!="
 | "is" ["not"] | ["not"] "in"

Comparisons yield boolean values: "True" or "False".

Comparisons can be chained arbitrarily, e.g., "x < y <= z" is
equivalent to "x < y and y <= z", except that "y" is evaluated only
once (but in both cases "z" is not evaluated at all when "x < y" is
found to be false).

Formally, if *a*, *b*, *c*, …, *y*, *z* are expressions and *op1*,
*op2*, …, *opN* are comparison operators, then "a op1 b op2 c ... y
opN z" is equivalent to "a op1 b and b op2 c and ... y opN z", except
that each expression is evaluated at most once.

Note that "a op1 b op2 c" doesnΓÇÖt imply any kind of comparison between
*a* and *c*, so that, e.g., "x < y > z" is perfectly legal (though
perhaps not pretty).

That is: …, …, ’

em-dash or ellipsis might be involved somehow...maybe fancy apostrophe?
My current guess is that it isn't about rendering anymore, because something 
went awry further upstream?

Thanks!

--
assignee: docs@python
components: Documentation
messages: 394817
nosy: docs@python, jessevsilverman
priority: normal
severity: normal
status: open
title: Is there a mojibake problem rendering interactive help in the REPL on 
Windows?
type: behavior
versions: Python 3.9

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

[issue43056] Use of dicts in 4.2 and 4.7 of Python tutorial a bit confusing

[Jesse Silverman]

Jesse Silverman  added the comment:

Agreed with the exception that I'd like to review whether the forward reference 
to dict in the tutorial might be better suited to people working thru the 
tutorial than the current forward reference to the real docs.

I got to take a look at Eric Matthes' excellent "Python Crash Course".  He 
avoids this by treating function definitions only after introducing both tuples 
and dicts, rather than together with simple control flow within a function.  
That would clearly be a re-org that is way out of scope of a bug report.

So, if someone compares the potential forward reference to the dict section of 
the tutorial rather than the current forward reference to the language 
reference in light of where the tutorial audience is expected to be at when 
reading this section, I am good with closing it.

--

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

[issue43034] Python tutorial misleads users about floor division behavior

[Jesse Silverman]

Jesse Silverman  added the comment:

I understand and agree with both comments.
I will confirm that a substantial number of people think -17 // 3 yields -5.0, 
so when I saw this I wondered if it reinforced that common misconception.

I was curious enough to not just confirm in the actual docs not only that -17 
// 3 == -6.0 but learned why it does so.

I would be happy to see any of Terry's three suggestions added, with the first 
one adding the most bang for the buck (if someone is surprised to see -6.0 
there, they can go look up why).

--

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

[issue43042] Delete or merge redundant tutorial sentence.

[Jesse Silverman]

Jesse Silverman  added the comment:

Yes, your takeaway was what precisely what I was getting at.  I sounded unsure 
because I was unsure.  In reality, it doesn't matter whether a different 
function is being called or one is calling itself, the current wording suggests 
that it might.

--

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

[issue43056] Use of dicts in sections 4.2 and 4.7 of Python tutorial a bit confusing

[Jesse Silverman]

New submission from Jesse Silverman :

The Python tutorial was not my first introduction to Python, but I see things 
in sections 4.2 and 4.7 that likely would have confused me a lot if it was.

In 4.2 near the end, we have great advice about how to avoid problems with 
modifying a collection while iterating thru it.

Unfortunately, it both makes use of a dict despite not having introduced it 
before at all within the tutorial (I wasn't shocked because it was NOT my first 
introduction to Python) and in fact, the .items() method which is beautifully 
explained in section 5.6, which hasn't been read yet.

I got thru it a bit shakily, and in a reference, rather than an introductory 
tutorial, it is quite literally impossible to present everything in a strict 
sequence, but I would definitely have been thrown for a loop if it was actually 
my first introduction to Python.

All was good again until I got to section 4.7.2, where I was again glad I had 
previously consumed tutorial materials concerning dict.  There is a forward 
reference to:
https://docs.python.org/3.9/library/stdtypes.html#typesmapping

Which every Python programmer should undoubtedly be familiar with eventually, 
but "why not?" to the more novice-friendly:
https://docs.python.org/3.9/tutorial/datastructures.html#dictionaries

The forward reference from this section to tuples in section 5 of the tutorial 
suggests that this might have been appropriate as well.

The dict, the tuple and parameter passing are all very basic topics indeed, but 
I would have found 4.7 very rough going if I had no prior exposure to dict and 
tuple.

This isn't a complaint demanding a refund for the cost of the tutorial, so much 
as an indication of where I think true novices attempting to follow the 
tutorial in sequence would likely be thrown for a loop.  I understand there is 
a healthy ecosystem of free and paid introductory tutorial material for Python, 
as evidenced by the fact that I was only working thru the tutorial just now, 
having been referred to it as a pre-req for other material I will be moving on 
to soon.

--
assignee: docs@python
components: Documentation
messages: 385870
nosy: docs@python, jessevsilverman
priority: normal
severity: normal
status: open
title: Use of dicts in sections 4.2 and 4.7 of Python tutorial a bit confusing
versions: Python 3.9

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

[issue43043] Python tutorial could make rules for default argument definition clearer

[Jesse Silverman]

New submission from Jesse Silverman :

I love the tutorial, but have been pointing out things I only knew from brutal 
experience, other tutorials, reasoning from other languages I know better, or 
looking things up.  I only mention them if they seem in scope and at the same 
level of the material which is presented.

Regarding 4.7.1. Default Argument Values of the excellent Python tutorial:

I guessed that I would see the behavior shown below from my understanding of 
default arguments in several other languages.  I did not read anything in this 
tutorial section that would lead me to conclude this, and other things 
mentioned in this section are neither much more or less subtle, more or less 
obvious, or more or less important.

PS F:\PythonCode> py VarArgs.py
  File "F:\PythonCode\VarArgs.py", line 1
def varArgs(quote, footnote='', times):
 ^
SyntaxError: non-default argument follows default argument

Most introductions to default argument definition in other languages go out of 
their way to highlight that the default parameters can be only the last N of 
them, and that all required ones must come first.
Python is intended to be accessible to people no more clever than the other 
languages intend, so tho it seems obvious to me that they must only come after 
all required arguments, I remember when it was not obvious (and fortunately the 
tutorials I read in the past for other languages belabored the point).

The explanatory text of:
giving one of the optional arguments: ask_ok('OK to overwrite the file?', 2)

as it merely says "one of", rather than "the first of" led me to wonder if 
Python was somehow more flexible/better at mind-reading than the languages I 
already know well that require all default args to be trailing, and to only let 
you default the last one, two, or ... N.  The results of the experiment shown 
above demonstrate it is similar to the behavior in other languages in this 
regard.

I deeply appreciate the information about when the default arguments get 
evaluated, which is highly relevant and is not something I would have picked up 
on from other languages I've used.

A simple line stating that "any default arguments must follow any required 
arguments in the definition" and something like "on calls, optional arguments 
may only be omitted from the end of the parameter list, they can't simply be 
skipped" would be awesome.

I am not sure whether or not this is made perfectly clear in the next section, 
which has a lot of other new and interesting ideas flying around in it as well, 
besides this one.

--
assignee: docs@python
components: Documentation
messages: 385813
nosy: docs@python, jessevsilverman
priority: normal
severity: normal
status: open
title: Python tutorial could make rules for default argument definition clearer
versions: Python 3.9

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

[issue43042] tutorial ambiguous about creation of local symbol table for recursive calls

[Jesse Silverman]

New submission from Jesse Silverman :

In section 4.6 of the tutorial, we find:

"When a function calls another function, a new local symbol table is created 
for that call."

Now, perhaps because we were just looking at a function that people will often 
ask you to write both recursively and non-recursively and then ask which one 
you would use and why...I was thinking "Wait -- when a function calls itself 
recursively, obviously they need a new local symbol table or local variables 
won't work??"

I may be confused, in which case the doc is fine and I personally need to 
better understand the moral equivalent of activation record / stack frame in 
Python.

If I am not, given that recursion isn't much more computer science oriented or 
obscure than Fibonacci sequences, could it not be worth the investment of a few 
extra words as:

"When a function calls another function, or calls itself recursively, a new 
local symbol table is created for that call."

--
assignee: docs@python
components: Documentation
messages: 385800
nosy: docs@python, jessevsilverman
priority: normal
severity: normal
status: open
title: tutorial ambiguous about creation of local symbol table for recursive 
calls
versions: Python 3.9

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

[issue43034] Python tutorial misleads users about floor division behavior

[Jesse Silverman]

New submission from Jesse Silverman :

I had never worked thru the Python tutorial, it's kind of awesome.

I noticed multiple independent presenters incorrectly describe the behavior of 
floor division when the signs of the operands don't match.  Not just sloppy 
ones, some who are usually pretty careful -- people forget.  I found it odd.

Today I read:
https://docs.python.org/3.9/tutorial/introduction.html#using-python-as-a-calculator
'Division (/) always returns a float. To do floor division and get an integer 
result (discarding any fractional result) you can use the // operator; to 
calculate the remainder you can use %:'

I know what they mean (there will never be a non-zero fractional component in 
the result) however, stating that it "discards any fraction result" explicitly 
suggests that it will round towards zero for all results.  The name of the 
operator tells us the true story, as does a test, it rounds towards negative 
infinity for all results.

Hopefully all the people using Python to treat cancer, fly to Mars and run 
power plants know what the behavior is.  However, anecdotally, I have seen 
evidence that generally cautious, fairly-detail oriented programmers seem to 
forget the details of the behavior, this is one place in the docs from which 
many people first learn about the floor division operator and this page would 
lead me to believe it operates differently than it does in reality.

If the words right there don't get changed, or the example of -10/3 doesn't get 
added, would this be a good excuse for a third footnote?  I would actually wish 
for both the wording to be changed and to show an example like -10 / 3, tho 
admittedly I came from an Engineering background so I am always worried 
someone's going to blow up somewhere...

Deepest regards for everyone who gets to regularly close the complaints about 
floor division working as designed and documented -- but not quite documented 
on this page which more people may read than others covering the operator.

--
assignee: docs@python
components: Documentation
messages: 385746
nosy: docs@python, jessevsilverman
priority: normal
severity: normal
status: open
title: Python tutorial misleads users about floor division behavior
versions: Python 3.9

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

[issue6721] Locks in the standard library should be sanitized on fork

[Jesse Farnham]

Change by Jesse Farnham :


--
nosy: +jesse.farnham

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

[issue22652] Add suggestion about keyword arguments to this error message: "builtins.TypeError: my_func() takes 1 positional argument but 2 were given"

[A. Jesse Jiryu Davis]

A. Jesse Jiryu Davis  added the comment:

If the patch requires a rewrite and its value is uncertain then I'll excuse 
myself from this issue.

--

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

Re: Embedding Python in C

[Jesse Ibarra]

On Tuesday, July 23, 2019 at 2:20:45 PM UTC-6, Stefan Behnel wrote:
> Jesse Ibarra schrieb am 22.07.19 um 18:12:
> > On Saturday, July 20, 2019 at 1:11:51 PM UTC-6, Stefan Behnel wrote:
> >> Jesse Ibarra schrieb am 20.07.19 um 04:12:
> >>> Sorry, I am not understanding. Smalltlak VW 8.3 does not support Python.
> >>> I can only call Pyhton code through C/Python API.
> >>
> >> Ok, but that doesn't mean you need to write code that uses the C-API of
> >> Python. All you need to do is:
> >>
> >> 1) Start up a CPython runtime from Smalltalk (see the embedding example I
> >> posted) and make it import an extension module that you write (e.g. using
> >> the "inittab" mechanism [1]).
> >>
> >> 2) Use Cython to implement this extension module to provide an interface
> >> between your Smalltalk code and your Python code. Use the Smalltalk C-API
> >> from your Cython code to call into Smalltalk and exchange data with it.
> >>
> >> Now you can execute Python code inside of Python and make it call back and
> >> forth into your Smalltalk code, through the interface module. And there is
> >> no need to use the Python C-API for anything beyond step 1), which is about
> >> 5 lines of Python C-API code if you write it yourself. Everything else can
> >> be implemented in Cython and Python.
> >>
> >> Stefan
> >>
> >>
> >> [1]
> >> https://docs.python.org/3/extending/embedding.html?highlight=PyImport_appendinittab#extending-embedded-python
> > 
> > This cleared so much @Stefan, thank you. I just need some clarification if 
> > you don't mind.
> >  
> > In (1), when you say  "import an extension module that you write",  do you 
> > mean the Python library that was created "import emb"? Is that gonna be 
> > written in Cython or standalone .C file?
> 
> Yes. In Cython.
> 
> 
> > in (2), what do to mean when you said "Use the Smalltalk C-API from your 
> > Cython code to call into Smalltalk and exchange data with it."? 
> 
> Not sure what part exactly you are asking about, but you somehow have to
> talk to the Smalltalk runtime from your Cython/Python code if you want to
> interact with it. I assume that this will be done through the C API that
> Smalltalk provides.
> 
> Just in case, did you check if there is already a bridge for your purpose?
> A quick web search let me find this, not sure if it helps.
> 
> https://github.com/ObjectProfile/PythonBridge
> 
> Stefan

Yes, I think that can be done through the "inittab" mechanism  you recommended. 
I will try it. 

Yes, I trying to implement the same thing as shown in the GitHub link but 
instead of Pharo I will use VisualWorks IDE

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

Re: Embedding Python in C

[Jesse Ibarra]

On Saturday, July 20, 2019 at 1:11:51 PM UTC-6, Stefan Behnel wrote:
> Jesse Ibarra schrieb am 20.07.19 um 04:12:
> > Sorry, I am not understanding. Smalltlak VW 8.3 does not support Python.
> > I can only call Pyhton code through C/Python API.
> 
> Ok, but that doesn't mean you need to write code that uses the C-API of
> Python. All you need to do is:
> 
> 1) Start up a CPython runtime from Smalltalk (see the embedding example I
> posted) and make it import an extension module that you write (e.g. using
> the "inittab" mechanism [1]).
> 
> 2) Use Cython to implement this extension module to provide an interface
> between your Smalltalk code and your Python code. Use the Smalltalk C-API
> from your Cython code to call into Smalltalk and exchange data with it.
> 
> Now you can execute Python code inside of Python and make it call back and
> forth into your Smalltalk code, through the interface module. And there is
> no need to use the Python C-API for anything beyond step 1), which is about
> 5 lines of Python C-API code if you write it yourself. Everything else can
> be implemented in Cython and Python.
> 
> Stefan
> 
> 
> [1]
> https://docs.python.org/3/extending/embedding.html?highlight=PyImport_appendinittab#extending-embedded-python

This cleared so much @Stefan, thank you. I just need some clarification if you 
don't mind.
 
In (1), when you say  "import an extension module that you write",  do you mean 
the Python library that was created "import emb"? Is that gonna be written in 
Cython or standalone .C file?

in (2), what do to mean when you said "Use the Smalltalk C-API from your Cython 
code to call into Smalltalk and exchange data with it."? 

Please advise,

Thank you so much for your help.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Embedding Python in C

[Jesse Ibarra]

Sorry, I am not understanding. Smalltlak VW 8.3 does not support Python. I can 
only call Pyhton code through C/Python API.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Embedding Python in C

[Jesse Ibarra]

On Friday, July 19, 2019 at 8:17:43 AM UTC-6, Chris Angelico wrote:
> On Sat, Jul 20, 2019 at 12:16 AM Jesse Ibarra
>  wrote:
> >
> > On Thursday, July 18, 2019 at 2:01:39 PM UTC-6, Chris Angelico wrote:
> > > On Fri, Jul 19, 2019 at 5:51 AM Christian Gollwitzer  
> > > wrote:
> > > > Once you can do this, you can proceed to call a Python function, which
> > > > in C means that you invoke the function PyObject_CallObject(). A basic
> > > > example is shown here:
> > > >
> > > > https://docs.python.org/2/extending/embedding.html#pure-embedding
> > > >
> > >
> > > Or, better:
> > >
> > > https://docs.python.org/3/extending/embedding.html#pure-embedding
> > >
> > > ChrisA
> >
> > I need to call a .so file, but I don't know I way to do that with PyObject. 
> > I can only seem to bring in .py files
> 
> I have vastly insufficient context to be able to even attempt to answer this.
> 
> ChrisA

Thank you for your help.

If this helps. I need PyImport_Import to bring in a C shared lib. (.so file)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Embedding Python in C

[Jesse Ibarra]

On Thursday, July 18, 2019 at 1:46:05 PM UTC-6, Christian Gollwitzer wrote:
> Am 18.07.19 um 16:18 schrieb Jesse Ibarra:
> > On Wednesday, July 17, 2019 at 2:20:51 PM UTC-6, Christian Gollwitzer wrote:
> >> What level of integration do you want to achieve? Do you want
> >>
> >> a) to call Python functions from Smalltalk
> >> b) call Smalltalk functions from Python
> >> c) pass callbacks around, e.g. use a Smalltalk function within a Python
> >> list comprehension, and if so, which way
> >> d) integrate the class systems - derive a Python class from a Smalltalk
> >> base or the other way round
> >>
> 
> > 
> > For right now, I need to call a .so file from Smalltalk. I can't explicitly 
> > use Python libraries since Smalltalk does not support Python. I need to use 
> > the C/Python API (in Smalltalk) to create a bridge where I can call a .so 
> > and a function in that .so file with a PyObject (This will be called back 
> > to Smalltalk from the .so file). I can't figure out a way to do that since 
> > the C/API can't call C or .so files.
> > 
> > sorry for the confusion on my part
> > 
> 
> I still don't get it, sorry. To me it is unclear which part of the 
> integration you manage to do so far, and which part is the problem.
> 
> Which Smalltalk interpreter are you using? The answer to the following 
> will heavily depend on that.
> 
> 
> Suppose I'd give you a C file with the following simple function:
> 
> 
> double add(double a, double b) {
>   return a+b;
> }
> 
> Do you know how to compile this code and make it usable from Smalltalk?
> 
> One level up, consider a C function working on an array:
> 
> double arrsum(int n, double *arr) {
>   double sum=0.0;
>   for (int i=0; i   return sum;
> }
> 
> 
> How would you compile and link this with your Smalltalk implementation, 
> such that you can pass it a Smalltalk array?
> 
> Once you can do this, you can proceed to call a Python function, which 
> in C means that you invoke the function PyObject_CallObject(). A basic 
> example is shown here:
> 
> https://docs.python.org/2/extending/embedding.html#pure-embedding
> 
>   Christian

I am using Visualworks 8.3. I can write that double arrsum function in 
Smalltalk. No Problem.

I can also make shared library and bring those function into Smalltalk with C 
(Since VW 8.3 supports C and C types). No Problem.

Smalltalk does not support Python. So I can use C/API to bring in Python 
libs,types and files. No Problem

Now ,I need to bring in shared libraries using C/Python API using Smalltalk. It 
seems like I can't directly bring in C shared libraries (.so files). PROBLEM.

HOW CAN I BRING THESE IN DIRECTLY?

Why do I want to call a C shared lib (.so file) using C/Python API from 
Smalltalk?

Because I want to make C shared libs that bring in individual Python libraries 
into Smalltalk, such as as (Scipy,NumPy,etc). That can be called using that 
C/Python API in Smalltalk


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

Re: Embedding Python in C

[Jesse Ibarra]

On Thursday, July 18, 2019 at 2:01:39 PM UTC-6, Chris Angelico wrote:
> On Fri, Jul 19, 2019 at 5:51 AM Christian Gollwitzer  wrote:
> > Once you can do this, you can proceed to call a Python function, which
> > in C means that you invoke the function PyObject_CallObject(). A basic
> > example is shown here:
> >
> > https://docs.python.org/2/extending/embedding.html#pure-embedding
> >
> 
> Or, better:
> 
> https://docs.python.org/3/extending/embedding.html#pure-embedding
> 
> ChrisA

I need to call a .so file, but I don't know I way to do that with PyObject. I 
can only seem to bring in .py files
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Embedding Python in C

[Jesse Ibarra]

On Wednesday, July 17, 2019 at 2:20:51 PM UTC-6, Christian Gollwitzer wrote:
> Am 17.07.19 um 20:39 schrieb Jesse Ibarra:
> > My options seem rather limited, I need to make a Pipeline from (Smalltalk 
> > -> C -> Python) then go back (Smalltalk <- C <- Python). Since Smalltalk 
> > does not support Python directly I have to settle with the C/Python API 
> > (https://docs.python.org/3.6/extending/embedding.html#beyond-very-high-level-embedding-an-overview).
> >  Any suggestions?
> > 
> 
> Ah, now you finally tell us your problem!
> 
> Depending on, how complete / advanced / efficient the bridge needs to 
> be, it can be easy or hard.
> 
> What level of integration do you want to achieve? Do you want
> 
> a) to call Python functions from Smalltalk
> b) call Smalltalk functions from Python
> c) pass callbacks around, e.g. use a Smalltalk function within a Python 
> list comprehension, and if so, which way
> d) integrate the class systems - derive a Python class from a Smalltalk 
> base or the other way round
> 
> e) ?
> 
> 
> The most basic thing is a), but even getting that right might be 
> non-trivial, since both C APIs will have different type systems which 
> you need to match. I don't speak Smalltalk, so can't comment in detail 
> on this - but in practice it will also depend on the implementation you 
> are using.
> 
> Best regards,
> 
>   Christian

For right now, I need to call a .so file from Smalltalk. I can't explicitly use 
Python libraries since Smalltalk does not support Python. I need to use the 
C/Python API (in Smalltalk) to create a bridge where I can call a .so and a 
function in that .so file with a PyObject (This will be called back to 
Smalltalk from the .so file). I can't figure out a way to do that since the 
C/API can't call C or .so files.

sorry for the confusion on my part
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Embedding Python in C

[Jesse Ibarra]

On Wednesday, July 17, 2019 at 11:55:28 AM UTC-6, Barry Scott wrote:
> > On 17 Jul 2019, at 16:57,  wrote:
> > 
> > I am using Python3.6:
> > 
> > [jibarra@redsky ~]$ python3.6
> > Python 3.6.8 (default, Apr 25 2019, 21:02:35) 
> > [GCC 4.8.5 20150623 (Red Hat 4.8.5-36)] on linux
> > Type "help", "copyright", "credits" or "license" for more information.
> > 
> > 
> > I am 
> > referencing:https://docs.python.org/3.6/extending/embedding.html#beyond-very-high-level-embedding-an-overview
> > 
> > Is there a way to call a shared C lib using PyObjects?
> 
> If what you want to call is simple enough then you can use the ctypes library
> that ships with python.
> 
> If the code you want to call is more complex you will want to use one of a 
> number of libraries to help
> you create a module that you can import.
> 
> I use PyCXX for this purpose that allows me to write C++ code that can call 
> C++ and C libs and interface
> easily with python. Home page http://cxx.sourceforge.net/ 
>  the source kit contains demo code that you shows
> how to cerate a module, a class and function etc. 
> 
> Example code: 
> https://sourceforge.net/p/cxx/code/HEAD/tree/trunk/CXX/Demo/Python3/simple.cxx
>  
> 
> 
> Barry
> PyCXX maintainer
> 
> > 
> > Please advise.
> > 
> > Thank you.
> > -- 
> > https://mail.python.org/mailman/listinfo/python-list
> >

My options seem rather limited, I need to make a Pipeline from (Smalltalk -> C 
-> Python) then go back (Smalltalk <- C <- Python). Since Smalltalk does not 
support Python directly I have to settle with the C/Python API 
(https://docs.python.org/3.6/extending/embedding.html#beyond-very-high-level-embedding-an-overview).
 Any suggestions?
-- 
https://mail.python.org/mailman/listinfo/python-list

Embedding Python in C

[jesse . ibarra . 1996]

I am using Python3.6:

[jibarra@redsky ~]$ python3.6
Python 3.6.8 (default, Apr 25 2019, 21:02:35) 
[GCC 4.8.5 20150623 (Red Hat 4.8.5-36)] on linux
Type "help", "copyright", "credits" or "license" for more information.


I am 
referencing:https://docs.python.org/3.6/extending/embedding.html#beyond-very-high-level-embedding-an-overview

Is there a way to call a shared C lib using PyObjects?

Please advise.

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

[issue37241] Item Count Error in Shelf

[Jesse Bacon]

Change by Jesse Bacon :


--
resolution:  -> third party

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

[issue37241] Item Count Error in Shelf

[Jesse Bacon]

Jesse Bacon  added the comment:

I was using anaconda distribution on OSX.  It failed for 3.6 and 3.7.  I pulled 
off anaconda and compiled from source and the script executed correctly 
regardless of whether or not "--enable-optimizations" was set.  Anaconda claims 
to be geared towards scientists so this is alarming.  Thank you for your time.

--

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

[issue37241] Item Count Error in Shelf

[Jesse Bacon]

Jesse Bacon  added the comment:

Eric,

The interpreter said something about passing a negative value when I converted 
the db.keys to a list.  I have attached a script in txt format and a Jupyter 
notebook for further analysis.  I apologize for posting images,  I just saw 
your note.  I'll go ahead and look at the shelve source while you determine if 
this information is sufficient. Thank you for your time.

--

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

[issue37241] Item Count Error in Shelf

[Jesse Bacon]

Change by Jesse Bacon :


Added file: https://bugs.python.org/file48415/pbr37241_Jesse_Bacon.py.txt

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

[issue37241] Item Count Error in Shelf

[Jesse Bacon]

Change by Jesse Bacon :


Added file: https://bugs.python.org/file48414/Python Proof.ipynb

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

[issue37241] Item Count Error in Shelf

[Jesse Bacon]

Change by Jesse Bacon :


Added file: https://bugs.python.org/file48413/ShelfKeys.png

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

[issue37241] Item Count Error in Shelf

[Jesse Bacon]

Jesse Bacon  added the comment:

I am missing keys, when extracting the data back out with todays NVD pull.
---
KeyError  Traceback (most recent call last)
~/anaconda3/lib/python3.6/shelve.py in __getitem__(self, key)
110 try:
--> 111 value = self.cache[key]
112 except KeyError:

KeyError: 'CVE-2019-1842'

During handling of the above exception, another exception occurred:

KeyError  Traceback (most recent call last)
 in 
  1 results = []
  2 for x in raw_cves:
> 3 results.append(db[x])

~/anaconda3/lib/python3.6/shelve.py in __getitem__(self, key)
111 value = self.cache[key]
112 except KeyError:
--> 113 f = BytesIO(self.dict[key.encode(self.keyencoding)])
114 value = Unpickler(f).load()
115 if self.writeback:

KeyError: b'CVE-2019-1842'

--

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

[issue37241] Item Count Error in Shelf

[Jesse Bacon]

New submission from Jesse Bacon :

I have loaded the National Vulnerability Database from NIST for 2019 and it 
includes 3989 JSON Documents.  This data I have placed in a shelf.  when I run 
len(db.keys()) I get 3658.  len(set(cves)) == 3989 : True

When I extract the data from the shelf I have the right amount of records, 
3989.  I tested on python 3.7.3 and Python 3.6.5.  I am concerned this is going 
to ruin a metric in a security report.  For example, A risk exposure report may 
use the number of keys in a yearly vulnerability db as the baseline for a risk 
calculation which contrasts the number of patched CVE's.  

nvdcve-1.0-2019.json

--
components: Library (Lib)
files: KeyCount.png
messages: 345290
nosy: jessembacon
priority: normal
severity: normal
status: open
title: Item Count Error in Shelf
type: behavior
versions: Python 3.6, Python 3.7
Added file: https://bugs.python.org/file48411/KeyCount.png

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

[issue29699] shutil.rmtree should not fail with FileNotFoundError (race condition)

[Jesse Farnham]

Change by Jesse Farnham :


--
nosy: +jesse.farnham

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

[issue36259] exception text is being sourced from the wrong file

[Jesse Farnham]

Jesse Farnham  added the comment:

Upon further digging, the filename to search for ultimately comes from the 
PyCodeObject where the error occurred. So a possible solution could be to 
populate the PyCodeObject with the absolute path to the file when it’s first 
created in compilation. Then no searching is needed and the problem doesn’t 
happen. This seems like a potentially very invasive change, though.

--

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

[issue36259] exception text is being sourced from the wrong file

[Jesse Farnham]

Jesse Farnham  added the comment:

I did some digging into this, and the problem seems to be that 
_Py_FindSourceFile() in traceback.c searches through every directory in 
sys.path (of which the first entry is the working directory) to find a file 
with the passed filename. So if there's a file in the working directory with 
name matching the filename passed in from the traceback object, 
_Py_FindSourceFile will find that one, resulting in the wrong listing being 
printed.

Does the traceback object contain any other information that would avoid the 
need to search sys.path to find the right file? If it can know the file name, 
maybe there's a way to find the file path as well?

Apologies if this is not useful -- this is my first attempt to contribute to 
Python.

--

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

[issue36259] exception text is being sourced from the wrong file

[Jesse Farnham]

Change by Jesse Farnham :


--
nosy: +jesse.farnham

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

[issue6721] Locks in the standard library should be sanitized on fork

[A. Jesse Jiryu Davis]

Change by A. Jesse Jiryu Davis :


--
nosy:  -emptysquare

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

[issue34803] argparse int type does not accept scientific notation

[Jesse Hostetler]

Jesse Hostetler  added the comment:

I suppose desired behavior would be to accept the argument only if it can be 
converted to int without loss of information.

--

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

[issue34803] argparse int type does not accept scientific notation

[Jesse Hostetler]

New submission from Jesse Hostetler :

The 'argparse' module gives a parse error for integer arguments written in 
scientific notation. I would expect this to work, since integers can be 
constructed from literals in scientific notation.

Example (also attached):

import argparse
foo = int(1e3) # Works: foo = 1000
parser = argparse.ArgumentParser()
parser.add_argument( "--foo", type=int )
parser.parse_args( ["--foo=1e3"] )
# error: argument --foo: invalid int value: '1e3'

--
components: Library (Lib)
files: argparse-int-scientific.py
messages: 326409
nosy: jessehostetler
priority: normal
severity: normal
status: open
title: argparse int type does not accept scientific notation
type: enhancement
versions: Python 3.7
Added file: https://bugs.python.org/file47824/argparse-int-scientific.py

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

[issue20886] Disabling logging to ~/.python_history is not simple enough

[Jesse Paul Ogle]

Jesse Paul Ogle  added the comment:

Greetings, I came across this issue while looking into XDG Base Directory 
Specification. This issue is only tagged with version 3.4, but the underlying 
issue (not being able to change the history file / size through environment 
variables) appears to still exist in the definiton of enablerlcompleter() in 
Lib/site.py for master. I may be wrong about that.

Tag 3.4:
https://github.com/python/cpython/blob/3.4/Lib/site.py#L423

Tag 3.7.0b5 (latest as of writing)
https://github.com/python/cpython/blob/v3.7.0b5/Lib/site.py#L436


This seems to me like a fairly straight forward fix. I made the change by 
copying enablercompleter() to a startup.py file and changing that line to the 
following:

if 'PYTHONHISTFILE' in os.environ:
history = os.path.expanduser(os.environ['PYTHONHISTFILE'])
elif 'XDG_DATA_HOME' in os.environ:
history = 
os.path.join(os.path.expanduser(os.environ['XDG_DATA_HOME']),
   'python', 'python_history')
else:
history = os.path.join(os.path.expanduser('~'),
   '.python_history')

history = os.path.abspath(history)
_dir, _ = os.path.split(history)
os.makedirs(_dir, exist_ok=True)

This enables specifying the history file via PYTHONHISTFILE or using 
XDG_DATA_HOME. XDG_DATA_HOME is convenient but not necessary as PYTHONHISTFILE 
would at least provide a work around. One could disable logging by setting 
PYTHONHISTFILE=/dev/null or whatever it is on Windows.

I apologize for not providing a patch but I have literally no idea where to 
start for that. I assume addition of environment variables requires iterating 
on the mailing list first?

--
nosy: +jesse.p.ogle

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

[issue32534] Speed-up list.insert: use memmove()

[Jesse Bakker]

Change by Jesse Bakker <jessebakke...@gmail.com>:


--
nosy: +Jesse Bakker

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

[issue29564] ResourceWarning: suggest to enable tracemalloc in the message

[Jesse Bakker]

Change by Jesse Bakker <jessebakke...@gmail.com>:


--
nosy: +Jesse Bakker

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

[issue32121] tracemalloc.Traceback.format() should have an option to reverse the traceback

[Jesse Bakker]

Jesse Bakker <jessebakke...@gmail.com> added the comment:

I can work on this if you want. Can have a PR ready in a few minutes.

--
nosy: +Jesse Bakker

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

[issue32121] tracemalloc.Traceback.format() should have an option to reverse the traceback

[Jesse Bakker]

Change by Jesse Bakker <jessebakke...@gmail.com>:


--
keywords: +patch
pull_requests: +4470
stage: needs patch -> patch review

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

[issue10049] Add a "no-op" (null) context manager to contextlib

[Jesse Bakker]

Change by Jesse Bakker <jessebakke...@gmail.com>:


--
nosy: +Jesse Bakker

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

[issue10049] Add a "no-op" (null) context manager to contextlib

[Jesse Bakker]

Change by Jesse Bakker <jessebakke...@gmail.com>:


--
pull_requests: +4397
stage: needs patch -> patch review

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

[issue10049] Add a "no-op" (null) context manager to contextlib

[Jesse Bakker]

Change by Jesse Bakker <jessebakke...@gmail.com>:


--
versions: +Python 3.8 -Python 3.2

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

[issue32042] Option for comparing values instead of reprs in doctest

[Jesse Bakker]

Jesse Bakker <jessebakke...@gmail.com> added the comment:

I think this would allow for inconsistency in docs (if implemented as 
suggested), as when actually running the code in the docs, one would get 
different results than suggested by the docs.

Maybe there is some other way (with different docs syntax) that would work 
well. Cannot think of anything from the top of my head, but maybe someone more 
creative can?

--
nosy: +Jesse Bakker

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

[issue32022] Python crashes with mutually recursive code

[Jesse Bakker]

Jesse Bakker <jessebakke...@gmail.com> added the comment:

On linux x86-64 with python 3.6.3 and python 3.7.0a2+ I get a RecursionError: 
maximum recursion depth exceeded.

--
nosy: +Jesse Bakker

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

[issue32070] Clarify the behavior of the staticmethod builtin

[Jesse SHapiro]

New submission from Jesse SHapiro <je...@jesseshapiro.net>:

It looks like the original staticmethod docstring might have been based on the 
classmethod docstring, and it seems like the current description might not be 
accurate.

Current string:

...It can be called either on the class (e.g. C.f()) or on an instance (e.g. 
C().f()); the instance is ignored except for its class...

Proposed change:

It can be called either on the class (e.g. C.f()) or on an instance (e.g. 
C().f()). Both the class and the instance are ignored, and neither is passed 
implicitly as the first argument to the method.

--
assignee: docs@python
components: Documentation
messages: 306489
nosy: docs@python, haikuginger
priority: normal
pull_requests: 4391
severity: normal
status: open
title: Clarify the behavior of the staticmethod builtin
type: enhancement

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

[issue31948] [EASY] Broken MSDN links in msilib docs

[Jesse Bakker]

Change by Jesse Bakker <jessebakke...@gmail.com>:


--
pull_requests: +4346
stage: backport needed -> patch review

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

[issue30182] Incorrect in referring to ISO as "International Standards Organization"

[Jesse Gonzalez]

Jesse Gonzalez added the comment:

PR created. CLA signed, but indicates otherwise in my account details.

--

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

[issue30182] Incorrect in referring to ISO as "International Standards Organization"

[Jesse Gonzalez]

Changes by Jesse Gonzalez <jesse.gonzalez...@gmail.com>:


--
pull_requests: +1419

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

[issue30182] Incorrect in referring to ISO as "International Standards Organization"

[Jesse Gonzalez]

New submission from Jesse Gonzalez:

When reviewing the Unicode HOWTO, I found a reference to ISO as "International 
Standards Organization", which should instead read "International Organization 
for Standardization".

https://www.iso.org/home.html

--
assignee: docs@python
components: Documentation
messages: 292389
nosy: Jesse Gonzalez, docs@python
priority: normal
severity: normal
status: open
title: Incorrect in referring to ISO as "International Standards Organization"

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

Re: Python Web Scrapping : Within href readonly those value that have href in it

[Jesse Alama]

To complement what Peter wrote: I'd approach this problem using
XPath. XPath is a query language for XML/HTML documents; it's a great
tool to have in your web scraping toolbox (among other tasks). With
Python's excellent lxml library you can do some XPath processing. Here's
how I might tackle this problem:

== [ scrape.py ] ==

from lxml import etree

# ...somehow get HTML/XML into the variable xml

root = etree.HTML(xml)

hrefs = root.xpath("//a[@href and starts-with(@href, 'http://')]/@href")

# magic =>  ^^

print(hrefs) # if you want to see what this looks like

== [ end scrape.py ] ==

The argument to the xpath method here is an XPath expression.  The
overall form is:

//a[.]/@href

The '//a' at the beginning means: starting at the root node of the
document, find all a (anchor) elements that match the condition
specified by ".".  The '/@href' at the end means: give me the href
attribute of the nodes (if any) that remain.

Looking inside the square brackets (what's known as the predicate in the
XPath world), we find

@href and starts-with(@href, 'http://')

The 'and' bit should be clear (there are two conditions that need to be
checked).  The first part says: the a element should have an href
attribute.  The second part says that the value of the href element had
better start with 'http://'.

In fact, we could simplify the predicate to

  starts-with(@href, 'http://')

If an element does not even have an href attribute, its value does not
start with 'http://'. It's not an error, and no exception will be
thrown, when the XPath evaluator applies the starts-with function to an
a element that does not have an href attribute.

Hope this helps.

Best regards,

Jesse

--
Jesse Alama
http://xml.sh
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue29112] questionable wording in sequences documentation

[Jesse Hall]

New submission from Jesse Hall:

In note 3 of 4.6.1, the word "string" should be replaced with "sequence", 
because the note is describing a general example where this concept is not 
specifically used with a string type sequence, it is discussing the general use 
of negative indexes which can be used on any type of sequence.

--
assignee: docs@python
components: Documentation
messages: 284303
nosy: Jesse Hall, docs@python
priority: normal
severity: normal
status: open
title: questionable wording in sequences documentation
versions: Python 3.6

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

[issue25924] investigate if getaddrinfo(3) on OSX is thread-safe

[A. Jesse Jiryu Davis]

A. Jesse Jiryu Davis added the comment:

Here's a retelling of this bug report as a silly fantasy saga:

https://engineering.mongodb.com/post/the-saga-of-concurrent-dns-in-python-and-the-defeat-of-the-wicked-mutex-troll/

--

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

[issue27136] sock_connect fails for bluetooth (and probably others)

[A. Jesse Jiryu Davis]

A. Jesse Jiryu Davis added the comment:

Thank you Martin!

--

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

[issue27136] sock_connect fails for bluetooth (and probably others)

[A. Jesse Jiryu Davis]

A. Jesse Jiryu Davis added the comment:

Thanks, I'm not a core dev or I'd try it myself.

Yury, do you think that's a good approach, or should I mock getaddrinfo for 
that test? I fear mocking out too much and accidentally not testing anything, 
or of making tests that someone *else* could accidentally change so they don't 
test anything.

--

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

[issue27136] sock_connect fails for bluetooth (and probably others)

[A. Jesse Jiryu Davis]

A. Jesse Jiryu Davis added the comment:

Thanks Martin. That test verifies behavior that I observe in Mac OS 10.10 and 
other modern platforms:

>>> socket.getaddrinfo('::2', 80, socket.AF_INET6, socket.SOCK_STREAM, 
>>> socket.IPPROTO_TCP)
[(30, 1, 6, '', ('::0.0.0.2', 80, 0, 0))]

Investigating, I wrote a C program to call getaddrinfo on my Mac OS X Tiger x86 
virtual machine, and indeed it resolves "::2" with family AF_INET6 in "hints" 
as an IPv4 address, "0.0.0.2". However, the same setup resolves "::1" as an 
IPv6 address, "::1".

Someone who knows more about IPv6 than I might guess the cause?

In any case, I wonder if replacing "::2" with "::1" at 
test_base_events.py:1188, and replacing the regex '::(0\.)*2' with '::(0\.)*1' 
at line 1195 would fix the test for Tiger.

Could you try that please? I'm having trouble compiling Python for Tiger so I 
don't know how to test it on my virtual machine.

--

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

[issue27136] sock_connect fails for bluetooth (and probably others)

[A. Jesse Jiryu Davis]

A. Jesse Jiryu Davis added the comment:

The asyncio fix was proposed and reviewed here:

https://github.com/python/asyncio/pull/357

--

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

[issue27136] sock_connect fails for bluetooth (and probably others)

[A. Jesse Jiryu Davis]

A. Jesse Jiryu Davis added the comment:

I can reproduce this. On Ubuntu 14.04 I installed "libbluetooth-dev" and then 
built Python 3.5.1 from source, confirmed the socket module has AF_BLUETOOTH 
and BTPROTO_RFCOMM. Running pyptr2's script gives the traceback pyptr2 reported.

Yury and I discussed a fix, which I'll propose as a patch in the asyncio GitHub 
repo.

--
nosy: +emptysquare

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

[issue16500] Add an 'atfork' module

[A. Jesse Jiryu Davis]

Changes by A. Jesse Jiryu Davis <je...@emptysquare.net>:


--
nosy: +emptysquare

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

[issue6721] Locks in the standard library should be sanitized on fork

[A. Jesse Jiryu Davis]

Changes by A. Jesse Jiryu Davis <je...@emptysquare.net>:


--
nosy: +emptysquare

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

[issue25924] investigate if getaddrinfo(3) on OSX is thread-safe

[A. Jesse Jiryu Davis]

A. Jesse Jiryu Davis added the comment:

Related to #26406, a fix for NetBSD and OpenBSD.

--

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

[issue26406] getaddrinfo is thread-safe on NetBSD and OpenBSD

[A. Jesse Jiryu Davis]

A. Jesse Jiryu Davis added the comment:

Thank you!

--

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

[issue26406] getaddrinfo is thread-safe on NetBSD and OpenBSD

[A. Jesse Jiryu Davis]

A. Jesse Jiryu Davis added the comment:

Patch uploaded.

I've copied the "nosy" list from #25924, if that was bad etiquette please 
forgive me.

--
keywords: +patch
Added file: 
http://bugs.python.org/file41998/26406-getaddrinfo-netbsd-openbsd.patch

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

[issue26406] getaddrinfo is thread-safe on NetBSD and OpenBSD

[A. Jesse Jiryu Davis]

New submission from A. Jesse Jiryu Davis:

In socketmodule.c we lock around getaddrinfo calls on platforms where 
getaddrinfo is believed not to be thread-safe. We've verified that it *is* 
thread-safe, and therefore stopped locking around it, on FreeBSD 5.3+ 
(#1288833) and Mac OS X 10.5+ (#25924). This ticket intends to do the same for 
OpenBSD and NetBSD.

OpenBSD 5.4 fixed getaddrinfo's thread safety and announced it 2013-11-01, 
"getaddrinfo(3) is now thread-safe":

http://www.openbsd.org/plus54.html

NetBSD's fix is older and less publicized. Since ancient times NetBSD's 
getaddrinfo.c included a comment, "Thread safe-ness must be checked", and the 
getaddrinfo(3) man page had the same warning as other BSDs, "The implementation 
of getaddrinfo is not thread-safe." On 2004-05-27 Christos Zoulas committed 
with the comment "make yp stuff re-entrant", fixing obvious problems like 
static variables in getaddrinfo:

http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/net/getaddrinfo.c.diff?r1=1.71=1.72_with_tag=MAIN

That change was released with NetBSD 3.0, and that alone might convince us to 
stop locking around getaddrinfo. Later, on 2006-07-18, between NetBSD 3 and 4, 
Zoulas deleted the comment "Thread safe-ness must be checked" from the source, 
with the message "Remove comments that do not reflect reality anymore":

http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/net/getaddrinfo.c.diff?r1=1.82=1.83_with_tag=MAIN

The same day, he removed the man page warning:

http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/net/getaddrinfo.3.diff?r1=1.43=1.44_with_tag=MAIN

NetBSD 4.0 was released 2007-12-19.

--
messages: 260655
nosy: emptysquare, gvanrossum, martin.panter, ned.deily, python-dev, 
ronaldoussoren, yselivanov
priority: normal
severity: normal
status: open
title: getaddrinfo is thread-safe on NetBSD and OpenBSD
versions: Python 2.7, Python 3.5, Python 3.6

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

[issue25924] investigate if getaddrinfo(3) on OSX is thread-safe

[A. Jesse Jiryu Davis]

A. Jesse Jiryu Davis added the comment:

I think we have consensus for "try 2". I'm not a core dev, would one of you 
please merge 25924-getaddrinfo-is-thread-safe-2.patch? Thanks!

--

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

[issue25924] investigate if getaddrinfo(3) on OSX is thread-safe

[A. Jesse Jiryu Davis]

A. Jesse Jiryu Davis added the comment:

Martin, here's a third patch, "try 3", which does a runtime version check 
instead of compile-time. It's a bit complex, compared to "try 2", which did a 
compile-time check instead.

I do NOT think this extra complexity is worth it to support Pythons that are 
built on 10.5+ and running on Mac OS 10.4 and older. 10.4 is long obsolete.

I propose merging "try 2" with the compile-time check. If that patch is 
accepted, I'll submit a patch for Python 2.7 also.

Thank you!

--
Added file: 
http://bugs.python.org/file41878/25924-getaddrinfo-is-thread-safe-3.patch

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

[issue25924] investigate if getaddrinfo(3) on OSX is thread-safe

[A. Jesse Jiryu Davis]

A. Jesse Jiryu Davis added the comment:

Thanks Martin. The MAC_OS_X_VERSION_10_5 macro ensures that Python is still 
compatible with Mac OS before version 10.5: if it's built on 10.4 or older, it 
locks around getaddrinfo (since it's not thread-safe there), and on 10.5 and 
later it doesn't lock.

I've built on a Mac OS 10.4 virtual machine and verified we'll still use the 
lock on that OS.

I think this is good enough, without a runtime check. We distribute prebuilt 
binaries for Mac OS 10.5+:

https://www.python.org/downloads/release/python-2711/

So those prebuilt Pythons should no longer lock around getaddrinfo. 

People who still use older Mac OSes (more than 12 years old!) will have to 
build Python themselves in order to get recent versions of Python, since we 
don't distribute binaries for them any more. Since they're building Python on 
old Mac OS, the MAC_OS_X_VERSION_10_5 macro will be undefined and they'll keep 
using the getaddrinfo lock.

--

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

[issue25924] investigate if getaddrinfo(3) on OSX is thread-safe

[A. Jesse Jiryu Davis]

A. Jesse Jiryu Davis added the comment:

Second patch with a comment about how we know Mac OS 10.5+'s getaddrinfo is 
thread-safe. I'll wait for this to be merged before submitting another for 
Python 2.7.

--
Added file: 
http://bugs.python.org/file41784/25924-getaddrinfo-is-thread-safe-2.patch

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

[issue25924] investigate if getaddrinfo(3) on OSX is thread-safe

[A. Jesse Jiryu Davis]

A. Jesse Jiryu Davis added the comment:

Great, how do we ensure this gets merged soon?

--

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

[issue25924] investigate if getaddrinfo(3) on OSX is thread-safe

[A. Jesse Jiryu Davis]

A. Jesse Jiryu Davis added the comment:

I've created a Mac OS 10.4 virtual machine and reproduced the getaddrinfo 
concurrency bug there using the attached h_resolv.c. The man page on that OS 
version indeed includes the "not thread-safe" warning.

The same test passes on my Mac OS 10.10 system.

I am convinced that getaddrinfo is thread-safe on Mac OS 10.5+, and I'm 
attaching a patch to disable the lock on these systems.

--
keywords: +patch
Added file: 
http://bugs.python.org/file41755/25924-getaddrinfo-is-thread-safe.patch

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

[issue25924] investigate if getaddrinfo(3) on OSX is thread-safe

[A. Jesse Jiryu Davis]

A. Jesse Jiryu Davis added the comment:

An Apple Developer Relations engineer tells me it's "reasonable to assume that 
getaddrinfo() is thread safe" on OS X 10.5 and later. (He mentioned that iOS 
inherited the OS X 10.5 DNS architecture, so Apple phones, watches, TVs, 
hairdryers, etc. can all do concurrent DNS too.)

Before OS X 10.5 the DNS system was a mix of new Mac OS X features, 
mDNSResponder and Open Directory, along with historical lookupd from NeXT and 
libresolv from an old BSD. In 10.5 the system was cleaned up to depend on OS 
X's mDNSResponder consistently; in the process getaddrinfo became thread-safe.

He cites as further evidence of its thread safety:

* The "bugs" section of getaddrinfo's man page was removed in 10.5
* 10.5 is the first OS X to be UNIX '03 certified, which includes the 
requirement that getaddrinfo be thread-safe
* The system itself uses getaddrinfo extensively as if it's thread-safe
* He hasn't seen reports of thread-safety problems with getaddrinfo

He explained how the code works. In the latest version:

http://www.opensource.apple.com/source/Libinfo/Libinfo-476/lookup.subproj/libinfo.c

getaddrinfo calls down to libinfo’s "mdns" module:

http://www.opensource.apple.com/source/Libinfo/Libinfo-476/lookup.subproj/mdns_module.c

"mdns" uses the DNS-SD API declared in dns_sd.h, which he says is "well known 
to be thread safe." The DNS-SD API is part of the mDNSResponder project:

http://www.opensource.apple.com/source/mDNSResponder/mDNSResponder-576.30.4/

The key function is DNSServiceQueryRecord:

http://www.opensource.apple.com/source/mDNSResponder/mDNSResponder-576.30.4/mDNSShared/dnssd_clientstub.c

My contact concludes, "As you can see, it does an IPC over to the mDNSResponder 
process, at which point thread safety is assured."

--

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

[issue25924] investigate if getaddrinfo(3) on OSX is thread-safe

[A. Jesse Jiryu Davis]

A. Jesse Jiryu Davis added the comment:

Related to #1288833, when FreeBSD 5.3's getaddrinfo was declared thread-safe.

--

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

[issue25924] investigate if getaddrinfo(3) on OSX is thread-safe

[A. Jesse Jiryu Davis]

Changes by A. Jesse Jiryu Davis <je...@emptysquare.net>:


Added file: http://bugs.python.org/file41597/d_mach

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

[issue25924] investigate if getaddrinfo(3) on OSX is thread-safe

[A. Jesse Jiryu Davis]

Changes by A. Jesse Jiryu Davis <je...@emptysquare.net>:


Added file: http://bugs.python.org/file41596/h_resolv.c

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

[issue25924] investigate if getaddrinfo(3) on OSX is thread-safe

[A. Jesse Jiryu Davis]

A. Jesse Jiryu Davis added the comment:

NetBSD has a concurrency test for getaddrinfo, so I tried it on Mac to see if 
getaddrinfo is thread-safe here, too. It appears that it is thread-safe.

I copied NetBSD's getaddrinfo concurrency test "h_resolv.c" and the test's data 
file "d_mach" from src/tests/lib/libpthread in the NetBSD 7 source:

http://cvsweb.netbsd.org/bsdweb.cgi/src/tests/lib/libpthread/

I've also attached these files to this ticket.*

The test program h_resolv.c compiles fine on Mac OS X 10.10 with clang 7, and 
the test passes using the same parameters that the NetBSD test uses, resolving 
five host names on five threads:

./h_resolv -d -n 5 -h 5 d_mach

There's even evidence that getaddrinfo is actually concurrent on my Mac: 
resolving 100 hostnames on 1 thread takes about 6 seconds, but using 100 
threads take only 3 seconds. To test concurrency I ran this:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
time h_resolv -d -h 100 -n 1 d_mach

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
time h_resolv -d -h 1 -n 100 d_mach

Those sudo commands flush the Mac's DNS cache between runs.

* I removed one unresolvable domain, "cnftp.bjpu.edu.cn", from the test file 
d_mach. That domain took 15 seconds to time out and made the rest of the timing 
irrelevant.

--

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

[issue25924] investigate if getaddrinfo(3) on OSX is thread-safe

[A. Jesse Jiryu Davis]

A. Jesse Jiryu Davis added the comment:

In Apple's Libinfo version 222.4.12 (corresponding to the last OS X 10.4 
release), the man page says getaddrinfo isn't thread-safe:

http://www.opensource.apple.com/source/Libinfo/Libinfo-222.4.12/lookup.subproj/getaddrinfo.3

And here's its source:

http://www.opensource.apple.com/source/Libinfo/Libinfo-222.4.12/lookup.subproj/getaddrinfo.c

Glancing at the source naïvely, I might see the data race: getaddrinfo calls 
gai_lookupd, which reads and writes the global static variable "gai_proc". I 
can't see what will go wrong as a result of the race, but it sure LOOKS bad.

In the next release, version 278 (OS X 10.5.0), the thread-safety warning is 
gone from the man page:

http://www.opensource.apple.com/source/Libinfo/Libinfo-278/lookup.subproj/getaddrinfo.3

And getaddrinfo is largely rewritten:

http://www.opensource.apple.com/source/Libinfo/Libinfo-278/lookup.subproj/getaddrinfo.c

It calls a new function, "ds_getaddrinfo". But ds_getaddrinfo still accesses 
the global static variable "gai_proc"; I wonder why this is considered 
thread-safe now?

--
nosy: +emptysquare

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

[issue25920] PyOS_AfterFork should reset socketmodule's lock

[A. Jesse Jiryu Davis]

New submission from A. Jesse Jiryu Davis:

On some platforms there's an exclusive lock in socketmodule, used for 
getaddrinfo, gethostbyname, gethostbyaddr. A thread can hold this lock while 
another forks, leaving it locked forever in the child process. Calls to these 
functions in the child process will hang.

(I wrote some more details here: 
https://emptysqua.re/blog/getaddrinfo-deadlock/ )

I propose that this is a bug, and that it can be fixed in PyOS_AfterFork, where 
a few similar locks are already reset.

--
messages: 256815
nosy: emptysquare
priority: normal
severity: normal
status: open
title: PyOS_AfterFork should reset socketmodule's lock

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

[issue25274] sys.setrecursionlimit() must fail if the current recursion depth is higher than the new low-water mark

[A. Jesse Jiryu Davis]

Changes by A. Jesse Jiryu Davis <je...@emptysquare.net>:


--
nosy: +emptysquare

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

[issue25612] nested try..excepts don't work correctly for generators

[A. Jesse Jiryu Davis]

Changes by A. Jesse Jiryu Davis <je...@emptysquare.net>:


--
nosy: +emptysquare

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

[issue25222] 3.5.0 regression - Fatal Python error: Cannot recover from stack overflow

[A. Jesse Jiryu Davis]

Changes by A. Jesse Jiryu Davis <je...@emptysquare.net>:


--
nosy: +emptysquare

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

[issue24383] consider implementing __await__ on concurrent.futures.Future

[A. Jesse Jiryu Davis]

Changes by A. Jesse Jiryu Davis je...@emptysquare.net:


--
nosy: +emptysquare

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

[issue24123] Python 2.7 Tutorial Conflicting behavior with WeakValueDictionary.

[Jesse Bacon]

New submission from Jesse Bacon:

https://docs.python.org/2/tutorial/stdlib2.html
Section 11.6. Weak References

The example code below from the python tutorial suggests that the value of a is 
no persistent when cast into a WeakValueDictionary as entry 'primary'

The value persisted in the dictionary aver 'a' was deleted and garbage 
collection had been called.  I did not see a bug report for this already 
forgive me if there was one already put in.  

import weakref, gc
class A:
def __init__(self, value):
self.value = value
def __repr__(self):
return str(self.value)

a = A(10)   # create a reference
d = weakref.WeakValueDictionary()
d['primary'] = a# does not create a reference
d['primary']# fetch the object if it is still alive

del a   # remove the one reference
gc.collect()# run garbage collection right away

d['primary']# entry was automatically removed

--
components: Demos and Tools
messages: 242534
nosy: jessembacon
priority: normal
severity: normal
status: open
title: Python 2.7 Tutorial Conflicting behavior  with WeakValueDictionary.
type: behavior
versions: Python 2.7

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

[issue24123] Python 2.7 Tutorial Conflicting behavior with WeakValueDictionary.

[Jesse Bacon]

Jesse Bacon added the comment:

https://docs.python.org/2/tutorial/stdlib2.html
Section 11.6. Weak References

The example code below from the python tutorial suggests that the value of 'a' 
is not persistent when cast into a WeakValueDictionary as entry 'primary'

The value persisted in the dictionary aver 'a' was deleted and garbage 
collection had been called.  I did not see a bug report for this already 
forgive me if there was one already put in.  

import weakref, gc
class A:
def __init__(self, value):
self.value = value
def __repr__(self):
return str(self.value)

a = A(10)   # create a reference
d = weakref.WeakValueDictionary()
d['primary'] = a# does not create a reference
d['primary']# fetch the object if it is still alive

del a   # remove the one reference
gc.collect()# run garbage collection right away

d['primary']# entry was automatically removed

--

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

[issue24123] Python 2.7 Tutorial Conflicting behavior with WeakValueDictionary.

[Jesse Bacon]

Jesse Bacon added the comment:

https://docs.python.org/2/tutorial/stdlib2.html
Section 11.6. Weak References

The example code below from the python tutorial suggests that the value of 'a' 
is not persistent when cast into a WeakValueDictionary as entry 'primary'

The value persisted in the dictionary after 'a' was deleted and garbage 
collection had been called.  I did not see a bug report for this already 
forgive me if there was one already put in.  

import weakref, gc
class A:
def __init__(self, value):
self.value = value
def __repr__(self):
return str(self.value)

a = A(10)   # create a reference
d = weakref.WeakValueDictionary()
d['primary'] = a# does not create a reference
d['primary']# fetch the object if it is still alive

del a   # remove the one reference
gc.collect()# run garbage collection right away

d['primary']# entry was automatically removed

--

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

[issue24123] Python 2.7 Tutorial Conflicting behavior with WeakValueDictionary.

[Jesse Bacon]

Jesse Bacon added the comment:

Thank you for the second eyes. 
I just verified that it works using the standard python shell.  It looks like 
the bug is in IPython.  I’ll post it there.

In [7]: class A:
   ...: def __init__(self, value):
   ...: self.value = value
   ...: def __repr__(self):
   ...: return str(self.value)
   ...: 

In [8]: a = A(10)

In [9]: d = weakref.WeakValueDictionary()

In [10]: d['primary'] = a

In [11]: d['primary'] 
Out[11]: 10

In [12]: del a

In [13]: gc.collect()
Out[13]: 148

In [14]: d['primary']
Out[14]: 10

In [15]: 

sincerely,

Jesse Bacon

 On May 3, 2015, at 8:54 PM, R. David Murray rep...@bugs.python.org wrote:
 
 
 R. David Murray added the comment:
 
 If I run the example code you pasted using 2.7, I get a KeyError.  So the 
 example looks correct to me.
 
 --
 nosy: +r.david.murray
 
 ___
 Python tracker rep...@bugs.python.org
 http://bugs.python.org/issue24123
 ___

--
title: Python 2.7 Tutorial Conflicting behavior  with WeakValueDictionary. - 
Python 2.7 Tutorial Conflicting behavior with WeakValueDictionary.

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

[issue24123] Python 2.7 Tutorial Conflicting behavior with WeakValueDictionary.

[Jesse Bacon]

Jesse Bacon added the comment:

After further testing it appears that the bug is in IPython not Python 2.7. 
The bug has been moved to the Python list at 
https://github.com/ipython/ipython/issues/8403#issuecomment-98565759

--
resolution:  - third party
status: open - closed

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

[issue10544] yield expression inside generator expression does nothing

[A. Jesse Jiryu Davis]

Changes by A. Jesse Jiryu Davis je...@emptysquare.net:


--
nosy: +emptysquare

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

any visualization web framework ?

[jesse]

show task execution;
data visualization;
easy to set up;

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

[issue23915] traceback set with BaseException.with_traceback() overwritten on raise

[A. Jesse Jiryu Davis]

A. Jesse Jiryu Davis added the comment:

I've had a very hard time adding to the doc in a way that elucidates rather 
than further obfuscating; see if you like this patch.

--
keywords: +patch
nosy: +emptysquare
Added file: http://bugs.python.org/file38916/issue23915.patch

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

[issue22652] Add suggestion about keyword arguments to this error message: builtins.TypeError: my_func() takes 1 positional argument but 2 were given

[A. Jesse Jiryu Davis]

A. Jesse Jiryu Davis added the comment:

Attached patch adds and N keyword-only argument(s) to the TypeError message 
if a function takes keyword-only arguments and the wrong number of positional 
arguments is provided.

--
keywords: +patch
nosy: +emptysquare
Added file: http://bugs.python.org/file38929/issue22652.patch

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

[issue23464] Remove or deprecate JoinableQueue in asyncio docs

[A. Jesse Jiryu Davis]

Changes by A. Jesse Jiryu Davis je...@emptysquare.net:


--
keywords: +patch
Added file: http://bugs.python.org/file38906/issue23464.diff

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

[issue23464] Remove or deprecate JoinableQueue in asyncio docs

[A. Jesse Jiryu Davis]

New submission from A. Jesse Jiryu Davis:

asyncio.JoinableQueue was once a distinct subclass of asyncio.Queue, now it's 
just a deprecated alias. Once this is merged into CPython:

https://code.google.com/p/tulip/issues/detail?id=220

...then remove or deprecate JoinableQueue in asyncio-sync.rst

--
components: asyncio
messages: 235971
nosy: emptysquare, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: Remove or deprecate JoinableQueue in asyncio docs
versions: Python 3.4

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

Re: why zip64_limit defined as 131 -1?

[jesse]

the official zip format spec states clearly that normal zip file should be
= 4G size instead 2G.  I just can not believe Python has such an obvious
bug.

People suggested monkey patch the ZIP64_LIMIT value to pass 2G, I am not
sure what will be the ramifications.
On Jan 28, 2015 1:37 PM, Chris Angelico ros...@gmail.com wrote:

 On Thu, Jan 29, 2015 at 5:53 AM, jesse chat2je...@gmail.com wrote:
  should not it be 132 -1(4g)?
 
  normal zip archive format should be able to support 4g file.
 
  thanks

 131-1 is the limit for a signed 32-bit integer. You'd have to look
 into the details of the zip file format to see whether that's the
 official limit or not; it might simply be that some (un)archivers have
 problems with 2GB files, even if the official stance is that it's
 unsigned.

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

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

Re: why zip64_limit defined as 131 -1?

[jesse]

On Jan 29, 2015 9:27 AM, Ian Kelly ian.g.ke...@gmail.com wrote:

 On Wed, Jan 28, 2015 at 2:36 PM, Chris Angelico ros...@gmail.com wrote:
  On Thu, Jan 29, 2015 at 5:53 AM, jesse chat2je...@gmail.com wrote:
  should not it be 132 -1(4g)?
 
  normal zip archive format should be able to support 4g file.
 
  thanks
 
  131-1 is the limit for a signed 32-bit integer. You'd have to look
  into the details of the zip file format to see whether that's the
  official limit or not; it might simply be that some (un)archivers have
  problems with 2GB files, even if the official stance is that it's
  unsigned.

 The bug in which zip64 support was added indicates that the value was
 indeed chosen as the limit of a signed 32-bit integer:

 http://bugs.python.org/issue1446489

ok,  then why signed 32-bit integer instead of unsigned 32 integer? any
technical limitation reason? the chosen 2G boundary does not conform to zip
standard specification.

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