[issue32839] Add after_info as a function to tkinter

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Real use case for after_info() (with not arg): #33855 is about minimally 
testing all IDLE modules.  At least import the module and create class 
instances when easily possible.  For test_editor, I started with 

def test_init(self):  # Temporary.
e = Editor(root=self.root)
self.assertEqual(e.root, self.root)

and got in Shell

warning: callback failed in WindowList  : invalid 
command name ".!menu.windows"

and in the console

invalid command name "119640952recolorize"
while executing
"119640952recolorize"
("after" script)
invalid command name "119872312timer_event"
while executing
"119872312timer_event"
("after" script)
invalid command name "119872440config_timer_event"
while executing
"119872440config_timer_event"
("after" script)

Perhaps this is why I previously omitted something so obvious (it add 24% to 
coverage).

I added e._close(), which tries to cleanup, and the messages, in console only, 
are reduced to

bgerror failed to handle background error.
Original error: invalid command name "115211704timer_event"
Error in bgerror: can't invoke "tk" command: application has been destroyed
bgerror failed to handle background error.
Original error: invalid command name "115211832config_timer_event"
Error in bgerror: can't invoke "tk" command: application has been destroyed

I would like to know what _close misses, but it is hard to track them down.
print(self.root.tk.call('after', 'info')) after the close returned ('after#4', 
'after#3', 'after#1', 'after#0').  Adding

for id in cls.root.tk.call('after', 'info'):
self.root.after_cancel(id)

before cls.root.destroy() in shutDownClass stops the messages.
--

For test_del in #32831, I think the following might work, and be much shorter 
than the current code.

n = len(self.root.tk.call('after', 'info')
self.cc.__del__()
self.assertEqual(len(self.root.tk.call('after', 'info')), n-2)

--

___
Python tracker 

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

[issue14102] argparse: add ability to create a man page

[Pavel Raiskup]

Pavel Raiskup  added the comment:

On Friday, June 15, 2018 1:52:41 AM CEST Ben Finney wrote:
> On Thu, 2018-06-14 23:46 +, Aaron Meurer  wrote:
> > Couldn't such a tool exist outside the standard library.
> 
> I've tried writing such a tool. It would ideally re-use as much as feasible of
> the functionality that assembles the usage message.

FWIW, I followed you and andialbrecht's solution, and did some changes to the
code (now the code is in PyPi as argparse-manpage).  Feel free to take what's
considered useful.

> So this bug report asks for that work to be done in the ‘argparse’ library.

Agreed.

> > Installing the manpage is a separate concern.
> 
> Yes, I agree. That is not part of this bug report.

I think installation is valid concern;  so it should be tracked somewhere.

--

___
Python tracker 

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

[issue19102] Add tests for CLI of the tabnanny module

[Jaysinh shukla]

Jaysinh shukla  added the comment:

@vstinner I have created the PR here. I wasn't sure so linked the PR with this 
issue. Thanks!

PR URL: https://github.com/python/cpython/pull/7699

--

___
Python tracker 

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

[issue19102] Add tests for CLI of the tabnanny module

[Jaysinh shukla]

Change by Jaysinh shukla :


--
pull_requests: +7315

___
Python tracker 

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

[issue33863] Enum doc correction relating to __members__

[INADA Naoki]

INADA Naoki  added the comment:

> A dictionary (treated as a synonym for dict) can't have an order different 
> than insertion order, because that is one of the guarantees a *dictionary* 
> provides.

When subclassing dict and overrides `__iter__` etc., the subclass is dict 
(isinstance(subclass, dict) is True) and it have order different than insertion 
order.

So when "dictionary" includes dict subclasses, it doesn't guarantee preserving 
insertion order.

Exact ``dict`` and ``OrderedDict`` guarantee insertion order, but when saying 
"dictionary", it's not guaranteed.


Anyway, word "dictionary" and "ordered dictionary" have vary meanings regarding 
to context.
So talking about general rule doesn't worth enough to use time and energy to 
discuss.  Let's focus on concrete cases.

For enum, I created pull request to change OrderedDict to dict. (PR-7698)

And for csv.DictReader, it uses OrderedDict already.  So I don't against 
changing "ordered dictionary" to OrderedDict.

--

___
Python tracker 

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

[issue33863] Enum doc correction relating to __members__

[Andrés Delfino]

Andrés Delfino  added the comment:

Something I forgot: we shouldn't write documentation that expects the user 
*not* to know that dictionaries are ordered now. It's described in What's New 
and in Built-in Types. That's why "ordered dictionaries" seems so wrong to me.

--

___
Python tracker 

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

[issue33867] Module dicts are wiped on module garbage collection

[natedogith1]

New submission from natedogith1 :

When a module is garbage collected, it fills it's __dict__ with None.  
issue19255 and issue18214 seem to suggest that this was fixed, along with 
github pull request 7140 (commit 196b0925ca55bf22ffbb97733cff3e63d4fb6e18).  
However, this still seems to be an issue in 2.7.14 and 3.6.2.

>>> import sys
>>> a = type(sys)('a')
>>> b = a.__dict__
>>> b['__name__'] is None
False
>>> del a
>>> b['__name__'] is None
True

--
components: Interpreter Core
messages: 319581
nosy: natedogith1
priority: normal
severity: normal
status: open
title: Module dicts are wiped on module garbage collection
type: behavior
versions: Python 2.7, Python 3.6

___
Python tracker 

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

[issue33863] Enum doc correction relating to __members__

[Andrés Delfino]

Andrés Delfino  added the comment:

The problem here is that while the historical issue is real, new programmers 
will come and they won't see a "non-ordered" dict, and having this 
"dictionaries" vs "ordered dictionaries" that aren't actual OrderedDict objects 
(which have the common name "ordered dictionaries", though), will be really 
confusing for them.

A dictionary (treated as a synonym for dict) can't have an order different than 
insertion order, because that is one of the guarantees a *dictionary* provides. 
If one needs to have an object with another sort of ordering, then we talk 
about a dict-like object, or a dict subclass; but IMHO "dictionary" alone 
should imply not only a very specific order, but a very specific type too: 
dict. A dict subclass with different ordering is nothing but that, not a 
dictionary with different ordering, that would imply one can setup the ordering 
method of a dict class.

Plus, ordered dictionaries (OrderedDict objects) don't provide exactly the same 
API as dictionaries, so it gets tricky to use that term to also include 
dictionaries. It's quite reasonable to expect "ordered dictionaries" to be 
confused with "OrderedDict objects".

Also, I feel somewhat uncomfortable about "most likely". It's fine to use weak 
names (dict-like, subclass of dict, mapping, etc.), but not knowing exactly 
what you can *rely on* (i.e. a required subset of whatever the implementation 
actually provides) from a given API is quite confusing. Notice that it doesn't 
have to be an actual type, but at least some sort of description of what is 
guaranteed (i.e. a mapping).

--

___
Python tracker 

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

[issue33863] Enum doc correction relating to __members__

[INADA Naoki]

INADA Naoki  added the comment:

I feel "dictionary" implies "most likely dict or it's subclass" too.  But I 
don't think "ordered dictionary" is bad wording because:

* Historically, dict didn't preserve insertion order.
* Dict subclass can provide other ordering.

So "ordered dictionary" implies "most likely dict or it's subclass, without 
customizing ordering".

--

___
Python tracker 

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

[issue33863] Enum doc correction relating to __members__

[Andrés Delfino]

Andrés Delfino  added the comment:

To be a little more clear about this: I don't think one implements a dict-like 
object by reading the Glossary reference. At least, we shouldn't expect nor 
encourage this.

--

___
Python tracker 

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

[issue33860] doc Avoid "ordered dictionary" references now that dictionaries are ordered

[Andrés Delfino]

Andrés Delfino  added the comment:

Perhaps we can continue the discussion on #33863 as there are more argumnets 
there, from all points of view, and when a decision is taken there, we can 
apply it here too.

--

___
Python tracker 

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

[issue33866] Stop using OrderedDict in enum

[INADA Naoki]

Change by INADA Naoki :


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

___
Python tracker 

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

[issue33866] Stop using OrderedDict in enum

[INADA Naoki]

Change by INADA Naoki :


--
components: Library (Lib)
nosy: inada.naoki
priority: normal
severity: normal
status: open
title: Stop using OrderedDict in enum
versions: Python 3.8

___
Python tracker 

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

[issue33863] Enum doc correction relating to __members__

[Andrés Delfino]

Andrés Delfino  added the comment:

IMHO, the Glossary is just a quick & dirty reference. I wouldn't search for 
hard definitions in there. See Built-in Types: "dictionary" is used 
specifically for dict.

I believe we should make clear use of definitions so users known exactly what 
they get. I know there's a significant effort in reviewing and merging PRs; all 
I can say is that if the change is deemed reasonable, I can take the task of 
making this clear everywhere in the docs.

--

___
Python tracker 

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

[issue27575] dict viewkeys intersection slow for large dicts

[Forest]

Forest  added the comment:

Hi Raymond,

I've created a PR here: https://github.com/python/cpython/pull/7696, and 
I've verified that there are tests for all the code paths. 

I reached out to Daniel Hsu and he has given his blessing to help push this 
forward. 

I think this is ready for your review. Please let me know if there's anything 
else I can do.

Thanks,

Forest

--

___
Python tracker 

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

[issue33860] doc Avoid "ordered dictionary" references now that dictionaries are ordered

[INADA Naoki]

INADA Naoki  added the comment:

> Please note that DictReader already mentions "OrderedDict" as a type it 
> returns now.

OK, but PR-7535 changes enum too.

> but "dictionary" alone doesn't seem like a good weak name to me, as it's the 
> common name of an actual type.

As I commented in #33863, "dictionary" is really common weak name defined in 
glossary.  dict ∈ dictionary

--

___
Python tracker 

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

[issue33863] Enum doc correction relating to __members__

[INADA Naoki]

INADA Naoki  added the comment:

> What do you mean by "a generic dictionary"? If it's a dict-like object, then 
> it *must* be ordered starting with 3.7.

No.  Even though dict is ordered, no guarantee about ordering of "dictionary".  
Glossary says:

  dictionary
  An associative array, where arbitrary keys are mapped to values. The keys can 
be any object with __hash__() and __eq__() methods. Called a hash in Perl.

So there can be dict-like object without preserving insertion order.

--

___
Python tracker 

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

[issue33863] Enum doc correction relating to __members__

[INADA Naoki]

INADA Naoki  added the comment:

We use the word "dictionary" for "dict-like" or "maybe dict or it's subclass" 
many places.
I don't feel it worth enough to change all wording about it.

--
nosy: +inada.naoki

___
Python tracker 

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

[issue33865] unknown encoding: 874

[Steven D'Aprano]

Steven D'Aprano  added the comment:

Please don't post screenshots of text, they make it difficult for the blind and 
visually impaired to contribute. Instead, please copy and paste the error 
message into the body of your bug report. (Which I see you have done, which 
makes the screenshot unnecessary.)

Just reporting the error message alone is not very useful, we also should see 
the context of what you were doing when the error occurred.

--
nosy: +steven.daprano

___
Python tracker 

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

[issue33865] unknown encoding: 874

[Prawin Phichitnitikorn]

New submission from Prawin Phichitnitikorn :

This Error "
Current thread 0x238c (most recent call first): Fatal Python error: 
Py_Initialize: can’t initialize sys standard streams LookupError: unknown 
encoding: 874"

is cause by mapping of 874 encodling is missing in encodings\aliases.py

--
components: Unicode
files: Capture.PNG
messages: 319569
nosy: ezio.melotti, vstinner, winvinc
priority: normal
severity: normal
status: open
title: unknown encoding: 874
type: crash
versions: Python 3.6
Added file: https://bugs.python.org/file47642/Capture.PNG

___
Python tracker 

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

[issue14102] argparse: add ability to create a man page

[Aaron Meurer]

Aaron Meurer  added the comment:

I see. I haven't dug much into the argoarse source, so I don't have a good feel 
for how feasible such a tool would be to write. Such refactoring would also be 
useful for generating HTML or RST for the help. I've previously used help2man 
and man2html to generate html help, but both tools are very limited in what 
they can do.

--

___
Python tracker 

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

[issue14102] argparse: add ability to create a man page

[Ben Finney]

Ben Finney  added the comment:

On Thu, 2018-06-14 23:46 +, Aaron Meurer  wrote:

> Couldn't such a tool exist outside the standard library.

I've tried writing such a tool. It would ideally re-use as much as feasible of 
the functionality that assembles the usage message. But that is hampered by the 
fact the usage message generation is not easily accessible from outside.

I am hoping that, in order to re-use that functionality, a common set of “take 
the argument collection as input, generate a document structure” functionality 
can be factored out for other use — initially, for generating a manual page.

So this bug report asks for that work to be done in the ‘argparse’ library.

> Installing the manpage is a separate concern.

Yes, I agree. That is not part of this bug report.

--

___
Python tracker 

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

[issue14102] argparse: add ability to create a man page

[Aaron Meurer]

Aaron Meurer  added the comment:

Couldn't such a tool exist outside the standard library. I'm thinking a 
function that you would import and wrap the parser object, similar to how 
argcomplete works (https://argcomplete.readthedocs.io/en/latest/index.html). 
The downside is that developers would have to opt-in for it to work (much like 
they currently have to opt-in to bash completion with things like argcomplete). 
But it would allow much more flexibility being outside the standard library.

I completely agree that it should be done in Python either way. help2man is 
very limited in its flexibility (it doesn't help that it's written in Perl), 
and there are fundamental limits to what you can do from parsing the --help 
output, vs. just generating correct troff from the source.

Installing the manpage is a separate concern. That would need to go in 
setuptools or distutils, if anywhere. But before you can worry about how to 
install it you need to be able to generate it in the first place.

--
nosy: +asmeurer

___
Python tracker 

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

[issue14102] argparse: add ability to create a man page

[Éric Araujo]

Éric Araujo  added the comment:

Thanks Ben for expressing exactly what this ticket is about and why the code 
would be in argparse.  (The author of argparse and Raymond a senior core dev 
also agree that adding a man page formatter to argparse would be useful.)

--

___
Python tracker 

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

[issue14102] argparse: add ability to create a man page

[Ben Finney]

Ben Finney  added the comment:

On Thu, 2018-06-14 20:02 +, Pablo Galindo Salgado  
wrote:
> The (possible) confusion is the existence of a manpage only available 
> though argparse (`./python foo.py --manpage`)

This report isn't asking for that. (I see only one person proposing such an 
interface, and even that person said it's not a good idea.) So please don't 
conflate that with the original bug report.

> I am  not sure how many people do something like `./python poc_2.py > output 
> && man ./output` to **read** the manpage.

Right, I am not asking for anything like that; I'm not asking that ‘argparse’ 
grow a way to read a manual page,. I am asking only for a standard way to 
programmatically generate that manual page from the information ‘argparse’ 
already knows.

> >This is asking that the ‘argparse’ library should have an API to
> >create a manual page, for use in the build system.
> 
> At this point argparse is user facing in the sense that once configured, 
> it provides functionality for the user of the command line application. 
> My opinion is that it will be weird to have it provide also APIs for 
> creating man pages (which is a developer utility).

Creating an argument parser itself is already a developer activity, and we 
don't see that as weird that ‘argparse’ allows for that.

I'm arguing that the library already knows how to turn the argument collection 
into a user-facing document (the usage message), and a manual page is a 
different way of rendering that same internal data. So that's why ‘argparse’ is 
a consistent place to have that functionality.

> My humble opinion is 
> that it if argparse starts to provide APIs for usage at install time is 
> not "doing one thing and doing it well".

That API already exists: the specific ‘ArgumentParser’ is available to be 
imported for a program which defines one. So, the library already provides APIs 
for usage at install time (or any other run-time).

I am asking to make that API more useful for the distribution of programs.

--

___
Python tracker 

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

[issue33860] doc Avoid "ordered dictionary" references now that dictionaries are ordered

[Andrés Delfino]

Andrés Delfino  added the comment:

I believe the discussion in #33863 is relevant. Depending on what the API the 
user can rely on, perhaps "an ordered mapping" fits here too.

--

___
Python tracker 

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

[issue33721] os.path.exists() ought to return False if pathname contains NUL

[pacujo]

pacujo  added the comment:

Eryk Sun:
> I only meant that, as an honest error, it has to be ValueError. I didn't
> think about raising a fake OSError.
>
> Note that I didn't say the ValueError shouldn't be ignored by
> os.path.exists (et al). In the spirit of the current function, it
> probably should be ignored. For example, it returns False for paths that
> exist but are inaccessible.

For the original complaint of mine, catching ValueError would work. I
must say, though, that Steven's arguments for raising a fake OSError are
very convincing.

Steven D'Aprano:
> Jython does this:
> 
> >>> import os
> >>> os.path.exists('/tmp/foo\0bar')
> False
> >>> os.stat('/tmp/foo\0bar')
> Traceback (most recent call last):
>   File "", line 1, in 
> OSError: [Errno 2] No such file or directory: '/tmp/foo\x00bar'
> 
> 
> As far as I am concerned, raising ValueError is simply a bug. The
> documentation for the os module clearly states:
> 
> All functions in this module raise OSError in the case of
> invalid or inaccessible file names and paths, or other
> arguments that have the correct type, but are not accepted
> by the operating system.

Now the question is not anymore if and how CPython should be fixed but
if and how Jython should be fixed.

IMO, Jython is doing the right thing. If that is not true, then Jython
must be declared buggy.

> Maybe it could raise an InvalidFilename subclass of OSError. This
> could even handle some actual OS errors such as POSIX ENAMETOOLONG and
> Windows ERROR_INVALID_NAME, ERROR_BAD_PATHNAME, and
> ERROR_FILENAME_EXCED_RANGE.

Maybe. You'll still need OSError.errno to hold a true error value.

Marko

--

___
Python tracker 

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

[issue33721] os.path.exists() ought to return False if pathname contains NUL

[Eryk Sun]

Eryk Sun  added the comment:

>> It has to be a ValueError since the error is an invalid 
>> parameter at the Python level.
>
> How does the first follow from the second?

I only meant that, as an honest error, it has to be ValueError. I didn't think 
about raising a fake OSError.

Note that I didn't say the ValueError shouldn't be ignored by os.path.exists 
(et al). In the spirit of the current function, it probably should be ignored. 
For example, it returns False for paths that exist but are inaccessible. 

> I don't believe there is any good reason for singling out NULs 
> for a different exception from other invalid file names 
> like ">" on NTFS.
>
> This ought to be an OSError for functions like os.stat and False 
> for os.path.exists, as Jython does.

Python can't pass a string that contains NUL characters to POSIX and Windows 
APIs that use null-terminated strings. That would yield wildly unpredictable 
results. We need this to be a reliable error. So for the low-level file I/O 
functions to return an OSError here, it would have to be a bit of a lie (i.e. 
an 'OS' error without making a system call and without an `errno` and/or 
`winerror` value). Maybe it could raise an InvalidFilename subclass of OSError. 
This could even handle some actual OS errors such as POSIX ENAMETOOLONG and 
Windows ERROR_INVALID_NAME, ERROR_BAD_PATHNAME, and ERROR_FILENAME_EXCED_RANGE.

--

___
Python tracker 

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

[issue32604] Expose the subinterpreters C-API in Python for testing use.

[Eric Snow]

Eric Snow  added the comment:

Also see #24553.

--

___
Python tracker 

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

[issue24553] improve test coverage for subinterpreters

[Eric Snow]

Eric Snow  added the comment:

Note that bpo-32604 is strongly related.

--

___
Python tracker 

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

[issue17045] Improve C-API doc for PyTypeObject

[Eric Snow]

Change by Eric Snow :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

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

[issue17045] Improve C-API doc for PyTypeObject

[Eric Snow]

Eric Snow  added the comment:


New changeset 9e7c92193cc98fd3c2d4751c87851460a33b9118 by Eric Snow in branch 
'master':
bpo-17045:  Improve C-API doc for PyTypeObject. (gh-7413)
https://github.com/python/cpython/commit/9e7c92193cc98fd3c2d4751c87851460a33b9118


--

___
Python tracker 

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

[issue33864] collections.abc.ByteString does not register memoryview

[Jason Fried]

New submission from Jason Fried :

Looking at the typing Module docs in the section for ByteString

This type represents the types bytes, bytearray, and memoryview.

But collections.abc.ByteString does not have memoryview registered.

Is it because memoryview doesn't support .index()?

--
assignee: docs@python
components: Documentation
messages: 319557
nosy: docs@python, fried, lukasz.langa
priority: normal
severity: normal
status: open
title: collections.abc.ByteString does not register memoryview
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

[issue33863] Enum doc correction relating to __members__

[Andrés Delfino]

Andrés Delfino  added the comment:

What do you mean by "a generic dictionary"? If it's a dict-like object, then it 
*must* be ordered starting with 3.7.

I believe we should make it clear that a dictionary is always a dict object.

If you refer to a mapping with no specific API, then "an ordered mapping" is 
clear and correct.

--

___
Python tracker 

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

[issue33863] Enum doc correction relating to __members__

[Ethan Furman]

Ethan Furman  added the comment:

An ordered mapping sounds good to me.  Let's let this sit for a couple days in 
case anyone else wants to chime in.  If there are no other ideas or objections 
then we can make the change mid-next week.

--

___
Python tracker 

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

[issue33863] Enum doc correction relating to __members__

[Ethan Furman]

Ethan Furman  added the comment:

I am open to suggestions, but I will say that there are other types of ordered 
dictionaries besides OrderedDict.  Also, if you have some generic dictionary 
that happens to be ordered but is not an OrderedDict, how would you describe it?

--

___
Python tracker 

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

[issue33863] Enum doc correction relating to __members__

[Andrés Delfino]

Andrés Delfino  added the comment:

What about "a dictionary-like object" for master/3.7, and "a dictionary-like 
object with insertion order preservation" for 3.6 (or something like that).

I'd avoid "ordered dictionary" altogether as that's the common name of an 
actual type.

--

___
Python tracker 

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

[issue33863] Enum doc correction relating to __members__

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Well, technically a function can say that it returns a dictionary and this 
dictionary will be ordered in 3.6> but is not important for the function return 
value. If a function says that it returns a "ordered dictionary" I now (1) that 
the order is important in the return value, (2) that it can be a regular dict 
or an OrderDict depending on the python version. The important thing here is 
that it preserves insertion order.

--

___
Python tracker 

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

[issue33863] Enum doc correction relating to __members__

[Andrés Delfino]

Andrés Delfino  added the comment:

What about "a dictionary-like object"?

--

___
Python tracker 

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

[issue33863] Enum doc correction relating to __members__

[Andrés Delfino]

Andrés Delfino  added the comment:

It doesn't seem right to me to change a term's meaning. Plus, saying "ordered 
dictionary" makes me think a "dictionary" isn't ordered.

--

___
Python tracker 

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

[issue33354] Python2: test_ssl fails on non-ASCII path

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +7312

___
Python tracker 

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

[issue32962] test_gdb fails in debug build with `-mcet -fcf-protection -O0`

[STINNER Victor]

STINNER Victor  added the comment:

Reminder: test_gdb is skipped on Travis CI and AppVeyor. I tested my two 
changes manually. I will backport python-gdb.py enhancements to other branches 
once PR 6754 fix will be merged.

--

___
Python tracker 

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

[issue33863] Enum doc correction relating to __members__

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Since dictionaries are ordered "ordered dictionary" can be a synonym of 
"dictionary" and "OrderDict", right?

--
nosy: +pablogsal

___
Python tracker 

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

[issue32962] test_gdb fails in debug build with `-mcet -fcf-protection -O0`

[STINNER Victor]

STINNER Victor  added the comment:


New changeset d22fc0bc7de7882da204abe50884bbde2da4f9e7 by Victor Stinner in 
branch 'master':
bpo-32962: python-gdb catchs UnicodeDecodeError (GH-7693)
https://github.com/python/cpython/commit/d22fc0bc7de7882da204abe50884bbde2da4f9e7


--

___
Python tracker 

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

[issue32962] test_gdb fails in debug build with `-mcet -fcf-protection -O0`

[STINNER Victor]

STINNER Victor  added the comment:

> Wouldn't be better to use the "surrogateescape" or the "backslashreplace" 
> error handlers?

Are you talking about my https://github.com/python/cpython/pull/7693 fix? If 
yes, the error comes from the string() method which comes from the gdb API. I 
don't see how to control how gdb decodes bytes.

--

___
Python tracker 

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

[issue33863] Enum doc correction relating to __members__

[Andrés Delfino]

Andrés Delfino  added the comment:

I'm not sure "ordered dictionary" is the right term. To me, "ordered 
dictionary" and "OrderedDict" are synonyms, just like "dictionary" and "dict" 
are. Documentation follows this path in several places.

You can see my reasons for this in this issue: 
https://bugs.python.org/issue33860

--

___
Python tracker 

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

[issue14102] argparse: add ability to create a man page

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

>What would cause that confusion? This is not something that would
>change how ‘argparse’ parses its arguments, so I don't know what
>you're referring to.

The (possible) confusion is the existence of a manpage only available though 
argparse (`./python foo.py --manpage`) and not systemwide. I am not sure how 
many people do something like `./python poc_2.py > output && man ./output` to 
**read** the manpage.

>This is asking that the ‘argparse’ library should have an API to
>create a manual page, for use in the build system.

At this point argparse is user facing in the sense that once configured, it 
provides functionality for the user of the command line application. My opinion 
is that it will be weird to have it provide also APIs for creating man pages 
(which is a developer utility). My humble opinion is that it if argparse starts 
to provide APIs for usage at install time is not "doing one thing and doing it 
well".

>The reason to have it in the ‘argparse’ library is that the library
>already knows how to build a single document (the ‘--help’ output)
>from the collection of arguments, so this would be just another
>rendering of that information. It makes sense to have it in the
>‘argparse’ library as an API for other tools to use

Argparse --help makes sense because people expect to use -h or --help with 
command line tools but IMHO opinion nobody expects --manpage to be the way to 
read the manpage. I do not know any command line utility that provides its 
manpage that way. If the argument is using --manpage is the way to generate 
one, then we are mixing user-facing options with developer ones.

Anyway, this is just my view of the problem, nothing more.

--

___
Python tracker 

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

[issue33863] Enum doc correction relating to __members__

[Ethan Furman]

New submission from Ethan Furman :

Checking the docs for Enum I see that section 8.13.15.3.1 says:

  `__members__` is an `OrderedDict`

which is incorrect.  It should say "an ordered dictionary".

--
messages: 319543
nosy: adelfino, barry, eli.bendersky, ethan.furman
priority: normal
severity: normal
stage: needs patch
status: open
title: Enum doc correction relating to __members__
versions: Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

[issue33862] doc Fix Enum __members__ type

[Ethan Furman]

Ethan Furman  added the comment:

Serhiy is correct.  The exact return type only needs to be ordered, and have 
appropriate dictionary methods such as `keys()`, `values()`, and `items()`.

The reason a mappingproxy was chosen is exactly because what you just tried is 
illegal and/or confusing:

- illegal because an Enum cannot be modified that way
- confusing because the dictionary returned is only a copy of the Enum class' 
__dict__, and successful attempts to modify it would not change the Enum class.

It is an implementation detail because the exact type of dictionary returned 
could change in the future.

--
assignee: docs@python -> ethan.furman
resolution:  -> not a bug
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

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

[issue30747] _Py_atomic_* not actually atomic on Windows with MSVC

[Pär Björklund]

Pär Björklund  added the comment:

The HLE variants were simply chosen to match the semantics on other
platforms with regard to aquire/release.
If Intel engineers say the plain versions are better that's good enough for
me.

It would be interesting seeing some benchmarks but I don't have any idea on
how to reliably test the non happy path.

On Thu, 14 Jun 2018, 21:32 Antoine Pitrou,  wrote:

>
> Antoine Pitrou  added the comment:
>
> I would be ok with reverting to the non-HLE variants.  Does anyone want to
> test the performance implications on TSX-enabled hardware?
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue14102] argparse: add ability to create a man page

[Ben Finney]

Ben Finney  added the comment:

On 14-Jun-2018, Pablo Galindo Salgado wrote:

> I think this should be something that is not included in argparse
> itself. I can imagine a scenario in which the manpage is accessible
> through `./python foo.py --manpage` but the manpage is not installed
> systemwide.

This bug report is not asking that ‘argparse’ install a manual page,
and it is not asking for any new command-line option in programs. So I
don't know the relevance of that point.

> This will be very confusing for users.

What would cause that confusion? This is not something that would
change how ‘argparse’ parses its arguments, so I don't know what
you're referring to.

> Generating a man page in a build script sounds like something that
> should be on its own or as a help function of the build system.

This is asking that the ‘argparse’ library should have an API to
create a manual page, for use in the build system.

The reason to have it in the ‘argparse’ library is that the library
already knows how to build a single document (the ‘--help’ output)
from the collection of arguments, so this would be just another
rendering of that information. It makes sense to have it in the
‘argparse’ library as an API for other tools to use.

--

___
Python tracker 

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

[issue30747] _Py_atomic_* not actually atomic on Windows with MSVC

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I would be ok with reverting to the non-HLE variants.  Does anyone want to test 
the performance implications on TSX-enabled hardware?

--

___
Python tracker 

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

[issue32962] test_gdb fails in debug build with `-mcet -fcf-protection -O0`

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Wouldn't be better to use the "surrogateescape" or the "backslashreplace" error 
handlers?

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue33862] doc Fix Enum __members__ type

[Andrés Delfino]

Andrés Delfino  added the comment:

I can't really say if it the return of __members__ is an implementation detail 
as there's no mention of that in the doc, but from reading the doc I think it's 
reasonable to think this is allowed:

import enum

class Colors(enum.Enum):
RED = enum.auto()
BLUE = enum.auto()

Colors.__members__['GREEN'] = enum.auto()

And the traceback:

Traceback (most recent call last):
  File "", line 1, in 
Colors.__members__['GREEN'] = enum.auto()
TypeError: 'mappingproxy' object does not support item assignment

is somewhat confusing, as the documentation says an "ordered dictionary" is to 
be returned, and the traceback talks about a mapping proxy.

--

___
Python tracker 

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

[issue27575] dict viewkeys intersection slow for large dicts

[Forest]

Change by Forest :


--
pull_requests: +7311
stage:  -> patch review

___
Python tracker 

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

[issue33862] doc Fix Enum __members__ type

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Is not returning a mappingproxy an implementation detail? The important thing 
is that the result is a mapping of names to members, and that it is ordered.

--
nosy: +barry, eli.bendersky, ethan.furman, serhiy.storchaka

___
Python tracker 

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

[issue33721] os.path.exists() ought to return False if pathname contains NUL

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

This change looks desirable to me. But it looks too large for backporting it to 
maintained versions.

--
type: behavior -> enhancement
versions: +Python 3.8 -Python 3.6

___
Python tracker 

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

[issue33721] os.path.exists() ought to return False if pathname contains NUL

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

___
Python tracker 

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

[issue33862] doc Fix Enum __members__ type

[Andrés Delfino]

Change by Andrés Delfino :


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

___
Python tracker 

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

[issue20187] The Great Argument Clinic Conversion Derby Meta-Issue

[Mark Lawrence]

Change by Mark Lawrence :


--
nosy:  -BreamoreBoy

___
Python tracker 

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

[issue8488] Docstrings of non-data descriptors "ignored"

[Sergey Fedoseev]

Change by Sergey Fedoseev :


--
nosy: +sir-sigurd

___
Python tracker 

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

[issue27777] cgi.FieldStorage can't parse simple body with Content-Length and no Content-Disposition

[Chris Eykamp]

Chris Eykamp  added the comment:

I'll get a PR submitted this weekend, and post back here.  It will not 
explicitly address that other case, as I don't have the capacity or wherewithal 
for that.  Alas.

--

___
Python tracker 

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

[issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9 files

[Tal Einat]

Tal Einat  added the comment:

IMO we should create new issues for AC conversion of the collections and random 
modules (assuming they haven't been converted yet), and close this issue.

--

___
Python tracker 

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

[issue33862] doc Fix Enum __members__ type

[Andrés Delfino]

New submission from Andrés Delfino :

Documentation says __members__ attribute returns an "ordered dictionary" but it 
returns a mappingproxy instead.

PR fixes this.

--
assignee: docs@python
components: Documentation
messages: 319532
nosy: adelfino, docs@python
priority: normal
severity: normal
status: open
title: doc Fix Enum __members__ type
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

[issue20181] Derby #12: Convert 50 sites to Argument Clinic across 4 files

[Tal Einat]

Change by Tal Einat :


--
nosy:  -taleinat

___
Python tracker 

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

[issue20177] Derby #8: Convert 28 sites to Argument Clinic across 2 files

[Tal Einat]

Change by Tal Einat :


--
nosy:  -taleinat

___
Python tracker 

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

[issue33860] doc Avoid "ordered dictionary" references now that dictionaries are ordered

[Andrés Delfino]

Andrés Delfino  added the comment:

Please note that DictReader already mentions "OrderedDict" as a type it returns 
now. I do see the issue you raise though and I'm not proposing to guarantee 
that type for next versions.

I see the benefits of using weak names, but "dictionary" alone doesn't seem 
like a good weak name to me, as it's the common name of an actual type. 
"ordered dictionary" is the common name of a type, too, which makes the 
"dictionary" in that phrase less of a weak name. Bacause of this, I don't think 
we are using weak names in the cases the PR changes.

A dict-like object must preserve insertion order as that's what dict does; 
specifying it could make people think dicts aren't ordered. I understand a 
dict-like object as if it were a dict subclass, that is, following the full 
dict API.

As to what the changes could look like with these things in mind... It's 
difficult to say without knowing which API are we actually telling people to 
rely on now: dict, dict-like, OrderedDict, OrderedDict-like?

--

___
Python tracker 

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

[issue20187] The Great Argument Clinic Conversion Derby Meta-Issue

[Tal Einat]

Change by Tal Einat :


--
nosy:  -taleinat

___
Python tracker 

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

[issue15533] subprocess.Popen(cwd) documentation: Posix vs Windows

[Gregory P. Smith]

Gregory P. Smith  added the comment:

Thanks for pointing me at this issue Ned.  It sounds like there is a behavior 
difference between Windows and POSIX systems related to the current directory 
and/or which process environment is used by the system call that launches the 
new process to find the executable.

It seems to have existed "forever" in subprocess module API terms, so I don't 
know if we should reconcile the corner cases when cwd and/or env are supplied 
to a single cross platform behavior as that could break existing code.  Such a 
behavior change _could_ be made but be 3.8 specific.  BUT:  If we did that, it 
becomes a challenge for people writing code that needs to work on multiple 
Python versions.  Popen growing yet another bool flag parameter to choose the 
new behavior is possible, but quite ugly (and unusable on multi-python version 
code).

I think we should start out by living with the difference - document these 
platform specific corner case behaviors to minimize surprise.

If we want to provide a way for people to have the same behavior on both, we 
should document a recommended way to do that.  I believe that entails telling 
people get an absolute path to their executable themselves before launching the 
subprocess as that should work the same no matter the cwd or environment?

--

___
Python tracker 

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

[issue33861] Minor improvements of tests for os.path.

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

When working on a path for issue33721 I have found that some tests for os.path 
can be improved, and these changes are worth backporting to older versions 
(3.6+).

* Test exists(), lexists(), isdir(), isfile(), islink(), ismount() with bytes 
paths.
* Remove unneeded silencing DeprecationWarning for ismount() with bytes path.
* Test common functions with unencodable and undecodable paths.
* Minor clean up and refactoring.

--
components: Tests
messages: 319529
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Minor improvements of tests for os.path.
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

[issue14102] argparse: add ability to create a man page

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

I think this should be something that is not included in argparse itself. I can 
imagine a scenario in which the manpage is accessible through `./python foo.py 
--manpage` but the manpage is not installed systemwide. This will be very 
confusing for users. Also, as Serhiy comments, argparse provides functionality 
that at this point is relevant for the enduser of the application. Generating a 
man page in a build script sounds like something that should be on its own or 
as a help function of the build system. The only thing argparse could do 
(maybe) is trying to read an already installed manpage and use that, but I 
still think that is not a good idea because it can generate conflicts and 
similar if multiple versions are installed or if the help of the package 
deviates from the manpage.

--
nosy: +pablogsal

___
Python tracker 

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

[issue33823] A BUG in concurrent/asyncio

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Python++: Sorry, I still cannot understand exactly what is wrong. Could you 
please redact a little paragraph explaining (1) what function/functions are you 
using (and maybe a very short example), (2) what is not working and (3) what do 
you expect to see instead. Sorry if it feels redundant but it will help is 
understand better the problem.

--
nosy: +pablogsal

___
Python tracker 

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

[issue33615] test__xxsubinterpreters crashed on x86 Gentoo Refleaks 3.x

[STINNER Victor]

STINNER Victor  added the comment:

It's nice to see this issue fixed :-)

--

___
Python tracker 

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

[issue33830] Error in the output of one example in the httplib docs

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
title: example output error -> Error in the output of one example in the 
httplib docs

___
Python tracker 

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

[issue33860] doc Avoid "ordered dictionary" references now that dictionaries are ordered

[INADA Naoki]

INADA Naoki  added the comment:

Sometime, we chose weak name like "file-like" or "dictionary" over 
"io.TextIOWrapper" or "dict", to avoid making future improvements harder.

If there are no strong reason to specify concrete type, let's keep using weak 
name.

In case of enum members, I want to change it to regular dict in Python 3.8, but 
I'm not sure yet.

--

___
Python tracker 

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

[issue33860] doc Avoid "ordered dictionary" references now that dictionaries are ordered

[INADA Naoki]

INADA Naoki  added the comment:

"ordered dictionary" means "dict-like object which preserves insertion order".  
Both of dict and OrderedDict is "ordered dictionary".

If we change it to OrderedDict, it make harder to change return type from 
OrderedDict to normal dict.

Do you propose we should never change return type?

--
nosy: +inada.naoki

___
Python tracker 

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

[issue33860] doc Avoid "ordered dictionary" references now that dictionaries are ordered

[Andrés Delfino]

New submission from Andrés Delfino :

IMHO, using "ordered dictionaries" references is somewhat confusing now that 
dictionaries preserve insertion order.

PR changes this references to "OrderedDict object".

--
assignee: docs@python
components: Documentation
messages: 319523
nosy: adelfino, docs@python
priority: normal
pull_requests: 7308
severity: normal
status: open
title: doc Avoid "ordered dictionary" references now that dictionaries are 
ordered
type: enhancement
versions: Python 3.7, Python 3.8

___
Python tracker 

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

[issue29750] smtplib doesn't handle unicode passwords

[david]

david  added the comment:

Yes, i used thunderbird for both

On June 14, 2018 5:14:31 PM GMT+02:00, "R. David Murray" 
 wrote:
>
>R. David Murray  added the comment:
>
>For the web cases I presume you also set the password using the web
>interface, so that doesn't really tell us anything useful.  Did you use
>thunderbird to access the mailbox that you set up via gmail and/or
>sogo?  That would make what thunderbird does the interesting question.
>
>--
>
>___
>Python tracker 
>
>___

--

___
Python tracker 

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

[issue29750] smtplib doesn't handle unicode passwords

[R. David Murray]

R. David Murray  added the comment:

For the web cases I presume you also set the password using the web interface, 
so that doesn't really tell us anything useful.  Did you use thunderbird to 
access the mailbox that you set up via gmail and/or sogo?  That would make what 
thunderbird does the interesting question.

--

___
Python tracker 

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

[issue31861] aiter() and anext() built-in functions

[Yury Selivanov]

Yury Selivanov  added the comment:

> Do these really need to be builtins?

We're only beginning to see async iterators being used in the wild, so we can't 
have a definitive answer at this point.

> They seem too specialized to be widely useful; I've personally never needed 
> them in any async code I've written. It would make more sense to me to put 
> them in a module like operators.

I think putting them to the operators module makes sense, at least for 3.8.  Do 
you want to work on a pull request?

--

___
Python tracker 

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

[issue15533] subprocess.Popen(cwd) documentation: Posix vs Windows

[Ned Deily]

Change by Ned Deily :


--
nosy: +gregory.p.smith
versions: +Python 3.8 -Python 3.5

___
Python tracker 

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

[issue31861] aiter() and anext() built-in functions

[Jelle Zijlstra]

Jelle Zijlstra  added the comment:

Do these really need to be builtins?

They seem too specialized to be widely useful; I've personally never needed 
them in any async code I've written. It would make more sense to me to put them 
in a module like operators.

--
nosy: +Jelle Zijlstra

___
Python tracker 

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

[issue33615] test__xxsubinterpreters crashed on x86 Gentoo Refleaks 3.x

[Eric Snow]

Change by Eric Snow :


--
status: pending -> closed

___
Python tracker 

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

[issue32962] test_gdb fails in debug build with `-mcet -fcf-protection -O0`

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 019d33b7a447e78057842332fb5d3bad01922122 by Victor Stinner in 
branch 'master':
bpo-32962: python-gdb catchs ValueError on read_var() (GH-7692)
https://github.com/python/cpython/commit/019d33b7a447e78057842332fb5d3bad01922122


--
nosy: +vstinner

___
Python tracker 

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

[issue32962] test_gdb fails in debug build with `-mcet -fcf-protection -O0`

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +7307

___
Python tracker 

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

[issue32962] test_gdb fails in debug build with `-mcet -fcf-protection -O0`

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +7306

___
Python tracker 

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

[issue33858] A typo in multiprocessing documentation

[aruseni]

aruseni  added the comment:

I just took a look at the most recent version of this file, and found out that 
this has already been fixed.

https://github.com/python/cpython/blob/master/Doc/library/multiprocessing.rst

--

___
Python tracker 

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

[issue29750] smtplib doesn't handle unicode passwords

[david]

david  added the comment:

Both thunderbird, sogo (web) and gmail (web).

On June 14, 2018 3:54:31 PM GMT+02:00, "R. David Murray" 
 wrote:
>
>R. David Murray  added the comment:
>
>While you are correct that latin1 may be common in this situation, I
>think it may still be better to have utf-8 be the default, since that
>is the (still emerging? :) standard.  However, you are correct to call
>for examples: if in the *majority* of the real-world cases it turns out
>latin1 is what is used, then we could default to that (or not have a
>default, but instead document our observations).
>
>I don't know how we accumulate enough information to make that
>decision, though.  Maybe we could look at what other mail programs do? 
>Thunderbird, etc?  David, which mail program(s) did you use that were
>able to successfully send that password?
>
>And yes, by binary passwords I mean that the module needs to support
>being passed a bytes-like object as the password, since clearly there
>are servers "in the wild" that support non-ascii passwords and the only
>way to be sure one can send the server the correct password is by
>treating it as a series of bytes.  The library caller will have to be
>responsible for picking the correct encoding based on local knowledge.
>
>--
>
>___
>Python tracker 
>
>___

--

___
Python tracker 

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

[issue33829] C API: provide new object protocol helper

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
nosy: +pablogsal

___
Python tracker 

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

[issue33858] A typo in multiprocessing documentation

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Could you make a PR correcting this bug? If you cannot I can do it instead. :)

--
nosy: +pablogsal

___
Python tracker 

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

[issue29750] smtplib doesn't handle unicode passwords

[R. David Murray]

R. David Murray  added the comment:

While you are correct that latin1 may be common in this situation, I think it 
may still be better to have utf-8 be the default, since that is the (still 
emerging? :) standard.  However, you are correct to call for examples: if in 
the *majority* of the real-world cases it turns out latin1 is what is used, 
then we could default to that (or not have a default, but instead document our 
observations).

I don't know how we accumulate enough information to make that decision, 
though.  Maybe we could look at what other mail programs do?  Thunderbird, etc? 
 David, which mail program(s) did you use that were able to successfully send 
that password?

And yes, by binary passwords I mean that the module needs to support being 
passed a bytes-like object as the password, since clearly there are servers "in 
the wild" that support non-ascii passwords and the only way to be sure one can 
send the server the correct password is by treating it as a series of bytes.  
The library caller will have to be responsible for picking the correct encoding 
based on local knowledge.

--

___
Python tracker 

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

[issue33721] os.path.exists() ought to return False if pathname contains NUL

[Steven D'Aprano]

Steven D'Aprano  added the comment:

Eryk Sun says:
> It has to be a ValueError since the error is an invalid parameter at the 
> Python level.

How does the first follow from the second?

Strings with NULs in them aren't errors or invalid parameters at the Python 
level, and they are legal file names in at least some file systems.

Jython does this:

>>> import os
>>> os.path.exists('/tmp/foo\0bar')
False
>>> os.stat('/tmp/foo\0bar')
Traceback (most recent call last):
  File "", line 1, in 
OSError: [Errno 2] No such file or directory: '/tmp/foo\x00bar'


As far as I am concerned, raising ValueError is simply a bug. The documentation 
for the os module clearly states:

All functions in this module raise OSError in the case of
invalid or inaccessible file names and paths, or other
arguments that have the correct type, but are not accepted
by the operating system.

I don't believe there is any good reason for singling out NULs for a different 
exception from other invalid file names like ">" on NTFS.

This ought to be an OSError for functions like os.stat and False for 
os.path.exists, as Jython does.

--

___
Python tracker 

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

[issue33721] os.path.exists() ought to return False if pathname contains NUL

[Steven D'Aprano]

Steven D'Aprano  added the comment:

Eric wrote:
> I don't know of any OS that supports NULs in filenames

HFS, HFS Plus, and Apple File System all support NULs in filenames.

HFS Plus volumes include a special special directory called the metadata 
directory, in the volume's root directory, called "\0\0\0\0HFS+ Private Data".

https://developer.apple.com/library/archive/technotes/tn/tn1150.html#HFSPlusNames

There are, I believe, Carbon APIs for checking for file names which do not rely 
on NUL-terminated strings (they use an array of Unicode characters with an 
explicit length), but I don't know enough about OS X APIs to know if they are 
current generation.

--

___
Python tracker 

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

[issue14102] argparse: add ability to create a man page

[Pavel Raiskup]

Change by Pavel Raiskup :


--
nosy: +Pavel Raiskup

___
Python tracker 

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

[issue33718] Enhance regrtest: meta-ticket for multiple changes

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 4ffe9c2b251f6e027b26250b7a2618e78d4edd22 by Victor Stinner in 
branch 'master':
bpo-33718: regrtest: use format_duration() to display failed tests (GH-7686)
https://github.com/python/cpython/commit/4ffe9c2b251f6e027b26250b7a2618e78d4edd22


--

___
Python tracker 

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

[issue33859] Spelling mistakes found using aspell

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


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

___
Python tracker 

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

[issue33859] Spelling mistakes found using aspell

[Karthikeyan Singaravelan]

New submission from Karthikeyan Singaravelan :

I have found some typos in docs folder using aspell. I have fixed them. The 
changes are as below : 

Doc/library/codecs.rst - cypher - cipher
Doc/library/email.rst - Protcol - Protocol
Doc/library/importlib.rst - abstact - abstract
Doc/library/xmlrpc.client.rst - unmarsalling - unmarshalling
Doc/license.rst - aheared to - adhered to
Doc/using/cmdline.rst - descibed - described
Doc/whatsnew/3.3.rst - accumlated - accumulated
Doc/whatsnew/3.6.rst - Lollilop - Lollipop
Doc/whatsnew/3.7.rst - direcory - directory

Find typos - 

find . -iname '*rst' | xargs -I{} sh -c "aspell --master=en_US 
--extra-dicts=en_GB --ignore 3 list < {}" | sort | uniq > typos.txt

Ignore case

tr '[:upper:]' '[:lower:]' < typos.txt | sort | uniq | less

This requires manually looking at output of less and then making changes.

--
assignee: docs@python
components: Documentation
messages: 319510
nosy: docs@python, xtreak
priority: normal
severity: normal
status: open
title: Spelling mistakes found using aspell
type: enhancement
versions: Python 3.8

___
Python tracker 

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

[issue33858] A typo in multiprocessing documentation

[aruseni]

New submission from aruseni :

https://docs.python.org/3/library/multiprocessing.html#contexts-and-start-methods

> locks created using the fork context cannot be passed to a processes started 
> using the spawn or forkserver start methods

--
assignee: docs@python
components: Documentation
messages: 319509
nosy: aruseni, docs@python
priority: normal
severity: normal
status: open
title: A typo in multiprocessing documentation
versions: Python 3.6

___
Python tracker 

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

[issue33857] python exception on Solaris : code for hash blake2b was not found

[goron]

New submission from goron :

Hi
I'm running python 3.6 on solaris and i'm always getting this error:

ERROR:root:code for hash blake2b was not found.
ValueError: unsupported hash type blake2b
ERROR:root:code for hash blake2s was not found.
ValueError: unsupported hash type blake2s

I have found that hashlib.so is missing in my library and the error is 
disappear when commenting out the import to  'blake2b' and 'blake2s' @ 
hashlib.py

Is this issue was fixed in later versions or a patches?
What should i do?
Thanks

--
components: Extension Modules
messages: 319508
nosy: goron
priority: normal
severity: normal
status: open
title: python exception on Solaris : code for hash blake2b was not found
type: behavior
versions: Python 3.6

___
Python tracker 

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

[issue24379] Add operator.subscript as a convenience for creating slices

[Tal Einat]

Tal Einat  added the comment:

So 3.8 then, or should this be closed?

FWIW I'm -1.  IMO this should be a code recipe somewhere, no need for it to be 
in the stdlib.

--

___
Python tracker 

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