[issue41459] pickle.load raises SystemError on malformed input

[Guillaume]

New submission from Guillaume :

pickle.load() raises a criptic SystemError with malformed input, whereas I 
would have expected an UnpicklingError. 

"SystemError: deallocated bytearray object has exported buffers"

Because pickle is not meant for use on untrusted input, this likely would not 
be considered a servere issue. 

Reproducing: 

import pickle
f = open("crash-95c0cb965cb66f5eebc778a1d2304eaffb72f1aa", "rb")
d = pickle.load(f)

--
components: Argument Clinic
files: crash-95c0cb965cb66f5eebc778a1d2304eaffb72f1aa
messages: 374695
nosy: Guillaume, larry
priority: normal
severity: normal
status: open
title: pickle.load raises SystemError on malformed input
versions: Python 3.8
Added file: 
https://bugs.python.org/file49358/crash-95c0cb965cb66f5eebc778a1d2304eaffb72f1aa

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

[issue41459] pickle.load raises SystemError on malformed input

[Guillaume]

Guillaume  added the comment:

Updated Components. I believe pickle fit in the Library category. 

Note this was discovered with python 3.8.5

--
components: +Library (Lib) -Argument Clinic

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

[issue41459] pickle.load raises SystemError on malformed input

[Guillaume]

Guillaume  added the comment:

Hi Eric, 

I'm not aware of a practical problem caused by this. 

This was discovered via fuzzing. I reported it because the unexpected error 
suggest an internal issue within the pickle library. 

Just before reporting this, I browsed the bug tracker and noticed a similar 
comment suggesting this kind of pickle issue is of little consequences given 
pickle is not designed for untrusted input. So I've shifted my focus away from 
fuzzing pickle.

--

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

[issue29427] Option to skip padding for base64 urlsafe encoding/decoding

[Guillaume]

Change by Guillaume :


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

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

[issue14864] Mention logging.disable(logging.NOTSET) to reset the command in logging module documentation

[Guillaume]

New submission from Guillaume :

In the logging module documentation, nothing tells the user how to undo or 
reset a call to logging.disable(lvl). From reading the code (python 2.6 
version) it seem the correct way to undo disable(lvl) is to call disable(0), 
but I think calling disable(NOTSET) would make more sense. The sentence I 
propose to add at the end of the paragraph about the disable() function is:

To undo the effect of a call to logging.disable(lvl), call 
logging.disable(logging.NOTSET).

(This is my first doc bug report, please feel free to tell me how to improve.)

--
assignee: docs@python
components: Documentation
messages: 161206
nosy: docs@python, guibog
priority: normal
severity: normal
status: open
title: Mention logging.disable(logging.NOTSET) to reset the command in logging 
module documentation
type: enhancement

___
Python tracker 
<http://bugs.python.org/issue14864>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23348] distutils.LooseVersion fails to compare two valid versions

[Guillaume]

New submission from Guillaume:

$ python2.7 -c "from distutils.version import LooseVersion as V; print 
V('3.16.0-0.bpo.4-amd64') > V('3.16-0.bpo.2-amd64')"
False
$ python3.4 -c "from distutils.version import LooseVersion as V; 
print(V('3.16.0-0.bpo.4-amd64') > V('3.16-0.bpo.2-amd64'))" 
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.4/distutils/version.py", line 70, in __gt__
c = self._cmp(other)
  File "/usr/lib/python3.4/distutils/version.py", line 343, in _cmp
if self.version < other.version:
TypeError: unorderable types: int() < str()

Same thing with python3.2 et python3.3.

I find this on Debian. They recently change the numerotation of backported 
kernels.

--
components: Distutils
messages: 234975
nosy: dstufft, eric.araujo, maethor
priority: normal
severity: normal
status: open
title: distutils.LooseVersion fails to compare two valid versions
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

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

[issue23348] distutils.LooseVersion fails to compare two valid versions

[Guillaume]

Guillaume added the comment:

Do you mean http://bugs.python.org/issue14894 ?

--

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

[issue1293] Trailing slash in sys.path cause import failure

[Guillaume Girard]

New submission from Guillaume Girard:

On win32, the following code:

import sys
sys.path.append('../bar/')
import bar

where the file bar.py is present in ../bar/ will return an import error
"No module named bar". Remove the trailing slash and the bar.py is
imported correctly. The problem is identical with backslash. This code
works in Python 2.4.

Not a very serious bug, but it breaks programs working with Python 2.4.

--
components: Interpreter Core
messages: 56523
nosy: guillaumegirard
severity: minor
status: open
title: Trailing slash in sys.path cause import failure
type: behavior
versions: Python 2.5

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1293>
__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13538] Docstring of str() and/or behavior

[Guillaume Bouchard]

New submission from Guillaume Bouchard :

The docstring associated with str() says:

  str(string[, encoding[, errors]]) -> str
  
  Create a new string object from the given encoded string.
  encoding defaults to the current default string encoding.
  errors can be 'strict', 'replace' or 'ignore' and defaults to 'strict'.

When it is stated in the on-line documentation::

  When only object is given, this returns its nicely printable representation.

My issue comes when I tried to convert bytes to str.

As stated in the documentation, and to avoid implicit behavior, converting str 
to bytes cannot be done without giving an encoding (using bytes(my_str, 
encoding=..) or my_str.encode(...). bytes(my_str) will raise a TypeError). But 
if you try to convert bytes to str using str(my_bytes), python will returns you 
the so-called nicely printable representation of the bytes object).

ie. ::


  >>> bytes("foo")
  Traceback (most recent call last):
File "", line 1, in 
  TypeError: string argument without an encoding
  >>> str(b"foo")
  "b'foo'"

As a matter of coherency and to avoid silent errors, I suggest that str() of a 
byte object without encoding raise an exception. I think it is usually what 
people want. If one wants a *nicely printable representation* of their bytes 
object, they can call explicitly the repr() function and will quickly see that 
what they just printed is wrong. But if they want to convert a byte object to 
its unicode representation, they will prefer an exception rather than a 
silently failing converting which leads to an unicode string starting with 'b"' 
and ending with '"'.

--
components: Interpreter Core
messages: 148914
nosy: Guillaume.Bouchard
priority: normal
severity: normal
status: open
title: Docstring of str() and/or behavior
versions: Python 3.2

___
Python tracker 
<http://bugs.python.org/issue13538>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13538] Docstring of str() and/or behavior

[Guillaume Bouchard]

Guillaume Bouchard  added the comment:

> str always falls back to the repr; in general str(obj) should always return 
> some value, otherwise the assumptions of a *lot* of Python code would be 
> broken.

Perhaps it may raises a warning ?

ie, the only reason encoding exists if for the conversion of bytes (or 
something which looks like bytes) to str. Do you think it may be possible to 
special case the use of str for bytes (and bytesarray) with something like this:

def str(object, encoding=None, errors=None):
if encoding is not None:
 # usual work
else:
   if isinstance(object, (bytes, bytesarray)):
 warning('Converting bytes/bytesarray to str without encoding, it 
may not be what you expect')
 return object.__str__()

But by the way, adding warnings and special case everywhere seems not too 
pythonic.

> Do you want to propose a doc patch?

The docstring for str() should looks like something like, in my frenglish way 
of writing english ::

  Create a new string object from the given encoded string.

  If object is bytes, bytesarray or a buffer-like object, encoding and error
  can be set. errors can be 'strict', 'replace' or 'ignore' and defaults to
  'strict'.

  WARNING, if encoding is not set, the object is converted to a nicely
  printable representation, which is totally different from what you may expect.

Perhaps a warning may be added in the on-line documentation, such as ::

  .. warning::
 When str() converts a bytes/bytesarray or a buffer-like object and
 *encoding* is not specified, the result will an unicode nicely printable
 representation, which is totally different from the unicode representation 
of
 you object using a specified encoding.

Whould you like a .diff on top of the current mercurial repository ?

--

___
Python tracker 
<http://bugs.python.org/issue13538>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2903] Add __name__ in globals of generated namedtuple namespace

[Guillaume Knispel]

New submission from Guillaume Knispel <[EMAIL PROTECTED]>:

Some 3rd party tracers rely on frame.f_globals["__name__"] to be set to
the module name that contains the code currently executed.
frame.f_globals["__name__"] is not defined when some code has been
generated with exec, which is the way namedtuples are created.

The attached patch set __name__ to '__generated_%s__' % typename in the
generated namespace, which is quite handy to see where the code comes
from. Indeed if sys._getframe is available it sets __name__ to
'__generated_%s__%s__' % (typename, result.__module__) which is even
more useful.

--
components: Library (Lib)
files: collections.r59898.patch
keywords: patch
messages: 67022
nosy: xilun
severity: normal
status: open
title: Add __name__ in globals of generated namedtuple namespace
versions: Python 2.6
Added file: http://bugs.python.org/file10361/collections.r59898.patch

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2903>
__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3698] incompatible arguments in warning formatting for idle

[Guillaume Coffin]

New submission from Guillaume Coffin <[EMAIL PROTECTED]>:

In idle, the function idle_formatwarning_subproc overrides
warnings.formatwarning, however the latter in Python 2.6 is called from
warnings._show_warning with an additional "line" argument:

line 29, in _show_warning
file.write(formatwarning(message, category, filename, lineno, line))

whereas idle_formatwarning_subproc still only accepts 4 arguments. The
optional line argument should be added.

--
components: IDLE
messages: 72023
nosy: gcoffin
severity: normal
status: open
title: incompatible arguments in warning formatting for idle
type: crash
versions: Python 2.6

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3698>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5111] httplib: wrong Host header when connecting to IPv6 loopback

[Guillaume Desmottes]

New submission from Guillaume Desmottes :

To reproduce:
- Launch a HTTP server listening on an Inet6 socket on, say, port 
- Try to connect using the IPv6 loopback: 
http = httplib.HTTPConnection('[::1]:')
http.request('GET', '/foo')
r = http.getresponse()
print r.status
- You get 400 (bad-request) instead of 404

It seems that's because the HTTP request is wrong. Python sends this header:
Host: ::1:
but it should be:
Host: [::1]:

I'm using python 2.5.2-1ubuntu1 on Intrepid.

--
components: Library (Lib)
messages: 80827
nosy: gdesmott
severity: normal
status: open
title: httplib: wrong Host header when connecting to IPv6 loopback
versions: Python 2.5

___
Python tracker 
<http://bugs.python.org/issue5111>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5111] httplib: wrong Host header when connecting to IPv6 litteral URL

[Guillaume Desmottes]

Guillaume Desmottes  added the comment:

Actually, this bug is present when you try to connect to any URL
containing an IP6 and a port.

So, we have the same problem when using, for example:
http = httplib.HTTPConnection('[2a01:8790:16d:0:218:de87:164:8745]:')

but
http = httplib.HTTPConnection('[2001:4860:0:1001::68]:80')

does work. Probably because we use the default HTTP port.

--
title: httplib: wrong Host header when connecting to IPv6 loopback -> httplib: 
wrong Host header when connecting to IPv6 litteral URL

___
Python tracker 
<http://bugs.python.org/issue5111>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44251] ctypes '_get_soname' fails silently on missing objdump

[Guillaume Desforges]

New submission from Guillaume Desforges :

## Description

Libraries such as oscrypto will use `ctypes.utils.find_library` to look for 
libraries, which in turns uses ``.

However, on Linux, if the system does not have the objdump command, the 
function fails silently.

https://github.com/python/cpython/blob/0bf0500baa4cbdd6c5668461c2a2a008121772be/Lib/ctypes/util.py#L177

## Expected behavior

It should either raise an Exception saying that objdump is missing, or 
outputting a helpful message.

--
components: Library (Lib)
messages: 394565
nosy: GuillaumeDesforges
priority: normal
severity: normal
status: open
title: ctypes '_get_soname' fails silently on missing objdump
type: behavior
versions: Python 3.9

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

[issue41145] EmailMessage.as_string is altering the message state and actually fix bugs

[Guillaume Gauvrit]

New submission from Guillaume Gauvrit :

I am currently refactoring code and use the EmailMessage api
to build message.

I encountered weird behavior while building an email.
The `as_string()` method is fixing the `make_alternative` method.

So, to me their is two bug here: a `as_string` method should not mutate 
internal state,
and the `make_alternative` should create a correct internal state.


It may be resume in the following program:


```
𝝿 python
Python 3.8.3 (default, May 17 2020, 18:15:42)
[GCC 10.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import email
>>> from email.message import EmailMessage, MIMEPart
>>>
>>> msg = EmailMessage()
>>> msg.make_alternative()
>>> print(msg.get_boundary())
None
>>> print(msg._headers)
[('Content-Type', 'multipart/alternative')]
>>> _ = msg.as_string()
>>> print(msg.get_boundary())
===3171625413581695247==
>>> print(msg._headers)
[('Content-Type', 'multipart/alternative; 
boundary="===3171625413581695247=="')]
```

--
files: bug.py
messages: 372508
nosy: mardiros
priority: normal
severity: normal
status: open
title: EmailMessage.as_string is altering the message state and actually fix 
bugs
type: resource usage
versions: Python 3.7, Python 3.8
Added file: https://bugs.python.org/file49271/bug.py

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

[issue30717] str.center() is not unicode aware

[Guillaume Sanchez]

New submission from Guillaume Sanchez:

"a⃑".center(width=5, fillchar=".")
produces
'..a⃑.' instead of '..a⃑..'

The reason is that "a⃑" is composed of two code points (2 UCS4 chars), one 'a' 
and one combining code point "above arrow". str.center() counts the size of the 
string and fills it both sides with `fillchar` until the size reaches `width`. 
However, this size is certainly intended to be the number of characters and not 
the number of code points.

The correct way to count characters is to use the grapheme clustering algorithm 
from UAX TR29.

Turns out I implemented this myself already, and might do the PR if asked so, 
with a little help to make the C <-> Python glue.

Thanks for your time.

--
components: Library (Lib)
messages: 296478
nosy: Guillaume Sanchez
priority: normal
severity: normal
status: open
title: str.center() is not unicode aware
versions: Python 3.7

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

[issue30717] str.center() is not unicode aware

[Guillaume Sanchez]

Guillaume Sanchez added the comment:

Obviously, I'm talking about str.center() but all functions needing a count of 
graphemes are then not totally correct.

I can fix that and add the corresponding function, or an iterator over 
graphemes, or whatever seems right :)

--

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

[issue30717] str.center() is not unicode aware

[Guillaume Sanchez]

Guillaume Sanchez added the comment:

Thanks for all those interesting cases you brought here! I didn't think of that 
at all!

I'm using the word "grapheme" as per the definition given in UAX TR29 which is 
*not* language/locale dependant [1].

This annex is very specific and precise about where to break "grapheme cluster" 
aka "when does a character starts and ends". Sadly, it's a bit more complex 
than just accumulating based on the Combining property. This annex gives a set 
of rules to implement, based on Grapheme_Cluster_Break property, and while 
those rules may naively be implemented as comparing adjacent pairs of code 
points, this is wrong and can be correctly and efficiently implemented as an 
automaton. My code [2] passes all tests from GraphemeBreakTests.txt (provided 
by Unicode).

We can definitely do a generator like you propose, or rather do it in the C 
layer to gain more efficiency and coherence since the other string / Unicode 
operations are in the C layer (upper, lower, casefold, etc)

Let me know what you guys think, what (and if) I should contribute :)

[1] http://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries
[2] 
https://github.com/Vermeille/batriz/blob/master/src/str/grapheme_iterator.h#L31

--

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

[issue30717] str.center() is not unicode aware

[Guillaume Sanchez]

Guillaume Sanchez added the comment:

Hello to all of you, sorry for the delay. Been busy.

I added the base code needed to built the grapheme cluster break algorithm. We 
now have the GraphemeBreakProperty available via 
unicodedata.grapheme_cluster_break()

Can you check that the implementation correctly fits the design? I was not sure 
about adding that prop to unicodedata_db ou unicodectype_db, tbh.

If it's all correct, I'll move forward with the automaton and the grapheme 
cluster breaking algorithm.

Thanks!

--

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

[issue30717] str.center() is not unicode aware

[Guillaume Sanchez]

Guillaume Sanchez added the comment:

Hello,

I implemented unicodedata.break_graphemes() that returns an iterators that 
spits consecutive graphemes.

This is a "test" implementation meant to see what doesn't fits Python's style 
and design, to discuss naming and implementation details.

https://github.com/python/cpython/pull/2673

Thanks for your time and interest

--

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

[issue12568] Add functions to get the width in columns of a character

[Guillaume Sanchez]

Guillaume Sanchez added the comment:

Hello,

I come from bugs.python.org/issue30717 . I have a pending PR that needs review 
( https://github.com/python/cpython/pull/2673 ) adding a function that breaks 
unicode strings into grapheme clusters (aka what one would intuitively call "a 
character"). It's based on the grapheme cluster breaking algorithm from TR29.

Let me know if this is of any relevance.

Quick demo:
>>> a=unicodedata.break_graphemes("lol")
>>> list(a)
['l', 'o', 'l']
>>> list(unicodedata.break_graphemes("lo\u0309l"))
['l', 'ỏ', 'l']
>>> list(unicodedata.break_graphemes("lo\u0309\u0301l"))
['l', 'ỏ́', 'l']
>>> list(unicodedata.break_graphemes("lo\u0301l"))
['l', 'ó', 'l']
>>> list(unicodedata.break_graphemes(""))
[]

--
nosy: +Guillaume Sanchez

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

[issue30717] str.center() is not unicode aware

[Guillaume Sanchez]

Guillaume Sanchez added the comment:

Hello Steven!

Thanks for your reactivity!

unicodedata.grapheme_cluster_break() takes a unicode code point as an argument 
and return its GraphemeBreakProperty as a string. Possible values are listed 
here: http://www.unicode.org/reports/tr29/#CR

help(unicodedata.grapheme_cluster_break) says:
grapheme_cluster_break(chr, /)
Returns the GraphemeBreakProperty assigned to the character chr as string.



unicodedata.break_graphemes() takes a unicode string as argument and returns an 
GraphemeClusterIterator that spits consecutive graphemes clusters.

help(unicodedata.break_graphemes) says:

break_graphemes(unistr, /)
Returns an iterator to iterate over grapheme clusters in unistr.

It uses extended grapheme cluster rules from TR29.


Is there anything else you would like to know? Don't hesitate to ask :)

Thank you for your time!

--
assignee:  -> christian.heimes
components: +SSL, Tests, Tkinter -Library (Lib)
nosy: +christian.heimes

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

[issue30717] str.center() is not unicode aware

[Guillaume Sanchez]

Guillaume Sanchez added the comment:

Hi,

Are you guys still interested? I haven't heard from you in a while

--

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

[issue30717] Add unicode grapheme cluster break algorithm

[Guillaume Sanchez]

Guillaume Sanchez added the comment:

Thanks for your consideration. I'm currently fixing what's been asked in the 
reviews.

> But it would be useful to provide also word and sentence iterators.

I'll gladly do that as well!

> I think emitting a pair (pos, substring) would be more useful.

That means emitting a pair like ((start, end), substr) ? Is it pythonic to 
return a structure like this?

For what it's worth, I don't like it, but I definitely understand the value of 
it. I'd prefer having two versions. One returning indexes, the other returning 
substrings.

But...

> Alternatively an iterator could emit slice objects.

I really like that. Do we have a clear common agreement or preference on any 
option?

--

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

[issue30717] Add unicode grapheme cluster break algorithm

[Guillaume Sanchez]

Guillaume Sanchez added the comment:

I have a few criticism to do against that proto-PEP

http://mail.python.org/pipermail/python-dev/2001-July/015938.html

In particular, the fact that all those functions return an index prevents any 
state keeping.

That's a problem because:

> next_(u, index) -> integer

As you've seen it, in grapheme clustering (as well as words and line breaking), 
we have to have an automaton to decide on the breaking point. Which means that 
starting at an arbitrary index is not possible.

> prev_(u, index) -> integer

Is it really necessary? It means implementing the same logic to go backward. In 
our current case, we'd need a backward grapheme cluster break automaton too.

> _start(u, index) -> integer
> _end(u, index) -> integer

Not doable in O(1) for the same reason as next_(). We need a 
context, and the code point itself cannot give enough information to know if 
it's the start/end of a given indextype.

--

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

[issue30717] Add unicode grapheme cluster break algorithm

[Guillaume Sanchez]

Guillaume Sanchez added the comment:

> I don't think unicodedata is the right place

I do agree with that. A new module sounds good, would it be a problem if that 
module would contain very few functions at first?

> Can we mark this as having a Provisional API to give us time to decide on the 
> best API before locking it in permanently?

I'm not sure it's my call to make, but I would gladly consider that option.

> we should go through a PEP.

Why not. I may need a bit of guidance though.

> If you want state keeping for iterating over multiple  parts of 
> the string, you can use an iterator.

Sure thing. It just wasn't specified like this in the proto-PEP.

> The APIs were inspired by the standard string.find() APIs, that's why they 
> work on indexes and don't return Unicode strings. As such, they serve a 
> different use case than an iterator.

I personally like having a generator returning slice objects, as suggested 
above. What would be some good objections to this?

> Wouldn't this be a typical case where we'd expect a module to evolve and gain 
> usage on PyPI first, before adding it to the stdlib? [...] they might give 
> inspiration for a suitable API design

I'll give it a look.

> The well known library for Unicode support in C++ and Java is ICU

Yes. I clearly don't want this PR to be interpreted as "we're needing ICU". ICU 
provides much much more than what I'm willing to provide. My goal here is just 
to "fix" how the python's standard library iterates over characters. Noting 
more, nothing less.

One might think that splitlines() should be "fixed" too, and there is clearly 
matter to discuss here. Same for words splitting. However, I do not intend to 
bring normalization, which you already have, collations, locale dependant 
upcasing or lowercasing, etc. We might need a wheel, but we don't have to take 
the whole truck.

How do we discuss all of this? Who's in charge of making decisions? How long 
should we debate? That's my first time contributing to Python and I'm new to 
all of that.

Thanks for your time.

--

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

[issue22102] Zipfile generates Zipfile error in zip with 0 total number of disk in Zip64 end of central directory locator

[Guillaume Carre]

Guillaume Carre  added the comment:

Hi,
In my case the zip file was created from windows 7  context menu (send to)
Regards,
Guillaume

On Mon, Mar 12, 2018 at 5:08 AM, Thomas Kluyver 
wrote:

>
> Thomas Kluyver  added the comment:
>
> I found source code for some other projects handling the same data. They
> all seem to agree that it should be 1:
>
> - Golang's zip reading code: https://github.com/golang/go/blob/
> f7ac70a56604033e2b1abc921d3f0f6afc85a7b3/src/archive/zip/
> reader.go#L536-L538
> - A C contrib file with zlib: https://github.com/madler/zlib/blob/
> cacf7f1d4e3d44d871b605da3b647f07d718623f/contrib/minizip/zip.c#L620-L624
> - Code from Info-ZIP, which is used by many Linux distros, is a bit less
> clear, but it has an illuminating comment:
>
> if ((G.ecrec.number_this_disk != 0x) &&
> (G.ecrec.number_this_disk != ecloc64_total_disks - 1)) {
>   /* Note: For some unknown reason, the developers at PKWARE decided to
>  store the "zip64 total disks" value as a counter starting from 1,
>  whereas all other "split/span volume" related fields use 0-based
>  volume numbers. Sigh... */
>
> So I think you've got an invalid zip file. If it's otherwise valid, there
> might be a case for Python tolerating that particular mistake. But it's
> probably better to fix whatever is making the incorrect zip file, because
> other tools are also going to reject it.
>
> --
>
> ___
> Python tracker 
> <https://bugs.python.org/issue22102>
> ___
>

--

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

[issue22102] Zipfile generates Zipfile error in zip with 0 total number of disk in Zip64 end of central directory locator

[Guillaume Carre]

Guillaume Carre  added the comment:

Yes these were pretty large zip 30 to 60Gb with thousands of small files in
them I've fixed locally on our servers and we've been happy even after
accepting similar sized files from linux machine.
I'm also quite surprised about this not being reported by others.

On Mon, Mar 12, 2018 at 9:01 AM, Thomas Kluyver 
wrote:

>
> Thomas Kluyver  added the comment:
>
> If every Windows 7 computer is generating zipfiles which are invalid in
> this way, that would be a pretty strong argument for Python (and other
> tools) to accept it. But if that was the case, I would also expect that
> there would be many more issues about it.
>
> Are the files you're compressing large (multi-GB)? Python only uses the
> zip64 format when the files are too big for the older zip format; maybe
> Windows is doing the same. Even in that case, I'm still surprised that more
> people don't hit it.
>
> --
>
> ___
> Python tracker 
> <https://bugs.python.org/issue22102>
> ___
>

--

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

[issue31966] print('hello\n', end='', flush=True) raises OSError when ran with py -u

[Guillaume Aldebert]

New submission from Guillaume Aldebert :

noticed on windows10, 3.6.3-64 and 3.7.0a2-64:

using this test.py file:

#!/usr/bin/env python3
print('hello\n', end='', flush=True)

and running it in unbuffered mode:

C:\Dev>py -u test.py
hello
Traceback (most recent call last):
  File "test.py", line 2, in 
print('hello\n', end='', flush=True)
OSError: [WinError 87] The parameter is incorrect

Note that (still using py -u):

print('hello', end='', flush=True) # works fine
print('', end='', flush=True) # raises OSError as well

--
components: Windows
messages: 305726
nosy: Guillaume Aldebert, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: print('hello\n', end='', flush=True) raises OSError when ran with py -u
type: behavior
versions: Python 3.6, Python 3.7

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

[issue26752] Mock(2.0.0).assert_has_calls() raise AssertionError in two same calls

[Guillaume Boily]

Guillaume Boily  added the comment:

As pointed here: https://github.com/testing-cabal/mock/issues/353,

this issue is related to the method assert_has_calls or probably any calls that 
use the method _call_matcher to match calls. Given that you mock a class and 
spec it, since we always bind to the _spec_signature (e.g. the constructor 
signature), when it is a method call then it bind() throws a TypeError looking 
like `missing a require argument`. A possible solution would be to include 
method signatures into the spec.

--
components: +Tests
nosy: +guboi72
versions: +Python 3.6 -Python 2.7, Python 3.4

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

[issue34702] urlopen doesn't handle query strings with "file" scheme

[Guillaume Ayoub]

New submission from Guillaume Ayoub :

urlopen includes query strings in the filename with "file"-scheme URLs.

>>> from urllib.request import urlopen
>>> urlopen('file:///tmp/test')
>
>>> urlopen('file:///tmp/test?q')
Traceback (most recent call last):
  File "/usr/lib/python3.7/urllib/request.py", line 1473, in open_local_file
stats = os.stat(localfile)
FileNotFoundError: [Errno 2] No such file or directory: '/tmp/test?q'

This behavior seems to be OK with what RFC 8089 tells, but many other 
implementations (including browsers and curl) remove query strings from the 
filename.

--
messages: 325475
nosy: liZe
priority: normal
severity: normal
status: open
title: urlopen doesn't handle query strings with "file" scheme
type: behavior

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

[issue34761] str(super()) != super().__str__()

[Guillaume Dominici]

New submission from Guillaume Dominici :

The super proxy does not seem to forward call to .__str__() when the call 
occurs via str() function.
It may be an expected behavior, but it looks unexpected to me.

Minimal reproduction (tested on Python 3.6, but I believe may newer versions 
have similar behavior):

class Parent():
  def __str__(self):
return "Parent"

class Child(Parent):
  def foo(self):
s = super(Child, self)
print(s.__str__())
print(str(s))


c = Child()
c.foo()

# Output :
### Parent
### , >

--
messages: 325976
nosy: Guillaume Dominici
priority: normal
severity: normal
status: open
title: str(super()) != super().__str__()
type: behavior
versions: Python 3.6

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

[issue13424] Add examples for open’s new opener argument

[Guillaume P]

Guillaume P added the comment:

Here is a proposed patch to the documentation.

--
keywords: +patch
nosy: +guillaumep
Added file: http://bugs.python.org/file27866/13424.patch

___
Python tracker 
<http://bugs.python.org/issue13424>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19279] UTF-7 to UTF-8 decoding crash

[Guillaume Lebourgeois]

New submission from Guillaume Lebourgeois:

After the fetch of a webpage with a wrongly declared encoding, the use of 
codecs module for a conversion crashes.

The issue is reproducible this way : 

>>> content = b"+1911\' rel=\'stylesheet\' type=\'text/css\' />\n>> rel="alternate" type="application/rss+xml"
>>> codecs.utf_7_decode(content, "replace", True)
Traceback (most recent call last):
  File "", line 1, in 
SystemError: invalid maximum character passed to PyUnicode_New

Original issue here  : https://github.com/kennethreitz/requests/issues/1682

--
components: Library (Lib)
messages: 200117
nosy: glebourgeois
priority: normal
severity: normal
status: open
title: UTF-7 to UTF-8 decoding crash
type: crash
versions: Python 3.3

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

[issue19279] UTF-7 to UTF-8 decoding crash

[Guillaume Lebourgeois]

Guillaume Lebourgeois added the comment:

My fault, bad paste. Should have written : 

>>> content = b'+1911\' rel=\'stylesheet\' type=\'text/css\' />\n>> rel="alternate" type="application/rss+xml'
>>> codecs.utf_7_decode(content, "replace", True)
Traceback (most recent call last):
  File "", line 1, in 
SystemError: invalid maximum character passed to PyUnicode_New

--

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

[issue19279] UTF-7 to UTF-8 decoding crash

[Guillaume Lebourgeois]

Guillaume Lebourgeois added the comment:

"Also, the usual way to decode by using the .decode method."

The original bug happened using requests library, so I have no leverage on the 
used method for decoding.

But if you used the "replace" mode with your methodology, you would have raised 
the same Exception : 

>>> content = b'+1911\' rel=\'stylesheet\' type=\'text/css\' />\n>> rel="alternate" type="application/rss+xml'
>>> content.decode("utf-7", "replace")
File "", line 1, in 
  File "/lib/python3.3/encodings/utf_7.py", line 12, in decode
return codecs.utf_7_decode(input, errors, True)
SystemError: invalid maximum character passed to PyUnicode_New

--

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

[issue22102] Zipfile generates Zipfile error in zip with 0 total number of disk in Zip64 end of central directory locator

[Guillaume Carre]

New submission from Guillaume Carre:

I've got a zip file with a Zip64 end of central directory locator in which:
- total number of disks = 
- number of the disk with the start of the zip64 end of central directory = 

According to the test line 176 in zipfile.py this fails:
if diskno != 0 or disks != 1:
raise BadZipfile("zipfiles that span multiple disks are not supported")

I believe the test should be changed to  
if diskno != 0 or disks > 1:

--
components: Library (Lib)
messages: 224257
nosy: Guillaume.Carre
priority: normal
severity: normal
status: open
title: Zipfile generates Zipfile error in zip with 0 total number of disk in 
Zip64 end of central directory locator
type: behavior
versions: Python 2.7

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

[issue17703] Trashcan mechanism segfault during interpreter finalization in Python 2.7.4

[Guillaume Matte]

Guillaume Matte added the comment:

It does still cause a Fatal Error in debug build as PyThreadState_GET() error 
out if _PyThreadState_Current is NULL

--
nosy: +flex.plexico

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

[issue18795] pstats - allow stats sorting by cumulative time per call and total time per call

[Guillaume Gelin]

Changes by Guillaume Gelin :


--
nosy: +ramnes

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

[issue1194378] sendmsg() and recvmsg() for C socket module

[Guillaume Desmottes]

Changes by Guillaume Desmottes :


--
nosy: +gdesmott

___
Python tracker 
<http://bugs.python.org/issue1194378>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29445] http.client: missing response headers when malformed header is part of the response

[Guillaume Boudreau]

New submission from Guillaume Boudreau:

Tested using urllib3 1.20

```
>>> import urllib3
>>> http = urllib3.PoolManager()
>>> r = http.request('GET', 
>>> 'https://online.chasecanada.ca/ChaseCanada_Consumer/Login.do')
>>> r.status
200
>>> r.headers
HTTPHeaderDict({'Date': 'Sat, 04 Feb 2017 20:09:21 GMT'})
>>>
```

I'm pretty sure the problem is caused by an invalid HTTP header returned by the 
server:

HTTP/1.1 200 OK
Date: Sat, 04 Feb 2017 19:16:34 GMT
My Param: None
[...]

It directly follows the Date response header, which is returned fine, but since 
no other response headers is returned, I think this broken header is breaking 
the HTTP response headers parser.

Of note: the `http.client.HTTPresponse.headers` object (`HTTPMessage`) shows 
all headers in `_payload`, but only the `Date` header in `_headers`.
Thus why I think this is a http.client issue, and not a urllib3 issue.

--
components: Library (Lib)
messages: 286987
nosy: gboudreau
priority: normal
severity: normal
status: open
title: http.client: missing response headers when malformed header is part of 
the response
type: behavior
versions: Python 3.5

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

[issue29445] http.client: missing response headers when malformed header is part of the response

[Guillaume Boudreau]

Guillaume Boudreau added the comment:

Yes, indeed. The latest patch in 24363 resolves this issue.
Sorry for the duplicate.

--

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

[issue24363] httplib fails to handle semivalid HTTP headers

[Guillaume Boudreau]

Guillaume Boudreau added the comment:

Any chance this could get reviewed and merged soon? I got hit by a similar 
issue (see #29445) where the server, which I don't control, sends me invalid 
HTTP headers, and the prevents all the headers that follow it to not be parsed.
The latest attached patch fixed the issue for me.
Thanks.

--
nosy: +gboudreau

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

[issue25340] libraries variable in setup.py ignore for multiprocessing module

[Guillaume DAVY]

New submission from Guillaume DAVY:

Around line 1455 in setup.py the "libraries" variable is assigned but
seems to be ignored when the Extension object for multiprocessing
is created. This leads to a linking error on my system : "undefined symbol: 
clock_gettime"

--
components: Installation
messages: 252517
nosy: davyg
priority: normal
severity: normal
status: open
title: libraries variable in setup.py ignore for multiprocessing module
type: compile error
versions: Python 2.7

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

[issue28318] Python unittest.mock.mock_calls stores references to arguments instead of their values

[Guillaume Chorn]

New submission from Guillaume Chorn:

In the unittest.mock library, when a Mock object stores the calls made on it in 
its `mock_calls` attribute, it appears to store references to the call 
arguments instead of the actual values of the call arguments. In cases where 
call args are mutable types, this results in the undesirable behavior below:

```python
import mock

arg = ['one']

test_function(arg)

# passes
test_function.assert_has_calls([mock.call(['one'])])

arg += ['two']

test_function(arg)

# fails, even though we just verified the first call above!
test_function.assert_has_calls([
mock.call(['one']),
mock.call(['one','two'])
])

# passes, even though we didn't make the exact same call twice!
test_function.assert_has_calls([
mock.call(['one', 'two']),
mock.call(['one', 'two'])
])
```

--
components: Tests
messages: 277764
nosy: Guillaume Chorn
priority: normal
severity: normal
status: open
title: Python unittest.mock.mock_calls stores references to arguments instead 
of their values
type: behavior
versions: Python 3.4

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

[issue28318] Python unittest.mock.mock_calls stores references to arguments instead of their values

[Guillaume Chorn]

Guillaume Chorn added the comment:

If it's true that our ability to accurately deep-copy mutable args makes fixing 
this behavior impossible, we should at the very least update the official 
unittest.mock documentation to warn users that testing for mock calls with 
mutable arguments is not reliable; i.e. make it clear that we're storing a 
reference to the arguments and not just the values. If it's not a bug, it's 
certainly a limitation that deserves as much mention as possible.

--

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

[issue1907] Httplib.py not supporting timeout - Propose Fix attached

[Guillaume Nourry-Marquis]

New submission from Guillaume Nourry-Marquis:

The httplib file wasn'T supporting a timeout feature which was essential
for my load testing application I built. In order to do that, I had to
append a parameter to the connect function, which takes a socket timeout
value integer in seconds.

def connect(self,timeout=None):
"""Connect to the host and port specified in __init__."""
msg = "getaddrinfo returns an empty list"
for res in socket.getaddrinfo(self.host, self.port, 0,
  socket.SOCK_STREAM):
af, socktype, proto, canonname, sa = res
try:
self.sock = socket.socket(af, socktype, proto)
#Guillaume's timeout
self.sock.settimeout(timeout)
if self.debuglevel > 0:
print "connect: (%s, %s)" % (self.host, self.port)
self.sock.connect(sa)
except socket.error, msg:
if self.debuglevel > 0:
print 'connect fail:', (self.host, self.port)
if self.sock:
self.sock.close()
self.sock = None
continue
break
if not self.sock:
raise socket.error, msg

Simple patch, but it was essential for my work.

--
components: Library (Lib)
files: httplib.py
messages: 61512
nosy: xlash
severity: minor
status: open
title: Httplib.py not supporting timeout - Propose Fix attached
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file9263/httplib.py

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1907>
__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34059] multiprocessing deadlock

[Guillaume Perrault-Archambault]

New submission from Guillaume Perrault-Archambault :

The simple code attached causes a deadlock in Linux.

Problem is I have to slightly muck around with it depending on the distro and 
python version to get it to deadlock.

On the cluster I use the most (python 3.6.3, CentOS Linux release 7.4.1708, 
pytorch 0.4.0 with no CUDA), the code attached causes a deadlock.

--
components: Library (Lib)
files: multiprocess_torch.py
messages: 321146
nosy: gobbedy
priority: normal
severity: normal
status: open
title: multiprocessing deadlock
type: crash
versions: Python 3.6
Added file: https://bugs.python.org/file47673/multiprocess_torch.py

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

[issue34059] multiprocessing deadlock

[Guillaume Perrault-Archambault]

Guillaume Perrault-Archambault  added the comment:

Hi Victor and Yang,

Thanks for your fast replies.

I did initially think it could be a torch issue. Indeed, I have an
equivalent numpy testcase that does not deadlock. However, the fact that it
gets stuck inside a multiprocessing wait statement makes me think it's
still a multiprocessing issue.

I've spent two weeks full time on this issue. Over at torch forums I've had
no replies (
https://discuss.pytorch.org/t/multiprocessing-code-works-using-numpy-but-deadlocked-using-pytorch/20473
).

On stackexchange I only got a workaround suggestion that works sporadically
(
https://stackoverflow.com/questions/51093970/multiprocessing-code-works-using-numpy-but-deadlocked-using-pytorch).
Basically I can get rid of the deadlock (sometimes) if I impose only one
thread per process. But this is not a solution anyway.

I have tried stepping through the code, but because it is multiprocessed,
you cannot step through it (at least not in the conventional way, since the
main thread is not doing the heavy lifting).

I've tried adding print statements in the multiprocess library and mucking
around with it a bit, but debugging multi-processed code in this way is an
absolute nightmare because you can't even trust the order in which print
statements display on the screen. And probably more relevant, I'm out of my
league here.

I'm really at a complete dead end. I'm blocked and my work cannot progress
without fixing this issue. I'd be very grateful if you could try to
reproduce and rule out the multiprocessing library. If you need help
reproducing I can send a different testcase that deadlocked on my friend's
Mac (for him, the original testcase did not deadlock).

Testcase I attached in my original post it sometimes deadlocks and
sometimes doesn't, depending on the machine I run on. So I'm not suprised
you got no deadlock when you tried to reproduce.

I can always get it deadlocking on Linux/Mac though, by tweaking the code.

To give you a sense of how unreliably it deadlocks, just removing the for
loop in the code (which is outside the multiprocessing portion of the
code!) somehow gets rid of the deadlock. Also, it never deadlocks on
Windows.

If you could provide any help on this issue I'd be very grateful.

Regards,
Guillaume.

On Fri, Jul 6, 2018 at 11:21 AM STINNER Victor 
wrote:

>
> STINNER Victor  added the comment:
>
> IMHO it's an issue with your usage of the torch module which is not part
> of the Python stdlib, so I suggest to close this issue as "third party" or
> "not a bug".
>
> --
> nosy: +vstinner
>
> ___
> Python tracker 
> <https://bugs.python.org/issue34059>
> ___
>

--

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

[issue34059] multiprocessing deadlock

[Guillaume Perrault-Archambault]

Guillaume Perrault-Archambault  added the comment:

A friend of mine has suggested a fix that seems to work for now (upgrade numpy 
from 1.14.3 to 1.14.5). This makes no sense at all but it does seem to work for 
now. I have a strong suspicion that this is just masking the problem and that 
it will reappear.

However, since it works I would not want you to waste any time on this. I will 
reopen if the deadlock reappears!

I do apologize if you already spent a lot of time on this.

Regards,
Guillaume

--
resolution:  -> third party
stage:  -> resolved
status: open -> closed

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

[issue6753] Python 3.1.1 test_cmd_line fails on Fedora 11

[Guillaume Delcourt-Petetin]

New submission from Guillaume Delcourt-Petetin :

Just what it says on the label :

[...]
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 618, in runtest_inner
indirect_test()
  File
"/home/Pif/Téléchargement/Python-3.1.1/Python-3.1.1/Lib/test/test_cmd_l
test.support.run_unittest(CmdLineTest)
  File
"/home/Pif/Téléchargement/Python-3.1.1/Python-3.1.1/Lib/test/support.py
_run_suite(suite)
  File
"/home/Pif/Téléchargement/Python-3.1.1/Python-3.1.1/Lib/test/support.py
raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File
"/home/Pif/Téléchargement/Python-3.1.1/Python-3.1.1/Lib/test/test_cmd_l
self.assertTrue(path1.encode('ascii') in stdout)
AssertionError: False is not True


During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 1222, in 
main()
  File "./Lib/test/regrtest.py", line 425, in main
testdir, huntrleaks)
  File "./Lib/test/regrtest.py", line 584, in runtest
testdir, huntrleaks)
  File "./Lib/test/regrtest.py", line 638, in runtest_inner
print("test", test, "failed --", msg)
UnicodeEncodeError: 'ascii' codec can't encode character '\xe9' in
position 54: ordinal not in range(128)
test test_cmd_line failed -- make: *** [test] Erreur 1

[...]


In my search for similar bugs, I only found a mac OSX/Python 3.0 issue
(http://bugs.python.org/issue4388)

--
components: Tests
messages: 91813
nosy: Pif
severity: normal
status: open
title: Python 3.1.1 test_cmd_line fails on Fedora 11
type: behavior
versions: Python 3.1

___
Python tracker 
<http://bugs.python.org/issue6753>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6753] Python 3.1.1 test_cmd_line fails on Fedora 11

[Guillaume Delcourt-Petetin]

Guillaume Delcourt-Petetin  added the comment:

Nope.

2009/8/21 Amaury Forgeot d'Arc 

>
> Amaury Forgeot d'Arc  added the comment:
>
> Does it happen if you build python from a directory with no accented
> letters?
>
> --
> nosy: +amaury.forgeotdarc
>
> ___
> Python tracker 
> <http://bugs.python.org/issue6753>
> ___
>

--
Added file: http://bugs.python.org/file14760/unnamed

___
Python tracker 
<http://bugs.python.org/issue6753>
___Nope.2009/8/21 Amaury Forgeot d'Arc <mailto:rep...@bugs.python.org";>rep...@bugs.python.org>

Amaury Forgeot d'Arc <mailto:amaur...@gmail.com";>amaur...@gmail.com> added the 
comment:

Does it happen if you build python from a directory with no accented
letters?

--
nosy: +amaury.forgeotdarc

___
Python tracker <mailto:rep...@bugs.python.org";>rep...@bugs.python.org>
<http://bugs.python.org/issue6753"; 
target="_blank">http://bugs.python.org/issue6753>
___

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

[issue28604] Exception raised by python3.5 when using en_GB locale

[Guillaume Pasquet (Etenil)]

New submission from Guillaume Pasquet (Etenil):

This issue was originally reported on Fedora's Bugzilla: 
https://bugzilla.redhat.com/show_bug.cgi?id=1391280

Description of problem:
After switching the monetary locale to en_GB, python then raises an exception 
when calling locale.localeconv()

Version-Release number of selected component (if applicable):
3.5.2-4.fc25

How reproducible:
Every time

Steps to Reproduce:
1. Write a python3 script or open the interactive interpreter with "python3"
2. Enter the following
import locale
locale.setlocale(locale.LC_MONETARY, 'en_GB')
locale.localeconv()
3. Observe that python raises an encoding exception

Actual results:
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib64/python3.5/locale.py", line 110, in localeconv
d = _localeconv()
UnicodeDecodeError: 'locale' codec can't decode byte 0xa3 in position 0: 
Invalid or incomplete multibyte or wide character

Expected results:
A dictionary of locale data similar to (for en_US):
{'mon_thousands_sep': ',', 'currency_symbol': '$', 'negative_sign': '-', 
'p_sep_by_space': 0, 'frac_digits': 2, 'int_frac_digits': 2, 'decimal_point': 
'.', 'mon_decimal_point': '.', 'positive_sign': '', 'p_cs_precedes': 1, 
'p_sign_posn': 1, 'mon_grouping': [3, 3, 0], 'n_cs_precedes': 1, 'n_sign_posn': 
1, 'grouping': [3, 3, 0], 'thousands_sep': ',', 'int_curr_symbol': 'USD ', 
'n_sep_by_space': 0}

Note:
This was reproduced on Linux Mint 18 (python 3.5.2), and also on Fedora with 
python 3.4 and python 3.6 (compiled).

--
components: Interpreter Core
messages: 280023
nosy: Guillaume Pasquet (Etenil)
priority: normal
severity: normal
status: open
title: Exception raised by python3.5 when using en_GB locale
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6

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