[issue29084] C API of OrderedDict

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

___
Python tracker 

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

[issue31954] Don't prevent dict optimization by coupling with OrderedDict

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Could you please make a review Raymond?

--
assignee:  -> rhettinger

___
Python tracker 

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

[issue31954] Don't prevent dict optimization by coupling with OrderedDict

[Raymond Hettinger]

Raymond Hettinger  added the comment:

This looks reasonable to me.  The previous design was too tightly coupled.  The 
regular dict shouldn't have to care about the OrderedDict at all.

--

___
Python tracker 

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

[issue32276] there is no way to make tempfile reproducible (i.e. seed the used RNG)

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I concur with Raymond.

Monkey patching the tempfile module looks the right solution of this uncommon 
problem.

--
nosy: +serhiy.storchaka
resolution:  -> fixed
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

[issue31954] Don't prevent dict optimization by coupling with OrderedDict

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

But this increases the size of regular dicts. Is it appropriate?

--

___
Python tracker 

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

[issue29084] C API of OrderedDict

[Raymond Hettinger]

Raymond Hettinger  added the comment:

With today's announcement of guaranteed ordering for regular dicts, OrderedDict 
just became much less important (almost insignificant).  Also, the original 
reason for having this C API no longer applies.

There is a reasonable case to be made for removing the API entirely (given that 
it was never documented, that it is buggy, and that it is no longer of any 
significance).

--

___
Python tracker 

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

[issue32315] can't run any scripts with 2.7.x, 32 and 64-bit

[Martin]

Martin  added the comment:

I used Python on other machines, I know how it's supposed to work. I'm using 
Windows 7 and this problem happened with 2.7.14, 2.7.13 and 2.7.9. I didn't 
bother trying all other versions because it looked like it didn't matter what 
version it was. For every version, I was running scripts with PyShell file (59 
KB) from idlelib.

I found another two files called "idle" in idlelib, one with and other without 
console. Either of those when ran starts Shell window and I can run scripts 
perfectly fine from there. 

I don't know what the problem is with PyShell file, but since with idle files 
it works as expected, I won't chase the cause of this.

--

___
Python tracker 

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

[issue31954] Don't prevent dict optimization by coupling with OrderedDict

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I also have misgivings about the extra field.  Perhaps solicit some other 
opinions about whether the trade-off is worth it. Maybe Tim can provide an 
insight.

My suspicion is that the current tight coupling is going to cost us in other 
ways.  The OrderedDict is now less important than ever, so we really don't want 
regular dicts to have to pay any price just for the convenience of OrderedDict.

--
assignee: rhettinger -> 

___
Python tracker 

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

[issue32002] test_c_locale_coercion fails when the default LC_CTYPE != "C"

[Nick Coghlan]

Nick Coghlan  added the comment:


New changeset 9c19b020249c451891affd81751947321a1e6957 by Nick Coghlan in 
branch 'master':
bpo-32002: Refactor C locale coercion tests (GH-4369)
https://github.com/python/cpython/commit/9c19b020249c451891affd81751947321a1e6957


--

___
Python tracker 

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

[issue32344] Explore whether peephole.c tuple of constants folding can be an AST transformation

[Raymond Hettinger]

New submission from Raymond Hettinger :

Can the peephole optimizer's fold_tuple_on_constants() be moved to ast_opt?

It looks to me like there is sufficient information in the tree:


import ast
print(ast.dump(ast.parse('c = (50+1, 60+2)')))
---
Module(body=[Assign(targets=[Name(id='c', ctx=Store())],
value=Tuple(elts=[BinOp(left=Num(n=50), op=Add(), 
right=Num(n=1)),
  BinOp(left=Num(n=60), op=Add(), 
right=Num(n=2))], ctx=Load()))],
   docstring=None)
'''

--
assignee: serhiy.storchaka
components: Interpreter Core
messages: 308467
nosy: inada.naoki, rhettinger, serhiy.storchaka, vstinner
priority: low
severity: normal
status: open
title: Explore whether peephole.c tuple of constants folding can be an AST 
transformation
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

[issue32321] functools.reduce has a redundant guard or needs a pure Python fallback

[Raymond Hettinger]

Change by Raymond Hettinger :


--
assignee:  -> ncoghlan
nosy: +ncoghlan

___
Python tracker 

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

[issue32345] EIO from write() is only fatal if print() contains a newline

[Creideiki]

New submission from Creideiki :

This is Python 2.7.14 on Gentoo Linux.

I ran into an issue where a program crashes if I run it from a terminal, put it 
in the background, and then close the terminal too soon. Upstream bug report: 
https://github.com/micahflee/torbrowser-launcher/issues/298

It seems the cause is that a print() call without a newline ignores the EIO 
returned by the write() syscall, but if there is a newline in the string, that 
EIO is suddenly a fatal error.

Reproducer:

$ cat fatal.py 
#!/bin/env python2.7
import time
time.sleep(5)
print('A')
print('B\nC')
print('D')

Run this program in the background under strace to see what it does, and while 
it is sleeping, close its controlling terminal:

$ strace -s 256 -o fatal.log -f ./fatal.py &
[1] 17974
^d

Now look at the strace log:

$ grep write fatal.log
17978 write(1, "A\n", 2)= -1 EIO (Input/output error)
17978 write(1, "B\n", 2)= -1 EIO (Input/output error)
17978 write(2, "Traceback (most recent call last):\n", 35) = -1 EIO 
(Input/output error)
17978 write(2, "  File \"./fatal.py\", line 5, in \n", 41) = -1 EIO 
(Input/output error)
17978 write(2, "", 4)   = -1 EIO (Input/output error)
17978 write(2, "print('B\\nC')\n", 14)  = -1 EIO (Input/output error)
17978 write(2, "IOError", 7)= -1 EIO (Input/output error)
17978 write(2, ": ", 2) = -1 EIO (Input/output error)
17978 write(2, "[Errno 5] Input/output error", 28) = -1 EIO (Input/output error)
17978 write(2, "\n", 1) = -1 EIO (Input/output error)

The first print('A') ran and had an EIO error, which was ignored. The second 
print('B\nC') tried to write 'B', had an EIO error, and crashed. The third 
print('D') was never attempted.

--
components: IO
messages: 308468
nosy: Creideiki
priority: normal
severity: normal
status: open
title: EIO from write() is only fatal if print() contains a newline
versions: Python 2.7

___
Python tracker 

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

[issue32344] Explore whether peephole.c tuple of constants folding can be an AST transformation

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Tuples represented in AST already are optimized at AST level. But there are 
tuples created at compilation stage (see the code emitting BUILD_TUPLE). 
Inada's PR 4879 simplifies the peephole optimizer.

I tried to move this optimization at the compiler level, but it is more complex 
change. Making this change can have additional advantages, but is just more 
complex. I think at end all remaining peephole optimizations will be moved to 
the compiler, so that it will generate already optimized code. Many 
optimizations had already moved, and I have yet few unfinished patches.

--
resolution:  -> rejected
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

[issue19764] subprocess: use PROC_THREAD_ATTRIBUTE_HANDLE_LIST with STARTUPINFOEX on Windows Vista

[Segev Finer]

Segev Finer  added the comment:

The PR has been sitting there for quite a while now...

--

___
Python tracker 

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

[issue32276] there is no way to make tempfile reproducible (i.e. seed the used RNG)

[Julien Palard]

Julien Palard  added the comment:

I concur with Raymond and Serhiy here, and monkeypatching tmpfile should not be 
that hard, maybe patching `tempfile._Random` with `partial(random.Random, 
seed)` if done soon enough?

--

___
Python tracker 

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

[issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected

[Camion]

Camion  added the comment:

Jerry, I've been troubleshooting thing for 30 years and I'm quite experienced 
at it, and in the end I was perfectly able to manage this problem and solve 
this problem by myself. 

My point is not about my own difficulty to solve this problem, but about the 
fact that an information was lacking clarity in a language which claims that 
things must be told. You mention the fact that Steven suggested playing playing 
around with simplified code, but it's not what Steven suggested. Steven 
suggested to make the example simpler, and I replied him that this example was 
not chosen to describe the programming situation but illustrate the 
troubleshooting situation and provide a good way to show how a real situation 
might be problematic to analyse with this message - and Steven confirmed that 
he was also put out on a wrong track by this message. 

For sure, when you are an experienced programmer, you will develop a different 
way to understand this. My point is that it seems to go in contradiction with 
"Python's Zen".

You suggest that I should have split the packing and the unpacking on two 
separate lines. Ok, but this is an easy suggestion to make _when you already 
know the cause of the problem_. Each language has it's programming culture and; 
Ok, I'm new here but I haven't seen any recommendation going in that direction. 
On the contrary all the sample code and course I have seen on that topic 
encourage young programmer not to use this practice - and I believe it would be 
simpler to find a way to adapt the error message to make things clear that such 
an error can also arise for unpacking reasons (whatever the way you word it), 
than to change the programming/training culture around python.

I have been made multiple propositions to re-word this message, and Steven also 
made some. My last proposition was motivated by the idea of keeping the message 
short. Some other were longer. One might also write : "not iterable (this 
problem may sometimes arise from unpacking)" or something else.

The point is that in many situation, the problem comes from a mismatching 
between the number of values packed and the number of destination positions for 
unpacking; and in this case, you have a ValueError message stating clearly what 
happens. 

Only in this case, when the fact that you had only one value and didn't see it, 
makes that you no longer have an iterable type - do you get a TypeError. And 
Ok, I agree with Serhiy that the type of exception is correct, but I believe 
that the whole situation is misleading and should be corrected.

(I apologize for my long sentences : My mother tongue is french and it's not 
always easy for me to to make them short like you do in English XD )

--

___
Python tracker 

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

[issue31954] Don't prevent dict optimization by coupling with OrderedDict

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests: +4796

___
Python tracker 

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

[issue31954] Don't prevent dict optimization by coupling with OrderedDict

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

PR 4901 implements Inada's idea about changing dk_lookup to an index. This 
decreases the size, but can have negative performance effect (I didn't make 
benchmarks).

--

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

New submission from Antoine Pitrou :

As mentioned in 
https://mail.python.org/pipermail/python-dev/2017-December/151298.html, slot 
lookup can take 75 to 80% of the runtime when creating a new class.  This was 
slightly improved in https://bugs.python.org/issue31336 but we're still doing 
one lookup per possible slot name *and* per class along the MRO.

I propose to speed up this step by caching the known descriptors for each 
class.  This way, when instantiating a new class, you can simply iterate over 
the known descriptors of the MRO without wasting time on hundreds of dict 
lookups.

(and it is reasonably easy to find all slot descriptors in a dict: first select 
only __dunder__ names, then look them up in a dedicated mapping)

--
components: Interpreter Core
messages: 308474
nosy: pitrou, scoder, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Speed up slot lookup for class creation
type: performance
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

[issue32346] Speed up slot lookup for class creation

[Antoine Pitrou]

Change by Antoine Pitrou :


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

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

I posted https://github.com/python/cpython/pull/4902 for this.

This approach has two drawbacks:
- uses an additional tp_ slot (and a corresponding TPFLAGS)
- adds a bit of code complexity (but quite localized)

--
stage: patch review -> 

___
Python tracker 

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

[issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

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

Change by Antoine Pitrou :


--
stage:  -> patch review

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

Some micro-benchmarks:

$ ./python -m timeit "class Test: pass"
- before: 8.84 usec per loop
- after: 7.03 usec per loop

$ ./python -m timeit "class Test(tuple): pass"
- before: 10.1 usec per loop
- after: 8.4 usec per loop

$ ./python -m timeit -s "from logging import Logger" "class Test(Logger): pass"
- before: 12 usec per loop
- after: 6.25 usec per loop

$ ./python -m timeit -s "from logging.handlers import DatagramHandler" "class 
Test(DatagramHandler): pass"
- before: 15 usec per loop
- after: 6.68 usec per loop

$ ./python -m timeit -s "from unittest.mock import MagicMock" "class 
Test(MagicMock): pass"
- before: 18.2 usec per loop
- after: 6.56 usec per loop

$ ./python -m timeit -s "from shelve import Shelf" "class Test(Shelf): pass"
- before: 28.6 usec per loop
- after: 18.4 usec per loop

--

___
Python tracker 

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

[issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

PR 4903 makes the error message more specific for this case.

>>> a, b = 1
Traceback (most recent call last):
  File "", line 1, in 
TypeError: cannot unpack int object

I don't know whether it is worth to do this change.

--

___
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

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
priority: normal -> low

___
Python tracker 

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

[issue32339] Make the dict type used in csv.DictReader configurable

[shangdahao]

Change by shangdahao :


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

___
Python tracker 

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

[issue32324] [Security] "python3 directory" inserts "directory" at sys.path[0] even in isolated mode

[Steve Dower]

Steve Dower  added the comment:

The more interesting part is the relative directory and how often is it 
resolved? Can you change a program's imports by inducing it to change its 
working directory immediately after startup (or before any lazy imports)? If 
so, we should resolve it to a full path when adding it, regardless of -I.

Having the first entry there is required for local imports to work from the 
startup script, so I don't see it going anywhere. There have been many 
discussions about how to deal with the shadowing "problem", but the eventual 
answer was consenting adults.

--

___
Python tracker 

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

[issue32347] System Integrity Protection breaks shutil.copystat()

[Ryan Govostes]

New submission from Ryan Govostes :

On macOS, shutil.copystat() uses chflags() to try to copy filesystem flags from 
the source to destination.

In recent years, Apple introduced System Integrity Protection, which prevents 
modification of system files. These files have the non-standard SF_RESTRICTED 
flag set, which only the superuser can set.

Thus, unprivileged users can no longer use shutil.copy2() et al. to copy system 
files, which is a regression from previous releases of the OS.

It's unclear what the correct behavior should be: It some cases, it would be 
desirable to attempt to copy the bit.

It might be informative to look at the behavior of Apple's `copyfile_stat` 
function, which unsets these two flags:

   /*
* File flags that are not preserved when copying stat information.
*/
   #define COPYFILE_OMIT_FLAGS  (UF_TRACKED | SF_RESTRICTED)

https://opensource.apple.com/source/copyfile/copyfile-146/copyfile.c.auto.html

This was also filed to Apple as rdar://36090921

--
components: macOS
messages: 308479
nosy: Ryan Govostes, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: System Integrity Protection breaks shutil.copystat()
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

[issue32250] Add asyncio.current_task() and asyncio.all_tasks() funcitons

[Andrew Svetlov]

Andrew Svetlov  added the comment:


New changeset 44d1a5912ea629aa20fdc377a5ab69d9ccf75d61 by Andrew Svetlov in 
branch 'master':
bpo-32250: Implement asyncio.current_task() and asyncio.all_tasks() (#4799)
https://github.com/python/cpython/commit/44d1a5912ea629aa20fdc377a5ab69d9ccf75d61


--

___
Python tracker 

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

[issue32250] Add asyncio.current_task() and asyncio.all_tasks() funcitons

[Andrew Svetlov]

Change by Andrew Svetlov :


--
components: +Library (Lib)
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> enhancement

___
Python tracker 

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

[issue32226] Implement PEP 560: Core support for typing module and generic types

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


--
pull_requests: +4800

___
Python tracker 

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

[issue32348] Optimize asyncio.Future schedule/add/remove callback

[Yury Selivanov]

New submission from Yury Selivanov :

Key observation: 99.9% of the time Futures and Tasks have only one callback.  

Currently we have a list of callbacks in each Future/Task.  We can avoid list 
object allocation if we add a field to store the first callback.  This way 
we'll only need to ever allocate the list if a Future/Task has more than one 
done callbacks.

asyncio with the proposed patch applied shows that 3-6% better performance of 
an asyncio echo server implemented using asyncio.streams.  This benchmark 
involves quite a bit of other Python code, so this improvement is actually 
quite significant.

The patch consists of:

1. first callback / callbacks list refactoring.

2. a free list implementation for Future.__await__ objects (which are created 
on almost all awaits in asyncio).

3. a big cleanup of the code, ensuring that Future/Task are always initialized 
properly.

--
assignee: yselivanov
components: asyncio
messages: 308481
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Optimize asyncio.Future schedule/add/remove callback
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

[issue32348] Optimize asyncio.Future schedule/add/remove callback

[Yury Selivanov]

Change by Yury Selivanov :


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

___
Python tracker 

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

[issue32264] move pygetopt.h into internal/

[David Bolen]

David Bolen  added the comment:

This commit appears to have broken OSX installer builds using the 
build-installer.py script (as in the last two attempts on the bolen-dmg-3.x 
builder), confirmed with a bisection from the first failing worker build 
(covering the range 02a0a19..3327a2d)

It fails during the main python compilation with:

ld: multiple definitions of symbol __PyOS_optarg
libpython3.7m.a(getopt.o) definition of __PyOS_optarg in section (__DATA,__data)
libpython3.7m.a(main.o) definition of __PyOS_optarg in section (__DATA,__common)
ld: multiple definitions of symbol __PyOS_opterr

(repeated for the various __PyOS__opt* symbols.

It doesn't seem to be a problem with a simple manual configure/make build 
(probably why the regular OSX workers aren't failing).  

So best guess at the moment is it's related to one of the extra configure 
options used by the build-installer script.  I'm not sure which of the commit 
or build process needs correction, although reverting this at least temporarily 
would resolve the immediate issue.

--
nosy: +db3l, ned.deily, ronaldoussoren

___
Python tracker 

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

[issue32264] move pygetopt.h into internal/

[David Bolen]

David Bolen  added the comment:

After some further testing, it does not appear to be configure related but 
something environmental (maybe MACOSX_DEPLOYMENT_TARGET) - using the same 
configure options manually as build-installer seems ok.

For what it's worth, since there do appear to be duplicate definitions in 
pygetopt.h and getopt.c, adding "extern" to the declarations in pygetopt.h 
appears to resolve the issue.  It looks like that was lost with the removal of 
PyAPI_DATA.

--

___
Python tracker 

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

[issue32349] Add detailed return value information for set.intersection function

[양유석]

New submission from 양유석 :

I think it's intentional behavior seems to be minor though.

At a glance, I assume that a.set(b) should return items in a. But I found out 
the implementation always return items in smaller set.

There is no issue for common case, but custom class can make a trouble. So, I 
think additional information of return value is helpful.

--
assignee: docs@python
components: Documentation
messages: 308484
nosy: docs@python, 양유석
priority: normal
severity: normal
status: open
title: Add detailed return value information for set.intersection function
type: enhancement

___
Python tracker 

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