[issue34849] Drop logging when asyncio waits in selector.select()

[miss-islington]

miss-islington  added the comment:


New changeset d5bd036138881bb90a803397d992870a46fbdc2d by Miss Islington (bot) 
(Andrew Svetlov) in branch 'master':
bpo-34849: Don't log wating for selector.select in asyncio loop iteration 
(GH-9641)
https://github.com/python/cpython/commit/d5bd036138881bb90a803397d992870a46fbdc2d


--
nosy: +miss-islington

___
Python tracker 

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

Re: What's an elegant way to test for list index existing?

[Glen D souza]

i have a approach, it may not be best

fld = [ ]
for data in shlex.split(ln):
   fld.append(data)



On Sat, 29 Sep 2018 at 07:52,  wrote:

> On Friday, September 28, 2018 at 11:03:17 AM UTC-7, Chris Green wrote:
> > I have a list created by:-
> >
> > fld = shlex.split(ln)
> >
> > It may contain 3, 4 or 5 entries according to data read into ln.
> > What's the neatest way of setting the fourth and fifth entries to an
> > empty string if they don't (yet) exist? Using 'if len(fld) < 4:' feels
> > clumsy somehow.
>
> How about this?
>
> from itertools import chain, repeat
> temp = shlex.split(ln)
> fld = list(chain(temp, repeat("", 5-len(temp
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What's an elegant way to test for list index existing?

[Glen D souza]

fld = [ ]
data = shlex.split(ln)
for item in data:
   fld.append(item)
fld = fld + [0] * (5 - len(data))


On Sat, 29 Sep 2018 at 11:03, Glen D souza  wrote:

> i have a approach, it may not be best
>
> fld = [ ]
> for data in shlex.split(ln):
>fld.append(data)
>
>
>
> On Sat, 29 Sep 2018 at 07:52,  wrote:
>
>> On Friday, September 28, 2018 at 11:03:17 AM UTC-7, Chris Green wrote:
>> > I have a list created by:-
>> >
>> > fld = shlex.split(ln)
>> >
>> > It may contain 3, 4 or 5 entries according to data read into ln.
>> > What's the neatest way of setting the fourth and fifth entries to an
>> > empty string if they don't (yet) exist? Using 'if len(fld) < 4:' feels
>> > clumsy somehow.
>>
>> How about this?
>>
>> from itertools import chain, repeat
>> temp = shlex.split(ln)
>> fld = list(chain(temp, repeat("", 5-len(temp
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What's an elegant way to test for list index existing?

[Chris Angelico]

On Sat, Sep 29, 2018 at 12:21 PM Chris Green  wrote:
>
> I have a list created by:-
>
> fld = shlex.split(ln)
>
> It may contain 3, 4 or 5 entries according to data read into ln.
> What's the neatest way of setting the fourth and fifth entries to an
> empty string if they don't (yet) exist? Using 'if len(fld) < 4:' feels
> clumsy somehow.

shlex.split(ln) + ["", ""]

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

Re: What's an elegant way to test for list index existing?

[Alister via Python-list]

On Fri, 28 Sep 2018 19:00:29 +0100, Chris Green wrote:

> I have a list created by:-
> 
> fld = shlex.split(ln)
> 
> It may contain 3, 4 or 5 entries according to data read into ln. What's
> the neatest way of setting the fourth and fifth entries to an empty
> string if they don't (yet) exist? Using 'if len(fld) < 4:' feels clumsy
> somehow.

how about simply
adding 2 or more null entries to the list then slicing?

string = "a b c"
a=string.split()
(a+['',''])[0:5]







-- 
QOTD:
If you're looking for trouble, I can offer you a wide selection.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What's an elegant way to test for list index existing?

[Dan Sommers]

On 9/28/18 2:00 PM, Chris Green wrote:

I have a list created by:-

 fld = shlex.split(ln)

It may contain 3, 4 or 5 entries according to data read into ln.
What's the neatest way of setting the fourth and fifth entries to an
empty string if they don't (yet) exist? Using 'if len(fld) < 4:' feels
clumsy somehow.


Do you care whether there are more than 5 entries in the list?  If not,
then just add two empty strings to the end of the list:

fld.extend(["", ""])

If fld already contained 5 entries, then the extra two empty strings may
or may not affect the subsequent logic.  If possible extra entries
bother you, then truncate the list:

fld = (fld + ["", ""])[:5]

Or add empty strings as long as the list contains 5 entries:

while len(fld) < 5:
fld.append("")

Which one is "better" or "best"?  Your call, depending on what your
criteria are.  I think the last one expresses the intent the most
clearly, but YMMV.
--
https://mail.python.org/mailman/listinfo/python-list

[issue34849] Drop logging when asyncio waits in selector.select()

[Andrew Svetlov]

Change by Andrew Svetlov :


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

___
Python tracker 

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

[issue34849] Drop logging when asyncio waits in selector.select()

[Andrew Svetlov]

New submission from Andrew Svetlov :

The waiting is the pretty normal case: no IO is performed and no immediate 
activities are scheduled.

Therefore logging such cases is just a noise.

--
components: asyncio
messages: 326702
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Drop logging when asyncio waits in selector.select()
type: behavior
versions: Python 3.8

___
Python tracker 

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

[issue34745] asyncio ssl memory leak

[Fantix King]

Change by Fantix King :


--
nosy: +fantix

___
Python tracker 

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

[issue34848] range.index only takes one argument when it's documented as taking the usual 3

[Dan Snider]

New submission from Dan Snider :

Unfortunately, it looks like there's no requirement for an abc.Sequence to 
implement the 3 argument form of seq.index, so I suppose this is technically 
just a documentation bug...

>>> range(5).index(2, 1)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: index() takes exactly one argument (2 given)

>>> help(range.index)
Help on method_descriptor:

index(...)
rangeobject.index(value, [start, [stop]]) -> integer -- return index of 
value.
Raise ValueError if the value is not present.

--
assignee: docs@python
components: Argument Clinic, Documentation
messages: 326701
nosy: bup, docs@python, larry
priority: normal
severity: normal
status: open
title: range.index only takes one argument when it's documented as taking the 
usual 3
versions: Python 3.4, Python 3.5, 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

[issue34847] asyncio: Add PHA for TLS 1.3

[Christian Heimes]

Change by Christian Heimes :


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

___
Python tracker 

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

[issue34847] asyncio: Add PHA for TLS 1.3

[Fantix King]

New submission from Fantix King :

This was raised in GH-9460 where the same post handshake authentication (PHA) 
was added to the ssl module. It should be added to asyncio too. This issue is 
to discuss the design of PHA API in asyncio, and implement it in Python 3.8.

One approach is to add _SSLProtocolTransport.verify_client_post_handshake(), 
but an additional new transport mixin type to asyncio/transports.py would be 
needed (Yury).

Yury also proposed another option to use get_extra_info() API to get something 
like an "SSLExtra" object with additional APIs.

--
components: asyncio
messages: 326700
nosy: asvetlov, fantix, yselivanov
priority: normal
severity: normal
status: open
title: asyncio: Add PHA for TLS 1.3
type: behavior
versions: Python 3.8

___
Python tracker 

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

[issue32833] argparse doesn't recognise two option aliases as equal

[paul j3]

paul j3  added the comment:

I'm going to close this issue.  The current behavior is a logical consequence 
of how option_strings and abbreviations are handled.  Handling this particular 
case differently would be require adding a special test, as opposed to a minor 
tweak to the current code.

It could be reopened if some one wrote a clever and complete patch (and/or made 
a compelling case that it is needed).

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

[issue32756] argparse: parse_known_args: raising exception on unknown arg following known one

[paul j3]

Change by paul j3 :


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

[issue32291] Value error for string shared memory in multiprocessing

[hongweipeng]

hongweipeng  added the comment:

I think I know the reason. `c_wchar_p` corresponds to the string pointer 
`wchar_t *`.It's not a good idea to pass pointers between processes. As quoted 
from `multiprocessing` docs:

Note Although it is possible to store a pointer in shared memory remember that 
this will refer to a location in the address space of a specific process. 
However, the pointer is quite likely to be invalid in the context of a second 
process and trying to dereference the pointer from the second process may cause 
a crash.

https://docs.python.org/3.6/library/multiprocessing.html?#module-multiprocessing.sharedctypes

--

___
Python tracker 

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

[issue34846] Runtime failure with Failed to import site module

[Satheesh Thomas]

New submission from Satheesh Thomas :

Run time failure to execute python scripts. It was running for long time 
without any issue . But sometimes get this error which stops the entire 
execution. Looks like some .pyc file got corrupted .

--
components: Build
files: Python error1.png
messages: 326697
nosy: sat@gmail.com
priority: normal
severity: normal
status: open
title: Runtime failure with Failed to import site module
type: crash
versions: Python 3.5
Added file: https://bugs.python.org/file47837/Python error1.png

___
Python tracker 

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

[issue13407] tarfile doesn't support multistream bzipped tar files

[Andrés Delfino]

Change by Andrés Delfino :


--
type:  -> enhancement

___
Python tracker 

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

[issue13407] tarfile doesn't support multistream bzipped tar files

[Andrés Delfino]

Andrés Delfino  added the comment:

I believe this can be closed.

--

___
Python tracker 

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

[issue34785] pty.spawn -- auto-termination after child process is dead (a zombie)

[Martin Panter]

Martin Panter  added the comment:

Is this to get “spawn” working on a non-Linux platform like a recent Free BSD, 
OS X, or Solaris? If so, see Issue 26228.

If not, you might have to explain your use case better. Polling for the child 
exiting is going to race with handling the child’s output, and if there are 
other processes writing to the terminal after the child exits this will change 
the behaviour.

--
nosy: +martin.panter

___
Python tracker 

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

[issue34845] allow exprlist as the iterators of comprehensions to be consistent with for statements

[thautwarm]

thautwarm  added the comment:

Well, sorry for that.

--

___
Python tracker 

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

[issue34845] allow exprlist as the iterators of comprehensions to be consistent with for statements

[Guido van Rossum]

Guido van Rossum  added the comment:

This is intentional. We don't want people accidentally writing e.g.

[i for i in range(10), j for j in range(10)]

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

[issue34845] allow exprlist as the iterators of comprehensions to be consistent with for statements

[thautwarm]

Change by thautwarm :


--
components: +Interpreter Core
type:  -> behavior
versions: +Python 3.8

___
Python tracker 

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

[issue34845] allow exprlist as the iterators of comprehensions to be consistent with for statements

[thautwarm]

New submission from thautwarm :

Currently we can use `exprlist` as the iterator in a `for` 
statement:

  ```
  for i in 1, 2,:
 print(i)

  1
  2
  ```

  However, when it comes to comprehension expressions:

  ```
  [i for i in 1, 2]

  SyntaxError: invalid syntax
  ```

  I know there might be some reason that leads to the absence of the 
consistency between `for` expression and statement, but IMO until now it could 
be better to allow `exprlist` to be the iterator of comprehensions. I'm not 
sure whether our community has noticed this problem so I'm to propose it here.

  A crucial benefit from this change is that we can avoid the ambiguity when a 
comprehension is accepted as function parameter.

  ```
  f(for i in [1, 2, 3], 1, 2)
  ```
  We now get a SyntaxError when writing such codes, but people who know this 
syntax might think the parameters can be distinguished from each other, but 
it's still not allowed. 
  
  Allowing `exprlist` to be the iterator slot of a comprehension would be a 
rational solution. If `f(for i in [1, 2, 3], 1, 2)` is equivalent to `f(for i 
([1, 2, 3], 1, 2))`, it will be natural to restrict the number of parameters to 
be just 1 when the parameter is a comprehension.

  You can slightly accept this workaround and try following examples:
  ```
  f(for i in 1,)
  f(for i in 1, for j in 2, 3,)
  f(for i in 1, 2 if cond(i) for j in 3, for k in 4,)
  ```
  Obviously, in each of above cases, the number of parameters is 1,
just because a `exprlist` could the iterator of a comprehension.

  The disadvantage of this change is, there is not too many related use cases, 
for any `[expr for target in iter_elem1, iter_elem2, ...]` could be altered as 
`[expr for target in (iter_elem1, iter_elem2, ...)]`. Meanwhile, that might not 
be true when it comes to someone works frequently with interactive python.
 
  
  Finally, I have finished this implementation at 
https://github.com/thautwarm/cpython/tree/exprlist-in-comprehensions, and I do 
want to make contributions to cpython projects. If most of you feel comfortable 
with this change, may I make a PR next?

--
messages: 326692
nosy: gvanrossum, serhiy.storchaka, thautwarm, yselivanov
priority: normal
severity: normal
status: open
title: allow exprlist as the iterators of comprehensions to be consistent with 
for statements

___
Python tracker 

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

[issue34844] logging.Formatter enhancement - Checking on style and fmt fields

[Guido van Rossum]

Guido van Rossum  added the comment:

Moving to Python 3.8 because this is a feature proposal. Adding Vinay to nosy 
list because this is about logging.

--
nosy: +vinay.sajip
versions: +Python 3.8 -Python 3.6

___
Python tracker 

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

[issue34844] logging.Formatter enhancement - Checking on style and fmt fields

[Luna Chen]

Change by Luna Chen :


--
title: logging.Formatter enhancement - Checking on style and -> 
logging.Formatter enhancement - Checking on style and fmt fields

___
Python tracker 

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

[issue34844] logging.Formatter enhancement - Checking on style and

[Luna Chen]

New submission from Luna Chen :

Issue: Currently logging.Formatter does not check if the format passed in is 
valid style or if the field is valid when creating the logging.Formatter 
object. It would be nice to have such check in the constructor of the 
logging.Formatter.

Here are 2 scenarios:

Scenario 1: Passing in invalid `fmt` when creating the logging.Formatter.
Example:
import logging
logger = logging.getLogger('my_logger')
handler = logging.StreamHandler()

fmt = logging.Formatter("blah-blah", style="{")
handler.setFormatter(fmt)

logger.addHandler(handler)
logger.setLevel(logging.DEBUG)

logger.info('This is my logging message.')

The above example would output the fmt string("blah-blah") whenever a logging 
operation is performed, such as `logging.info`, `logging.warning`.
And this goes the same for mismatching style and fmt, like so:
fmt = logging.Formatter("{asctime}-{message}", style="%")


Scenario 2: Passing in invalid fields to logging.Formatter

import logging
logger = logging.getLogger('my_logger')
handler = logging.StreamHandler()

fmt = logging.Formatter("%(FuncName)s-%(message)s")
handler.setFormatter(fmt)

logger.addHandler(handler)
logger.setLevel(logging.DEBUG)

logger.info('This is my logging message.'
)
As you can see from the above example, the "%(FuncName)s" field is misspelled 
with a capital "F", which should have been a lowercase "f". In this scenario, 
we would get an interesting stacktrace:

--- Logging error ---
Traceback (most recent call last):
  File 
"/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/logging/__init__.py",
 line 992, in emit
msg = self.format(record)
  File 
"/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/logging/__init__.py",
 line 838, in format
return fmt.format(record)
  File 
"/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/logging/__init__.py",
 line 578, in format
s = self.formatMessage(record)
  File 
"/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/logging/__init__.py",
 line 547, in formatMessage
return self._style.format(record)
  File 
"/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/logging/__init__.py",
 line 391, in format
return self._fmt % record.__dict__
KeyError: 'FuncName'
Call stack:
  File "", line 1, in 
Message: 'This is my logging message.'
Arguments: ()

Personally, I think the "KeyError" here can be misleading and confusing to 
some. 



Proposal:

I would like to make a PR with the following changes:
- Checking fmt to match the style in the constructor of logging.Formatting
- When calling log message functions such as "logger.info()", an "extra" key 
word arg can be passed for custom format fields, 
  for example:
  fmt = logging.Formatter("{cpuUsage} - {message}", style="{") # In this case, 
cpuUsage would be custom
  logger.info("my logging message", extra={"cpuUsage": "my_cpu_usage"})

  - I would like to have custom fields passed in as an additional (optional) 
argument into the constructor for logging.Formatter
  - Another option is to have an additional member method for adding additional 
fields
  - I think we could essentially have both options
  - With this, we can remove the "extra" argument in Logger.makeRecord()


Draw Backs:

- This change might essentially break some existing code where someone might 
use the "extra" argument in log message functions, as we would do the check on 
logging.Formatter level



Please let me know your thoughts, and I thought it would be nice to get some 
new ideas and areas I haven't thought about before I make this PR.


Best regards,
Luna Chen (BNMetrics)

--
components: Library (Lib)
messages: 326690
nosy: BNMetrics, gvanrossum
priority: normal
severity: normal
status: open
title: logging.Formatter enhancement - Checking on style and
type: enhancement
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

[issue34778] Memoryview for column-major (f_contiguous) arrays from bytes impossible to achieve

[Laurent Gautier]

Laurent Gautier  added the comment:

Wouldn't a contiguity argument ('C' or 'F') be simpler ?
 
(Independently, an argument strides is likely also missing from "cast").

Do you know what are the next possible steps here ? Bring this to the 
python-dev list ? Submit a patch ?

--
components: +Extension Modules, Library (Lib) -Interpreter Core

___
Python tracker 

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

[issue34842] Incorrect error messages in bisect

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
resolution: not a bug -> out of date

___
Python tracker 

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

[issue34842] Incorrect error messages in bisect

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Dan, thanks for the suggestion.  Changing to PyObject_Size() would have been 
the right thing to do if the error message had not been fixed.  But since the 
new error message "TypeError: dict is not a sequence" is more helpful than 
"TypeError: 'dict' object does not support indexing", we should leave the code 
as-is.

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

[issue13407] tarfile doesn't support multistream bzipped tar files

[Brian Curtin]

Brian Curtin  added the comment:


New changeset 8d3b0f49021e6cd25030a1eb979218cfceb44061 by Brian Curtin (Andrés 
Delfino) in branch '2.7':
[2.7] bpo-13407: Mention that bz2/tarfile doesn't support multi-stream bzip2 
files (GH-8428)
https://github.com/python/cpython/commit/8d3b0f49021e6cd25030a1eb979218cfceb44061


--
nosy: +brian.curtin

___
Python tracker 

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

[issue27351] Unexpected ConfigParser.read() behavior when passed fileobject

[Brian Curtin]

Brian Curtin  added the comment:


New changeset 3cd5e8e83c9785d9f505138903c7a50dc964101e by Brian Curtin (Miss 
Islington (bot)) in branch '3.6':
bpo-27351: Fix ConfigParser.read() documentation and docstring (GH-8123)
https://github.com/python/cpython/commit/3cd5e8e83c9785d9f505138903c7a50dc964101e


--

___
Python tracker 

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

[issue27351] Unexpected ConfigParser.read() behavior when passed fileobject

[Brian Curtin]

Brian Curtin  added the comment:


New changeset b0b8f9bd4e6f78ac7383b4e56cfb6cbacc77da89 by Brian Curtin (Miss 
Islington (bot)) in branch '3.7':
bpo-27351: Fix ConfigParser.read() documentation and docstring (GH-8123)
https://github.com/python/cpython/commit/b0b8f9bd4e6f78ac7383b4e56cfb6cbacc77da89


--

___
Python tracker 

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

[issue34778] Memoryview for column-major (f_contiguous) arrays from bytes impossible to achieve

[mattip]

mattip  added the comment:

Sorry, I meant a "strides" keyword. "shape" is already a valid keyword

--

___
Python tracker 

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

[issue27351] Unexpected ConfigParser.read() behavior when passed fileobject

[miss-islington]

Change by miss-islington :


--
pull_requests: +9029

___
Python tracker 

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

[issue27351] Unexpected ConfigParser.read() behavior when passed fileobject

[Brian Curtin]

Brian Curtin  added the comment:


New changeset e45473e3ca31e5b78dc85cab575f5bb60d5b7f8f by Brian Curtin (Zackery 
Spytz) in branch 'master':
bpo-27351: Fix ConfigParser.read() documentation and docstring (GH-8123)
https://github.com/python/cpython/commit/e45473e3ca31e5b78dc85cab575f5bb60d5b7f8f


--
nosy: +brian.curtin

___
Python tracker 

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

[issue27351] Unexpected ConfigParser.read() behavior when passed fileobject

[miss-islington]

Change by miss-islington :


--
pull_requests: +9030

___
Python tracker 

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

[issue32606] Email Header Injection Protection Bypass

[Cheryl Sabella]

Cheryl Sabella  added the comment:

Should this be closed as 'not a bug'?

--
nosy: +cheryl.sabella

___
Python tracker 

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

[issue31370] Remove support for threads-less builds

[Brian Curtin]

Brian Curtin  added the comment:


New changeset eef059657d6b10babdb4831e1148d60cc644ee9a by Brian Curtin (Zackery 
Spytz) in branch 'master':
bpo-31370: Remove references to threadless builds (#8805)
https://github.com/python/cpython/commit/eef059657d6b10babdb4831e1148d60cc644ee9a


--
nosy: +brian.curtin

___
Python tracker 

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

[issue34832] "Short circuiting" in base64's b64decode, decode, decodebytes

[Felipe Rodrigues]

Felipe Rodrigues  added the comment:

For reference in future discussions, Python's base64 module implements RFC 3548 
(https://tools.ietf.org/html/rfc3548) whose section 2.3 
(https://tools.ietf.org/html/rfc3548#section-2.3) discusses about 
"Interpretation of non-alphabet characters in encoded data".

The section's content is:

   Base encodings use a specific, reduced, alphabet to encode binary
   data.  Non alphabet characters could exist within base encoded data,
   caused by data corruption or by design.  Non alphabet characters may
   be exploited as a "covert channel", where non-protocol data can be
   sent for nefarious purposes.  Non alphabet characters might also be
   sent in order to exploit implementation errors leading to, e.g.,
   buffer overflow attacks.

   Implementations MUST reject the encoding if it contains characters
   outside the base alphabet when interpreting base encoded data, unless
   the specification referring to this document explicitly states
   otherwise.  Such specifications may, as MIME does, instead state that
   characters outside the base encoding alphabet should simply be
   ignored when interpreting data ("be liberal in what you accept").
   Note that this means that any CRLF constitute "non alphabet
   characters" and are ignored.  Furthermore, such specifications may
   consider the pad character, "=", as not part of the base alphabet
   until the end of the string.  If more than the allowed number of pad
   characters are found at the end of the string, e.g., a base 64 string
   terminated with "===", the excess pad characters could be ignored.

In my opinion, the RFC is rather permissive about strange characters in the 
encoded data. The RFC refers to the MIME specification that ignores the data 
and hints the possibility of rejecting the pad symbol '=' unless it is found in 
the end of the string.

I think that our best option if we would like to address this issue is to add 
an 'errors' argument whose default value will keep the current behavior for 
backwards compatibility but will accept more options in order to both ignore 
the strange characters and carry on with the processing - like bytes.decode's 
errors=ignore flag - and to raise an error in such situations, like 
bytes.decode's errors=strict.

--

___
Python tracker 

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

[issue34833] [CI] Azure Pipeline: Initialize Agent failed

[Steve Dower]

Steve Dower  added the comment:

I'll pass it along in case someone is collecting statistics on the team, but 
unless it's consistently broken for us (e.g. as apt-get was recently) there's 
not much value in opening a bug. Transient failures occur, ultimately, and 
nobody needs encouragement to add the "re-run check" feature besides GitHub 
(and their response is to use the new UI, which is also a top priority for 
Pipelines right now).

Victor, if you'd like your account enabled to be able to restart builds though 
the Azure DevOps page, send me your Microsoft Account 
email(live.com/hotmail.com/etc) and I'll happily add you. But I'm still not 
sure whether that hooks up properly with GitHub's checks.

--

___
Python tracker 

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

[issue34841] Script’s directory not in sys.path with embeddable Windows distribution

[Simon Sapin]

Simon Sapin  added the comment:

Removing python37._pth restores the documented behavior, I don’t know if it has 
adverse effects.

--

___
Python tracker 

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

[issue34835] Multiprocessing module update fails with pip3

[Cheryl Sabella]

Cheryl Sabella  added the comment:

As Steven said,
> In Python 2.6+ multiprocessing is a std lib module

This means that multiprocessing will be current with the version of Python 3 
that you have installed.  If you're currently on 3.7.0, when 3.7.1 is released 
and you install it, you will get all the updates to multiprocessing (if there 
were any).

--
nosy: +cheryl.sabella

___
Python tracker 

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

Re: I am not able to run Python in Powershell

[Calvin Spealman]

Did you actually confirm the PATH variable contains the right path?

echo $env:Path

And look for a path entry that mentions Python. Then, make sure you can
actually find python.exe in that location.

As long as you keep the PATH option checked with the Python installer it
absolutely should work from PowerShell. What version of Python did you
install? Have you also tried to invoke Python from the Command Prompt to
determine if the issue only affects PowerShell or not?

On Fri, Sep 28, 2018 at 1:10 PM  wrote:

> On Friday, 1 September 2017 19:37:41 UTC+1, The Cat Gamer  wrote:
> > fter I installed Python I try to open it in Powershell, by typing
> > python/python.exe.
> > It gives me an error:
> > python : The term 'python' is not recognized as the name of a cmdlet,
> > function, script file, or operable program. Check the spelling of the
> name,
> > or if a path was included, verify that the path is correct and try again.
> > At line:1 char:1
> > + python
> > + ~~
> > + CategoryInfo  : ObjectNotFound: (python:String) [],
> > CommandNotFoundException
> > + FullyQualifiedErrorId : CommandNotFoundException
> > This happens with version 3 and version 2. The newest versions and the
> > older versions none of them makes me able to open Python in Windows
> > Powershell. Are you guys aware of a fix?
> >
> > (I already tried the environment fix and that didnt work as well)
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue34843] logging cookbook docs: remove 'recent' when referring to multiprocessing

[Cheryl Sabella]

New submission from Cheryl Sabella :

In the logging cookbook docs, the word 'recent' is used to describe versions of 
Python containing the multiprocessing module.  Since multiprocessing is 10 
years old, I think it may be safe to remove the word 'recent'.

--
assignee: docs@python
components: Documentation
messages: 326676
nosy: cheryl.sabella, docs@python
priority: normal
severity: normal
status: open
title: logging cookbook docs: remove 'recent' when referring to multiprocessing
type: enhancement
versions: Python 3.8

___
Python tracker 

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

[issue34843] logging cookbook docs: remove 'recent' when referring to multiprocessing

[Cheryl Sabella]

Change by Cheryl Sabella :


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

___
Python tracker 

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

[issue34842] Incorrect error messages in bisect

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

It was fixed in issue32500. This is a new feature and it was not backported.

>>> bisect.bisect_right(dict.fromkeys(range(10)), 5)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: dict is not a sequence
>>> bisect.bisect_right(dict.fromkeys(range(10)), 5, 0, 10)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: dict is not a sequence

--
nosy: +rhettinger, serhiy.storchaka

___
Python tracker 

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

Re: What's an elegant way to test for list index existing?

[Peter Otten]

Ben Finney wrote:

> Ben Finney  writes:
> 
>> You can use a comprehension, iterating over the full range of index you
>> want::
>>
>> words = shlex.split(line)
>> padding_length = 5
>> words_padded = [
>> (words[index] if index < len(words))
>> for index in range(padding_length)]
> 
> That omits the important case you were concerned with: when `index <
> len(words)` is false. In other words, that example fails to actually pad
> the resulting list.

It would if it weren't a syntax error. 

No harm done ;)

> Try this instead::
> 
> words = shlex.split(line)
> padding_length = 5
> padding_value = None
> words_padded = [
> (words[index] if index < len(words) else padding_value)
> for index in range(padding_length)]
> 


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

Re: What's an elegant way to test for list index existing?

[Ben Finney]

Ben Finney  writes:

> You can use a comprehension, iterating over the full range of index you
> want::
>
> words = shlex.split(line)
> padding_length = 5
> words_padded = [
> (words[index] if index < len(words))
> for index in range(padding_length)]

That omits the important case you were concerned with: when `index <
len(words)` is false. In other words, that example fails to actually pad
the resulting list.

Try this instead::

words = shlex.split(line)
padding_length = 5
padding_value = None
words_padded = [
(words[index] if index < len(words) else padding_value)
for index in range(padding_length)]

-- 
 \   “When a well-packaged web of lies has been sold to the masses |
  `\over generations, the truth will seem utterly preposterous and |
_o__)its speaker a raving lunatic.” —Dresden James |
Ben Finney

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

[issue34609] Importing certain modules while debugging raises an exception

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I think pperry nailed it above:

> Pdb fails because it is attempting to import the readline module every time 
> its `trace_dispatch` is called, and the import implementation is not 
> reentrant in that way.

More precisely, _ModuleLock.acquire() in 
https://github.com/python/cpython/blob/master/Lib/importlib/_bootstrap.py#L101 
is not reentrant.  If pdb steps into that function and tries to call it again 
by making an "import" call, `_blocking_on[tid]` will be overwritten and then 
deleted inside the nested call, so `del _blocking_on` in the enclosing call 
will raise a KeyError.

I think the solution would be either one of:
1) pdb avoids doing anything import-related as part of its step function
2) pdb avoids stepping inside importlib internals (e.g. by blacklisting 
importlib modules)

--

___
Python tracker 

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

[issue32291] Value error for string shared memory in multiprocessing

[hongweipeng]

hongweipeng  added the comment:

This problem seems to be support for str.

import multiprocessing
import ctypes

def child_process_fun(share):
share.value = 'bb'

if __name__ == '__main__':
share = multiprocessing.Value(ctypes.c_wchar_p, 'aa')
process = multiprocessing.Process(target=child_process_fun, args=(share, ))
process.start()
process.join()
print(share.value)

It also raises ValueError.When use c_double or c_int, it works well.

Test in python3.7 and 3.8

--

___
Python tracker 

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

[issue34842] Incorrect error messages in bisect

[Dan Snider]

New submission from Dan Snider :

internal_bisect_left and internal_bisect_right use PySequence_Size when a "hi" 
argument wasn't provided, which causes this silly error message:

>>> bisect.bisect_right(dict.fromkeys(range(10)), 5)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: object of type 'dict' has no len()

They could use PyObject_Size and let PySequence_GetItem in the loop catch the 
error:

>>> bisect.bisect_right(dict.fromkeys(range(10)), 5, 0, 10)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: 'dict' object does not support indexing

Since that actually makes sense and is more efficient / less verbose than 
adding a PySequence_Check.

--
components: Interpreter Core
messages: 326672
nosy: bup
priority: normal
severity: normal
status: open
title: Incorrect error messages in bisect
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

[issue32291] Value error for string shared memory in multiprocessing

[hongweipeng]

Change by hongweipeng :


--
nosy: +hongweipeng

___
Python tracker 

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

Re: JPEGImage() hangs

[Chris Green]

Cameron Simpson  wrote:
> On 28Sep2018 20:12, Chris Green  wrote:
> >Peter Pearson  wrote:
> >> On Fri, 28 Sep 2018 15:01:41 +0100, Chris Green  wrote:
> >> > Chris Green  wrote:
> >> >> Brian Oney  wrote:
> >> >> > Could you please try another tool like `convert'? E.g.
> >> >> >
> >> >> > $ convert 102_PANA/P1020466.JPG test.png
> >> >> >
> >> >> > What does that say?
> >> >>
> >> >> Well, after having returned home with the laptop where this was
> >> >> failing and doing exactly the same thing again, it now works.  However
> >> >> it did take several seconds before the >>> prompt appeared.
> >> >>
> >> >> The problem seems to be intermittent as I'm calling the function while
> >> >> importing images from a camera SD card and, sometimes, the import
> >> >> hangs but most times it works OK.
> 
> Can you separate the conversion from the copy? Copy the images off, run 
> convert 
> against the copies? That would give you more info as to whether it was the 
> copy 
> (implying an issue with the SD card as Peter suggests) or some pathologial 
> image data (eg spinning out convert).
> 
> Also, you can strace the hanging process; I'm a big fan of this for 
> diagnostic 
> purposes. A "hanging" process will normally be either spinning (using lots of 
> CPU, or a mix of CPU and OS calls), or blocked (using no CPU at all while it 
> waits for a OS call to complete). If it is blocked doing a read() then you 
> immediately suspect the device from which the read is taking place.
> 
It's blocked, I watched using top and it's using no CPU.  So,
definitely points at a dodgy SD card.

-- 
Chris Green
·
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What's an elegant way to test for list index existing?

[Chris Green]

Thanks all, several possible ways of doing it there.

-- 
Chris Green
·
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue34841] Script’s directory not in sys.path with embeddable Windows distribution

[Simon Sapin]

New submission from Simon Sapin :

https://docs.python.org/3/library/sys.html#sys.path documents:

> As initialized upon program startup, the first item of this list, path[0], is 
> the directory containing the script that was used to invoke the Python 
> interpreter.

On Windows with an embeddable zip file distribution, this does not happen.

Steps to reproduce:

* Create a foo.py file that contains `import bar`
* Create an empty bar.py file
* With your usual Python installed from the "normal" executable installer, 
check that `python foo.py` runs without output or error
* Download and extract 
https://www.python.org/ftp/python/3.7.0/python-3.7.0-embed-amd64.zip
* Run `..\python-3.7.0-embed-amd64\python foo.py`

Expected result:

The script runs again without output or error.

Actual result:

Traceback (most recent call last):
  File "foo.py", line 1, in 
import bar
ModuleNotFoundError: No module named 'bar'


This might be an occurrence of https://bugs.python.org/issue33698, since the 
embeddable distribution has a python37._pth file that contains "python37.zip" 
and "."

print(sys.path) shows [
  'C:\\Users\\example\\python-3.7.0-embed-amd64\\python37.zip',
  'C:\\Users\\example\\python-3.7.0-embed-amd64'
]

This StackOverflow question describes the same issue: 
https://stackoverflow.com/q/51403126/1162888

--
messages: 326671
nosy: ssapin
priority: normal
severity: normal
status: open
title: Script’s directory not in sys.path with embeddable Windows distribution
type: behavior

___
Python tracker 

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

Re: What's an elegant way to test for list index existing?

[Peter Otten]

jlada...@itu.edu wrote:

> On Friday, September 28, 2018 at 11:03:17 AM UTC-7, Chris Green wrote:
>> I have a list created by:-
>> 
>> fld = shlex.split(ln)
>> 
>> It may contain 3, 4 or 5 entries according to data read into ln.
>> What's the neatest way of setting the fourth and fifth entries to an
>> empty string if they don't (yet) exist? Using 'if len(fld) < 4:' feels
>> clumsy somehow.
> 
> How about this?
> 
> from itertools import chain, repeat
> temp = shlex.split(ln)
> fld = list(chain(temp, repeat("", 5-len(temp

If you are OK with silently dropping extra entries

fld = list(islice(chain(shlex.split(ln), repeat("")), 5))

or its non-itertools equivalent

fld = (shlex.split(ln) + [""] * 5)[:5]

are also possible. Personally I consider none of these to be elegant.
If you are going to unpack the fld entries I'd do it in a function with 
default values:

>>> def use_args(foo, bar, baz, ham="", spam=""):
... print("\n".join("{} = {!r}".format(*p) for p in locals().items()))
... 
>>> use_args(*shlex.split("a b c"))
spam = ''
ham = ''
baz = 'c'
foo = 'a'
bar = 'b'
>>> use_args(*shlex.split("a b c d"))
spam = ''
ham = 'd'
baz = 'c'
foo = 'a'
bar = 'b'

This has the advantage that it fails for the unforeseen cases:

>>> use_args(*shlex.split("a b c d e f"))
Traceback (most recent call last):
  File "", line 1, in 
TypeError: use_args() takes from 3 to 5 positional arguments but 6 were 
given
>>> use_args(*shlex.split("a b"))
Traceback (most recent call last):
  File "", line 1, in 
TypeError: use_args() missing 1 required positional argument: 'baz'


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

[issue33698] `._pth` does not allow to populate `sys.path` with empty entry

[Simon Sapin]

Change by Simon Sapin :


--
nosy: +ssapin

___
Python tracker 

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

[issue28655] Tests altered the execution environment in isolated mode

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

I guess this can be safely closed as fixed since 3.6 changes were merged and I 
verified the PR changes locally at msg326477. The issue regarding using -I 
along with -j0 is tracked at issue34812 .

Thanks Serhiy and Victor for the fixes :)

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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

[issue34812] support.args_from_interpreter_flags() doesn't inherit -I (isolated) flag

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

Thanks Victor for the details. Can this be classified as an easy issue? I guess 
the fix will be as below : 

1. Add an entry for '-I' at 
https://github.com/python/cpython/blob/4b430e5f6954ef4b248e95bfb4087635dcdefc6d/Lib/subprocess.py#L260

2. Add a test for '-I' at 
https://github.com/python/cpython/blob/4b430e5f6954ef4b248e95bfb4087635dcdefc6d/Lib/test/test_support.py#L472.
 
The only thing here is that '-I' returns '-s -E -I' unlike other options where 
args can be used for comparison logic in check_options. check_options should be 
changed so that this can take given args and the expected args for comparison 
to accommodate -I. Maybe there is a better way?

Off topic : I don't know why '-I' is not documented as sys.flags.isolated at 
https://docs.python.org/3.7/library/sys.html#sys.flags . Maybe I will open up a 
separate issue for this?

--

___
Python tracker 

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

[issue34840] dlopen() error with no error message from dlerror()

[shuoz]

New submission from shuoz :

python _ctypes.dlclose(arg). 
Never check the arg  so we get a Segmentation fault (core dumped)

poc.py
```
import _ctypes
_ctypes.dlclose(3)  # 3-4294967296
```
python poc.py


gdb info

```
--registers---]
RAX: 0x77ffcca0 --> 0x40d0d 
RBX: 0x0 
RCX: 0x76a49fd0 (:movrax,QWORD PTR [rip+0x201fe1] 
   # 0x76c4bfb8)
RDX: 0x2e10a0bf96213a9d 
RSI: 0x0 
RDI: 0x3 
RBP: 0x76a49fd0 (:movrax,QWORD PTR [rip+0x201fe1] 
   # 0x76c4bfb8)
RSP: 0x7fffd280 --> 0x0 
RIP: 0x77dee161 (<_dl_close+1>: test   BYTE PTR [rdi+0x3d4],0x8)
R8 : 0x3 
R9 : 0x76a49fd0 (:movrax,QWORD PTR [rip+0x201fe1] 
   # 0x76c4bfb8)
R10: 0xc55dc0 --> 0x31 ('1')
R11: 0x77eec3d8 --> 0x9 ('\t')
R12: 0x3 
R13: 0x77e952b0 --> 0x1 
R14: 0x72d12140 (: push   r14)
R15: 0x77e17228 --> 0x16
EFLAGS: 0x10246 (carry PARITY adjust ZERO sign trap INTERRUPT direction 
overflow)
[-code-]
   0x77dee152:  nopDWORD PTR [rax+0x0]
   0x77dee156:  nopWORD PTR cs:[rax+rax*1+0x0]
   0x77dee160 <_dl_close>:  push   rbx
=> 0x77dee161 <_dl_close+1>:test   BYTE PTR [rdi+0x3d4],0x8
   0x77dee168 <_dl_close+8>:movrbx,rdi
   0x77dee16b <_dl_close+11>:   jne0x77dee210 <_dl_close+176>
   0x77dee171 <_dl_close+17>:   movedx,DWORD PTR [rdi+0x310]
   0x77dee177 <_dl_close+23>:   test   edx,edx
[stack-]
| 0x7fffd280 --> 0x0 
0008| 0x7fffd288 --> 0x77de7564 (<_dl_catch_error+116>: mov
rax,QWORD PTR [rsp+0x8])
0016| 0x7fffd290 --> 0x0 
0024| 0x7fffd298 --> 0x77fd8720 --> 0x7fffd2e0 --> 0x7737f690 
--> 0x0 
0032| 0x7fffd2a0 --> 0x0 
0040| 0x7fffd2a8 --> 0x7737f690 --> 0x0 
0048| 0x7fffd2b0 --> 0x7737f698 --> 0x0 
0056| 0x7fffd2b8 --> 0x7737f688 --> 0x0 
[--]
Legend: code, data, rodata, value
Stopped reason: SIGSEGV
_dl_close (_map=0x3) at dl-close.c:809
809 dl-close.c: No such file or directory.
gdb-peda$ bt
```

--
components: ctypes
messages: 326668
nosy: shuoz
priority: normal
severity: normal
status: open
title: dlopen() error with no error message from dlerror()
type: crash
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

[issue34751] Hash collisions for tuples

[Tim Peters]

Tim Peters  added the comment:

Jeroen, thanks for helping us fly slightly less blind! ;-) It's a lot of work.

I'd say you may as well pick a prime.  It's folklore, but "a reason" is that 
you've discovered that regular bit patterns in multipliers can hurt, and 
sticking to primes eliminates worlds of simple & subtle bit patterns.

Another bit of folklore:  pick a multiplier such that for each byte, neither it 
nor its complement are close in value to any other byte of the multiplier.  
Which may seem more valuable for byte-oriented hashes, yet the byte-oriented 
FNV violates it spectacularly:  all FNV multipliers have _no_ bits set higher 
than 2**8 except for their leading bit.  So the longer the FNV multiplier, the 
more all-0 bytes it contains.

Which appears to be a deliberate choice to limit how quickly each new input 
byte propagates to other lower-order state bits across iterations.  The DJB33 
algorithms accomplish that by using a tiny multiplier (relative to the output 
hash width) instead.

As I explained in other msgs here, treating tuple component hashes as sequences 
of bytes seems to deliver excellent results with the unaltered byte-oriented 
versions of FNV-1[a] and DJBX33[AX] - too good for anything in my test 
collection to detect anything even suspicious, let alone "a problem" (although 
it would be easy to contrive problem cases for 33[AX] - 33 is way "too small" 
to avoid collisions even across tuples with a single component).

So part of our challenge appears to me to be that we're trying instead to 
produce a hash from inputs of the _same_ bit width.  DJB/FNV were designed to 
produce hashes of width at least 4 times their inputs' bit widths.  Each input 
has a relatively tiny effect on the internal state for them.  For us, each 
input can change the entire internal state.

--

___
Python tracker 

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