date:20160531


Changes by Terry J. Reedy :


--
dependencies: +Add idlelib.interface module, Idle: add ttk widgets as an option
priority: low -> critical

___
Python tracker 

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

[issue27163] IDLE entry for What's New in Python 3.6


Changes by Terry J. Reedy :


--
components: +Documentation, IDLE -ctypes

___
Python tracker 

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

[issue26526] In parsermodule.c, replace over 2KLOC of hand-crafted validation code, with a DFA

2016-05-31 Thread A. Skrobov


A. Skrobov added the comment:

Thank you Fred for your review!

I don't have commit access myself; can anybody please commit it for me?

--

___
Python tracker 

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

[issue27148] Make VENV_DIR relative to Script directory

2016-05-31 Thread Vinay Sajip


Vinay Sajip added the comment:

Thanks for the suggestion, but I don't propose to change the way things work in 
this area, for the following reasons:

1. pyvenv tries to use the same directory layout/location of scripts as 
virtualenv does. This allows users who are used to virtualenv to have less to 
think about when switching to pyvenv.
2. Virtual environments (venvs) aren't meant to be movable. Scripts installed 
into virtual environments have the venv's absolute path hard-coded into their 
shebang. This is true for both virtualenv and pyvenv. However, a venv can 
always be created at another location and have the same stuff installed into 
it, and the old venv discarded.
3. Making changes like this would not be backwards compatible - they would 
probably break existing code which relies on a common layout between virtualenv 
and pyvenv, or the existing relative locations of script files.

--
resolution:  -> wont fix
status: open -> closed

___
Python tracker 

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

[issue24759] Idle: require tk 8.5 and ttk widgets, and drop unneeded code.


Terry J. Reedy added the comment:

In msg265349, Ned stated that running IDLE with 8.4 should no longer be a 
requirement in 3.6.  Hence the revised title and restriction to 3.6.

Serhiy, I read the code in your #24750 patch.  Should it not be enough to first 
check tkinter.Tkversion >= 8.5 before trying to import ttk. And is testing ttk 
then needed?  Is it possible for ttk to not work in 8.5/6)?

Tkversion (or a refinement thereof) is already checked in colorizer, config, 
editor, macosx, and pyshell.  With one check on startup, existing check can be 
eliminated, along with code only for older versions.

--
title: Idle: add ttk widgets as an option -> Idle: require tk 8.5 and ttk 
widgets, and drop unneeded code.
versions:  -Python 2.7, Python 3.4, Python 3.5

___
Python tracker 

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

[issue26546] Provide translated french translation on docs.python.org


Julien added the comment:

Hi,

The thread on python-ideas did not raised a long conversation, I don't think 
many english speaking people are interested in this subject, and non-english 
people are not in this list.

BWT, we translated a lot since march: translated 23% of the strings (versus 14% 
in march), and we'd like to serve a greater number of readers by hitting 
docs.python.org/fr/, so this messages is a ... bump ?

If I can help in anything, don't hesitate, but I think there's almost nothing 
left to, I already provided a patch for 
https://github.com/python/docsbuild-scripts to build the internationalized 
versions of documentation, tested it as far as I can without knowing your 
production servers by replicating the same paths on my test machine.

--

___
Python tracker 

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

[issue26546] Provide translated french translation on docs.python.org

2016-05-31 Thread STINNER Victor


STINNER Victor added the comment:

About the URL, we are only talking about 4 languages:

* english
* french
* japanese
* spanish

For docs.python.org.ar, I don't know if it's "spanish" or "spanish of 
Argentina"?

For a technical documentation, I don't expect to have a flavor of the 
docuemntation for the USA, UK, Australia, etc. It's the same for french, I only 
expect one french version. Same for japanese. For spanish, maybe we might 
support to have other flavors?

We can take a look at PHP documentation since they already support a wide 
choice of languages. English is "en", french is "fr", japanese is "jp", spanish 
is "es". Only Brazilian Portuguese uses "pt_BR".

PHP uses the URL http://php.net/manual//

I suggest to make english "implicit", the default, and don't break existing 
URLs since they are now hardcoded in many books, many websites, etc. I don't 
think that it's worth to add "/en/" and add many redirection pages.

What do you think?

--
nosy: +haypo

___
Python tracker 

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

[issue27145] long_add and long_sub might return a new int where &small_ints[x] could be returned

2016-05-31 Thread SilentGhost


Changes by SilentGhost :


--
nosy: +haypo, rhettinger
stage:  -> patch review
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

[issue25548] Show the address in the repr for class objects

2016-05-31 Thread Nofar Schnider


Changes by Nofar Schnider :


--
nosy: +Nofar Schnider

___
Python tracker 

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

[issue26632] all decorator

2016-05-31 Thread Franklin? Lee


Franklin? Lee added the comment:

BIKESHEDDING

Here is another concern with decorators and `.__module__` (or 
`inspect.getmodule`). (Or is it the original concern?)

If an earlier decorator creates a wrapper and doesn't set .__module__, you'll 
make the function public in the wrong module.

@public
@bad_wrapper
def f(...): ...


IMO, the correct solution is a new stdlib function, to get the 
currently-loading module. You wouldn't need explicit frame hacking, and it will 
be portable between different Python implementations because each 
implementation will have to define it correctly.

The problem with this solution is the lack of other usecases for such a 
function, though maybe someone in python-ideas can think of one.

Candidate owners: sys, importlib.

Candidate names:
- sys.getloadingmodule()
- importlib.currentimport()
- importlib.???()

Effect:
- Returns the "innermost" loading module. If no module is loading, returns None?
- In a thread, return the module being loaded in that thread (possibly None, 
even if other threads are loading modules).
- (I don't know what I'm talking about:) If a Python implementation uses 
multithreaded loading, each thread whose result could immediately be loaded 
into the module's namespace (i.e. it's close to the "surface" of the load) is 
considered to be loading that module.
- Needs to handle re-imports, such as from `importlib.reload`.

Other solutions include:
- Require explicit `@public(__all__)` (or `__module__`)
- Special `super()`-like treatment of `public` which automatically inserts the 
`__all__` (or whatever).
- Hope that bad wrappers don't come up.




I think nonexistence of module.__all__ should be an error.

The behavior with a module with __all__ is very different from one without, so 
I think that if you want your module to have __all__, you should be required to 
create it, even if it's empty.

Assuming that __all__ is, by convention, always near the top, someone reading 
your code would know whether the first dozen or so functions are part of the 
public interface, without searching for `@public`.

--

___
Python tracker 

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

[issue27164] zlib can't decompress DEFLATE using shared dictionary

2016-05-31 Thread Vladimir Mihailenco


New submission from Vladimir Mihailenco:

Consider following code:

```
import zlib


hello = b'hello'

# Compress data using deflate and shared/predefined dict.
co = zlib.compressobj(wbits=-zlib.MAX_WBITS, zdict=hello)
data = co.compress(hello) + co.flush()

# Decompress deflate by providing same dict.
do = zlib.decompressobj(wbits=-zlib.MAX_WBITS, zdict=hello)
data = do.decompress(data)

print(data)
```

Decompression fails with "zlib.error: Error -3 while decompressing data: 
invalid distance too far back".

My original task was to decompress data I get from Golang library - 
https://golang.org/pkg/compress/flate/#NewWriterDict

--
components: Library (Lib)
messages: 266747
nosy: Vladimir Mihailenco
priority: normal
severity: normal
status: open
title: zlib can't decompress DEFLATE using shared dictionary
type: behavior
versions: Python 3.5

___
Python tracker 

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

[issue26546] Provide translated french translation on docs.python.org


Julien added the comment:

> About the URL, we are only talking about 4 languages

Yes, and other are clearly not ready to be merged, I still don't know if they 
want it to happen soon.

> For docs.python.org.ar, I don't know if it's "spanish" or "spanish of 
> Argentina"?

Same conclusion: I don't know either, but let them decide. In all cases, we'll 
not merge them until they ask for it, so, probably not even this year. Let's do 
things one by one, showing the way. (Personally I think we may propose them 
/es/, and if a es_ES version shows up, move `/es/` to `/es-ar/` and give `/es/` 
to es_ES, but that may just never happen...).

> For a technical documentation, I don't expect to have a flavor of the 
> docuemntation [...] English is "en", french is "fr", japanese is "jp", 
> spanish is "es". Only Brazilian Portuguese uses "pt_BR".

Yes [my 
proposition](https://mail.python.org/pipermail/python-ideas/2016-March/038879.html)
 has a whole paragraph about "Dropping the default locale of a language". 
Around the same subject, it's still undecided if we use a dash (IETF format) or 
an underscore (gettext format) to separate language and locale, but as we only 
have "fr" from now, we don't really have to decide today. We'll have to decide 
when we'll merge "pt-br" which does not even exists (one of some few languages 
having a "mandatory locale part").

> I suggest to make english "implicit", the default, and don't break existing 
> URLs

+1, we do not need to break anything, let's just don't add `/en/` for 
"upstream" documentation, that's in fact what my proposed patch does.

> What do you think?

Look like we agree on all points.

--

___
Python tracker 

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

[issue27165] Skip callables when displaying exception fields in cgitb

2016-05-31 Thread Adam Bielański


New submission from Adam Bielański:

Issue: cgitb text formatter outputs all members of exception object, using 
standard dir() to get their names.

My patch changes its behaviour to skip fields which are callable, since 
printing them only clutters the output but is rarely helpful.


HTML formatter skips members starting with underscore (_), which is slightly 
different behaviour and I can alter my patch to make both formatters behave in 
the same way, should the need be. Both can skip members starting with 
underscore, callables, or callables and values starting with underscore - any 
option will be better than printing them all.


Current change alters output for exception value Exception("123412312") from:

: 123412312
__class__ = 
__delattr__ = 
__dict__ = {}
__doc__ = 'Common base class for all non-exit exceptions.'
__format__ = 
__getattribute__ = 
__getitem__ = 
__getslice__ = 
__hash__ = 
__init__ = 
__new__ = 
__reduce__ = 
__reduce_ex__ = 
__repr__ = 
__setattr__ = 
__setstate__ = 
__sizeof__ = 
__str__ = 
__subclasshook__ = 
__unicode__ = 
args = ('123412312',)
message = '123412312'


to:

: 123412312
__dict__ = {}
__doc__ = 'Common base class for all non-exit exceptions.'
args = ('123412312',)
message = '123412312'

--
components: Library (Lib)
files: cgitb.diff
keywords: patch
messages: 266749
nosy: Adam.Bielański
priority: normal
severity: normal
status: open
title: Skip callables when displaying exception fields in cgitb
type: enhancement
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file43065/cgitb.diff

___
Python tracker 

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

[issue27164] zlib can't decompress DEFLATE using shared dictionary

2016-05-31 Thread Xiang Zhang


Changes by Xiang Zhang :


--
nosy: +xiang.zhang

___
Python tracker 

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

[issue24291] Many servers (wsgiref, http.server, etc) can truncate large output blobs


Martin Panter added the comment:

Here is a patch for just the wsgiref module, which I plan to commit in time for 
3.5.2. I also updated the test case to avoid hanging due to a (theoretical) 
race with how signal handling works.

--
Added file: http://bugs.python.org/file43066/wsgiref-only.patch

___
Python tracker 

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

[issue27166] interesting info

2016-05-31 Thread Rogi


New submission from Rogi:

Hi, I found some info and I thought it might be interesting for you, please 
read more at 

r...@linuxmail.org

--
messages: 266751
nosy: Rogi
priority: normal
severity: normal
status: open
title: interesting info

___
Python tracker 

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

[issue26556] Update expat to 2.2.1

2016-05-31 Thread Mirko Dziadzka


Changes by Mirko Dziadzka :


--
nosy: +mirko.dziadzka

___
Python tracker 

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

[issue27166] interesting info

2016-05-31 Thread Emanuel Barry


Changes by Emanuel Barry :


--
Removed message: http://bugs.python.org/msg266751

___
Python tracker 

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

[issue27166] interesting info

2016-05-31 Thread Emanuel Barry


Changes by Emanuel Barry :


--
resolution:  -> not a bug
stage:  -> 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

[issue27145] long_add and long_sub might return a new int where &small_ints[x] could be returned

2016-05-31 Thread STINNER Victor


Changes by STINNER Victor :


--
nosy: +yselivanov

___
Python tracker 

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

[issue27166] Spam

2016-05-31 Thread Zachary Ware


Changes by Zachary Ware :


--
nosy:  -Rogi
title: interesting info -> Spam

___
Python tracker 

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

[issue16182] readline: Wrong tab completion scope indices in Unicode terminals


Martin Panter added the comment:

Attached patch adds a possible test, and fixes the truncation problem I 
mentioned above.

I tried testing set_completer_delims() with a UTF-8 locale, but I suspect Gnu 
Readline does not support it. I called set_completer_delims("\xF6"), which 
encodes as C3 B6, but it seems to be breaking any UTF-8 sequence in half at a 
C3 byte. In other words, it is treating the delimiter list as a list of bytes, 
not code points. So I changed to an ASCII delimiter.

--
Added file: http://bugs.python.org/file43067/readline_locale.v2.patch

___
Python tracker 

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

[issue16182] readline: Wrong tab completion scope indices in Unicode terminals


Changes by Martin Panter :


Added file: http://bugs.python.org/file43068/readline_locale.v2.patch

___
Python tracker 

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

[issue16182] readline: Wrong tab completion scope indices in Unicode terminals


Changes by Martin Panter :


Removed file: http://bugs.python.org/file43067/readline_locale.v2.patch

___
Python tracker 

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

[issue23459] Linux: expose the new execveat() syscall


R. David Murray added the comment:

Yes, last paragraph of that section.  It doesn't mention fexecve explicitly 
because it doesn't need to, the functionality is what matters.

--

___
Python tracker 

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

[issue26526] In parsermodule.c, replace over 2KLOC of hand-crafted validation code, with a DFA

2016-05-31 Thread A. Skrobov


Changes by A. Skrobov :


--
keywords: +patch
Added file: http://bugs.python.org/file43069/issue26526_16704_63395.diff

___
Python tracker 

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

[issue27161] Confusing exception in Path().with_name


R. David Murray added the comment:

It's a resaonable approach, but I question if the gain is worth the chance of 
introducing bugs (behavior changes...for example, a None argument would be 
handled differently by the patch).

--

___
Python tracker 

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

[issue26546] Provide translated french translation on docs.python.org


Terry J. Reedy added the comment:

>From what I know of regional and country variations in spanish, the main 
>grammatical differences are in usages, such as the informal plural 2nd person, 
>that need not appear in a techical manual.  I don't know about recently 
>acquired technical terms.  From reading pyar for awhile, I also know that it 
>has participants from all over latin america, so I suspect that their 
>translation is not necessarily Argentina-specific.  Conclusion: we (pydev) 
>should not worry until there is an actual conflict from competing translations.

The patch has this table:

+   # version, target, isdev
+   ('3.4', WWWROOT + "/3.4", False),
+   ('3.5', WWWROOT + "/3.5", False),
+   ('3.6', WWWROOT + "/3.6", True),
+   ('2.7', WWWROOT + "/2.7", False)

Why is 3.4 included, given that it now has the same status as 3.3?
Would it not be easier to default to False and only list 3.6?
Is it because you maintain separate branches for different 3.x branches?  Given 
the presence of Version Changed and Version Added paragraphs, that is almost 
unnecessary.  (Not having Version Deleted items is the main reason they might 
be.)

Is/are the main author/maintainer(s) of build_docs.py already nosy on the 
issue, to review?  I cannot even though at least mildly interested.
(The disconnect between interest and technical expertise is part of the problem 
with translation issues.)

There is no Rietveld review link for the patch.  I do not know if it is the 
form of the patch or the target file.  Viktor, do you?  If not, someone on the 
core-mentorship list would.

--

___
Python tracker 

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

[issue26632] @public - an all decorator

2016-05-31 Thread Barry A. Warsaw


Barry A. Warsaw added the comment:

I'm going to go ahead and close this issue.  There wasn't much positive 
reception to @public in the Pycon 2016 language summit (where I presented it as 
a lightning talk).

https://gitlab.com/warsaw/public

Some of the other ideas for changes to Python may still be valid, but they 
would be best discussed under a new issue.

--
resolution:  -> wont fix
status: open -> closed
title: __all__ decorator -> @public - an __all__ decorator

___
Python tracker 

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

[issue26546] Provide translated french translation on docs.python.org

2016-05-31 Thread Zachary Ware


Zachary Ware added the comment:

I think you should submit this as a PR against docsbuild-scripts, it will be 
easier to review there.

--
nosy: +zach.ware

___
Python tracker 

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

[issue27167] subprocess reports signal as negative exit status, not documented

2016-05-31 Thread David MacKenzie


New submission from David MacKenzie:

If a command run by subprocess.check_call() exits because of a signal, e.g. 
SIGPIPE, Popen._handle_exitstatus() encodes the signal number as a negative 
return code. check_call() then raises that as a CalledProcessError, which 
describes it as "returned non-zero exit status -13". This is misleading and 
undocumented. 

CalledProcessError.__str__() should check if self.returncode is negative and if 
so return a string indicating that it was "signal 13", not "exit status -13". 
Better yet, it should include the descriptive name of the signal, e.g., SIGPIPE.

And, the documentation for the subprocess module should note that a signal is 
converted into a negative returncode.

--
components: Library (Lib)
messages: 266758
nosy: dmacnet
priority: normal
severity: normal
status: open
title: subprocess reports signal as negative exit status, not documented
type: behavior
versions: Python 3.5

___
Python tracker 

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

[issue26546] Provide translated french translation on docs.python.org


Julien added the comment:

> From what I know of regional and country variations in spanish, [...] we 
> (pydev) should not worry until there is an actual conflict from competing 
> translations.

Totally agree.

> The patch has this table:

> +   # version, target, isdev
> +   ('3.4', WWWROOT + "/3.4", False),
> +   ('3.5', WWWROOT + "/3.5", False),
> +   ('3.6', WWWROOT + "/3.6", True),
> +   ('2.7', WWWROOT + "/2.7", False)

Yes, it sticks to the current style: 
https://github.com/python/docsbuild-scripts/blob/master/build_docs.py#L33

> Why is 3.4 included, given that it now has the same status as 3.3?

What do you mean with "the same status" ? From my translator point of view, 
they still diverges, like in `Doc/library/zlib.rst:233`:

< "If the optional parameter *max_length* is supplied then the return value "
---
> "If the optional parameter *max_length* is non-zero then the return value "

And I don't think we can rely on certain releases being theorically identical 
to others, it look like an exception, look like it's not always true. I still 
prefer having a [clear tree of versions](https://github.com/AFPy/python_doc_fr) 
but we're (humans) only translating the latest version, we have scripts 
replicating our work to others.

Yet, if you tell me that there's work ongoing (that I clearly missed) to have 
every documentations, like by major version, converge to single one, with just 
some paragraphs added, it may simplify my hierarchy.

> Would it not be easier to default to False and only list 3.6?

Again I stick to the current style of the script, so ease its reading as a 
whole, but I agree, if we change it, let change it in another commit?

> Is it because you maintain separate branches for different 3.x branches?  
> Given the presence of Version Changed and Version Added paragraphs, that is 
> almost unnecessary.  (Not having Version Deleted items is the main reason 
> they might be.)

I am not aware of "Version Added" and "Version Changed" paragraphs, I 
understand that this is a policy to only add new paragraphs and never modify 
them inside the `3` major version ? This is cool for me, as said in my last 
paragraph, it may reduce the number of versionned `.po`, but it will not change 
the human workload (script replicating between po files ...).

> Is/are the main author/maintainer(s) of build_docs.py already nosy on the 
> issue, to review?

Yes, I soon `nosy`ed Benjamin Peterson, look like he's the father of this 
script, if we trust commits here: 
https://github.com/python/docsbuild-scripts/commits/master

I even mailed him personally to speak about it (and he even replied once), but 
he's probably highly busy, and this is something I can understand. So here is 
my call on the issue to try to move this issue forward (I try to push this 
project less than once a month, to avoid buzzing everyone ears with this 
non-critical issue...).

> I cannot even though at least mildly interested. (The disconnect between 
> interest and technical expertise is part of the problem with translation 
> issues.)

Yes I also fully understand that the french translation of the documentation is 
not a point of interest for most of you upstream ^^ don't worry.

--

___
Python tracker 

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

[issue27167] subprocess reports signal as negative exit status, not documented

2016-05-31 Thread Gregory P. Smith


Gregory P. Smith added the comment:

I'll take this as a documentation update for 3.5 and a feature request for 
better message text in 3.6.

--
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith
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

[issue26700] Make digest_size a class variable

2016-05-31 Thread Gregory P. Smith


Gregory P. Smith added the comment:

+cc Christian Heimes: do the upcoming standard hash functions amenable to a 
constant class attribute digest_size?

Are any of the expected future hashes variable length from a single class / 
constructor function?

--
nosy: +christian.heimes

___
Python tracker 

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

[issue26700] Make digest_size a class variable

2016-05-31 Thread Christian Heimes


Christian Heimes added the comment:

Not all hash functions have a fixed digest size, e.g. blake2 is a variable 
length hash algorithm. 
https://pythonhosted.org/pyblake2/examples.html#using-different-digest-sizes 
How about a new class attribute default_digest_size?

--

___
Python tracker 

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

[issue27168] Yury isn't sure comprehensions and await interact correctly

2016-05-31 Thread Nathaniel Smith


New submission from Nathaniel Smith:

So he asked me to file a bug reminding him to write more unit tests.

Interesting cases:

async def f():
return (x for x in await g())

async def f():
return (await x for x in g())

(and ditto for [], {} comprehensions)

--
components: Interpreter Core
messages: 266763
nosy: njs, yselivanov
priority: normal
severity: normal
status: open
title: Yury isn't sure comprehensions and await interact correctly
versions: Python 3.5, Python 3.6

___
Python tracker 

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

[issue26546] Provide translated french translation on docs.python.org


Julien added the comment:

@zach.ware done: https://github.com/python/docsbuild-scripts/pull/1

--

___
Python tracker 

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

[issue27161] Confusing exception in Path().with_name

2016-05-31 Thread Antony Lee


Antony Lee added the comment:

Would it?  Note that splitroot is not public, and some quick tests did not show 
any other behavior difference from the public API side.

--

___
Python tracker 

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

[issue27161] Confusing exception in Path().with_name

2016-05-31 Thread Serhiy Storchaka


Serhiy Storchaka added the comment:

The "part and part[0] == sep" check is here for speed. pathlib-splitroot.patch 
removes this optimization.

--
nosy: +pitrou, serhiy.storchaka

___
Python tracker 

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

[issue27161] Confusing exception in Path().with_name

2016-05-31 Thread Antony Lee


Antony Lee added the comment:

First, I doubt that this optimization actually changes anything measurable, but 
if you want you can always replace that line by "if part.startswith(sep)" (also 
solving the original issue).

Additionally, note that `parse_parts` (the only function to call `splitroot` 
already (and redundantly) checks that `part` is truthy before calling 
`splitroot`.  There are a couple of other "optimizations" in the same function 
(`if x and x != '.'`, `if rel and rel != '.'`) for which I'd be surprised if 
they truly mattered.

--

___
Python tracker 

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

[issue26176] EmailMessage example doesn't work

2016-05-31 Thread Nathan Harold


Nathan Harold added the comment:

emailexample.patch fixes the specific issue mentioned in #26426: the Address 
constructor is now used as documented.  It changes the final output of the two 
combined examples (as presented in the documentation) accordingly.

In general it seems as though these examples (the two in in 19.1.14.1) were 
meant to be read, not run.  To run them, the user would have to supply (1) 
their own roasted-asparagus.jpg, (2) their own local SMTP server, and (3) their 
own implementation of imaginary.magic_html_parser.  However, the Address 
constructor usage issue was real, and I was able to generate the relevant 
output without (2) and (3).

--
keywords: +patch
nosy: +nharold
Added file: http://bugs.python.org/file43070/emailexample.patch

___
Python tracker 

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

[issue27169] debug is not optimized out at compile time for anything but `if:` and `while:` blocks


New submission from Josh Rosenberg:

Issue #22091 points out a quirk in the compile function and use of the 
__debug__ "constant" causing inconsistent behavior when the optimize level of 
the compile call differs from that of the main interpreter; __debug__ in an 
`if` or `while` statement is compiled out, but all other uses load it 
dynamically (at runtime), so in a mixed environment (interpreter at 
optimization=0, compile at optimize=2), you get non-obvious behavior.

This behavior appears to be a consequence of __debug__ being handled by a 
special case for the `if` and `while` statements in compile.c that statements 
of that form to be compiled out, but *not* for similar constructs, e.g. `a if 
__debug__ else b` and `__debug__ or a` are always evaluated at runtime, whether 
or not `compile` is involved. The `expr_constant` function here 
https://hg.python.org/cpython/file/fd0ac7ba091e/Python/compile.c#l3542 is 
responsible for this (and only called in the same file, for `if` and `while` 
statements).

I'm not sure I understand the peephole optimizer, but if it can operate 
recursively (that is, an initial replacement of A->B where B could be optimized 
from B->C is optimized in a subsequent pass, turning all uses of A to C 
eventually), it seems like the "correct" solution would be to piggyback on 
optimizations for True and False, by having the peephole optimizer replace 
LOAD_NAME/LOAD_GLOBAL for __debug__ with an appropriate LOAD_CONST, True or 
False, based on the compile environment. This would fix this bug (making 
__debug__ evaluate in the `compile` call, so the environment when the compiled 
code is executed doesn't matter), and it would optimize all the other cases 
that the current special cases for `if` and `while` don't cover by letting the 
recursive pass optimize them out the same way uses of literal True and False is 
optimized, so uses of ternary expressions, non-`if`/`while` boolean operations, 
and all other operations using __debug__ are optimized using a constant (and 
poss
 ibly optimized out of existence) without needing to independently maintain 
separate optimizations all over the codebase for __debug__. Might also allow 
the removal of the explicit special case for __debug__ in compile.c for `if` 
and `while`, simplifying that code a bit.

This would fix the problem from #22091 and also make __debug__ reliably useful 
for "optimization", since all uses of it would "compile out" to optimized 
runtime code, where right now only two cases do so.

Does this seem reasonable?

Note: I added the nosy list from #22091 here, since that bug is really just a 
special case of this one for `compile` only.

--
components: Interpreter Core
messages: 266769
nosy: SilentGhost, arigo, eryksun, josh.r
priority: normal
severity: normal
status: open
title: __debug__ is not optimized out at compile time for anything but `if:` 
and `while:` blocks
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

[issue22091] debug in compile(optimize=1)


Josh Rosenberg added the comment:

I just opened #27169: "__debug__ is not optimized out at compile time for 
anything but `if:` and `while:` blocks" as a more general case of this bug.

This bug covers inconsistent behavior, but ultimately, it's caused by 
incomplete optimization: `__debug__` doesn't act as a compile time constant 
outside of `if:` and `while:` blocks, so the behavior is inconsistent for all 
other uses in the `compile` case where `optimize` doesn't match the main 
interpreter session, and inefficient for all other uses whether or not 
`compile` is involved.

If #27169 is resolved as I suggested (or in some other similar way), it would 
also resolve this bug.

--
nosy: +josh.r

___
Python tracker 

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

[issue27169] debug is not optimized out at compile time for anything but `if:` and `while:` blocks

2016-05-31 Thread Serhiy Storchaka


Serhiy Storchaka added the comment:

I think that the complete solution of this problem is making __debug__ a named 
constant like None, True, False.

This needs changing the grammar of Python.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue24882] ThreadPoolExecutor doesn't reuse threads until #threads == max_workers


Josh Rosenberg added the comment:

Is there a good reason to worry about overeager worker spawning? 
ProcessPoolExecutor spawns all workers when the first work item is submitted ( 
https://hg.python.org/cpython/file/3.4/Lib/concurrent/futures/process.py#l361 
), only ThreadPoolExecutor even makes an effort to limit the number of threads 
spawned. Threads are typically more lightweight than processes, and with the 
recent GIL improvements, the CPython specific costs associated with threads 
(particularly threads that are just sitting around waiting on a lock) are 
fairly minimal.

It just seems like if eager process spawning isn't a problem, neither is 
(cheaper) eager thread spawning.

--
nosy: +josh.r

___
Python tracker 

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

[issue27170] IDLE: remove Toggle Auto Coloring or add to edit menu & doc

New submission from Terry J. Reedy:

On Stackoverflow, person asked why syntax coloring sometimes stopped working,
seemingly at random.
https://stackoverflow.com/questions/37511276/how-to-make-python-idle-editor-to-change-line-colors-according-to-the-color-map

The OP finally traced the problem to hitting ctrl-/ because of habit from using
PyCharm, which bind ^/ to something else. In IDLE, cntrl-/ is bound to
<>, but that is not easy to discover. (If I ever halfway
knew about it, I had forgotten.) There is no menu entry and, I am sure, no
mention in the doc. There is only the hard-to-search list in the Keys tab of
the configuration dialog. T think that this feature should either be visible
on the menu and documented and enhanced, or deleted.

I am currently inclined to delete it as I cannot see hardly any use, and doubt
that is sees real use, especially by beginners. It only affects the current
window. It only affects future keystrokes (and pasted text), leaving current
colorization as is. There is no indication that coloring is off until one
types something that should be colored, and many will not know all the fine
details. (This is why the SO OP had trouble pinning down the trigger.) If the
toggle is kept, there should be an indication added to the status bar.

Searching all IDLE issues for 'toggle' returned 24 hits, none for color. I
should check hg annotate for the author of the code and issue #, if not part of
the original submission.

--
components: 2to3 (2.x to 3.x conversion tool)
messages: 266773
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: IDLE: remove Toggle Auto Coloring or add to edit menu & doc
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

[issue10109] itertools.product with infinite iterator cause MemoryError.

2016-05-31 Thread Lucas Wiman


Lucas Wiman added the comment:

I realize this is an old (and closed!) thread, but here are a few notes from 
running into this issue recently, working on a search problem with infinite 
iterators.

First, note that yegle's recursive solution is not correct, since it exhausts 
the iterators:
>>> def product(*args):
... if len(args) == 1:
... for i in args[0]:
... yield [i]
... else:
... for i in args[0]:
... for j in product(*args[1:]):
... j.append(i)
... yield j
... 
>>> 
>>> assert len(list(itertools.product(*[iter(range(2)) for _ in range(10)]))) 
>>> == 2 ** 10
>>> assert len(list(product(*[iter(range(2)) for _ in range(10)]))) == 2 ** 10
Traceback (most recent call last):
  File "", line 1, in 
AssertionError

This is fairly tricky to get right, and even a correct fully-lazy solution 
requires each iterator to eventually be fully stored in memory. For that 
reason, Sumudu's MemoryError is not something that can be easily escaped, 
though it can be delayed.

For infinite iterators, the naive "lexicographic" solution to product(count(0), 
count(0)) would never get to 1 on the first iterator, yielding (0, 0), (0, 1), 
(0, 2), ...  To fully explore the space, the user needs to think about how to 
iterate over that space, so IMO keeping infinite iterators as invalid arguments 
to itertools.product makes sense.

--
nosy: +Lucas Wiman

___
Python tracker 

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

[issue26546] Provide translated french translation on docs.python.org


Terry J. Reedy added the comment:

By 'same status', I meant that 3.4 is on 'security maintenance', just like 3.3 
and 3.2.  But do whatever a reviewer wants.

Some people are busy at PyCon this week.  Anyway, I think Zack pointed you in 
the right direction.

--

___
Python tracker 

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

[issue27161] Confusing exception in Path().with_name


R. David Murray added the comment:

Just because it isn't public doesn't mean no one calls it :).  But seriously, 
that's why I said "the risk".  Is the small benefit of the codechange worth the 
small risk of breaking something?  I'm not answering that question, I'm posing 
it.  Call me -0 on the change.

I agree that the optimization argument doesn't really seem relevant.  If 
someone cares about performance they aren't going to be using pathlib.

--

___
Python tracker 

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

[issue27161] Confusing exception in Path().with_name


R. David Murray added the comment:

To clarify that performance statement: if someone is optimizing a tight loop, 
the first thing they'll likely do is drop down to the lower level calls to 
avoid all of the pathlib overhead.

--

___
Python tracker 

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

[issue27099] IDLE: turn builting extensions into regular modules


Terry J. Reedy added the comment:

The version conflict problem is why I reverted changing 'extension names' to 
match the new file names, before rebase collapsing my patches.  I was really 
glad most were in a separate patch.

Each time a feature ceases to be an extension, the (old) extension name will 
have to be added to a set of names ignored when calculating the set of 
extensions.  I will start with one until I have worked out and tested the 
details.

--

___
Python tracker 

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

[issue26176] EmailMessage example doesn't work


R. David Murray added the comment:

Thank you for the patch.  I blame the mistake on too great a familiarity with 
the old API :)

--
nosy: +r.david.murray

___
Python tracker 

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

[issue26176] EmailMessage example doesn't work


Changes by R. David Murray :


--
stage: needs patch -> commit review

___
Python tracker 

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

[issue27169] debug is not optimized out at compile time for anything but `if:` and `while:` blocks


Josh Rosenberg added the comment:

That would also work. The argument I'd give in favor of performing a pass that 
replaces it with a literal True or False is that you don't have update as many 
places, don't have to worry about missing a place, and you don't have to decide 
if __debug__ is a reference to True or False, or a new object entirely.

It's just too easy to miss a case where __debug__ should be special and not 
notice (because optimizations aren't heavily tested for specific byte code 
outputs or anything), where a missed optimization for the True or False 
constant is much less likely to go unnoticed.

--

___
Python tracker 

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

[issue22232] str.splitlines splitting on non-\r\n characters

2016-05-31 Thread Alexander Schrijver


Alexander Schrijver added the comment:

This diff updates the cpython (tip) documentation to document the different 
behaviour when using splitlines on bytes objects or string objects.

--
keywords: +patch
nosy: +Alexander Schrijver
Added file: http://bugs.python.org/file43071/cpython3.5_splitlines.diff

___
Python tracker 

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

[issue22232] str.splitlines splitting on non-\r\n characters

2016-05-31 Thread Alexander Schrijver


Alexander Schrijver added the comment:

This diff synchronizes the cpython 2.7 with that from 3.5 and also describes 
the difference between bytes objects and unicode objects (from the other diff)

--
Added file: http://bugs.python.org/file43072/cpython3.5_splitlines.diff

___
Python tracker 

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

[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)

2016-05-31 Thread Michael Felt


Michael Felt added the comment:

As a separate file in the hope it re-fits into Mercurial better

--
Added file: http://bugs.python.org/file43073/aixutil.py

___
Python tracker 

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

[issue22232] str.splitlines splitting on non-\r\n characters

2016-05-31 Thread Alexander Schrijver


Alexander Schrijver added the comment:

Oops, wrong diff. Sorry, this is the correct one for 2.7.

--
Added file: http://bugs.python.org/file43075/cpython2.7_splitlines.diff

___
Python tracker 

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

[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)

2016-05-31 Thread Michael Felt


Michael Felt added the comment:

without aixutil.py - hopefully better for Mercurial import

--
Added file: http://bugs.python.org/file43074/Python2.Lib.ctypes.160531.patch

___
Python tracker 

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

[issue26739] idle: Errno 10035 a non-blocking socket operation could not be completed immediately

2016-05-31 Thread MICHAEL JACOBSON


MICHAEL JACOBSON added the comment:

Kristján, when you say 'dead or dying code', it worries me a lot.  Can you tell 
me what you mean because I do NOT want to reinstall IDLE.

--

___
Python tracker 

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

[issue26739] idle: Errno 10035 a non-blocking socket operation could not be completed immediately

2016-05-31 Thread MICHAEL JACOBSON


MICHAEL JACOBSON added the comment:

I also do not want to change something in the /lib folder because that is like 
going into the Windows Registry and 'fixing' a bunch of stuff.

I've made other games with PyGame and they generate errno 10035, too.
I've also installed the same version of Python, on a newer computer.
It is a Windows 10, ex-8.1
I haven't finished the program on my newer computer.

--

___
Python tracker 

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

[issue26739] idle: Errno 10035 a non-blocking socket operation could not be completed immediately

2016-05-31 Thread Zachary Ware


Zachary Ware added the comment:

If you're still using 2.7.5, we can't help you.  If you can reproduce the issue 
with 2.7.11 or 3.5.1, please reopen.

--
resolution:  -> out of date
stage:  -> resolved
status: open -> closed
type: resource usage -> behavior

___
Python tracker 

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

[issue22232] str.splitlines splitting on non-\r\n characters


Martin Panter added the comment:

For Python 3, the bytes.splitlines() and bytearray.splitlines() documentation 
has been moved to a separate section out (Issue 21777). I don’t think it is 
good to add much detail of bytes.splitlines() in the str.splitlines() 
documentation.

For Python 2, perhaps see Matthew’s patches for 2.7 in Issue 12855. IMO we 
could reopen that bug if that helps, because only the Python 3 branches were 
comitted.

--

___
Python tracker 

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

[issue27170] IDLE: remove Toggle Auto Coloring or add to edit menu & doc


Terry J. Reedy added the comment:

Looking more, there are lots of editor bindings that are not on the menu that 
are more important than this.  Example: Center insert, ^L, scrolls text to 
bring insert cursor as close to the middle of the window as possible.  It does 
move the position of the cursor within the doc.  I discovered the existence of 
this and determined its actual behavior by reading the code.

Some are listed in the doc, section '2. Editing and navigation'. Anything that 
can be user configured can be discovered, but not everything is.

If this feature is kept, it should be on a submenu with other missing items.

--

___
Python tracker 

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

[issue26739] idle: Errno 10035 a non-blocking socket operation could not be completed immediately


Terry J. Reedy added the comment:

Michael, IDLE is not dead, and I am working steadily to modernize it inside and 
out for 3.6.  There have even been improvements for 2.7 since 2.7.5.  For his 
work, Kristján has had no reason to keep up to date on IDLE's progress.

--

___
Python tracker 

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

[issue24225] Idlelib: changing file names

2016-05-31 Thread Roundup Robot


Roundup Robot added the comment:

New changeset 20bd4c23cfe4 by Terry Jan Reedy in branch 'default':
Issue # 24225: Update idlelib.README.txt with new file names and event handlers.
https://hg.python.org/cpython/rev/20bd4c23cfe4

--

___
Python tracker 

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

[issue25570] urllib.request > Request.add_header("abcd", "efgh") fails with character ":" in first parameter string


Berker Peksag added the comment:

add_header.patch looks good to me. Thanks Martin.

--
nosy: +berker.peksag
stage: patch review -> commit review
versions:  -Python 3.4

___
Python tracker 

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

[issue24225] Idlelib: changing file names


Terry J. Reedy added the comment:

I brought IDLE news entries up to date 2 days ago.  This patch updates 
README.txt with the new names and many new entries for event handlers.  A 
What's New entry needs to wait for more patches, and is the subject of #27163.  
This completes the 'still to do' list in msg266572.

--
resolution:  -> fixed
stage: needs patch -> 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

[issue20683] Add example to tutorial namespace doc, section 9.2


Berker Peksag added the comment:

Thanks for the report, Karl. Could you give more details about what's missing? 
The section gives some examples of namespaces:

[...] the set of built-in names (containing functions such as abs(), and 
built-in exception names); the global names in a module; and the local names in 
a function invocation.

I'm not sure if it's worth to convert them to code examples.

--
nosy: +berker.peksag
status: open -> pending

___
Python tracker 

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

[issue5996] abstract class instantiable when subclassing dict

2016-05-31 Thread Luiz Poleto


Changes by Luiz Poleto :


--
nosy: +luiz.poleto

___
Python tracker 

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

[issue20496] function definition tutorial encourages bad practice


Berker Peksag added the comment:

I agree with Terry. The print example is also useful to show the implicit 
return value of fib(). Quoting from the same section:

[...] In fact, even functions without a return statement do return a value, 
albeit a rather boring one. This value is called None [...]

--
nosy: +berker.peksag
resolution:  -> not a bug
stage:  -> 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

[issue17383] Possibly ambiguous phrasing in tutorial/modules#more-on-modules


Changes by Berker Peksag :


--
nosy: +berker.peksag
stage: patch review -> needs patch
type:  -> behavior
versions: +Python 3.5, Python 3.6

___
Python tracker 

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

[issue27171] Fix various typos


New submission from Martin Panter:

This fixes various spelling mistakes in documentation, code comments, and test 
function names.

There is also a correction to an exception message in 
Modules/_ctypes/callproc.c, which I propose to fix only in 3.6.

--
files: typos.py3.patch
keywords: patch
messages: 266797
nosy: martin.panter
priority: normal
severity: normal
stage: patch review
status: open
title: Fix various typos
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file43076/typos.py3.patch

___
Python tracker 

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

[issue27171] Fix various typos


Changes by Martin Panter :


Added file: http://bugs.python.org/file43077/typos.py2.patch

___
Python tracker 

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

[issue7769] SimpleXMLRPCServer.SimpleXMLRPCServer.register_function as decorator