[issue17972] inspect module docs omits many functions

[Paul Rudin]

Paul Rudin  added the comment:

If some are to be considered private then the questions are: which ones and how 
to fix. Presumably renaming to start with "_" might break existing code, so 
maybe adding an __all__, and just including the public objects is better? That 
could break code existing relying on * imports I suppose. Deprecation is 
another possibility, although feels a little odd for things never documented.

formatannotation and formatannotationrelativeto look like a helper functions 
for formatargspec and are probably not intended as part of the public interface.

Similarly walktree looks like a helper for getclasstree (and its docstring 
describes it as such).

--
nosy: +PaulRudin

___
Python tracker 

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

[issue32491] base64.decode: linebreaks are not ignored

[Martin Panter]

Martin Panter  added the comment:

I wrote an incremental base-64 decoder for the "codecs" module in Issue 27799, 
which you could use. It just does some preprocessing using a regular expression 
to pick four-character chunks before passing the data to a2b_base64. Or maybe 
implementing it properly in the "binascii" module is better.

Quickly reading RFC 2045, I saw it says "All line breaks or other characters 
not found in Table 1 [64 alphabet characters plus padding character] must be 
ignored by decoding software." So this is a real bug, although I think a 
base-64 encoder that triggers it would be rare.

--
nosy: +martin.panter

___
Python tracker 

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

[issue32455] PyCompile_OpcodeStackEffect() and dis.stack_effect() are not particularly useful

[Larry Hastings]

Larry Hastings  added the comment:

> 1. This will actually simplify the code for calculating the stack size.

Simplify whose code, the caller or the callee?  It seems like it's simplifying 
the life of the callee (PyCompile_OpcodeStackEffectEx) at the expense of 
pushing complexity into the caller.


> 2. This will simplify third-party compilers (like
> https://github.com/vstinner/bytecode). They wouldn't need to
> duplicate the complicated code.

What complicated code?  Compilers simply call PyCompile_OpcodeStackEffect(), 
passing in an opcode + oparg pair, and it simply returns the maximum stack 
effect.  No crazy "is it a jump" logic needed.  Again: this may mean 
overallocating the stack.  But CPython has behaved like this for twenty years 
and I'm not convinced it's a problem that needs solving.


Victor, do you want to use Serhiy's proposed API in your library?

--

___
Python tracker 

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

[issue32455] PyCompile_OpcodeStackEffect() and dis.stack_effect() are not particularly useful

[Larry Hastings]

Change by Larry Hastings :


--
nosy: +vstinner

___
Python tracker 

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

[issue32455] PyCompile_OpcodeStackEffect() and dis.stack_effect() are not particularly useful

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

1. This will actually simplify the code for calculating the stack size. Instead 
of supporting special cases for jumping instructions in stackdepth_walk() you 
could just write something like

new_depth = depth + PyCompile_OpcodeStackEffectEx(opcode, oparg, 0);
if (new_depth > maxdepth)
maxdepth = new_depth;
if (isjump) {
target_depth = depth + PyCompile_OpcodeStackEffectEx(opcode, oparg, 1);
maxdepth = stackdepth_walk(c, instr->i_target, target_depth, maxdepth);
}
depth = new_depth;

After adding new opcodes or changing existing opcodes you would need to change 
the code only in one place.

2. This will simplify third-party compilers (like 
https://github.com/vstinner/bytecode). They wouldn't need to duplicate the 
complicated code.

--

___
Python tracker 

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

[issue32491] base64.decode: linebreaks are not ignored

[R. David Murray]

R. David Murray  added the comment:

This reduces to the following:

>>> from binascii import a2b_base64 as f
>>> f(b'MTIzND\nU2Nzg5\n')
b'123456789'
>>> f(b'MTIzND\n')
Traceback (most recent call last):
  File "", line 1, in 
binascii.Error: Incorrect padding

That is, decode does its decoding line by line, whereas decodebytes passes the 
entire object to a2b_base64 as a single entity.  Apparently a2b_base64 looks at 
the padding for the entirety of what it is given, which I believe is in 
accordance with the RFC.  This means that decode is fundamentally broken per 
the RFC, and there is no obvious way to fix it without adding an incremental 
decoder to binascii.  And an incremental decoder probably belongs in codecs 
(assuming we ever resolved the transcode interface issue, I can't actually 
remember...).

Note that it will work as long as an "integral" number of base64 encoding units 
are in each line.

--
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

[issue32455] PyCompile_OpcodeStackEffect() and dis.stack_effect() are not particularly useful

[Larry Hastings]

Larry Hastings  added the comment:

The rationale: without this information, it is impossible for anybody else to 
write a bytecode compiler / assembler, because when you create a code object 
you have to specify its stack depth.  I used this information for my "maynard" 
bytecode assembler / disassembler.

That said, I'm not sure who needs these super-fancy versions Serhiy is 
proposing.  To calculate stack depth, all you really need is the *maximum* 
stack depth per instruction.  You might slightly over-allocate but it shouldn't 
really be much of a problem.

Serhiy: what's your use case for all these complicated new features?

--

___
Python tracker 

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

[issue32491] base64.decode: linebreaks are not ignored

[Gregory P. Smith]

New submission from Gregory P. Smith :

I've tried reading various RFCs around Base64 encoding, but I couldn't make the 
ends meet.  Yet there is an inconsistency between base64.decodebytes() and 
base64.decode() in that how they handle linebreaks that were used to collate 
the encoded text.  Below is an example of what I'm talking about:

>>> import base64
>>> foo = base64.encodebytes(b'123456789')
>>> foo
b'MTIzNDU2Nzg5\n'
>>> foo = b'MTIzND\n' + b'U2Nzg5\n'
>>> foo
b'MTIzND\nU2Nzg5\n'
>>> base64.decodebytes(foo)
b'123456789'
>>> from io import BytesIO
>>> bytes_in = BytesIO(foo)
>>> bytes_out = BytesIO()
>>> bytes_in.seek(0)
0
>>> base64.decode(bytes_in, bytes_out)
Traceback (most recent call last):
  File "", line 1, in 
  File "/somewhere/lib/python3.6/base64.py", line 512, in decode
s = binascii.a2b_base64(line)
binascii.Error: Incorrect padding
>>> bytes_in = BytesIO(base64.encodebytes(b'123456789'))
>>> bytes_in.seek(0)
0
>>> base64.decode(bytes_in, bytes_out)
>>> bytes_out.getvalue()
b'123456789'

Obviously, I'd expect encodebytes() and encode both to either accept or to 
reject the same input.

Thanks.

Oleg

via Oleg Sivokon on python-dev (who was having trouble getting bugs.python.org 
account creation to work)

--
components: Library (Lib)
messages: 309449
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: base64.decode: linebreaks are not ignored
type: behavior
versions: Python 3.6, Python 3.7

___
Python tracker 

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

[issue32455] PyCompile_OpcodeStackEffect() and dis.stack_effect() are not particularly useful

[Benjamin Peterson]

Benjamin Peterson  added the comment:

What was the rationale for exposing these interfaces in the first place? If 
they're not useful, I'd rather deprecate and remove them.

--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue15982] asyncore.dispatcher does not handle windows socket error code correctly (namely WSAEWOULDBLOCK 10035)

[STINNER Victor]

STINNER Victor  added the comment:

I reopen the issue since David Vitek proposed a patch.

--
resolution: duplicate -> 
status: closed -> open

___
Python tracker 

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

[issue32477] Move jumps optimization from the peepholer to the compiler

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Well, on the other hand, the change you're proposing is hardly necessary, 
unless it actually demonstrates a noticeable improvement on some workload.  So 
perhaps we should leave the peepholer alone until someone has a better idea.

--

___
Python tracker 

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

[issue32477] Move jumps optimization from the peepholer to the compiler

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

> I think it's valuable to have a separate C module for optimizations, instead 
> of cramming them in compiler.c.

This would require major rewriting. PR 5077 adds just two functions in 
compile.c. But they use 4 structures defined locally in this file. If move 
these two functions in a separate file we will need to move these 4 structures 
and related definitions to the common header file. And maybe it will be in vain 
if once all these optimizations will be moved to other parts of the compiler. 
Some of jumps optimization already are performed on instructions emitting 
stage. Dead code elimination perhaps could be performed at the stage of 
assembling the bytecode from basic blocks. Constant tuples folding could be 
implemented by at least three ways besides the current implementation, I'm 
testing what of them is the simplest.

--

___
Python tracker 

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

[issue32346] Speed up slot lookup for class creation

[Guido van Rossum]

Guido van Rossum  added the comment:

I don't recall what I meant to use tp_cache for, but everything I can find 
about it says it's unused, so let's kill it if we can. I guess the ABI requires 
that we keep the slot around until we find a new use for it?

--

___
Python tracker 

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

[issue32428] dataclasses: make it an error to have initialized non-fields in a dataclass

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

> There is no real conflict with PEP 526 though. PEP 526 introduces ClassVar so 
> the type checker can be made to understand. PEP 557 allows omitting ClassVar 
> in case you don't care about type checkers. So I think we should stick with 
> the current spec of PEP 557 (which lets you omit ClassVar), except for this 
> special case: ...

OK.

--

___
Python tracker 

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

[issue32428] dataclasses: make it an error to have initialized non-fields in a dataclass

[Guido van Rossum]

Guido van Rossum  added the comment:

> > I liked the original design better, where things without annotations would 
> > just be ignored. What changed?

> With the original proposal the ignored variables without annotations will 
> behave as class variables. This "conflicts" with PEP 526 which requires class 
> variables to be annotated with ClassVar[...]. On the other hand some people 
> may be unhappy that they need to import `typing` to define a class variable 
> in a dataclass. So this is a convenience vs consistence question. I am more 
> in favour of consistence here, but only +0.

There is no real conflict with PEP 526 though. PEP 526 introduces ClassVar so 
the type checker can be made to understand. PEP 557 allows omitting ClassVar in 
case you don't care about type checkers. So I think we should stick with the 
current spec of PEP 557 (which lets you omit ClassVar), except for this special 
case:

> I still think that flagging this
> 
> @dataclass
> class C:
> x = field()
> 
> is important, since simply ignoring a ``field()`` will be too confusing 
> (especially for ``attrs`` users).

Agreed. That's a special case and I'm fine with flagging it as an error.

--

___
Python tracker 

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

[issue32489] Allow 'continue' in 'finally' clause

[Guido van Rossum]

Guido van Rossum  added the comment:

I think this should be accepted once the code is reviewed.

--

___
Python tracker 

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

[issue32477] Move jumps optimization from the peepholer to the compiler

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> But some peephole optimizations will work with the intermediate fixed-size 
> representations used by the compiler, before generating the concrete bytecode.

Then perhaps the goal should be to make the peephole operate on that 
intermediate representation?

I think it's valuable to have a separate C module for optimizations, instead of 
cramming them in compiler.c.

--

___
Python tracker 

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

[issue32477] Move jumps optimization from the peepholer to the compiler

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Actually moving any of remaining optimizations (including two optimizations 
that are moved by this issue and two other that are left) slightly increases 
the complexity. But instead the optimizations become more general. At the end, 
after moving all optimizations, we could drop the auxiliary code in the 
peepholer (building the table of basic blocks, removing NOPs, fixing up jump 
targets) and the net complexity will be reduced. This can also reduce the time 
and memory consumption of compilation.

Thus getting rid of the peepholer optimizer working with the bytecode is my 
goal. But some peephole optimizations will work with the intermediate 
fixed-size representations used by the compiler, before generating the concrete 
bytecode.

--

___
Python tracker 

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

[issue32490] subprocess: duplicate filename in exception message

[Jakub Wilk]

New submission from Jakub Wilk :

Python 3.6.4 (default, Jan  3 2018, 21:10:22) 
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> subprocess.call('nonexistent')
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/local/lib/python3.6/subprocess.py", line 267, in call
with Popen(*popenargs, **kwargs) as p:
  File "/usr/local/lib/python3.6/subprocess.py", line 709, in __init__
restore_signals, start_new_session)
  File "/usr/local/lib/python3.6/subprocess.py", line 1344, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'nonexistent': 
'nonexistent'


Note that the name of the missing file is mentioned twice in the error message.
(Strictly speaking it's once in the message, and once in the filename 
attribute, but for a casual observer, the effect is the same.)

--
components: Library (Lib)
messages: 309438
nosy: jwilk
priority: normal
severity: normal
status: open
title: subprocess: duplicate filename in exception message
type: behavior

___
Python tracker 

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

[issue32449] MappingView must inherit from Collection instead of Sized

[Yahya Abou Imran]

Yahya Abou Imran  added the comment:

I'm sorry, It's already done...
https://bugs.python.org/issue32467

--

___
Python tracker 

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

[issue32489] Allow 'continue' in 'finally' clause

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

See the patch against PR 5006 at 
https://github.com/serhiy-storchaka/cpython/pull/2.

--

___
Python tracker 

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

[issue32449] MappingView must inherit from Collection instead of Sized

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> Maybe I have to open a new one?

No need. Just continue here.

--

___
Python tracker 

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

[issue32489] Allow 'continue' in 'finally' clause

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

A 'continue' statement is illegal in the 'finally' clause due to a problem with 
the current implementation. After resolving issue17611 it will be easy to 
remove this restriction.

--
assignee: serhiy.storchaka
components: Interpreter Core
messages: 309434
nosy: gvanrossum, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Allow 'continue' in 'finally' clause
type: enhancement
versions: Python 3.7

___
Python tracker 

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

[issue15982] asyncore.dispatcher does not handle windows socket error code correctly (namely WSAEWOULDBLOCK 10035)

[David Vitek]

David Vitek  added the comment:

It doesn't look like the fix for issue #16133 fixed this problem, or perhaps it 
only fixed it for asynchat but not asyncore.

I have attached a patch (against python 2, since this is where I needed it 
fixed).  The patch treats WSA flavors of all errno values in the same way that 
the non-WSA flavors were treated before.

It is the intent that no direct references to errno values persist after 
applying this patch.  The patch fixed my particular issue, but I certainly 
haven't tested every new error condition.

--
keywords: +patch
nosy: +dvitek
Added file: https://bugs.python.org/file47363/p.patch

___
Python tracker 

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

[issue32485] Multiprocessing dict sharing between forked processes

[Raymond Hettinger]

Change by Raymond Hettinger :


--
nosy: +davin

___
Python tracker 

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

[issue32477] Move jumps optimization from the peepholer to the compiler

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> This is a step to getting rid of the peepholer.

There is no goal to get rid of the peepholer optimizer.  Please don't invent 
this as a requirement.

If some optimization are more easily performed upstream, then go ahead and move 
them upstream.  The goal is to have a net reduction in complexity, not just the 
elimination of peephole.c just because you decided it should disappear.

--
nosy: +rhettinger

___
Python tracker 

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

[issue32471] Add an UML class diagram to the collections.abc module documentation

[Raymond Hettinger]

Raymond Hettinger  added the comment:

This is a nice looking diagram.  Nice work.  The existing table is great when 
you care about knowing what a particular ABC does, but the diagram nicely gives 
an overview of whole ecosystem all at once.

If the collections.abc module continues its unabated growth, the diagram will 
become a spaghetti bowl.  But for now, it reads nicely.

--
nosy: +rhettinger

___
Python tracker 

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

[issue27435] ctypes library loading and AIX - also for 2.7.X (and later)

[Michael Felt]

Michael Felt  added the comment:

On 24/02/2017 09:44, Michael Haubenwallner wrote:
> Michael Haubenwallner added the comment:
>
> Let's switch to github-based patches to discuss about:
> https://github.com/python/cpython/compare/2.7...haubi:issue27435/2.7
>
> For the library search path I prefer to use loadquery(L_GETLIBPATH), 
> available via new _ctypes_aix module now, but also used with L_GETINFO in 
> Python/dynload_aix.c already.

Back again - I could not find the _ctypes_aix you mentioned. github was 
new, and I had no time then. And what I saw in dynload_aix.c I did not 
understand. I was trying to emulate what I saw in the existing 
Lib/ctypes (i.e., resolve it in python code) rather than write code in C.

Clearly, you understand that path - I (still) do not. Obviously - making 
a library call is more efficient than making multiple subprocess calls.

I may be far enough along with git that I might be able to figure out 
how to "fetch" what you have on github as haubi:issue27435/2.7.

This may also be better, i.e., more efficient, ultimately, than what was 
merged via https://github.com/python/cpython/pull/4507

Now that I have found your work - thank you for all the time you put 
into this last year!

Michael

>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue32471] Add an UML class diagram to the collections.abc module documentation

[Brett Cannon]

Brett Cannon  added the comment:

I should mention that over on python-ideas people found the open source code to 
plantuml, so I think the format is acceptable for use in the docs.

--

___
Python tracker 

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

[issue32488] Fatal error using pydoc

[Ned Deily]

Ned Deily  added the comment:

Glad you solved the immediate problem.  Under the covers, pydoc (either pydoc2 
or pydoc3) tries to import all the modules associated with the interpreter 
instance it's running under - from the Python standard library plus any 
additional vendor-supplied modules and and any you install (with pip et al).  
It seems likely that the Python 2 instance associated with the "pydoc" on your 
shell path (not "pydoc3" and Python 3) has at least one broken module 
installed.  It may be a case of a third-party module being compiled against one 
version of Python 2.7 (say, a Homebrew version) and being executed with another 
(say the Apple-supplied system Python 2.7).  See, for example, 
https://stackoverflow.com/questions/35640529/what-does-fatal-python-error-pythreadstate-get-no-current-thread-mean

--
resolution:  -> works for me
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

[issue31113] Stack overflow with large program

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
assignee:  -> serhiy.storchaka
dependencies: +co_stacksize estimate can be highly off

___
Python tracker 

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

[issue32455] PyCompile_OpcodeStackEffect() and dis.stack_effect() are not particularly useful

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

After resolving issue24340 I'm going to add PyCompile_OpcodeStackEffect() that 
takes an additional integer argument, and add an optional tristate argument to 
dis.stack_effect(). If it is True, return the effect when jump, if it is false, 
return the effect when not jump, when omitted or None, return the maximal 
effect.

--
dependencies: +co_stacksize estimate can be highly off

___
Python tracker 

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

[issue32473] Readibility of ABCMeta._dump_registry()

[Yahya Abou Imran]

Change by Yahya Abou Imran :


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

___
Python tracker 

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

[issue32455] PyCompile_OpcodeStackEffect() and dis.stack_effect() are not particularly useful

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
assignee:  -> serhiy.storchaka

___
Python tracker 

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

[issue32488] Fatal error using pydoc

[Dave Opstad]

Dave Opstad  added the comment:

I think this was my mistake; when I used pydoc3 instead of pydoc it ran to 
completion. Please feel free to close this; sorry for the noise.

--

___
Python tracker 

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

[issue32488] Fatal error using pydoc

[R. David Murray]

Change by R. David Murray :


--
components: +macOS
nosy: +ned.deily, ronaldoussoren

___
Python tracker 

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

[issue32390] AIX compile error with Modules/posixmodule.c: Function argument assignment between types "unsigned long" and "struct fsid_t" is not allowed

[Michael Felt]

Michael Felt  added the comment:

On 03/01/2018 18:03, Xavier de Gaye wrote:
> Xavier de Gaye  added the comment:
>
> The following patch may be less invasive and more explicit:
>
> diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c
> index 38b6c80e6b..e0bb4ba869 100644
> --- a/Modules/posixmodule.c
> +++ b/Modules/posixmodule.c
> @@ -9325,7 +9325,11 @@ _pystatvfs_fromstructstatvfs(struct statvfs st) {
>   PyStructSequence_SET_ITEM(v, 8, PyLong_FromLong((long) st.f_flag));
>   PyStructSequence_SET_ITEM(v, 9, PyLong_FromLong((long) st.f_namemax));
>   #endif
> +#if defined(_AIX) && defined(_ALL_SOURCE)
> +PyStructSequence_SET_ITEM(v, 10, 
> PyLong_FromUnsignedLong(st.f_fsid.val[0]));
> +#else
>   PyStructSequence_SET_ITEM(v, 10, PyLong_FromUnsignedLong(st.f_fsid));
> +#endif
>   if (PyErr_Occurred()) {
>   Py_DECREF(v);
>   return NULL;
>
> --
Applied to the PR. Thx.
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

[Neil Schemenauer]

Neil Schemenauer  added the comment:

On 2017-12-29, Mark Shannon wrote:
> One point I didn't cover is jumping to a new line in the debugger.
> Implementing that reliably for finally blocks with code
> duplication is tricky and would mean adding a number of marker
> bytecodes.  Which is a big point in favour of the JSR style.

Could we virtually execute the code, forwards or backwards,
starting from f_lasti?  For conditional jumps, we would follow both
branches.  Stop when we find the line number we want.  If we hit an
opcode that causes a fblock push or pop, abort.

I started implementing this as a proof of concept but didn't finish.
It seems to fit most naturally as an exported function of
Python/peephole.c.  That file already does a lot of similar stuff.

--

___
Python tracker 

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

[issue32390] AIX compile error with Modules/posixmodule.c: Function argument assignment between types "unsigned long" and "struct fsid_t" is not allowed

[Michael Felt]

Michael Felt  added the comment:

Ignore my last comment - I have a headache. If I could edit/delete it I would.

aka "reset 2018 - here I come!"

--

___
Python tracker 

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

[issue32488] Fatal error using pydoc

[Dave Opstad]

New submission from Dave Opstad :

I'm running 3.6.4 on Mac OS X 10.13.2, bash shell. Doing:

$ pydoc modules

causes:

Please wait a moment while I gather a list of all available modules...

Fatal Python error: PyThreadState_Get: no current thread
Abort trap: 6

Reproduced this several times with the same result.

--
components: Demos and Tools
messages: 309422
nosy: opstad
priority: normal
severity: normal
status: open
title: Fatal error using pydoc
type: crash
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

[issue21288] hashlib.pbkdf2_hmac Hash Constructor

[Christian Heimes]

Christian Heimes  added the comment:

I'm working on a hashing algorith v2.0 PEP. New hashing constructors and 
modules will have an allow_optimization flag and oid attribute. Once finalized 
and implemented, hashlib.pbkdf2_hmac() will support digestmod and digest 
constructors that have allow_optimization=True and a valid OID class / module 
attributes.

--

___
Python tracker 

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

[issue32346] Speed up slot lookup for class creation

[Antoine Pitrou]

Antoine Pitrou  added the comment:

What exactly is tp_cache? Apparently it was added by Guido in 
https://github.com/python/cpython/commit/687ae00460da9cac04eb1ba8f6f5ab4db25fbfc2
 but never used (at least officially).

commit 687ae00460da9cac04eb1ba8f6f5ab4db25fbfc2
Author: Guido van Rossum 
Date:   Mon Oct 15 22:03:32 2001 +

Get rid of __defined__ and tp_defined -- there's no need to
distinguish __dict__ and __defined__ any more.  In the C structure,
tp_cache takes its place -- but this hasn't been implemented yet.

--
nosy: +gvanrossum

___
Python tracker 

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

[issue32390] AIX compile error with Modules/posixmodule.c: Function argument assignment between types "unsigned long" and "struct fsid_t" is not allowed

[Michael Felt]

Michael Felt  added the comment:

On 03/01/2018 14:41, David Edelsohn wrote:
> David Edelsohn  added the comment:
>
> _ALL_SOURCE is overkill. It probably is too big a club for this regression.

Maybe. Clearly it is a big club. The documentation - if you can find any 
- is ancient and/or confusing. For example the xlc compiler reference 
quide (v12 is what I referenced, not the latest, but what I found) only 
has a single reference to any "_SOURCE" macro (-D_POSIX_SOURCE).

I do not know 'why' AIX and Linux differ in the way they name things. I 
do not want to care either - which is why I, personally, am less 
concerned about the size of the club. People much more clever than I 
decided that many variable names should be without two underscores 
(_ALL_SOURCE is defined) while others felt they must have two 
underscores (_ALL_SOURCE is undefined).

IMHO: 15+ years ago IBM (AIX) worked to find a method to simplify 
porting. And, I hope somewhere someone knows what these all meant. The 
practice seems to be to always define _ALL_SOURCE (see configure.ac:
   +882  # checks for UNIX variants that set C preprocessor variables
   +883  AC_USE_SYSTEM_EXTENSIONS
   +884
https://www.gnu.org/software/autoconf/manual/autoconf-2.64/html_node/Posix-Variants.html

Here is where I read that _ALL_SOURCE is for AIX3. I can neither deny 
nor affirm that that is (still) accurate. But that is what working with 
autotools does. Throws a sauce over everything that may, or maynot be 
what is needed.

I considered it 'interesting' that  at least talks a bit 
about _POSIX_SOURCE and _ALL_SOURCE.

>   However, the AIX header definition of fsid compatible with the current 
> Python posixmodule.c code is bracketed by _ALL_SOURCE.
>
> AFAICT, the change to posixmodule.c made assumptions about fsid based on 
> Linux and not required by POSIX. This didn't simply introduce a testsuite 
> regression, but broke the build on AIX. The posixmodule.c code should be 
> corrected or should be reverted.

Maybe reverting the change is better than using the "big club". But, 
asis, AIX is dead to development. Was it possible to have AIX included 
in the PR test process I would hope that the PR would never have been 
merged.

IMHO - this is a spelling issue, going back years. But if you use a 
UK-only spelling checker and try and use only US spelling rules - and 
v.v. - there will be 'issues'. What is the solution with the most 
clarity? Above my pay grade to answer.

In any case the previous issue that saw adding fsid as a solution was 
not fully tested across all platforms. Currently AIX is broken. Someone 
needs to decide how to restore a supported platform - and where the 
discussion on fsid either restarts or continues.

In short - I am just a messenger - you are the experts. :)

>
> --
> nosy: +vstinner
> title: AIX (xlc_r) compile error with Modules/posixmodule.c: Function 
> argument assignment between types "unsigned long" and "struct fsid_t" is not 
> allowed -> AIX compile error with Modules/posixmodule.c: Function argument 
> assignment between types "unsigned long" and "struct fsid_t" is not allowed
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue32390] AIX compile error with Modules/posixmodule.c: Function argument assignment between types "unsigned long" and "struct fsid_t" is not allowed

[Xavier de Gaye]

Xavier de Gaye  added the comment:

The following patch may be less invasive and more explicit:

diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c
index 38b6c80e6b..e0bb4ba869 100644
--- a/Modules/posixmodule.c
+++ b/Modules/posixmodule.c
@@ -9325,7 +9325,11 @@ _pystatvfs_fromstructstatvfs(struct statvfs st) {
 PyStructSequence_SET_ITEM(v, 8, PyLong_FromLong((long) st.f_flag));
 PyStructSequence_SET_ITEM(v, 9, PyLong_FromLong((long) st.f_namemax));
 #endif
+#if defined(_AIX) && defined(_ALL_SOURCE)
+PyStructSequence_SET_ITEM(v, 10, 
PyLong_FromUnsignedLong(st.f_fsid.val[0]));
+#else
 PyStructSequence_SET_ITEM(v, 10, PyLong_FromUnsignedLong(st.f_fsid));
+#endif
 if (PyErr_Occurred()) {
 Py_DECREF(v);
 return NULL;

--

___
Python tracker 

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

[issue32428] dataclasses: make it an error to have initialized non-fields in a dataclass

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

Just to clarify the previous comment, I still think that flagging this

@dataclass
class C:
x = field()

is important, since simply ignoring a ``field()`` will be too confusing 
(especially for ``attrs`` users).

The previous comment is about

@dataclass
class C:
x = 42

--

___
Python tracker 

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

[issue32428] dataclasses: make it an error to have initialized non-fields in a dataclass

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

> I liked the original design better, where things without annotations would 
> just be ignored. What changed?

With the original proposal the ignored variables without annotations will 
behave as class variables. This "conflicts" with PEP 526 which requires class 
variables to be annotated with ClassVar[...]. On the other hand some people may 
be unhappy that they need to import `typing` to define a class variable in a 
dataclass. So this is a convenience vs consistence question. I am more in 
favour of consistence here, but only +0.

--

___
Python tracker 

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

[issue32484] ImportError for gdbm 1.14

[Benjamin Peterson]

Change by Benjamin Peterson :


--
resolution:  -> third party
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

[issue32487] assertRaises should return the "captured" exception

[R. David Murray]

R. David Murray  added the comment:

This has been proposed and rejected before, for example in issue 28135.  If you 
want to pursue it you'll need to start a thread on python-ideas.

--
nosy: +r.david.murray
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> assertRaises should return the exception in its simple form

___
Python tracker 

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

[issue32487] assertRaises should return the "captured" exception

[Facundo Batista]

New submission from Facundo Batista :

Sometimes it's nice to do extra checks on the error raised and captured by 
self.assertRaises call.

Yes, the same can be achieved using assertRaises as a context manager and then 
accessing the `exception` attribute in the context manager, but it looks too 
cumbersome to just get the exception, when it can be simply returned by the 
assertRaises call.

Note 1: Currently it returns None, so no backward compatibility problem.

Note 2: assertRaises in testtools does this and is very useful

--
messages: 309414
nosy: facundobatista
priority: normal
severity: normal
stage: needs patch
status: open
title: assertRaises should return the "captured" exception
type: enhancement
versions: Python 3.7

___
Python tracker 

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

[issue32390] AIX compile error with Modules/posixmodule.c: Function argument assignment between types "unsigned long" and "struct fsid_t" is not allowed

[David Edelsohn]

David Edelsohn  added the comment:

_ALL_SOURCE is overkill. It probably is too big a club for this regression. 
However, the AIX header definition of fsid compatible with the current Python 
posixmodule.c code is bracketed by _ALL_SOURCE.

AFAICT, the change to posixmodule.c made assumptions about fsid based on Linux 
and not required by POSIX. This didn't simply introduce a testsuite regression, 
but broke the build on AIX. The posixmodule.c code should be corrected or 
should be reverted.

--
nosy: +vstinner
title: AIX (xlc_r) compile error with Modules/posixmodule.c: Function argument 
assignment between types "unsigned long" and "struct fsid_t" is not allowed -> 
AIX compile error with Modules/posixmodule.c: Function argument assignment 
between types "unsigned long" and "struct fsid_t" is not allowed

___
Python tracker 

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

[issue32390] AIX (xlc_r) compile error with Modules/posixmodule.c: Function argument assignment between types "unsigned long" and "struct fsid_t" is not allowed

[Xavier de Gaye]

Xavier de Gaye  added the comment:

The _ALL_SOURCE feature test macro is set by the AC_USE_SYSTEM_EXTENSIONS macro 
in configure.ac.
It is not clear why the _ALL_SOURCE macro is currently needed by Python.

The _ALL_SOURCE feature test macro is defined here: 
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxbd00/ftms.htm

--

___
Python tracker 

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

[issue32346] Speed up slot lookup for class creation

[INADA Naoki]

INADA Naoki  added the comment:

How about reusing tp_cache instead of adding new slot?

--

___
Python tracker 

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

[issue32485] Multiprocessing dict sharing between forked processes

[Christian Heimes]

Christian Heimes  added the comment:

Don't worry about your choice of words. We usually use the C definition of the 
term crash. An exception is just a bug, but a segfault may be a security issue.

--

___
Python tracker 

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

[issue32461] the first build after a change to Makefile.pre.in uses the old Makefile

[Xavier de Gaye]

Xavier de Gaye  added the comment:

Two problems:
* It is not clear whether one should re-run make after the Makefile file has 
been updated since the (stale when not using GNU make) Makefile is run to 
completion.
* The 'Makefile' target is remade twice when Makefile.pre.in has been changed. 
The 'Makefile.pre' target is a pre-requisite of only the 'Makefile' target 
which means that if 'Makefile.pre' is being remade then 'Makefile' will be 
remade next and so it is useless to run the 'Makefile' target in a sub-make 
within the 'Makefile.pre' target.

The implementation of the uploaded stale-makefile.patch aborts the build when 
'Makefile' has been remade and we are not running GNU make. It also removes the 
useless sub-make in the 'Makefile.pre' target.

--
Added file: https://bugs.python.org/file47362/stale-makefile.patch

___
Python tracker 

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

[issue32456] PYTHONIOENCODING=undefined doesn't work in Python 3

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

The "undefined" encoding exists.

--

___
Python tracker 

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

[issue32486] tail optimization for 'yield from'

[Robert Smart]

New submission from Robert Smart :

When a generator procedure ends with "yield from" it would be nice if this was 
handled efficiently (just replace the generator with the new source). Because 
it is natural to push things back into a generator with

def prependGen(hd,tl):
yield hd
yield from tl

--
messages: 309407
nosy: Robert Smart
priority: normal
severity: normal
status: open
title: tail optimization for 'yield from'
type: resource usage
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

[issue32456] PYTHONIOENCODING=undefined doesn't work in Python 3

[STINNER Victor]

STINNER Victor  added the comment:

Can't we check if the encoding exists using codecs.lookup() before using it
to emit a better error message?

Look at initfsencoding() in the C code which implements such check.

--

___
Python tracker 

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

[issue32485] Multiprocessing dict sharing between forked processes

[André Neto]

André Neto  added the comment:

You are right, it does not segfault (sorry for the abuse of language). It 
raises an exception while accessing the shared dictionary. The exception varies 
but typically is:
Traceback (most recent call last):
  File "multiprocessbug.py", line 156, in 
test_manyForkedProcessesSingleThreaded(inst1, inst2, nRuns, nProcesses)
  File "multiprocessbug.py", line 77, in test_manyForkedProcessesSingleThreaded
run(inst1, nRuns)
  File "multiprocessbug.py", line 29, in run
inst.run()
  File "multiprocessbug.py", line 18, in run
if (self.d.has_key(self.key)):
  File "", line 2, in has_key
  File "/usr/local/lib/python2.7/multiprocessing/managers.py", line 759, in 
_callmethod
kind, result = conn.recv()
cPickle.UnpicklingError: invalid load key, '#'.

--

___
Python tracker 

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

[issue32456] PYTHONIOENCODING=undefined doesn't work in Python 3

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Thank you for solving this puzzle Martin.

The question is whether we need to do something for improving error reporting 
in this case or just close this issue with a resolution "not a bug" or "won't 
fix".

--

___
Python tracker 

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

[issue15450] Allow dircmp.subdirs to behave well under subclassing

[Mitar]

Change by Mitar :


--
pull_requests: +4962

___
Python tracker 

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

[issue32485] Multiprocessing dict sharing between forked processes

[Christian Heimes]

Christian Heimes  added the comment:

Does it it actually crash (segfault) or are you merely getting an exception? 
I'm just getting bunch of exception:

Traceback (most recent call last):
  File "multiprocessing_crash.py", line 155, in 
test_manyForkedProcessesSingleThreaded(inst1, inst2, nRuns, nProcesses)
  File "multiprocessing_crash.py", line 76, in 
test_manyForkedProcessesSingleThreaded
run(inst1, nRuns)
  File "multiprocessing_crash.py", line 28, in run
inst.run()
  File "multiprocessing_crash.py", line 23, in run
self.d[self.key] = 0
  File "", line 2, in __setitem__
Traceback (most recent call last):
  File "/usr/lib64/python2.7/multiprocessing/managers.py", line 759, in 
_callmethod
  File "multiprocessing_crash.py", line 155, in 
test_manyForkedProcessesSingleThreaded(inst1, inst2, nRuns, nProcesses)
  File "multiprocessing_crash.py", line 82, in 
test_manyForkedProcessesSingleThreaded
run(inst2, nRuns)
  File "multiprocessing_crash.py", line 28, in run
inst.run()
  File "multiprocessing_crash.py", line 19, in run
item = self.d.get(self.key)
  File "", line 2, in get
  File "/usr/lib64/python2.7/multiprocessing/managers.py", line 759, in 
_callmethod
kind, result = conn.recv()
kind, result = conn.recv()
cPickle.UnpicklingErrorMemoryError
: invalid load key, '#'.
Traceback (most recent call last):
  File "/usr/lib64/python2.7/multiprocessing/util.py", line 268, in 
_run_finalizers
Traceback (most recent call last):
  File "/usr/lib64/python2.7/multiprocessing/util.py", line 268, in 
_run_finalizers
finalizer()
finalizer()
  File "/usr/lib64/python2.7/multiprocessing/util.py", line 201, in __call__
  File "/usr/lib64/python2.7/multiprocessing/util.py", line 201, in __call__
res = self._callback(*self._args, **self._kwargs)
res = self._callback(*self._args, **self._kwargs)
  File "/usr/lib64/python2.7/multiprocessing/managers.py", line 609, in 
_finalize_manager
  File "/usr/lib64/python2.7/multiprocessing/managers.py", line 609, in 
_finalize_manager
if process.is_alive():
if process.is_alive():
  File "/usr/lib64/python2.7/multiprocessing/process.py", line 155, in is_alive
  File "/usr/lib64/python2.7/multiprocessing/process.py", line 155, in is_alive
assert self._parent_pid == os.getpid(), 'can only test a child process'
AssertionError: can only test a child process

--
nosy: +christian.heimes

___
Python tracker 

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

[issue32485] Multiprocessing dict sharing between forked processes

[André Neto]

New submission from André Neto :

I'm working on a project where I need to share state between several processes 
(forked using gunicorn). I'm using dictionaries obtained from a multiprocessing 
SyncManager to achieve this.

The issue is that if I have multiple forked processes concurrently accessing to 
different dictionaries created by the same SyncManager, the code will randomly 
crash while accessing (read-only and read-write) to any of the dictionaries. 
This behaviour is independent of the way I access the dictionary (i.e. it 
happens both using the dictionary functions (e.g. has_key) or the built-in 
keywords (e.g. key in dict).

The attached snippet demonstrates the issue (tested only in python2.7): the 
function test_manyForkedProcessesSingleThreaded will crash.

The issue is also being discussed here: 
https://stackoverflow.com/questions/48052148/python-multiprocessing-dict-sharing-between-processes

--
files: multiprocessing_crash.py
messages: 309402
nosy: André Neto
priority: normal
severity: normal
status: open
title: Multiprocessing dict sharing between forked processes
type: crash
versions: Python 2.7
Added file: https://bugs.python.org/file47361/multiprocessing_crash.py

___
Python tracker 

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

[issue15450] Allow dircmp.subdirs to behave well under subclassing

[Mitar]

Change by Mitar :


--
nosy: +mitar

___
Python tracker 

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

[issue12932] filecmp.dircmp does not allow non-shallow comparisons

[Mitar]

Change by Mitar :


--
nosy: +mitar

___
Python tracker 

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

[issue29708] support reproducible Python builds

[Antoine Pitrou]

Change by Antoine Pitrou :


--
nosy: +Ray Donnelly

___
Python tracker 

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

[issue29708] support reproducible Python builds

[Alexandru Ardelean]

Alexandru Ardelean  added the comment:

Thank you for the heads-up.
I did not follow-up too in-depth on the resolution.

I just stumbled over this last night.

Will keep an eye for 3.7, and see about 2.7.

--

___
Python tracker 

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