[issue15786] IDLE code completion window can hang or misbehave with mouse

[Terry J. Reedy]

Terry J. Reedy added the comment:

I experimented more with 3.5.1, Win 10 and formulated a question and hypothesis.

In a text widget, pressing button 1 (usually the left) moves the cursor to the 
nearest between-character slice line.  Hold the button down allows selecting 
text.  Releasing and pressing again selects a word after moving the cursor.  
Pretty standard behavior, independent of IDLE.  I believe the bindings are Text 
class rather than instance bindings.

When a completion box is present, button 1 down outside the box dismiss the box 
and moves the cursor.  I believe this is intended.  I don't know how general 
this behavior is.

The IDLE completion box binds the button *release* to, I believe, "move cursor 
to line clicked and display line in text".  A double click is supposed to do 
something more.  So the button1 press event goes to the Text, which dismisses 
the popup and moves the cursor.

Question: does the text widget freezes on button down or not until button up.  
The experiment is to press and hold the button while moving the mouse.  Does 
the cursor move and select text while the button is down, or does it freeze 
immediately.  Paul, could you try this?

Hypothesis (cause): a delicate timing issue? Is the button-up event somehow 
'half-caught'?

Hypothesis (fix): prevent the text from seeing or acting on the button down 
event.  It should be possible to have the completion box catch the down event 
first and return 'break'.  My first attempt failed but I was too tired to 
continue.

--

___
Python tracker 

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

[issue24550] maxint on 64 bit platforms breaks os.read

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

There is more specific issue for 32-bit reads in 2.7 (with patch): issue21199.

I think this issue can be closed as a duplicate of two other issues.

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

[issue21313] Py_GetVersion() is broken when using mqueue and a long patch name

[Martin Panter]

Martin Panter added the comment:

>>> Py_GetBuildInfo = pythonapi.Py_GetBuildInfo
>>> Py_GetBuildInfo.restype = c_char_p
>>> Py_GetBuildInfo()  # Not truncated
'qbase qtip subprocess-stderr_redirect_with_no_stdout_redirect-2.diff 
tip:0b641285389d+, May 13 2016, 02:10:26'

Demo of my problem with the test suite:

$ ./python -m test.regrtest
Traceback (most recent call last):
  [. . .]
  File "/media/disk/home/proj/python/cpython/Lib/test/test_support.py", line 
1423, in check_impl_detail
return guards.get(platform.python_implementation().lower(), default)
  File "/media/disk/home/proj/python/cpython/Lib/platform.py", line 1451, in 
python_implementation
return _sys_version()[0]
  File "/media/disk/home/proj/python/cpython/Lib/platform.py", line 1416, in 
_sys_version
repr(sys_version))
ValueError: failed to parse CPython sys.version: '2.7.11+ (qbase qtip 
subprocess-stderr_redirect_with_no_stdout_redirect-2.diff tip:0b64128) \n[GCC 
5.3.0]'

--

___
Python tracker 

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

[issue21313] Py_GetVersion() is broken when using mqueue and a long patch name

[Martin Panter]

Martin Panter added the comment:

Currently Py_GetBuildInfo() just returns a long untruncated string. Perhaps it 
would be safer to leave that as it is, and just make the parsing in the 
“platform” module more tolerant. What do you think?

I never really cared about the details in Py_GetBuildInfo(), but it would be 
nice if the test suite would run :)

--
keywords: +patch
nosy: +martin.panter
versions: +Python 3.6 -Python 3.4
Added file: http://bugs.python.org/file42836/parse-version.patch

___
Python tracker 

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

[issue26647] ceval: use Wordcode, 16-bit bytecode

[Demur Rumed]

Changes by Demur Rumed :


Added file: http://bugs.python.org/file42835/wpy8.patch

___
Python tracker 

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

[issue6422] timeit called from within Python should allow autoranging

[Nick Coghlan]

Nick Coghlan added the comment:

Good point - given that, +1 from me for the callback based version, especially 
since exception chaining will still disambiguate failures in the callback from 
other errors.

--

___
Python tracker 

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

[issue26826] Expose new copy_file_range() syscall in os module.

[Martin Panter]

Martin Panter added the comment:

Another option could be to use Serhiy’s proposed partial keywords support in 
Issue 26282. It is not yet committed, but it looks like it will go ahead, and 
then you could make “in” and “out” positional-only parameters, and the rest 
keywords. But IMO “src” and “dst” is fine.

Also, dropping “flags” support seems reasonable. One benefit is that if Linux 
added an unexpected flag in the future that conflicts with Python’s 
assumptions, it could do weird stuff or crash Python. See Issue 24933 for 
example, where socket.recv(n, MSG_TRUNC) returns uninitialized data.

The latest patch looks pretty good to me. Is there a consensus yet to add it as 
a public function? Before this goes in, it would be good to have a test case.

--

___
Python tracker 

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

[issue26993] Copy idlelib *.py files with new names

[Terry J. Reedy]

Terry J. Reedy added the comment:

Both Serhiy and Ned have expressed concern about the difficulty of merging 
patches from 3.5 to 3.6 once the 3.6 files are renamed.  To me, this is a 
non-issue since I don't expect to do that more than a few times, and some may 
be null merges of backports of fixes originally developed for and applied to 
3.6.  And I don't expect another core developer to start applying patches to 
3.5.

Hence my opinion that I should use hg rename, to keep continuity of revision 
history as much as possible, and that I should push a complete rename patch as 
soom as possible.

Two things that I *will* apply to 3.5, if and when possible, are fixing the 
third regression (Idle preferences not opening on Linux with tk 8.6, #26673) 
and fixing freezing of Macs when clicking on a completion window (#15786).

To me, this issue is a start on paying down IDLE's technical debt.

--

___
Python tracker 

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

[issue27003] Python 3.5.1 fails at HTTPSTest with SSL CERT error

[Martin Panter]

Changes by Martin Panter :


--
components: +Tests -Extension Modules

___
Python tracker 

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

[issue27003] Python 3.5.1 fails at HTTPSTest with SSL CERT error

[Martin Panter]

Martin Panter added the comment:

After 3.5.1 was released, there were some SSL certificate changes with a server 
(ab)used in the test suite. See Issue 25940. The result was that I changed some 
tests over to use the https://self-signed.pythontest.net/ server, and I had to 
enable the CA flag in its certificate 
(https://hg.python.org/pythontestdotnet/rev/1882edb402ab).

A workaround might be to grab the updated 
Lib/test/selfsigned_pythontestdotnet.pem file, and perhaps some of the other 
changes made in Issue 25940 if necessary.

--
nosy: +martin.panter
resolution:  -> out of date
status: open -> closed
superseder:  -> SSL tests failed due to expired svn.python.org SSL certificate

___
Python tracker 

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

[issue24550] maxint on 64 bit platforms breaks os.read

[Martin Panter]

Martin Panter added the comment:

Yes 3.5 should do 64-bit reads (if you have enough memory) thanks to revision 
0c57aba6b1a3 (Argument Clinic conversion):

>>> os.read(0, 2**32)
Traceback (most recent call last):
  File "", line 1, in 
MemoryError
>>> os.read(0, 2**63)
Traceback (most recent call last):
  File "", line 1, in 
OverflowError: Python int too large to convert to C ssize_t

I understand 3.4 is only open to security fixes, not changes like this. But 2.7 
is affected:

>>> os.read(0, 2**32)
Traceback (most recent call last):
  File "", line 1, in 
OverflowError: signed integer is greater than maximum

I guess this could be considered a bug in 2.7 (not an enhancement), but I’m not 
really sure.

--
nosy: +martin.panter
versions: +Python 2.7 -Python 3.4

___
Python tracker 

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

[issue26993] Copy idlelib *.py files with new names

[Terry J. Reedy]

Terry J. Reedy added the comment:

In response to Nick's point 4: To me, these are important aspects of 'in the 
stdlib'.

First is having issues on this tracker.  As Guido said in his King Day speech, 
non-trivial software is a collective project.  IDLE needs continued access to 
dependency experts, such as Serhiy for tkinter, and platform experts, such as 
Ned for Mac.  In April, I nosyed Kristján Valur Jónsson to ask an IDLE question 
that seemed related to a socket patch he pushed, and he helpfully answered.  On 
the other side, users are much more likely to participate here than on a 
separate tracker.

Second is being easily installable with the rest of Python.  I think some 
out-of-the-box augment to the console is crucial on Windows.

I am aware that Linux distributions have a separate tkinter-gui install instead 
of just a checkbox option.  I think it should consistently, on all plateforms, 
comprise _tkinter, tkinter, idlelib, turtle, and turtledemo.

All of those except idlelib are documented even though optional.  So I think 
idlelib could be also.  But documenting direct usage, which Nick recommended in 
#24225, could be relegated to the modules themselves and the idlelib README or 
a new text file.  Ditto for indicating replacements for thing known or strongly 
 suspected of external use.

--

___
Python tracker 

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

[issue26993] Copy idlelib *.py files with new names

[Terry J. Reedy]

Terry J. Reedy added the comment:

I should have explained my usage of 'idle2' and 'idle3'.  'Idle1' was the 
original IDLE that executed user code in the idle process.  'Idle2' was the 
re-write, still in use, that executes user code in a separate process.  'Idle3' 
is intended to be a re-write of similar scope that uses ttk, but also refactors 
to make automated tests and other changes easier.  (Adding multi-pane windows 
might be called 'idle4'.)  It is the tests and other changes that require 
refactoring.  Hence 'ttk-idle' partly misses the point unless understood as 
including name changes and refactoring.

For the idle2 re-writes, all the new code needed to execute remotely, by 
default, while keeping local execution as an option, had to be in place for any 
of it to be useful. The idle3 changes can be broken up into multiple usable and 
testable pieces.  I wish the renames could be in alpha1 and definitely want 
them in alpha2, along with a notice in What's New.  Anyone who has code that 
will break because of the changes should have opportunity to find out as soon 
as possible.  I would like to do simple ttk replacements by alpha 3.

--

___
Python tracker 

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

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

[Martin Panter]

Martin Panter added the comment:

Thanks for trying to move the directory in the new patch, but it does not seem 
to have been picked up by Rietveld. I have only seen patches generated with 
Mercurial and Git work, but I don’t exactly know _why_ they work :)

Here is a summary of what I would be comfortable adding to Python:

1. Add ctypes.RTLD_MEMBER constant (new API, so 3.6+ only)

2. Basic ctypes.util.find_library("crypto") implementation for AIX. But cases 
like find_library("libintl.so") should fail. I think your earlier patches were 
closer to this implementation than the later ones.

I am a bit hesitant about the automatic behaviour of 
CDLL("libcrypto.a(libcrypto.so.1.0.0)") using RTLD_MEMBER. IMO it may be better 
to let the caller specify RTLD_MEMBER explicitly. If a shared library file 
literally called “/usr/lib/libcrypto.a(libcrypto.so.1.0.0)” existed, i.e. not 
inside an archive, would dlopen("libcrypto.a(libcrypto.so.1.0.0)", RTLD_NOW) 
succeed? I admit this is an unlikely scenario, but it seems bad to reduce the 
domain of a low-level API.

I understand it would be good to have the return value of find_library() 
consistent with the name accepted by CDLL(). Perhaps a new parameter format 
would help, such as a tuple (archive, member).

I am not comfortable with other aspects. I think I would have to see more 
discussion with other people to change my opinion:

1. CDLL("libintl.so") should not load “libintl.a(libintl.so.1)”. I understand 
you want this to help code written for Gnu or Linux automatically work on AIX, 
but it doesn’t feel correct and robust to me. Perhaps moving this sort of thing 
to a separate function or package would be better.

2. find_library("libintl.so") -> "libintl.a(libintl.so.1)". I would expect it 
to look for a shared library installed in something like 
"/usr/lib/liblibintl.so.a", unless I have misunderstood how compile-time 
linking (cc -llibintl.so) works.

3. find_library() should not set the LIBPATH environment variable.

--

___
Python tracker 

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

[issue24254] Make class definition namespace ordered by default

[Eric Snow]

Eric Snow added the comment:

Here's a refresh of the patch that only sets the default definition namespace 
(and does not introduce __definition_order__).

--
Added file: http://bugs.python.org/file42834/just-default-to-odict.diff

___
Python tracker 

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

[issue24254] Make class definition namespace ordered by default

[Eric Snow]

Changes by Eric Snow :


Removed file: http://bugs.python.org/file39456/just-default-to-odict.diff

___
Python tracker 

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

[issue26999] Add child separator keyword to logging.basicConfig and use it in Logger.getChild()

[Vinay Sajip]

Vinay Sajip added the comment:

> However, if you still think that this is not, what the logging library is 
> meant for, I'd appreciate to know.

Confirmed. I would advise against using logger names in this way.

--

___
Python tracker 

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

[issue26359] CPython build options for out-of-the box performance

[Brett Cannon]

Brett Cannon added the comment:

The patch LGTM but I'm not a configure/make expert. Anyone else want to have a 
look?

Alecsandru, if no one takes a look within the next week then just assign the 
issue to me.

--

___
Python tracker 

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

[issue26970] Replace OpenSSL's CPRNG with system entropy source

[Christian Heimes]

Christian Heimes added the comment:

I have to replace _PyOS_URandom with a variant that doesn't need the GIL, 
https://mail.python.org/pipermail/cryptography-dev/2016-May/000595.html

--

___
Python tracker 

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

[issue26839] Python 3.5 running in a virtual machine with Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

[Colm Buckley]

Colm Buckley added the comment:

Oh; it's not actually hashlib which is calling getrandom(), it's the main 
runtime - the initialization of the per-process secret hash seed in 
_PyRandom_Init

Don't know enough about the internal logic here to comment on what the Right 
Thing is; but I second the suggestion of msg264303. This might just require 
setting "flags" to GRND_NONBLOCK in py_getrandom() assuming that's portable to 
other OS.

--

___
Python tracker 

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

[issue22970] asyncio: Cancelling wait() after notification leaves Condition in an inconsistent state

[Guido van Rossum]

Guido van Rossum added the comment:

Presumably. :-(

--

___
Python tracker 

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

[issue26632] __all__ decorator

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

Now with docs and tests.

--
Added file: http://bugs.python.org/file42833/26632-in-c-5.diff

___
Python tracker 

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

[issue26839] Python 3.5 running in a virtual machine with Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

[Colm Buckley]

Colm Buckley added the comment:

It's worth noting that this issue now affects every installation of Debian 
testing track with systemd and systemd-cron installed; the python program 
/lib/systemd/system-generators/systemd-crontab-generator is called very early 
in the boot process; it imports hashlib (although only .md5() is used) and 
blocks on getrandom(), delaying boot time until a 90s timeout has occurred.

Suggestions: modify hashlib to avoid calling getrandom() until entropy is 
actually required, rather than on import; change the logic to use /dev/urandom 
(or an in-process PRNG) when getrandom() blocks; or both.

--
nosy: +Colm Buckley

___
Python tracker 

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

[issue26556] Update expat to 2.2.1

[Christian Heimes]

Christian Heimes added the comment:

Another critical bug fix will be released next Tuesday.

--

___
Python tracker 

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

[issue26556] Update expat to 2.2.1

[Ned Deily]

Ned Deily added the comment:

Any progress on this?  It is still flagged as a Release Blocker and releases 
are approaching.

--

___
Python tracker 

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

[issue22970] asyncio: Cancelling wait() after notification leaves Condition in an inconsistent state

[Ned Deily]

Ned Deily added the comment:

Is this still a Release Blocker for 3.6?

--
nosy: +ned.deily

___
Python tracker 

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

[issue26556] Update expat to 2.2.1

[Ned Deily]

Changes by Ned Deily :


--
nosy: +ned.deily

___
Python tracker 

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

[issue27012] Rename the posix module to _os

[Brett Cannon]

Brett Cannon added the comment:

You're correct that it could break code checking the module's __name__ value if 
that was changed.

As for why I care, it sucks trying to import this module for any reason. Any 
place you touch this module you have to proper try/except ImportError checks to 
work around its multiple names. I just personally think it's a bit silly to 
have to do that.

Anyway, there's a reason why I marked this a low priority. :)

--

___
Python tracker 

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

[issue27012] Rename the posix module to _os

[R. David Murray]

R. David Murray added the comment:

I know you know this, but to be clear for other readers, the module naming 
happens at compile time, not runtime.

If you alias the module, it's __name__ will still be '_os', won't it?  Might 
that not have backward compatibility issues?  And if you also change that, then 
what's the point of not having it use an os specific name?

--
nosy: +r.david.murray

___
Python tracker 

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

[issue27012] Rename the posix module to _os

[Brett Cannon]

New submission from Brett Cannon:

It's always bugged me that the posix module changes its name based on what OS 
you're running under. I think it would be better to name the module _os as that 
it's consistent. We can alias the name to posix/nt for backwards compatibility 
(and even do this in importlib since it uses the module, so no worries of 
missing the aliasing). It also helps reinforce the note at the top of the posix 
module that it shouldn't be imported directly.

--
components: Library (Lib)
messages: 265421
nosy: brett.cannon
priority: low
severity: normal
status: open
title: Rename the posix module to _os
type: enhancement

___
Python tracker 

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

[issue27010] email library could "recover" from bad mime boundary like (some?) email clients do

[R. David Murray]

R. David Murray added the comment:

I'm going to change the title of this and see if anyone wants to propose a 
patch. It'll probably end up getting closed as not a bug if no one does for a 
while, though.

--
title: Attachments not detected from email library -> email library could 
"recover" from bad mime boundary like (some?) email clients do
versions: +Python 3.6 -Python 2.7

___
Python tracker 

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

[issue27011] Identation error

[Stepan]

Changes by Stepan :


--
files: ident.patch
keywords: patch
nosy: Ma3aXaKa
priority: normal
severity: normal
status: open
title: Identation error
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42832/ident.patch

___
Python tracker 

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

[issue6422] timeit called from within Python should allow autoranging

[Steven D'Aprano]

Steven D'Aprano added the comment:

On Thu, May 12, 2016 at 04:49:59AM +, Nick Coghlan wrote:
> The embedded side-effects were my main concern with Scott's original 
> patch, so Steven's callback-based approach strikes me as a definite 
> improvement. However, the awkwardness of the revised calling code in 
> main does make me wonder whether or not this might be better 
> implemented as a generator rather than as a function accepting a 
> callback:

I thought about a generator too, but then I thought about the *non* 
verbose case, where you don't care about the intermediate results, only 
the final (number, time_taken) pair.

# function with callback:
number, time_taken = t.autorange()

# generator
number, time_taken = list(t.autorange())[-1]

Which hints that your code snippet is buggy, or at least incomplete:

> try:
> results = list(t.autorange())
> except:
> t.print_exc()
> return 1
> if verbose:
> for number, time_taken in results:
> msg = "{} loops -> {:.{}g} secs"
> print(msg.format(number, time_taken, precision))

If verbose is False, you never set number and time_taken. So you need an 
else clause:

else:
number, time_taken = results[-1]

--

___
Python tracker 

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

[issue27010] Attachments not detected from email library

[Fedele Mantuano]

Fedele Mantuano added the comment:

Hi David,

I use email library to detect malicious attachments, so:

message = email.message_from_file(open('mail'))
for i in message.walk():
   do somethings

Not detected means that in for loop I can't see these attachments.

The same problem there is with tika parser (now I attached file).

I think that all automatics tools that using email library can't extract and 
post analyze these mails.

--
Added file: http://bugs.python.org/file42831/mail.json

___
Python tracker 

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

[issue19711] add test for changed portions after reloading a namespace package

[Mark Lawrence]

Changes by Mark Lawrence :


--
nosy:  -BreamoreBoy

___
Python tracker 

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

[issue27010] Attachments not detected from email library

[R. David Murray]

R. David Murray added the comment:

When you say the attachment is not detected, what do you mean?  What call are 
you making to the email library that you are expecting to see the attachment in 
that it is not in?  Your 'parsed' pastebin isn't something the library 
produces, so I assume that's the Tika output.

(By the way, pastbin links are problematic in tracker issues, since they may 
expire.  Please paste directly in to the issue, or attach files to the issue.)

Oh, wait.  Looking at the email I think I see the problem:





--51a14337d8625bb8ce4a5b1667f--

--51a14337d8625bb8ce4a5b1667f



That line that ends with '--' signals the end of the last MIME part in the 
message.  So by RFC standards the remainder of the message is part of the 
'epilogue'.  If you check msg.epilogue I think you'll find that it contains the 
raw text of the remainder of the message.

It is interesting that your email client treats it as an actual attachment.  It 
would be possible to have the email library recognize such out of place mime 
dividers and register it as an error.  I would review a patch for that if 
someone wants to propose one.

--David

--

___
Python tracker 

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

[issue27008] error message of ord is not intuitive

[R. David Murray]

R. David Murray added the comment:

All right, we'll close this then.

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

[issue22570] Better stdlib support for Path objects

[Guido van Rossum]

Guido van Rossum added the comment:

Reopening as we need to rename the path attribute to __fspath__ once Brett's 
PEP is accepted (which will be soon). 
https://github.com/brettcannon/path-pep/blob/master/pep-0NNN.rst

The 3.4 and 3.5 versions of this should probably just be reversed before their 
releases (early June).

--
resolution: fixed -> out of date
status: closed -> open

___
Python tracker 

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

[issue27010] Attachments not detected from email library

[Fedele Mantuano]

New submission from Fedele Mantuano:

We are receiving a lot of mail with attachments not detected from email library.
I also tested Tika parser and it have the same issue:

mail: http://pastebin.com/kSEJnzSa
mail parsed: http://pastebin.com/7HaVPcTq

I can read only these content types:
multipart/mixed
multipart/alternative
text/plain
text/html

there isn't Content-Type: application/zip.

With a normal mail client I can read the attachment.

Where is the issue?

--
components: email
files: mail
messages: 265413
nosy: Fedele Mantuano, barry, r.david.murray
priority: normal
severity: normal
status: open
title: Attachments not detected from email library
versions: Python 2.7
Added file: http://bugs.python.org/file42830/mail

___
Python tracker 

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

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

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
stage:  -> patch review

___
Python tracker 

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

[issue26415] Fragmentation of the heap memory in the Python parser

[A. Skrobov]

A. Skrobov added the comment:

Ping? This patch is two months old now.

--

___
Python tracker 

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

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

[A. Skrobov]

A. Skrobov added the comment:

Ping? This patch is two months old now.

--

___
Python tracker 

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

[issue19711] add test for changed portions after reloading a namespace package

[Eric Snow]

Changes by Eric Snow :


--
versions: +Python 3.6 -Python 3.5

___
Python tracker 

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

[issue25452] Add __bool__() method to subprocess.CompletedProcess

[Richard Neumann]

Richard Neumann added the comment:

Thank you for the hint.
I never before contributed code to the python foundation and thus am not 
familiar with the process.
I will look into it when I find the time.

--

___
Python tracker 

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

[issue27008] error message of ord is not intuitive

[Xiang Zhang]

Xiang Zhang added the comment:

I also notice the document. I get surprised when I see the implementation also 
supports bytes while the doc says one unicode character. But then I tell myself 
that maybe unicode character also includes bytes? I am not sure about the 
English description.

But giving your opinion that maybe the bytes supports are not intended now, I 
think leaving the error message untouched is quite OK. It describes what it is 
intended to do, same as the doc.

Really glad to have your comments, Serhiy and David.

--

___
Python tracker 

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

[issue18864] Implementation for PEP 451 (importlib.machinery.ModuleSpec)

[Eric Snow]

Eric Snow added the comment:

The last dependencies have now been closed!

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

[issue21099] Switch applicable importlib tests to use PEP 451 API

[Eric Snow]

Changes by Eric Snow :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.6 -Python 3.4, Python 3.5

___
Python tracker 

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

[issue26765] Factor out common bytes and bytearray implementation

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +haypo

___
Python tracker 

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

[issue21099] Switch applicable importlib tests to use PEP 451 API

[Roundup Robot]

Roundup Robot added the comment:

New changeset fceaa0dc715e by Eric Snow in branch 'default':
Issue #21099: Switch applicable importlib tests to use PEP 451 API.
https://hg.python.org/cpython/rev/fceaa0dc715e

--
nosy: +python-dev

___
Python tracker 

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

[issue25452] Add __bool__() method to subprocess.CompletedProcess

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

This is not enough. New feature should be documented (in new method docstring, 
in subprocess documentation and in What's New document) and tested.

And please sign a Contributor Licensing Agreement.

http://www.python.org/psf/contrib/contrib-form/
http://www.python.org/psf/contrib/

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue26826] Expose new copy_file_range() syscall in os module.

[Marcos Dione]

Marcos Dione added the comment:

I settled for s/in/src/ and s/out/dst/, fixed typos, made sure the docs are in 
sync (parameters in the docstring were out of order), rephrased paragraph about 
flags parameter and included the configure.ac code for detecting availability 
of the syscall. I'm also thinking of leaving flags out, what do you think?

--
Added file: http://bugs.python.org/file42829/copy_file_range.diff

___
Python tracker 

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

[issue25452] Add __bool__() method to subprocess.CompletedProcess

[Richard Neumann]

Richard Neumann added the comment:

Please excuse my ambiguous phrasing.
What I meant was I created the patch _from_ the Python 3.5.1 module _for_ 
Python 3.6.

--

___
Python tracker 

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

[issue24550] maxint on 64 bit platforms breaks os.read

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

The 32-bit size limit in multiprocessing is issue17560. AFAIK read() and 
write() now support 64-bit size on 64-bit systems.

--
nosy: +haypo, serhiy.storchaka

___
Python tracker 

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

[issue21199] Python on 64-bit Windows uses signed 32-bit type for read length

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Ping?

--

___
Python tracker 

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

[issue27008] error message of ord is not intuitive

[R. David Murray]

R. David Murray added the comment:

You are right, if it is too big a job to do it all at once, then we can fix 
them as we find them.  Do you want to propose a patch?

However, in this case I think there is arguably not a bug.  It looks as though 
the intent is that ord only support strings (see the documentation).  The fact 
that it supports bytes-like objects is redudant (ord(b'a') == b'a'[0]).  I'd 
call it a bug that it supports bytes-like objects, but we probably kept (and 
should keep it) it to make it easier to port python2 code to python3.

So, if any change were to be made here, it would probably be to change the 
error message if and only if the input is not in fact a string, and perhaps 
even recommend using the indexing syntax.

On the gripping hand, I've never been a fan of the fact that indexing a byte 
string gets you an integer :)

--

___
Python tracker 

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

[issue27009] multiprocessing Connection data length limited to max(int32)

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

This is a duplicate of issue17560.

--
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> problem using multiprocessing with really big objects?

___
Python tracker 

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

[issue26369] unicode.decode and str.encode are unnecessarily confusing for non-ascii

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

If str.encode() raises a decoding exception, this is a programming bug. It 
would be bad to hide it.

FYI, the default encoding is not hardcoded 'ascii'. Google "Changing default 
encoding in Python". Maybe this will help in your program.

--

___
Python tracker 

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

[issue20371] datetime.datetime.replace bypasses a subclass's __new__

[R. David Murray]

R. David Murray added the comment:

To summarize, it looks like there are three issues here: (1) the python and C 
versions are out of sync behavior wise (the python should work like the C in 
this case, it seems) (2) there are some missing tests, since we are running the 
same tests against both code bases and not getting any errors and (3) replace 
is doing its copy in a way that does not actually supporting subclassing (which 
again speaks to missing tests).

--

___
Python tracker 

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

[issue20371] datetime.datetime.replace bypasses a subclass's __new__

[R. David Murray]

Changes by R. David Murray :


--
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4

___
Python tracker 

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

[issue27009] multiprocessing Connection data length limited to max(int32)

[Hartmann]

Changes by Hartmann :


--
versions: +Python 3.5 -Python 3.6

___
Python tracker 

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

[issue23640] int.from_bytes() is broken for subclasses

[R. David Murray]

R. David Murray added the comment:

@eltoder: Ah, you are right, I was looking at the python version.  There's an 
open issue about this, #20371, which indicates that the design decision was to 
support subclasses.  Clearly I was remembering the conversation backward based 
on looking at the wrong code :)

--

___
Python tracker 

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

[issue23640] int.from_bytes() is broken for subclasses

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy:  -pitrou

___
Python tracker 

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

[issue27009] multiprocessing Connection data length limited to max(int32)

[Hartmann]

New submission from Hartmann:

I wonder if size restriction for the data blobs send via 
multiprocessing.Connection is intentionally. Otherwise it would be nice to get 
rid of that restriction.

File "python3.5/multiprocessing/connection.py", line 393, in _send_bytes
header = struct.pack("!i", n)

--
messages: 265396
nosy: cimatosa
priority: normal
severity: normal
status: open
title: multiprocessing Connection data length limited to max(int32)
type: behavior
versions: Python 3.6

___
Python tracker 

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

[issue26369] unicode.decode and str.encode are unnecessarily confusing for non-ascii

[Ben Spiller]

Ben Spiller added the comment:

I'm proposing that str.encode() should _not_ throw a 'decode' exception  for 
non-ascii characters and be effectively a no-op, to match what it already does 
for ascii characters - which therefore shouldn't break behavior anyone will be 
depending on. This could be achieved by passing the encoding parameter through 
to the implicit decode() call (which is where the exception is coming from it 
appears), rather than (arbitrarily and surprisingly) using "ascii" (which of 
course sometimes works and sometimes doesn't depending on the input string)

Does that make sense?

If someone can find the place in the code (sorry I tried and failed!) where 
str.encode('utf-8') is resulting in an implicit call to the equivalent of 
decode('ascii') (as suggested by the exception message) I think it'll be easier 
to discuss the details

--

___
Python tracker 

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

[issue26369] unicode.decode and str.encode are unnecessarily confusing for non-ascii

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

What do you propose? Note that str.encode() doesn't raise an exception. Ascii 
unicode and 8-bit strings are interchangeable. Ascii unicode strings can be 
packed in str for less memory consumption (see xmlrpclib or ElementTree), a lot 
of str constant are used in unicode context (like os.sep or empty string). 
Breaking str.encode() will break valid existing code.

--

___
Python tracker 

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

[issue25452] Add __bool__() method to subprocess.CompletedProcess

[STINNER Victor]

STINNER Victor added the comment:

It's a new feature, it should only go to Python 3.6.

--

___
Python tracker 

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

[issue26369] unicode.decode and str.encode are unnecessarily confusing for non-ascii

[Ben Spiller]

Ben Spiller added the comment:

yes the situation is loads better in python 3, this issue is specific to 2.x, 
but like many people sadly we're not able to move to 3 for the time being. 

Since making this mistake is quite common and there's some sensible behaviour 
that would make it disappear (resulting in ascii and non-ascii strings being 
treated the same way by these methods) I'd much prefer if we could actually fix 
it for python 2.7

--

___
Python tracker 

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

[issue25452] Add __bool__() method to subprocess.CompletedProcess

[Richard Neumann]

Richard Neumann added the comment:

I took the liberty to create a patch for Python v3.5.1.

--
keywords: +patch
nosy: +Richard Neumann
Added file: http://bugs.python.org/file42828/subprocess.patch

___
Python tracker 

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

[issue26999] Add child separator keyword to logging.basicConfig and use it in Logger.getChild()

[Richard Neumann]

Changes by Richard Neumann :


Added file: http://bugs.python.org/file42827/logger.patch

___
Python tracker 

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

[issue26369] unicode.decode and str.encode are unnecessarily confusing for non-ascii

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Note that with the -3 option Python 2.7 already warns about incompatibilities. 

>>> 'abc'.encode('base64')
__main__:1: DeprecationWarning: 'base64' is not a text encoding; use 
codecs.encode() to handle arbitrary codecs
'YWJj\n'
>>> 'YWJj\n'.decode('base64')
__main__:1: DeprecationWarning: 'base64' is not a text encoding; use 
codecs.decode() to handle arbitrary codecs
'abc'
>>> u'abc'.decode('ascii')
__main__:1: DeprecationWarning: decoding Unicode is not supported in 3.x
u'abc'

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue26369] unicode.decode and str.encode are unnecessarily confusing for non-ascii

[Ben Spiller]

Ben Spiller added the comment:

Thanks that's really helpful

Having thought about it some more, I think if possible it'd be really so much 
better to actually 'fix' the behaviour for the unicode<->str standard codecs 
(i.e. not base64) rather than just documenting around it. The current behaviour 
is not only confusing but leads to bugs that are very easy to miss since the 
methods work correctly when given 7-bit ascii characters. 

I had a poke around in the python source but couldn't quite identify where it's 
happening - presumably there is somewhere in the str.encode('utf-8') 
implementation that first "decodes" the string and does so using the ascii 
codec. If it could be made to use the same encoding that was passed in (e.g. 
utf8) then this would end up being a no-op and there would be no unpleasant 
bugs that only appear when the input includes non-ascii characters. 

It would also allow X.encode('utf-8') to be called successfully whether X is 
already a str or is a unicode object, which would save callers having to 
explicitly check what kind of string they've been passed. 

Is anyone able to look into the code to see where this would need to be fixed 
and how difficult it would be to do? I have a feeling that once the line is 
located it might be quite a straightforward fix

Many thanks

--
components: +Interpreter Core -Documentation
title: doc for unicode.decode and str.encode is unnecessarily confusing -> 
unicode.decode and str.encode are unnecessarily confusing for non-ascii

___
Python tracker 

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

[issue26039] More flexibility in zipfile write interface

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Thank you for your contribution Thomas. I'll push the patch with fixed writestr 
in short time unless Martin left comments.

--
stage: patch review -> commit review

___
Python tracker 

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

[issue27007] Alternate constructors bytes.fromhex() and bytearray.fromhex() return an instance of base type

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Here is a patch.

--
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file42826/bytes_fromhex.patch

___
Python tracker 

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

[issue26039] More flexibility in zipfile write interface

[Thomas Kluyver]

Thomas Kluyver added the comment:

Thanks Serhiy. I'm quite happy with that set of constraints. I had a look over 
your patch set, and just spotted one thing in writestr that I have overlooked 
all along.

--

___
Python tracker 

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

[issue26999] Add child separator keyword to logging.basicConfig and use it in Logger.getChild()

[Richard Neumann]

Changes by Richard Neumann :


Removed file: http://bugs.python.org/file42825/logger.patch

___
Python tracker 

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

[issue26999] Add child separator keyword to logging.basicConfig and use it in Logger.getChild()

[Richard Neumann]

Richard Neumann added the comment:

Added proposed patch

--
keywords: +patch
Added file: http://bugs.python.org/file42825/logger.patch

___
Python tracker 

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

[issue27008] error message of ord is not intuitive

[Xiang Zhang]

Xiang Zhang added the comment:

Ohh, you have tried to do that. It must be a large work.

But on the other hand, if this is a too large work, why not solve this case by 
case? This work is too large to get someone work on it, even you, the most 
active developer in the community I see have abandoned. And then maybe 
improving the situation a little bit every time is the only solution.

> This is not wrong if we consider strings of size 1 as separate type

This sounds weird. But I can understand the importance of compatibility.

--

___
Python tracker 

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

[issue26999] Add child separator keyword to logging.basicConfig and use it in Logger.getChild()

[Richard Neumann]

Richard Neumann added the comment:

PS: @vinay.sajip

You do realize that I want this argument to be optional and to retain '.' as 
default setting in order to keep the current behaviour?!

--

___
Python tracker 

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

[issue27008] error message of ord is not intuitive

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

In any case it doesn't make much sense to change just one separate docstring. 
If you want to avoid misleading and support consistent wording, you should 
examine all occurrences of the word "string" in the documentation, docstrings, 
error messages and comments -- does it mean Unicode string, bytes-like object 
that supports the buffer protocol (including memoryview), bytes-like object 
that supports str-like interface (including bytes, bytearray, but excluding 
memoryview), either Unicode or bytes string? I tried to do this but abandoned 
the work on half-way. This is too large work.

> BTW, what do you think about the second TypeError in ``ord``. Shouldn't it be 
> ValueError?

It could be ValueError. But for compatibility it should stay TypeError. This is 
not wrong if we consider strings of size 1 as separate type.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue26999] Add child separator keyword to logging.basicConfig and use it in Logger.getChild()

[Richard Neumann]

Richard Neumann added the comment:

I am using loggers and sub-loggers (getChild()) in classes, which contain 
sub-classes, wich contain sub-sub-classes and so on for complex data processing.
Hence I was using the logging library with sub-loggers to see in which of the 
(sub-)classes things happen.
Most classes are, however, instanced for different configuration and are 
represented by strings like {instance_config}@{class_name} where 
{instance_config} often contains dots as separators for IDs.
Example:

INFO1000@TerminalsSyncer:   Aggregating customer data: 
1031002@Facebook
INFO1000@TerminalsSyncer:   Aggregating virtual data: 
v60.1031002@Config
INFO1000@TerminalsSyncer:   Aggregating virtual data: 
v60.1031002@Presentation
WARNING 1000@TerminalsSyncer->1.1000@TerminalSyncer:Terminal 1.1000 is 
offline


However, if you still think that this is not, what the logging library is meant 
for, I'd appreciate to know.

--

___
Python tracker 

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

[issue27008] error message of ord is not intuitive

[Xiang Zhang]

Xiang Zhang added the comment:

BTW, what do you think about the second TypeError in ``ord``. Shouldn't it be 
ValueError?

--

___
Python tracker 

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

[issue26999] Add child separator keyword to logging.basicConfig and use it in Logger.getChild()

[Vinay Sajip]

Vinay Sajip added the comment:

This is a change with wide-ranging ramifications. I don't propose to do this, 
as the use of '.' as a logging separator mirrors the separator used in the 
Python package namespace.

Logger names are supposed to indicate the "where" of a logging event - nothing 
more.

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

___
Python tracker 

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

[issue27008] error message of ord is not intuitive

[Xiang Zhang]

Xiang Zhang added the comment:

If you think it's OK, it's fine. Please close this thread.

--

___
Python tracker 

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

[issue27008] error message of ord is not intuitive

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

This not the only place where "string" means unicode string or bytes string. I 
don't think this is large issue.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue27008] error message of ord is not intuitive

[Xiang Zhang]

New submission from Xiang Zhang:

The error message of ``ord`` is not that right. It says 'ord() expected string 
of length 1'. I don't think in Py3.x string can refer to both bytes and 
unicodes.

--
messages: 265376
nosy: xiang.zhang
priority: normal
severity: normal
status: open
title: error message of ord is not intuitive
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

[issue27007] Alternate constructors bytes.fromhex() and bytearray.fromhex() return an instance of base type

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

According to the discussion on Python-Dev [1] alternate constructors should 
return an instance of the subclass (else why invoke it through the subclass). 
bytes.fromhex() and bytearray.fromhex() are the only exceptions.

I think bytes.fromhex() and bytearray.fromhex() should be changed to match the 
behavior of all other alternate constructors.

[1] http://comments.gmane.org/gmane.comp.python.devel/157649

--
components: Interpreter Core
messages: 265375
nosy: georg.brandl, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Alternate constructors bytes.fromhex() and bytearray.fromhex() return an 
instance of base type
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

[issue27005] Faster float.fromhex()

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

A mistake in using PyObject_CallFunctionObjArgs() caused a crash in using 
fromhex() for subclasses. New tests added in issue23640 covers this case.

--

___
Python tracker 

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

[issue23640] int.from_bytes() is broken for subclasses

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Discussion on Python-Dev: 
http://comments.gmane.org/gmane.comp.python.devel/157649 .

The conclusion is that alternate constructors should return an instance of the 
subclass, and either call constructor or use pickling machinery for creating an 
object in correct state.

Pushed the fix for int.from_bytes() and tests. I'll open separate issues for 
other alternate constructors (for example issue27006 -- for 
Decimal.from_float()).

Yes, there is similar bug in date.replace(). C implementation doesn't match 
Python implementation and bypasses the constructor. Please open separate issue 
for this Eugene.

--
assignee:  -> serhiy.storchaka
components: +Interpreter Core -Library (Lib)
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed
versions: +Python 3.6 -Python 3.4

___
Python tracker 

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

[issue23640] int.from_bytes() is broken for subclasses

[Roundup Robot]

Roundup Robot added the comment:

New changeset 0af15b8ef3b2 by Serhiy Storchaka in branch '3.5':
Issue #23640: int.from_bytes() no longer bypasses constructors for subclasses.
https://hg.python.org/cpython/rev/0af15b8ef3b2

New changeset df14ea17a517 by Serhiy Storchaka in branch 'default':
Issue #23640: int.from_bytes() no longer bypasses constructors for subclasses.
https://hg.python.org/cpython/rev/df14ea17a517

--
nosy: +python-dev

___
Python tracker 

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

[issue27005] Faster float.fromhex()

[Roundup Robot]

Roundup Robot added the comment:

New changeset 1bae2a6bb37c by Serhiy Storchaka in branch 'default':
Issue #27005: Fixed the call of PyObject_CallFunctionObjArgs().
https://hg.python.org/cpython/rev/1bae2a6bb37c

--

___
Python tracker 

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

[issue27005] Faster float.fromhex()

[Roundup Robot]

Roundup Robot added the comment:

New changeset 3b19660611a4 by Serhiy Storchaka in branch 'default':
Issue #27005: Optimized the float.fromhex() class method for exact float.
https://hg.python.org/cpython/rev/3b19660611a4

--
nosy: +python-dev

___
Python tracker 

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

[issue27005] Faster float.fromhex()

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Thank you Mark.

--
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> 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

[issue27006] C implementation of Decimal.from_float() bypasses __new__ and __init__

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

Python implementation of Decimal.from_float() calls __new__ and __init__ 
methods of subclass.

>>> from _pydecimal import Decimal
>>> class D(Decimal):
... def __new__(cls, *args, **kwargs):
... print('__new__')
... return Decimal.__new__(cls, *args, **kwargs)
... def __init__(self, *args, **kwargs):
... print('__init__')
... 
>>> print(type(D.from_float(42)))
__new__
__init__

>>> print(type(D.from_float(42.0)))
__new__
__init__


But C implementation doesn't.

>>> from decimal import Decimal
>>> class D(Decimal):
... def __new__(cls, *args, **kwargs):
... print('__new__')
... return Decimal.__new__(cls, *args, **kwargs)
... def __init__(self, *args, **kwargs):
... print('__init__')
... 
>>> print(type(D.from_float(42)))

>>> print(type(D.from_float(42.0)))


This means that resulting instance of Decimal subclass can be in not valid 
state.

Example is Decimal enums (see also issue23640).

>>> from decimal import Decimal
>>> from enum import Enum
>>> class D(Decimal, Enum):
... A = Decimal('3.25')
... 
>>> D(Decimal(3.25))

>>> D(3.25)

>>> D.from_float(3.25)
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/serhiy/py/cpython/Lib/enum.py", line 486, in __repr__
self.__class__.__name__, self._name_, self._value_)
AttributeError: 'D' object has no attribute '_name_'

A solution is to reproduce Python implementation in C code:

result = ... # create exact Decimal
if cls is not Decimal:
result = cls(result)
return result

--
components: Extension Modules
messages: 265368
nosy: facundobatista, mark.dickinson, rhettinger, serhiy.storchaka, skrah
priority: normal
severity: normal
status: open
title: C implementation of Decimal.from_float() bypasses __new__ and __init__
type: behavior
versions: Python 3.5, Python 3.6

___
Python tracker 

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

[issue27005] Faster float.fromhex()

[Mark Dickinson]

Mark Dickinson added the comment:

LGTM

--

___
Python tracker 

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

[issue27005] Faster float.fromhex()

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

Proposed patch makes float.fromhex() faster for exact float.

$ ./python -m timeit -s "h = float.hex(1.23)" -- "float.fromhex(h)"

Unpatched: 100 loops, best of 3: 0.886 usec per loop
Patched:   100 loops, best of 3: 0.519 usec per loop

--
components: Interpreter Core
files: float_fromhex.patch
keywords: patch
messages: 265366
nosy: mark.dickinson, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Faster float.fromhex()
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file42824/float_fromhex.patch

___
Python tracker 

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

[issue26993] Copy idlelib *.py files with new names

[Nick Coghlan]

Nick Coghlan added the comment:

+1 for Ned's point that PEP 434 grants the IDLE developers *permission* to 
backport IDLE enhancements to maintenance releases, but doesn't *oblige* them 
to provide such backports.

For Python 3.6, another point to keep in mind is that if anyone particularly 
wants to keep the old idlelib API alive, they can either fork the existing code 
as a PyPI project, or create a compatibility shim that runs atop the new 
ttk-based API.

--

___
Python tracker 

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

[issue26807] mock_open()().readline() fails at EOF

[Robert Collins]

Robert Collins added the comment:

So something like

  for line in _state[0]:
  yield line
  while True:
yield ''

Will probably do it just fine.

--

___
Python tracker 

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