[issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons

[Mark Hammond]

Mark Hammond added the comment:

> Mark said the "built binary links against the DLL version of the CRT
> but I just checked in 3.5.1 that you actually didn't switch that
> one to link against vcruntime140.dll like you did with everything else

Yeah, I didn't dig too much further here, but I'm fairly sure that "static crt" 
has been a thing for quite a while now for that stub (there are comments about 
that around the SetStdHandle calls in that file). I suspect it was accidentally 
lost in one of the build system fixups that happened (which seem great and a 
vast improvement!)

--

___
Python tracker 

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

[issue25986] Collections.deque maxlen: added in 2.6 or 2.7?

[Elena Oat]

Elena Oat added the comment:

I checked and 2.6 python has maxlen as a parameter, but not a maxlen attribute. 
The maxlen attribute was added in 2.7.

--
nosy: +Elena.Oat

___
Python tracker 

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

[issue25986] Collections.deque maxlen: added in 2.6 or 2.7?

[Ezio Melotti]

Ezio Melotti added the comment:

Thanks for checking.  Closing.

--
nosy: +ezio.melotti
resolution:  -> not a bug
stage: needs patch -> 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

[issue26070] Launcher fails to find in-place built binaries from earlier Python versions

[Vinay Sajip]

Vinay Sajip added the comment:

Hey, Steve, don't shut me out, I'm still here ;-)

I've had a heavy consulting load for the past year or so which means I can't 
always deal with issues as quickly as before. If someone else fixes issues 
before I get to them, it's fine by me :-)

IMO the proposed change by Mark seems reasonable. It's really only for us devs 
anyway.

--

___
Python tracker 

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

[issue26074] Add a method to pip.. pip.require("package_name")

[Blaize Rhodes]

New submission from Blaize Rhodes:

The idea is to add a method to pip that tries to import a package and if the 
import fails then try to download and install the package handling the UI.

Yes, you can put the package as a dependency in your pip config for 
your code.  This is intended for the case when you have a bunch of 
python tools/libs in some shared repository in your organization.
People check the code out and expect it to run but it has third party 
dependencies.  There is no install step for your code, per se.  Furthermore the 
people using your code don't know enough about python to install things 
themselves.

Proposed syntax is:

import pip
pip.require("foo")

If you search online for pip.main you'll see a whole bunch of hall-baked 
brittle solutions to this problem that look like this:

try:
import foo
except ImportError:
 pip.main("install", "foo")

--
files: require.py
messages: 257903
nosy: Blaize Rhodes
priority: normal
severity: normal
status: open
title: Add a method to pip.. pip.require("package_name")
type: enhancement
Added file: http://bugs.python.org/file41565/require.py

___
Python tracker 

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

[issue26074] Add a method to pip.. pip.require("package_name")

[Blaize Rhodes]

Blaize Rhodes added the comment:

I'm more than happy to fill in the contributor agreement.. but it seems like a 
hassle if, what I'm assuming will happen, someone points out a good reason why 
this hasn't been done already.

--

___
Python tracker 

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

[issue21047] html.parser.HTMLParser: convert_charrefs should become True by default

[lilydjwg]

lilydjwg added the comment:

FYI, this breaks one of my programs. I find it now because it only threw errors 
in rare cases, and I've never seen the deprecated warning because I don't check 
the logs unless something goes wrong.

--
nosy: +lilydjwg

___
Python tracker 

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

[issue25517] regex howto example in "Lookahead Assertions"

[Elena Oat]

Elena Oat added the comment:

Corrected the regular expression and documented why [^.]* is used.

--
keywords: +patch
nosy: +Elena.Oat
Added file: http://bugs.python.org/file41566/issue25517.diff

___
Python tracker 

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

[issue26074] Add a method to pip.. pip.require("package_name")

[Stéphane Wirtel]

Stéphane Wirtel added the comment:

But in fact, Pip is an external project to CPython.

Could you explain why you post this issue in the CPython Bug Tracker?

Thank you

--
nosy: +matrixise

___
Python tracker 

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

[issue25967] Devguide: add 2to3 to the "Changing CPython's Grammar" checklist

[Chris Thomas]

Chris Thomas added the comment:

Added a note to the check list as needed.

--
keywords: +patch
nosy: +Aegil
Added file: http://bugs.python.org/file41567/issue25967.patch

___
Python tracker 

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

[issue19316] devguide: compiler - wording

[Elena Oat]

Elena Oat added the comment:

Here's the patch regenerated for the latest devguide.

--
nosy: +Elena.Oat
Added file: http://bugs.python.org/file41568/issue19316.diff

___
Python tracker 

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

[issue26075] typing.Union unifies types too broadly

[Alex Grönholm]

New submission from Alex Grönholm:

>>> from typing import Union, Iterable
>>> Union[str, Iterable[int]]
typing.Iterable[int]

The union loses the "str" parameter because issubclass(str, 
collections.abc.Iterable) returns True and the check completely disregards 
generics.

Guido mentioned that issubclass() support for generic types should be going 
away. In the mean time, maybe the subclass check in typing.GenericMeta should 
be modified not to do it with types from Typing, but how can we accurately 
identify them?

--
components: Extension Modules
messages: 257910
nosy: alex.gronholm, gvanrossum, lukasz.langa
priority: normal
severity: normal
status: open
title: typing.Union unifies types too broadly
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

[issue26075] typing.Union unifies types too broadly

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +ezio.melotti
stage:  -> test needed

___
Python tracker 

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

[issue19251] bitwise ops for bytes of equal length

[cowlicks]

cowlicks added the comment:

I've attached a diff that adds ^, |, and & to bytes and bytearray object on the 
master branch (err the analogous hg thing).

It also includes a test file which definitely is in the wrong place, but 
demonstrates what is working.

Personally this came up while I was playing with toy crypto problems. I 
expected to already be part of the language, but it wasn't. I think this is a 
natural expectation. I don't think it is obvious to newer python users that 
they need to cast bytes to ints to do bitwise operations on them.

And I do not understand how bitwise operations work on arbitrary precision 
integers. So perhaps it is not as simple of a concept as "bytes xor bytes".

Some folks have suggested using NumPy, but that is a very heavy dependency, and 
not useful outside of cpython.

I searched for code this would clean up in the wild. It was easy to find.

This would also catch bugs when bytes objects are different lengths, but there 
is no check. Like this code I found 

# XOR each byte of the roundKey with the state table
def addRoundKey(state, roundKey):
for i in range(len(state)):
state[i] = state[i] ^ roundKey[i]

p.s. this is my first cpython issue/patch please let me know if I'm doing 
something wrong.

--
keywords: +patch
nosy: +cowlicks
Added file: http://bugs.python.org/file41569/bitwise_bytes.diff

___
Python tracker 

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

[issue25596] regular files handled as directories in the glob module

[Xavier de Gaye]

Changes by Xavier de Gaye :


Added file: http://bugs.python.org/file41571/glob_scandir_3.patch

___
Python tracker 

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

[issue25596] regular files handled as directories in the glob module

[Xavier de Gaye]

Xavier de Gaye added the comment:

FWIW I have followed the idea of having _iterdir() yielding the DirEntry entry 
instead of the name in Serhiy's patch.  There is a slight performance gain. Now 
_glob0() and _glob1() do return a list of directories when dironly is true but 
there is now another place where OSError must be tracked, so it is not clear if 
this is worth it.

glob_scandir_2_diff.patch is the differential patch between 
glob_scandir_2.patch and glob_scandir_3.patch.

Here are the performance tests run with both patches.

$ ./python -m timeit -s "from glob import glob" -- "glob('**/*', 
recursive=True)"
glob_scandir_2.patch: 33.1 msec per loop
glob_scandir_3.patch: 33.8 msec per loop

$ ./python -m timeit -s "from glob import glob" -- "glob('/usr/lib*/**/*', 
recursive=True)"
glob_scandir_2.patch: 927 msec per loop
glob_scandir_3.patch: 850 msec per loop

$ ./python -m timeit -s "from glob import glob" -- "glob('/usr/lib*/**/', 
recursive=True)"
glob_scandir_2.patch: 423 msec per loop
glob_scandir_3.patch: 337 msec per loop

--
Added file: http://bugs.python.org/file41570/glob_scandir_2_diff.patch

___
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

[Ram Rachum]

Ram Rachum added the comment:

Here's an alternate idea I thought of now. Maybe `path.path` should be a 
pointer to the same `Path` object, so every function will do this: 

str(arg.path) if hasattr(arg, 'path') else arg

What I like about this is that it avoids having the path argument be a string. 
I don't like misnomers :)

I'd understand though if people won't like this suggestion since it introduces 
another step, of turning the path back into a string.

--

___
Python tracker 

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

[issue19251] bitwise ops for bytes of equal length

[Andrew Barnert]

Andrew Barnert added the comment:

On Jan 10, 2016, at 06:48, cowlicks  wrote:
> 
> 
> Personally this came up while I was playing with toy crypto problems. I 
> expected to already be part of the language, but it wasn't. I think this is a 
> natural expectation.

Maybe if you're coming to Python from APL or R or something, but C, C#, Scala, 
Ruby, Haskell--almost any other language you pick, there's no bitwise 
operations on (byte) strings. (And if you _are_ coming to Python from something 
like R, you definitely should be using NumPy.)
> 
> And I do not understand how bitwise operations work on arbitrary precision 
> integers.

It's obvious once you think of them as infinite-sized fixed-size ints: 0x27 is 
the same number as 0x0027, so 0x27 & 0x0134 is 0x0024. (Of course not and 
negation aren't quite as obvious, but once you think about it, there's only one 
sensible thing 2's complement could do, and only two sensible things 1's 
complement could do, and Python is sensible, so it's not surprising once you 
try it out.)

> Some folks have suggested using NumPy, but that is a very heavy dependency, 
> and not useful outside of cpython.

It's useful outside of CPython. While NumPyPy isn't 100% yet, it's usable 
enough for many projects.

More to the point, if you're looking for arrays that have really fast and 
highly readable elementwise operations, that's exactly what NumPy is all about. 
Sure, you can get bits and pieces of similar functionality without it, but if 
you're thinking about your code in NumPy's terms (elementwise operations), you 
really do want to think about NumPy.

Meanwhile, have you looked around PyPI at the various bitarray, bitstring, etc. 
libraries? Are they too slow, too heavyweight, or too inconveniently-API'd? I 
know whenever I want to play with things like Huffman coding or the underlying 
bit representation of IEEE floats or anything else bitwise besides basic C 
integer stuff, I reach for one of those libraries, rather than trying to hack 
things up around bytes strings. (Except for that example I posted 
above--clearly for some reason I _did_ hack things up around bytes strings that 
time--but it only took me that simple class to make things convenient and 
efficient.)

--

___
Python tracker 

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

[issue13963] dev guide has no mention of mechanics of patch review

[Ezio Melotti]

Ezio Melotti added the comment:

Since we are moving away from rietveld, I'm going to close this as out of date.

--
resolution:  -> out of date
stage: needs patch -> 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

[issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons

[Steve Dower]

Steve Dower added the comment:

Ultimately, launching python.exe is better than loading python##.dll here 
because it avoids DLL planting vulnerabilities, but I'm honestly a little 
surprised still that LoadLibrary won't resolve vcruntime in this case. Been a 
while since I looked, and I haven't had a chance to check for this yet, but why 
isn't the directory containing the loaded DLL searched for dependencies?

--

___
Python tracker 

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

[issue26070] Launcher fails to find in-place built binaries from earlier Python versions

[Steve Dower]

Steve Dower added the comment:

> I've had a heavy consulting load for the past year or so which means I can't 
> always deal with issues as quickly as before.

That explains it :) With so little visibility into what we're doing outside of 
Python it's hard to know. Glad you're still about.

--

___
Python tracker 

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

[issue26030] Use PEP8 in documentation examples

[Ezio Melotti]

Ezio Melotti added the comment:

> I'll slowly review what I see, and provide little patches from
> time to time, only when the PEP8 infringement look obvious.

Sounds good to me.  If you are not sure you can ask on IRC (#python-dev on 
freenode) or the core-mentorship mailing list.

--

___
Python tracker 

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

[issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons

[Eryk Sun]

Eryk Sun added the comment:

> why isn't the directory containing the loaded DLL searched 
> for dependencies?

That's possible. The loader provides several ways to go about solving this 
problem. The directory of the DLL can be added to the search path if you use 
LoadLibraryEx with the flag LOAD_WITH_ALTERED_SEARCH_PATH and use an absolute 
path. Python already does this for loading extension modules. 

If we didn't have to worry about older systems, in Windows 8/10 (and Vista/7 
with KB2533623), the loader supports a set of flags that give detailed control 
of the DLL path, including LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR. Individual 
directories can be added via AddDllDirectory and enabled via the flag 
LOAD_LIBRARY_SEARCH_USER_DIRS. Default flags can be set via 
SetDefaultDllDirectories, which affects LoadLibrary as well as LoadLibraryEx. 

On a related note, it would be nice to modify ctypes to call LoadLibraryEx 
instead of LoadLibrary. If the flags value is 0 the two calls are identical, so 
it wouldn't be a disruptive change. The existing dlopen "mode" parameter can be 
used for the flags, since it isn't used on Windows currently.

--

___
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

[Brett Cannon]

Brett Cannon added the comment:

I appreciate the thought, Ram, but I'm not a fan.

--

___
Python tracker 

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

[issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons

[Steve Dower]

Steve Dower added the comment:

> The directory of the DLL can be added to the search path if you use 
> LoadLibraryEx with the flag LOAD_WITH_ALTERED_SEARCH_PATH and use an absolute 
> path. 

That sounds like the better fix then. I thought there was something along those 
lines available.

We already use the full path to load it - can someone test this change? If not 
I'll give it a go later today.

--

___
Python tracker 

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

[issue26074] Add a method to pip.. pip.require("package_name")

[Berker Peksag]

Berker Peksag added the comment:

Thanks for the report, but this should be discussed either at 
https://groups.google.com/forum/#!forum/pypa-dev or 
https://github.com/pypa/pip/issues

--
nosy: +berker.peksag
resolution:  -> third party
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue22570] Better stdlib support for Path objects

[Guido van Rossum]

Guido van Rossum added the comment:

Using 'path' for this field is not a misnomer (example: DictEntry uses 'path' 
for the same field).

See issue #26027 for a follow-up idea.

--
dependencies:  -Support Path objects in the posix module
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue26075] typing.Union unifies types too broadly

[Guido van Rossum]

Guido van Rossum added the comment:

Oh, this is yet another reason to finally rip out the issubclass() support...  
We're tracking that at https://github.com/ambv/typehinting/issues/136

In the meantime, just don't do this!

--

___
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

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> str(arg.path) if hasattr(arg, 'path') else arg

DirEntry.path can be bytes.

--

___
Python tracker 

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

[issue26076] redundant checks in tok_get in Parser\tokenizer.c

[Oren Milman]

New submission from Oren Milman:

In Parser\tokenizer.c, in tok_get, in the identification of a potential NUMBER 
token, in case the token starts with a '0', the next char of the token is 
retrieved, followed by two redundant checks:
if (c == '.')
goto fraction;
if (c == 'j' || c == 'J')
goto imaginary;

These two are redundant, because they check for the case of a token starting 
with '0.' or '0j', but even without them, the flow in either of these would 
reach the code after the /* maybe old-style octal; c is first char of it */ 
comment.
This code (after consuming all zeros and all decimal digits) would again 
perform those exact two checks, and handle them exactly the same.

My proposal is simply to remove the first two checks.

I have attached the patched tokenizer.c (the redundant checks are just 
commented out).

--
components: Interpreter Core
files: tokenizer.c.withoutRedundantChecks.c
messages: 257927
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: redundant checks in tok_get in Parser\tokenizer.c
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: 
http://bugs.python.org/file41572/tokenizer.c.withoutRedundantChecks.c

___
Python tracker 

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

[issue26076] redundant checks in tok_get in Parser\tokenizer.c

[SilentGhost]

Changes by SilentGhost :


--
keywords: +patch
nosy: +benjamin.peterson
stage:  -> patch review
versions:  -Python 2.7, Python 3.2, Python 3.3, 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

[issue22570] Better stdlib support for Path objects

[Guido van Rossum]

Guido van Rossum added the comment:

You can't win 'em all... :-)

--

___
Python tracker 

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

[issue25919] http.client PUT method ignores error responses sent immediatly after headers

[Wiktor Niesiobedzki]

Wiktor Niesiobedzki added the comment:

Here are the test cases that I've come up with.

test_response_after_headers - tests for the case that I'm missing
test_ssl_renegotiation - tests for the case that Martin point out

As in stock ssl library there is no way to force renegotiation, I've just 
separated the receiving of standard HTTP status message into few parts and 
checking, if the http.client is still sending the contents.

So - without my patch, first case is failing, with my patch - the second case 
is failing.  I'll try to find some better solution here, which will cover both 
cases.

--
Added file: http://bugs.python.org/file41573/early_http_response_tests.patch

___
Python tracker 

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

[issue25596] regular files handled as directories in the glob module

[Xavier de Gaye]

Xavier de Gaye added the comment:

Oops, the list comprehension in _glob1() of glob_scandir_3.patch should be 
instead: names = [x.name for x in _iterdir(dirname, dironly)]
This does not change the tests results except it improves 
glob('/usr/lib*/**/*', True) that gives now 820 msec instead of 927 msec with 
glob_scandir_2.patch.

--

___
Python tracker 

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

[issue19316] devguide: compiler - wording

[Stéphane Wirtel]

Stéphane Wirtel added the comment:

maybe :/

I have reinstalled my laptop, will try to find the patch asap

--

___
Python tracker 

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

[issue26076] redundant checks in tok_get in Parser\tokenizer.c

[Stéphane Wirtel]

Stéphane Wirtel added the comment:

Hi SilentGhost and Oren,

There is a problem with this patch. This is not a patch, but the
complete file. 

1. Could you provide a real patch, with the real diff. Use hg diff >
/tmp/issue26076.diff

2. Please, could you provide a small test to be sure that everything
goes well.

Thank you,

Stephane

--
nosy: +matrixise

___
Python tracker 

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

[issue26076] redundant checks in tok_get in Parser\tokenizer.c

[SilentGhost]

SilentGhost added the comment:

The patch indeed would be more useful, though I'd suggest to actually delete 
the lines you think should be deleted, rather than just leave the commented out.

--
nosy: +SilentGhost

___
Python tracker 

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

[issue26076] redundant checks in tok_get in Parser\tokenizer.c

[Stéphane Wirtel]

Stéphane Wirtel added the comment:

Totally agree with you, 

1. Create a patch
2. Remove the commented lines in the patch

--

___
Python tracker 

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

[issue8810] TZ offset description is unclear in docs

[Martin Panter]

Changes by Martin Panter :


--
stage: needs patch -> patch review

___
Python tracker 

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

[issue9305] Don't use east/west of UTC in date/time documentation

[Martin Panter]

Martin Panter added the comment:

Assuming you meant Issue 8810, yes these patches would collide with each other. 
I am yet to look at the patches, but I gess they should be merged.

--
dependencies: +TZ offset description is unclear in docs -Don't use east/west of 
UTC in date/time documentation
nosy: +martin.panter

___
Python tracker 

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

[issue8810] TZ offset description is unclear in docs

[Stéphane Wirtel]

Stéphane Wirtel added the comment:

Hi Martin,

Which patch?

Thanks
-- 
Stéphane Wirtel - http://wirtel.be - @matrixise

--
nosy: +matrixise

___
Python tracker 

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

[issue26077] Make slicing of immutable structures return a view instead of a copy

[Filip Haglund]

New submission from Filip Haglund:

Slicing tuples returns a copy, which is O(n) time. This could be O(1) since 
tuples are immutable, by just pointing to the same data.

This probably applies to other immutable structures as well, such as strings.

--
components: Interpreter Core
messages: 257937
nosy: Filip Haglund
priority: normal
severity: normal
status: open
title: Make slicing of immutable structures return a view instead of a copy
type: performance
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, 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

[issue25596] regular files handled as directories in the glob module

[Xavier de Gaye]

Xavier de Gaye added the comment:

Actually the microbenchmarks comparison between glob_scandir_2.patch and 
glob_scandir_3.patch must be made by removing the call to entry.is_symlink() 
also in glob_scandir_2.patch.
In that case the microbenchmarks give about the same results for each patch.
Sorry for the noise.

--

___
Python tracker 

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

[issue26077] Make slicing of immutable structures return a view instead of a copy

[Emanuel Barry]

Emanuel Barry added the comment:

This is an interesting idea, +1 from me. Do you want to submit a patch?

--
nosy: +ebarry
stage:  -> needs patch
versions:  -Python 2.7, Python 3.2, Python 3.3, 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

[issue26078] Python launcher options enhancement

[Edward]

New submission from Edward:

The Python launcher in Windows is a neat tool for running multiple versions of 
Python 2 and Python 3 at different times. It allows as options the ability to 
specify the latest version of either Python 2 or Python 3 defaulting to the 
64-bit version if both exist, or a specific 32-bit or 64-bit version of Python 
2 or Python 3. What is missing is the ability to specify the latest 32-bit 
version of Python 2 or Python 3. The equivalent syntax would be '-2-32' or 
'-3-32'. Is there some reason why this option has been disallowed ? If not I 
would like to see this logical enhancement to the Python launcher in Windows 
added to its functionality.

--
components: Windows
messages: 257940
nosy: edienerlee, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python launcher options enhancement
type: enhancement
versions: Python 3.5

___
Python tracker 

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

[issue1753718] base64 "legacy" functions violate RFC 3548

[Martin Panter]

Martin Panter added the comment:

Uploaded a Python 3 patch to Issue 22088 which includes the doc string changes.

--

___
Python tracker 

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

[issue26077] Make slicing of immutable structures return a view instead of a copy

[Martin Panter]

Martin Panter added the comment:

I think which technique (copy or view) is better depends on the situation. If 
you are making a large temporary slice, a view may be more efficient. But if 
you are making a long-term slice and don’t need the original any more, a copy 
would allow the original memory to be freed early.

Do you have any use cases? You can already get a kind of slice view into bytes 
etc by using memoryview().

--
nosy: +martin.panter

___
Python tracker 

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

[issue26076] redundant checks in tok_get in Parser\tokenizer.c

[Oren Milman]

Oren Milman added the comment:

Sorry for being so clueless.
The diff is attached.

I manually did some checks to verify that relevant stuff work correctly (the 
imaginary number 0j, and fractions starting with '0.').
I run 'python -m test', and got the following output:
352 tests OK.
1 test altered the execution environment:
test_subprocess
45 tests skipped:
test_bz2 test_crypt test_curses test_dbm_gnu test_dbm_ndbm
test_devpoll test_epoll test_fcntl test_fork1 test_gdb test_grp
test_idle test_ioctl test_kqueue test_lzma test_nis test_openpty
test_ossaudiodev test_pipes test_poll test_posix test_pty test_pwd
test_readline test_resource test_smtpnet test_socketserver
test_spwd test_sqlite test_ssl test_syslog test_tcl
test_threadsignals test_timeout test_tix test_tk test_ttk_guionly
test_ttk_textonly test_urllib2net test_urllibnet test_wait3
test_wait4 test_winsound test_xmlrpc_net test_zipfile64

Then, I removed my patch (and made sure hg diff output nothing), rebuilt 
CPython, run 'python -m test', and got exactly the same output.

--
versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file41574/issue26076.diff

___
Python tracker 

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

[issue26076] redundant checks in tok_get in Parser\tokenizer.c

[SilentGhost]

Changes by SilentGhost :


--
versions:  -Python 2.7, Python 3.2, Python 3.3, 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

[issue25170] 3.5.0 documentation archives missing

[Martin Panter]

Martin Panter added the comment:

Perhaps related is that the list at  only 
goes up to 3.4.3.

--
nosy: +martin.panter

___
Python tracker 

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

[issue25919] http.client PUT method ignores error responses sent immediatly after headers

[Martin Panter]

Martin Panter added the comment:

Sorry for making a seemingly easy problem harder :)

Your version of test_ssl_renegotiation() would actually be harder to fix IMO, 
since that would require the client to receive response data (the “H”) and 
continue to transmit request data concurrently. It would probably require 
sending and receiving in separate coroutines or threads, like asyncio.

There may still be a way to avoid that if we don’t need to send and receive 
HTTP data at the same time. We only need the low-level SSL messages to work 
properly. The following might work:

self.sock.setblocking(False)
try:
...  # Get chunks of request body to send
while datablock:
select((self._reader,), (self.sock,), (), self._timeout)
if self._reader.peek():
...  # Early response received
try:
amount = self.sock.send(datablock)
except (BlockingIOError, SSLWantRead, SSLWantWrite):
continue
datablock = datablock[amount:]
finally:
self.sock.settimeout(self.timeout)

This might require the following problems investigated and fixed first:

* Need to maintain the buffered socket reader of self.sock.makefile(), before 
the response is actually read. Could use my patch for Issue 23377.

* Allow a buffered socket reader to be non-blocking without upsetting its 
buffer. The documentation 

 disallows non-blocking mode, but I suspect that is just a Python 2 relic and 
there is no restriction in the Python 3 implementation. I thought there was a 
bug open for this but I can only find mentions in other bugs.

* Allow using BufferedReader.peek() to see if data is ready to be read. The 
current documentation does not guarantee it will return any bytes (Issue 5811), 
but I understand the implementation normally does return ≥ 1 byte.

* Clarify what peek() should do if no non-blocking data is available. Currently 
I think it returns b"", but that is inconsistent with other APIs, and does not 
differentiate from EOF. I proposed to change peek() to return None in Issue 
13322.

--

___
Python tracker 

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

[issue19332] Guard against changing dict during iteration

[Roundup Robot]

Roundup Robot added the comment:

New changeset a576199a5350 by Victor Stinner in branch 'default':
PEP 509
https://hg.python.org/peps/rev/a576199a5350

--
nosy: +python-dev

___
Python tracker 

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

[issue25596] regular files handled as directories in the glob module

[Guido van Rossum]

Guido van Rossum added the comment:

@serhiy, I assume this is in your capable hands?

Personally I'd like to have seen the refactoring in a separate diff from the 
switch to scandir(), just to ensure that the refactoring does not change 
anything and to make it easier to read the changes for the scandir() switch.

--

___
Python tracker 

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

[issue26076] redundant checks in tok_get in Parser\tokenizer.c

[Stéphane Wirtel]

Changes by Stéphane Wirtel :


--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue26076] redundant checks in tok_get in Parser\tokenizer.c

[Stéphane Wirtel]

Stéphane Wirtel added the comment:

Thank you for your patch, it's easier for the review.

--

___
Python tracker 

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

[issue26070] Launcher fails to find in-place built binaries from earlier Python versions

[Roundup Robot]

Roundup Robot added the comment:

New changeset 51cc7adac78d by Mark Hammond in branch '3.5':
Issue #26070: py.exe launcher fails to find in-place built binaries from 
earlier Python versions.
https://hg.python.org/cpython/rev/51cc7adac78d

New changeset bfb4a09149b1 by Mark Hammond in branch 'default':
Issue #26070: py.exe launcher fails to find in-place built binaries from 
earlier Python versions.
https://hg.python.org/cpython/rev/bfb4a09149b1

--
nosy: +python-dev

___
Python tracker 

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

[issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons

[Mark Hammond]

Mark Hammond added the comment:

> > The directory of the DLL can be added to the search path if you
> > use LoadLibraryEx with the flag LOAD_WITH_ALTERED_SEARCH_PATH and use an 
> > absolute path. 

> That sounds like the better fix then. I thought there was something along 
> those lines available.

That does work. I didn't do it that way initially as I felt your earlier 
comment:

> Setting the working directory is likely to lead to a more reliable initial 
> state.

Was an additional nice outcome of just changing the cwd. This patch does the 
LoadLibraryEx() and works (but obviously leaves the CWD being the downloaded 
directory, probably %temp%)

I'll check this in once I get the green-light, thanks.

--
Added file: http://bugs.python.org/file41575/bdist.patch

___
Python tracker 

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

[issue26078] Python launcher options enhancement

[Eryk Sun]

Changes by Eryk Sun :


--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Let launcher autoselect best 32-bit Python on 64-bit system

___
Python tracker 

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

[issue25636] Let launcher autoselect best 32-bit Python on 64-bit system

[Eryk Sun]

Changes by Eryk Sun :


--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
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