[issue17170] string method lookup is too slow

[Larry Hastings]

Larry Hastings added the comment:

Argument Clinic has languished for lack of time.  I didn't get much feedback, 
though a couple people were shouting for a PEP, which I was resisting.  I 
figured, if they have something to say, they can go ahead and reply on the 
tracker issue, and if they don't have something to say, why do we need a PEP?

I need to reply to one bit of thorough feedback, and after that--I don't know.  
I'd like to get things moving before PyCon so we can point sprinters at it.

--
nosy: +larry

___
Python tracker 

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

[issue16278] os.rename documentation slightly inaccurate

[Senthil Kumaran]

Senthil Kumaran added the comment:

The doc change looks good to me. I am adding Terry and Ezio to see if they have 
any comments on wordings in the doc. If not, I can commit this change. I think 
that this is helpful.

--
nosy: +ezio.melotti, orsenthil, terry.reedy

___
Python tracker 

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

[issue16278] os.rename documentation slightly inaccurate

[Chris Jerdonek]

Chris Jerdonek added the comment:

I commented above that the tests are not very DRY though.  Shouldn't there be 
tests to check that the documented behavior is correct?

--

___
Python tracker 

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

[issue16278] os.rename documentation slightly inaccurate

[Senthil Kumaran]

Senthil Kumaran added the comment:

Chris:  The patch is for the docs. the test code I believe, is for
reference. It would be to run it on different OS and verify the
documentation matches the behavior.I am okay with more than one person
verifying this and I shall do on OS'es I have.

--

___
Python tracker 

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

[issue17170] string method lookup is too slow

[Larry Hastings]

Larry Hastings added the comment:

Oh, and, as to whether Argument Clinic would solve this problem, the answer is 
"not yet".  Right now Argument Clinic literally generates calls to 
PyArg_ParseTupleAndKeywords.  (In special cases it switches to 
PyArg_ParseTuple.)

I'm more interested in Argument Clinic from the API perspective; I wanted to 
make a better way of specifying arguments to functions so we got all the 
metadata we needed without having to endlessly repeat ourselves.  Truthfully I 
was hoping someone else would pick up the gauntlet once it was checked in and 
make a new argument processing API / hack up the Argument Clinic output to make 
it faster.

--

___
Python tracker 

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

[issue17170] string method lookup is too slow

[Antoine Pitrou]

Antoine Pitrou added the comment:

> Truthfully I was hoping someone else would pick up the gauntlet once it 
> was checked in and make a new argument processing API / hack up the
> Argument Clinic output to make it faster.

Argument Clinic's preprocessing would be a very nice building block to generate 
faster parsing sequences.
Like Nick I'd still like to see a PEP, though ;-)

--

___
Python tracker 

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

[issue17197] c/profile refactoring

[Antoine Pitrou]

Antoine Pitrou added the comment:

The patch doesn't look right to me. If you import cProfile, profile will always 
invoke the cProfile profiler.

--

___
Python tracker 

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

[issue17189] Add zip64 support to shutil

[Antoine Pitrou]

Antoine Pitrou added the comment:

Would there be a way to automatically switch the flag as necessary?
(i.e. when writing more than 2GB, I guess)

--
nosy: +hynek, pitrou, tarek

___
Python tracker 

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

[issue17197] c/profile refactoring

[Giampaolo Rodola']

Giampaolo Rodola' added the comment:

No, it's the other way around. It's from cProfile which I import profile.

diff --git a/Lib/cProfile.py b/Lib/cProfile.py
--- a/Lib/cProfile.py
+++ b/Lib/cProfile.py
...
+import profile as _pyprofile

--

___
Python tracker 

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

[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +christian.heimes, hynek, tarek
priority: normal -> high
type:  -> security
versions: +Python 3.3, Python 3.4 -Python 2.6, Python 3.1

___
Python tracker 

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

[issue5308] cannot marshal objects with more than 2**31 elements

[Roundup Robot]

Roundup Robot added the comment:

New changeset 385d982ce641 by Serhiy Storchaka in branch '2.7':
Issue #5308: Raise ValueError when marshalling too large object (a sequence
http://hg.python.org/cpython/rev/385d982ce641

New changeset e0464fa28c85 by Serhiy Storchaka in branch '3.2':
Issue #5308: Raise ValueError when marshalling too large object (a sequence
http://hg.python.org/cpython/rev/e0464fa28c85

New changeset b48e1cd2d3be by Serhiy Storchaka in branch '3.3':
Issue #5308: Raise ValueError when marshalling too large object (a sequence
http://hg.python.org/cpython/rev/b48e1cd2d3be

New changeset ea36478a36ee by Serhiy Storchaka in branch 'default':
Issue #5308: Raise ValueError when marshalling too large object (a sequence
http://hg.python.org/cpython/rev/ea36478a36ee

--
nosy: +python-dev

___
Python tracker 

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

[issue16996] Reuse shutil.which() in webbrowser module

[Roundup Robot]

Roundup Robot added the comment:

New changeset 050c94f5f72c by Serhiy Storchaka in branch 'default':
Issue #16996: webbrowser module now uses shutil.which() to find a
http://hg.python.org/cpython/rev/050c94f5f72c

--
nosy: +python-dev

___
Python tracker 

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

[issue11311] StringIO.readline(0) returns incorrect results

[Roundup Robot]

Roundup Robot added the comment:

New changeset 7513bd184a01 by Serhiy Storchaka in branch '2.7':
Issue #11311: StringIO.readline(0) now returns an empty string as all other
http://hg.python.org/cpython/rev/7513bd184a01

--
nosy: +python-dev

___
Python tracker 

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

[issue5308] cannot marshal objects with more than 2**31 elements

[Roundup Robot]

Roundup Robot added the comment:

New changeset 72e75ea25d00 by Serhiy Storchaka in branch '2.7':
Fix tests for issue #5308.
http://hg.python.org/cpython/rev/72e75ea25d00

New changeset 0407e5e5915e by Serhiy Storchaka in branch '3.3':
Cleanup a test for issue #5308.
http://hg.python.org/cpython/rev/0407e5e5915e

New changeset e45f2fcf202c by Serhiy Storchaka in branch 'default':
Cleanup a test for issue #5308.
http://hg.python.org/cpython/rev/e45f2fcf202c

--

___
Python tracker 

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

[issue5308] cannot marshal objects with more than 2**31 elements

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> Perhaps you could add a bigmem test for this?
> (assuming you have enough memory somewhere to test it)

Some tests require more than 252 GiB of memory.

--

___
Python tracker 

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

[issue11311] StringIO.readline(0) returns incorrect results

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Fixed. Thank you for the report, Ville.

--
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue16996] Reuse shutil.which() in webbrowser module

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Thank you, Senthil.

--

___
Python tracker 

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

[issue16692] Support TLS 1.1 and TLS 1.2

[Michele Orrù]

Changes by Michele Orrù :


--
nosy: +eric.araujo

___
Python tracker 

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

[issue17189] Add zip64 support to shutil

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> Would there be a way to automatically switch the flag as necessary?
> (i.e. when writing more than 2GB, I guess)

Yes, there is a special flag for this in zipfile. It is named allowZip64.

The only reason to use allowZip64=False is when you expect to unzip a zipfile 
with a tool which doesn't support zip64 (PKUNZIP.EXE for DOS?) and you want to 
keep yourself from unintentional zipping a file larger than 2 GiB.

Perhaps sometime we should to change the default value for allowZip64 from 
False to True.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue16996] Reuse shutil.which() in webbrowser module

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue17193] Use binary prefixes

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

For what versions can I apply this patch?

--

___
Python tracker 

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

[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits

[Christian Heimes]

Christian Heimes added the comment:

Thanks for the report. I agree with your analysis. We should follow the 
behavior of cp and always strip off the suid/sgid bits in shutil.copy(). 
coreutil's cp removes the bits and doesn't handle source owner = destination 
owner special.

There are other bits that may need special treatment, too. I'm going to check 
the sources of cp.

--
stage:  -> needs patch

___
Python tracker 

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

[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits

[Christian Heimes]

Christian Heimes added the comment:

cp removes three bits unless preserve ownership is enabled and some additional 
things are true. 

mode &= ~ (S_ISUID | S_ISGID | S_ISVTX)

S_ISVTX is the sticky bit.

--

___
Python tracker 

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

[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits

[Hynek Schlawack]

Hynek Schlawack added the comment:

While I agree that it’s a problem, I’m a bit uneasy about changing that back to 
2.7. I’m pretty sure this would break numerous programs.

--

___
Python tracker 

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

[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits

[Christian Heimes]

Christian Heimes added the comment:

Here is a patch for the issue with test and doc updates.

I'm escalating the bug to release blocker to draw the attention of our RMs.

--

___
Python tracker 

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

[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits

[Christian Heimes]

Changes by Christian Heimes :


--
keywords: +patch
Added file: http://bugs.python.org/file29057/17180.patch

___
Python tracker 

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

[issue17199] Slightly wrong behavior of logging.StrFormatStyle.usesTime

[R. David Murray]

Changes by R. David Murray :


--
nosy: +vinay.sajip

___
Python tracker 

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

[issue17199] Slightly wrong behavior of logging.StrFormatStyle.usesTime

[R. David Murray]

Changes by R. David Murray :


--
type: enhancement -> behavior
versions: +Python 3.2, Python 3.4

___
Python tracker 

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

[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits

[Christian Heimes]

Christian Heimes added the comment:

Sorry for the extra noise. I got into a comment conflict with Hynek.

Hynek,
I don't think it's going to break lots of apps. setuid/setgid programs are rare 
these days. Most operating system ignore sticky bits on files, too.

It may break system scripts that copy entire Unix systems with a recursive 
copytree(), though ...

--
nosy: +benjamin.peterson, georg.brandl, larry
priority: high -> release blocker
stage: needs patch -> patch review

___
Python tracker 

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

[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits

[Hynek Schlawack]

Hynek Schlawack added the comment:

Yeah, I’m thinking about backup scripts etc.

--

___
Python tracker 

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

[issue17197] c/profile refactoring

[Antoine Pitrou]

Antoine Pitrou added the comment:

> No, it's the other way around. It's from cProfile which I import
> profile.
> 
> diff --git a/Lib/cProfile.py b/Lib/cProfile.py
> --- a/Lib/cProfile.py
> +++ b/Lib/cProfile.py
> ...
> +import profile as _pyprofile

That's exactly what I'm saying. Once you import cProfile, the attributes
on the profile functions are overriden.
Either way, a module shouldn't mutate another module's functions.

--

___
Python tracker 

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

[issue17189] Add zip64 support to shutil

[Antoine Pitrou]

Antoine Pitrou added the comment:

> Yes, there is a special flag for this in zipfile. It is named
> allowZip64.

Then I think shutil should set allowZip64 to True by default.
People who want fine-grained control over the zipfile's characteristics can 
still use the zipfile module directly.

--

___
Python tracker 

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

[issue16743] mmap on Windows can mishandle files larger than sys.maxsize

[Roundup Robot]

Roundup Robot added the comment:

New changeset b1bbe519770b by Richard Oudkerk in branch '2.7':
Issue #16743: Fix mmap overflow check on 32 bit Windows
http://hg.python.org/cpython/rev/b1bbe519770b

New changeset c2c84d3ab393 by Richard Oudkerk in branch '3.2':
Issue #16743: Fix mmap overflow check on 32 bit Windows
http://hg.python.org/cpython/rev/c2c84d3ab393

--
nosy: +python-dev

___
Python tracker 

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

[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits

[Christian Heimes]

Christian Heimes added the comment:

Here is a new patch with a new keyword argument preserve_sbits. Perhaps we use 
`True` as default for Python 2.6 to 3.3 and switch to False in Python 3.4?

--
Added file: http://bugs.python.org/file29058/17180_preserve_sbits.patch

___
Python tracker 

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

[issue16612] Integrate "Argument Clinic" specialized preprocessor into CPython trunk

[Stefan Krah]

Stefan Krah added the comment:

Here's a proposal for an alternative without parameter docstrings and a
different DSL (see os_stat.c). I guess it's easiest to present my thoughts
in list form.


Changes and rationale:
==

  Split docstring into function header and rest
  -

- Since the docstrings aren't repeated, less vertical space is used.

- The main part of the docstring can go into a header file.

- It's (IMO) easier to compare the generated header (see OS_STAT_HEADER)
  to the specification in the comment.


  More formal DSL
  ---

This is my personal opinion: The existing DSL is fine for a configuration
file (think .hgrc), but I have trouble with it in the context of a C file.

Most importantly, I'm unable to take in the required information at a
single glance.

So I propose to make the structure of the specification explicit. For
me the result is more readable. Also, it's already pretty close to a formal
grammar and can be optionally condensed into single lines.

  Logical grouping
  

The preprocessor comment, OS_STAT_HEADER and the os_stat() definition are
close together and fit on a single screen.

--
Added file: http://bugs.python.org/file29059/os_stat.c

___
Python tracker 

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

[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits

[Hynek Schlawack]

Hynek Schlawack added the comment:

SGTM. I’d like an explicit warning on the security implications in the docs 
though.

--

___
Python tracker 

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

[issue17189] Add zip64 support to shutil

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Agree.

--

___
Python tracker 

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

[issue16743] mmap on Windows can mishandle files larger than sys.maxsize

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Perhaps NEWS item needed for this change.

--

___
Python tracker 

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

[issue17089] Expat parser parses strings only when XML encoding is UTF-8

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue17061] tokenize unconditionally emits NL after comment lines & blank lines

[Thomas Kluyver]

Thomas Kluyver added the comment:

Hmm, that's interesting.

For our purposes, a blank line or a comment line shouldn't result in a 
continuation prompt. This is consistent with what the plain Python shell does.

As part of this, we're tokenizing the code, and if the final \n results in a NL 
token (instead of NEWLINE), we wait to build a 'Python line'. (Likewise if the 
final \n doesn't appear before EOFError, indicating that a string continues to 
the next line). Since tokenize doesn't expose parenlev (parentheses level), my 
modification to tokenize makes this work as we need.

Maybe another way forward would be to make parenlev accessible in some way, so 
that we can use that rather than using NL == parenlev > 0?

--

___
Python tracker 

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

[issue17199] Slightly wrong behavior of logging.StrFormatStyle.usesTime

[Vinay Sajip]

Vinay Sajip added the comment:

It's not a bug - the reason it's like that is that it allows conversion and 
format specifiers to be given - {field_name!conversion:format_spec}.

Of course a more robust solution using regular expressions could be 
implemented, but it's not really worth it. If there's a misspelt field name, 
generally you'll know because there will either be an exception raised, or (in 
production) no output will be produced.

--
resolution:  -> invalid
status: open -> closed

___
Python tracker 

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

[issue17199] Slightly wrong behavior of logging.StrFormatStyle.usesTime

[Enrique A Tobis]

Enrique A Tobis added the comment:

Thanks! Got it. Sorry for the noise.

--

___
Python tracker 

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

[issue17199] Slightly wrong behavior of logging.StrFormatStyle.usesTime

[R. David Murray]

R. David Murray added the comment:

I would still consider it a bug myself, but I understand and accept that you 
feel it is not worth fixing.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue17170] string method lookup is too slow

[Barry A. Warsaw]

Changes by Barry A. Warsaw :


--
nosy: +barry

___
Python tracker 

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

[issue16743] mmap on Windows can mishandle files larger than sys.maxsize

[Roundup Robot]

Roundup Robot added the comment:

New changeset 82db097cd2e0 by Richard Oudkerk in branch '2.7':
Add Misc/NEWS entry for Issue #16743
http://hg.python.org/cpython/rev/82db097cd2e0

New changeset efe489f87881 by Richard Oudkerk in branch '3.2':
Add Misc/NEWS entry for Issue #16743
http://hg.python.org/cpython/rev/efe489f87881

--

___
Python tracker 

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

[issue16743] mmap on Windows can mishandle files larger than sys.maxsize

[Richard Oudkerk]

Richard Oudkerk added the comment:

> Perhaps NEWS item needed for this change.

Done.

--

___
Python tracker 

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

[issue7279] decimal.py: == and != comparisons involving NaNs

[Sebastian Berg]

Sebastian Berg added the comment:

This is closed, and maybe I am missing something. But from a general point of 
view, why does hashing of NaN not raise an error as it did for decimals, i.e. 
why was this not resolved exactly the other way around? I am mostly just 
wondering about this it is not a problem for me.

Hashing NaNs seems dangerous and surprising because it might work in 
dicts/sets, but normally doesn't. (The only thing for it to work right would be 
if NaN was a singleton, but that is impossible for subclasses, etc.).

The thing is:

In [16]: s = {float('nan'): 1, float('nan'): 2, float('nan'): 3}
In [17]: s
Out[17]: {nan: 1, nan: 2, nan: 3}

In [18]: s[float('nan')]
KeyError: nan

In [19]: n = float('nan')
In [20]: s = {n: 1, n: 2, n: 3}
In [21]: s
Out[21]: {nan: 3}

This is because `n is n`, and PyObject_RichCompareBool assumes that if `a is b` 
then `a == b` which is simply wrong for NaNs and also makes comparisons  of 
iterables including NaNs an impossible business. NaNs have their unavoidable 
weirdness, but at least for dictionaries/sets it would seem more clear to me if 
they raised an error.

--
nosy: +seberg

___
Python tracker 

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

[issue16278] os.rename documentation slightly inaccurate

[Todd Rovito]

Todd Rovito added the comment:

Chris,
   I first verified the issue then created some wording and you pointed out 
that we needed test cases so I created a bunch of test cases.  As you pointed 
out "I count 2*3*2=12 possibilities to check (excluding src and dst being on 
different filesystems):" so I created 16 test cases then discovered that the 
behavior is different on Windows and Unix so all together there are 32 test 
cases.  Your last comment about the test cases being "Dry" didn't make sense to 
me.  If you provide specific feedback I would be glad to work on the issue.  
The test cases are designed to make sure that the documented behavior is 
actually how Python performs.  It made the most sense to me to put together two 
patches one for the test cases and another for the documentation, but maybe 
that has confused everybody?  If it would help I could submit a single patch.  
OSRenameCombinations.py was just for reference to prove to myself that I got 
all the possible test cases.

I am a fairly new Python contributor and this is my first attempt at writing 
test cases so I could be missing something.  Thanks for the mentorship and the 
time required for a little extra guidance.

--

___
Python tracker 

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

[issue17193] Use binary prefixes

[Brett Cannon]

Brett Cannon added the comment:

IMO I say just do 3.4 since it isn't really a bug fix but a cleanup, but I 
wouldn't object if it was backported.

--

___
Python tracker 

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

[issue17189] Add zip64 support to shutil

[William Mallard]

William Mallard added the comment:

Ok, here's a patch that makes zip64 the default in make_archive() when 
format='zip'.

I also agree that ZipFile should set allowZip64=True by default. (PKZIP has 
supported zip64 since 2001!)

--
Added file: http://bugs.python.org/file29060/shutil_zip64_by_default.patch

___
Python tracker 

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

[issue7279] decimal.py: == and != comparisons involving NaNs

[Mark Dickinson]

Mark Dickinson added the comment:

Sebastian:  I think this discussion is a bit off-topic for this particular bug; 
 you might want to raise it on python-dev or python-ideas instead.  

Bear in mind, though, that the behaviour of NaNs and containers has been 
discussed to death many times in the past;  I'd suggest not bringing the issue 
up again unless there's something genuinely new to bring to the discussion.  
The current behaviour is certainly a compromise, but it seems to be the best 
compromise available.

Note that with respect to this particular issue: it's only *signalling* nans 
that raise on hashing for the Decimal type.  Quiet nans are hashable as usual.  
Since for float, all nans can be regarded as quiet, Decimal and float behave 
the same way on this.

--

___
Python tracker 

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

[issue7279] decimal.py: == and != comparisons involving NaNs

[Sebastian Berg]

Sebastian Berg added the comment:

Thanks, yes, you are right, should have googled a bit more anyway. Though I did 
not find much on the hashable vs unhashable itself, so if I ever stumble across 
it again, I will write a mail...

--

___
Python tracker 

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

[issue16612] Integrate "Argument Clinic" specialized preprocessor into CPython trunk

[Antoine Pitrou]

Antoine Pitrou added the comment:

> Here's a proposal for an alternative without parameter docstrings and
> a
> different DSL (see os_stat.c). I guess it's easiest to present my
> thoughts
> in list form.

It's a bit difficult to give an opinion without a more formal definition.
For example it seems you are using REQUIRED and KEYWORD as opposites,
but a required argument can also be a keyword argument.

As for the docstring: I would like it better if I could avoid typing
the cumbersome "\n\"s.

As for the general parameter declaration syntax: I think it shouldn't
be too verbose, otherwise it will quickly become tiring.
(also I don't think it should be required to write "[preprocessor]"
twice)

--
title: Integrate "Argument Clinic" specialized preprocessor into CPython trunk 
-> Integrate "Argument Clinic" specialized preprocessor  into CPython trunk

___
Python tracker 

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

[issue17192] libffi-3.0.12 import

[Arfrever Frehtes Taifersar Arahesis]

Arfrever Frehtes Taifersar Arahesis added the comment:

Maybe Modules/_ctypes/libffi in 2.7, 3.2 and 3.3 branches should be updated?

--
nosy: +Arfrever

___
Python tracker 

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

[issue17201] Use allowZip64=True by default

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

Python supports ZIP64 extension since 2.5 (more 6 years ago). May be it is time 
to use it by default, leaving the option to disable it by specifying 
allowZip64=False.

--
components: Library (Lib)
messages: 182048
nosy: alanmcintyre, loewis, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Use allowZip64=True by default
type: enhancement
versions: Python 3.4

___
Python tracker 

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

[issue17193] Use binary prefixes

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Then I'll apply this to 3.3 too. This will facilitate support of both versions.

--
assignee: docs@python -> serhiy.storchaka
versions: +Python 3.3, Python 3.4

___
Python tracker 

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

[issue16278] os.rename documentation slightly inaccurate

[Chris Jerdonek]

Chris Jerdonek added the comment:

Senthil, in my experience, whenever documentation is added that documents new 
aspects of behavior (e.g. is not just a rewording of existing documentation), 
tests are always added simultaneously (if not already present) to ensure that 
the code doesn't regress against the new documentation.

Todd, DRY means "don't repeat yourself."  You can look it up on Wikipedia, etc. 
 Identical chunks of code are repeated several times which make it harder for 
others to see how the test cases differ from each other (as well as making the 
code harder to maintain).

--

___
Python tracker 

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

[issue16278] os.rename documentation slightly inaccurate

[Chris Jerdonek]

Chris Jerdonek added the comment:

> If it would help I could submit a single patch.

Yes, a single patch is best.  One way to make code more DRY is refactoring to 
use helper functions as needed (i.e. same code in multiple places -> one helper 
function).

--

___
Python tracker 

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

[issue17189] Add zip64 support to shutil

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

This should be reflected in the documentation.

--
dependencies: +Use allowZip64=True by default

___
Python tracker 

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

[issue16612] Integrate "Argument Clinic" specialized preprocessor into CPython trunk

[Bradley Froehle]

Bradley Froehle added the comment:

> As for the docstring: I would like it better if I could avoid typing
> the cumbersome "\n\"s.

I agree with Stefan that the file is a lot more readable if the docstring
is not repeated twice. It's unfortunate that C doesn't have a notion of
a raw string (as opposed to C++11 with the new R"(...)" syntax) but I
think it is something we'll have to live with. I would have expected
that a good text editor would be able to convert a selected region into a
C string, but I've never actually seen such a feature.

In general I think we should aim for clarity in scope of the arguments in
the DSL -- either by using curly-braces (a C construct) or indentation (a
Python construct). To minimize the usage of vertical space, I'd like to
see the DSL not require a blank line between arguments.

In a project I worked on recently I ended up writing a parser to go
through a list of C arguments and automatically produce the
PyArg_ParseTuple / PyArg_ParseTupleAndKeywords lines. It's not as
full featured as what we are looking for here, but it did have the
benefit of minimizing the number of extra vertical lines.  For example::

static PyObject *
w_rktime(PyObject *self, PyObject *args, PyObject *kwargs)
{
/*[kwargs rktime]*/
darray u;
meshdata msh;
double dt;
int nsteps=1;
/*[/kwargs]*/
static char *_keywords[] = {"u", "msh", "dt", "nsteps", NULL};
if (!PyArg_ParseTupleAndKeywords(args, kwargs, "O&O&d|i:rktime", 
_keywords, view_as_darray, &u, DgMeshData_Converter, &msh, &dt, &nsteps))
return NULL;
/*[checksum=...]*/
...
}

I could imagine extending such a syntax to allow custom converters
and other extensions using comments::

path_t path = PATH_T_INITIALIZE("stat", 0, 1)
/* converter = path_converter; default = None */;
int dir_fd = DEFAULT_DIR_FD
/* converter = OS_STAT_DIR_FD_CONVERTER */;

The biggest downside to this approach would be that the parser could
not inject C code directly into the global scope -- instead it would
be limited to producing #define lines.

-Brad

--

___
Python tracker 

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

[issue16612] Integrate "Argument Clinic" specialized preprocessor into CPython trunk

[Jim Jewett]

Jim Jewett added the comment:

I'm not sure I correctly understand skrah's proposal.  If I do, then

(1)  The first several lines ( "/* pymacro.h */" until "/* could go into a 
separate header file */" ) would not be written at all, and are just there to 
help reviewers understand.

(2)  The "#define OS_STAT_DOC ..." line is the docstring, and would be needed, 
but could easily go into a separate header file, like os_stat__doc.h.  For 
something like cdecimal, there might be only a single _cdecimal__doc.h 
containing all the docstrings.  There might even be a build switch that (at a 
minimum) replaced anything from those __doc.h files with "" for 
space-constrained builds.

(3)  The human-maintained code would be the DSL between "/*[preprocessor]" and 
"[preprocessor]*/".

(4)  The lines between "[preprocessor]*/" and "/*[preprocessor 
end:f3e6b328245207c240825782d908d3ff3a9c11c0]*/" would NOT be written or 
maintained by a human, but WOULD be checked into hg for the benefit builders 
without the argument-clinic tool.

(5)  The only C code written or maintained by a human (or another macro system) 
would be the last 5 lines (the system call, the path cleanup, and the return).

If I'm wrong about the above assumptions, then I think your proposal is 
insufficiently ambitious.  

If I'm correct, then your proposal boils down to

(1)  Allow (require?) the function-level docstring to be defined somewhere 
else, possibly in another file.

(2)  Change the DSL
  (2a)  Get rid of function flags?  (Not sure this is workable)
  (2b)  Replace the (previously proposed) parameter declarations with literal C 
code forming an array of [parameter kind, 
array-of-setup-instructions-and-or-magically-named-variable-settings]


More flexibility in building the docstring is probably good.  

The other changes -- I'm not sure I see the advantage, except that it might 
simplify writing the thing as a C pre-processing macro.

--
nosy: +Jim.Jewett

___
Python tracker 

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

[issue2175] Expat sax parser silently ignores the InputSource protocol

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


Removed file: http://bugs.python.org/file28954/sax_character_stream.patch

___
Python tracker 

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

[issue2175] Expat sax parser silently ignores the InputSource protocol

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


Added file: http://bugs.python.org/file29061/sax_character_stream.patch

___
Python tracker 

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

[issue2175] Expat sax parser silently ignores the InputSource protocol

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


Added file: http://bugs.python.org/file29062/sax_character_stream-2.7.patch

___
Python tracker 

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

[issue2175] Expat sax parser silently ignores the InputSource protocol

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

This patch is rather complicated and I doubt whether it is necessary to apply 
it to the older version. Can anyone review it?

--

___
Python tracker 

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

[issue10590] Parameter type error for xml.sax.parseString(string, ...)

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
dependencies: +Expat sax parser silently ignores the InputSource protocol

___
Python tracker 

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

[issue14191] argparse doesn't allow optionals within positionals

[Andrew McNabb]

Changes by Andrew McNabb :


--
nosy: +amcnabb

___
Python tracker 

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

[issue15258] argparse documentation: Improve optparse section regarding allow_interspersed_args

[Andrew McNabb]

Changes by Andrew McNabb :


--
nosy: +amcnabb

___
Python tracker 

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

[issue1285086] urllib.quote is too slow

[Maciej Fijalkowski]

Maciej Fijalkowski added the comment:

As per discussion on python-dev, this bug should probably be reopened and the 
patch maybe reverted as relying on the refcounting hack is both dodgy and hurts 
other implementations, like PyPy.

--
nosy: +fijall

___
Python tracker 

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

[issue1285086] urllib.quote is too slow

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution: fixed -> 
stage: committed/rejected -> needs patch
status: closed -> open

___
Python tracker 

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

[issue16278] os.rename documentation slightly inaccurate

[Todd Rovito]

Todd Rovito added the comment:

Chris,
  Thanks for the clarification.  I thought you were telling me my test cases 
were dry as in dry humorI will read-up on the dry concept and see what I 
can do to consolidate plus I will combine the patches.  Initially I am thinking 
I could collapse all the test cases into two functions each for their 
respective operating system.  Would that be ok?

--

___
Python tracker 

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

[issue16278] os.rename documentation slightly inaccurate

[Chris Jerdonek]

Chris Jerdonek added the comment:

The number of test cases isn't the problem.  Having more but finer-grained test 
cases is usually preferred in fact.  It's just that the test cases should be 
sharing code where possible so that they're shorter and easy to see how they 
differ from one another.

--

___
Python tracker 

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

[issue17189] Add zip64 support to shutil

[William Mallard]

William Mallard added the comment:

Documentation added. See attached.

--
Added file: http://bugs.python.org/file29063/shutil_zip64_by_default.patch

___
Python tracker 

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

[issue16612] Integrate "Argument Clinic" specialized preprocessor into CPython trunk

[Stefan Krah]

Stefan Krah added the comment:

Jim Jewett  wrote:
> (1)  The first several lines ( "/* pymacro.h */" until "/* could go into a 
> separate header file */" ) would not be written at all, and are just there to 
> help reviewers understand.

Yes, they should ultimately go into Include/pymacro.h.

> (2)  The "#define OS_STAT_DOC ..." line is the docstring, and would be 
> needed, but could easily go into a separate header file, like os_stat__doc.h. 
>  For something like cdecimal, there might be only a single _cdecimal__doc.h 
> containing all the docstrings.  There might even be a build switch that (at a 
> minimum) replaced anything from those __doc.h files with "" for 
> space-constrained builds.

Yes, it's supposed to be the main part of the docstring. The docstring header
containing the function signature would be autogenerated.

> (3)  The human-maintained code would be the DSL between "/*[preprocessor]" 
> and "[preprocessor]*/".

Yes.

> (4)  The lines between "[preprocessor]*/" and "/*[preprocessor 
> end:f3e6b328245207c240825782d908d3ff3a9c11c0]*/" would NOT be written or 
> maintained by a human, but WOULD be checked into hg for the benefit builders 
> without the argument-clinic tool.

Yes, all that code would be generated by clinic.py.

> (5)  The only C code written or maintained by a human (or another macro 
> system) would be the last 5 lines (the system call, the path cleanup, and the 
> return).

Correct.

> If I'm correct, then your proposal boils down to
> 
> (1)  Allow (require?) the function-level docstring to be defined somewhere 
> else, possibly in another file.

Yes.

> (2)  Change the DSL
>   (2a)  Get rid of function flags?  (Not sure this is workable)

I didn't intend to but you're right, they were missing.

>   (2b)  Replace the (previously proposed) parameter declarations with literal 
> C code forming an array of [parameter kind, 
> array-of-setup-instructions-and-or-magically-named-variable-settings]

Regarding the DSL: I wanted to change the syntax, not the functionality.
Unfortunately, as Antoine pointed out, I didn't get it quite right.

(2b): Perhaps I misunderstand, but the snippets of literal C code are also
present in Larry's original:

/*[clinic]
os.stat -> stat result

path_t path = PATH_T_INITIALIZE("stat", 0, 1);
required
converter=path_converter

int dir_fd = DEFAULT_DIR_FD;
default=None
converter=OS_STAT_DIR_FD_CONVERTER
keyword-only

int follow_symlinks = 1;
default=True
types=bool
[clinic]*/

The motivation for trying to change the DSL is that I'd like to see
a) something that looks more like a C declaration, b) something that
is easily compressible vertically and c) some visual hints that
subdivide the declaration into sections.

--

___
Python tracker 

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

[issue1285086] urllib.quote is too slow

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Proposed patches not only get rid of the refcount hack, but make unquote() and 
unquote_to_bytes() even significant faster for large strings.

--
nosy: +serhiy.storchaka
Added file: http://bugs.python.org/file29064/urllib_faster_unquote.patch

___
Python tracker 

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

[issue1285086] urllib.quote is too slow

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
stage: needs patch -> patch review
versions: +Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29065/urllib_faster_unquote-2.7.patch

___
Python tracker 

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

[issue16743] mmap on Windows can mishandle files larger than sys.maxsize

[Richard Oudkerk]

Changes by Richard Oudkerk :


--
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits

[Antoine Pitrou]

Antoine Pitrou added the comment:

Shouldn't you try to make the permission removal atomic? Otherwise there's a 
window of opportunity to exploit the suid bit.

--
nosy: +pitrou

___
Python tracker 

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

[issue17201] Use allowZip64=True by default

[William Mallard]

William Mallard added the comment:

Enabling ZIP64 seems like a reasonable default.

The documentation justifies the current 32-bit default with outdated 
information:
"""
ZIP64 extensions are disabled by default because the default 'zip' and 'unzip' 
commands on Unix (the InfoZIP utilities) don't support these extensions.
"""

But InfoZIP has supported the ZIP64 extension for 4 years (since UnZip 6.0, and 
Zip 3.0).

--
nosy: +william.mallard

___
Python tracker 

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

[issue2175] Expat sax parser silently ignores the InputSource protocol

[Fred L. Drake, Jr.]

Changes by Fred L. Drake, Jr. :


--
nosy: +fdrake

___
Python tracker 

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

[issue16692] Support TLS 1.1 and TLS 1.2

[Michele Orrù]

Changes by Michele Orrù :


Added file: http://bugs.python.org/file29066/issue16692.1.patch

___
Python tracker 

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

[issue16692] Support TLS 1.1 and TLS 1.2

[Éric Araujo]

Changes by Éric Araujo :


--
nosy:  -eric.araujo

___
Python tracker 

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

[issue17179] Incorrect use of type function in types.new_class

[Chris Withers]

Chris Withers added the comment:

Eric, surely this is a bugfix candidate for 3.3.1?

--

___
Python tracker 

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

[issue17179] Incorrect use of type function in types.new_class

[Éric Araujo]

Changes by Éric Araujo :


--
keywords: +easy
nosy: +eric.araujo
stage:  -> needs patch
title: TypeError: type() takes 1 or 3 arguments -> Incorrect use of type 
function in types.new_class
versions: +Python 3.4

___
Python tracker 

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

[issue17179] Incorrect use of type function in types.new_class

[Éric Araujo]

Éric Araujo added the comment:

> I'm guessing ns and kwds should be combined before being passed through to 
> meta?
Possibly; can you try that?

> surely this is a bugfix candidate for 3.3.1?
If we get a patch with a test in time, otherwise 3.3.2.

--

___
Python tracker 

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

[issue17192] libffi-3.0.12 import

[Éric Araujo]

Éric Araujo added the comment:

Sound like a large change for stable releases.  Usually we would not do that.

--
nosy: +eric.araujo

___
Python tracker 

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

[issue16612] Integrate "Argument Clinic" specialized preprocessor into CPython trunk

[Nick Coghlan]

Nick Coghlan added the comment:

Stefan, would you be willing to write up your version as a PEP? (FWIW, I
personally favour your suggested C'ish style for the preprocessor, since my
brain would be in that mode anyway when hacking on C code)

--
title: Integrate "Argument Clinic" specialized preprocessor into CPython 
trunk -> Integrate "Argument Clinic" specialized preprocessor into CPython trunk

___
Python tracker 

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

[issue17198] dbm.whichdbm references non-existent 'ndbm'

[Éric Araujo]

Changes by Éric Araujo :


--
keywords: +easy
nosy: +eric.araujo

___
Python tracker 

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

[issue15220] Reduce parsing overhead in email.feedparser.BufferedSubFile

[R. David Murray]

Changes by R. David Murray :


--
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue17198] dbm.whichdbm references non-existent 'ndbm'

[R. David Murray]

R. David Murray added the comment:

The code appears to be correct, but I think we need to add an explicit import 
for ndbm in the __init__ file.  Right now I think it is only passing the tests 
because the test infrastructure imports all the dbm modules, including ndbm.

(I did not realize that doing 'import X.abc' causes 'abc' to be defined in the 
X.__init__.py module's namespace, but of course it must once I thought about 
it.)

The tricky bit here is writing a test case :)

--
nosy: +r.david.murray
stage: needs patch -> 

___
Python tracker 

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

[issue17198] dbm.whichdb references unitialized 'ndbm' variable

[R. David Murray]

R. David Murray added the comment:

By the way, this will demonstrate the bug:

  touch foo.pag
  python -m dbm.__init__ foo

Perhaps that could be the basis for the test (using subprocess).

--
stage:  -> needs patch
title: dbm.whichdbm references non-existent 'ndbm' -> dbm.whichdb references 
unitialized 'ndbm' variable

___
Python tracker 

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

[issue17198] dbm.whichdb references unitialized 'ndbm' variable

[R. David Murray]

R. David Murray added the comment:

Well, that test works only on 3.2/3.3, because by 3.4 the ndbm variable is only 
referenced in the second try; make it 'touch foo.db' instead for 3.4.

--

___
Python tracker 

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

[issue15220] Reduce parsing overhead in email.feedparser.BufferedSubFile

[Roundup Robot]

Roundup Robot added the comment:

New changeset 0f827775f7b7 by R David Murray in branch 'default':
#15220: simplify and speed up feedparser's line splitting.
http://hg.python.org/cpython/rev/0f827775f7b7

--
nosy: +python-dev

___
Python tracker 

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

[issue17145] memoryview(array.array)

[Demian Brecht]

Demian Brecht added the comment:

I've given this some more thought and quite a bit more work and reorganization. 
I think this clarifies the usage of memoryviews and buffers as well as the 
C-level API for each.

This is my first run at contributing a patch of any sort, so please let me know 
if there's anything further needed or any changes are required (or I'm just 
right out to lunch with this).

--
Added file: http://bugs.python.org/file29067/buffer.patch

___
Python tracker 

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

[issue9822] windows batch files are dependent on cmd current directory

[Zachary Ware]

Zachary Ware added the comment:

I just stumbled across this issue in looking for another issue, and this turns 
out to be of interest to me as well.  As such, I've updated sorin's patch to 
apply to the current default branch, added the same kind of change to the 
new-since-then clean-amd64.bat, and fixed a bug in the initial patch to 
external-common.bat--it had been doing 'cd /D "%~dp0\.."' instead of 
"%~dp0\..\..\..".  It also looks like my editor stripped some trailing 
whitespace in a couple of files.

A much larger change that I made was to switch to using pushd/popd to make the 
initial dir change, and to return to the calling dir.  It strikes me as good 
practice not to change directory without warning simply by calling a batch 
file.  Alternately, things could be switched back to cd /D instead of pushd, 
and switch popd to "echo Leaving you in %CD%..." just to give some notice of 
the change.

I can't test whether the change would affect the buildbots, but it doesn't look 
like it should.  I have tested calling each file from several locations, 
including the root of the source tree, and everything seems to work as expected.

I will also be attaching a patch that also moves external*.bat into PCbuild as 
Martin suggested, as that does seem a more natural place for them.

--
components: +Windows
nosy: +zach.ware
versions: +Python 3.4 -Python 3.2
Added file: http://bugs.python.org/file29068/issue9822.v2.diff

___
Python tracker 

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

[issue16278] os.rename documentation slightly inaccurate

[Terry J. Reedy]

Terry J. Reedy added the comment:

"directory name.Yet a" needs spaces after '.'.

The text is decent English and clear enough sentence by sentence, but the 
reality and hence the text as a whole is confusing.

I wonder if it would be possible to make a little table

dest
   
Src file empty-dirnon-empty-dir
-
file |||

dir

with the behavior for each combination indicated, 'success' or 'OSError', with 
two lines prefixed with Unix, Win where they differ. Then the differences would 
be much more obvious.

(A separate issue: Patch says that Windows currently raises a different error 
in one situation. I think it would be better -- in a future version -- if that 
were caught and reraised as OSError also.)

--

___
Python tracker 

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

[issue9822] windows batch files are dependent on cmd current directory

[Zachary Ware]

Zachary Ware added the comment:

Here's the patch that moves external*.bat into PCbuild.  I also took the 
opportunity to give the three files more descriptive names: external.bat -> 
get_externals.bat, external-common.bat -> get_common_externals.bat, and 
external-amd64.bat -> get_externals-amd64.bat.  I'm pretty sure I got all 
references to them; I know I got everything in PCbuild\readme.txt and in the 
Tools\buildbot scripts.

As an aside, it seems like my last message caused my avast! to freak out about 
and refuse to load this page, calling it an HTML:Script-inf virus.  My 
apologies if anyone else is similarly affected.

--
Added file: http://bugs.python.org/file29069/issue9822.v3.diff

___
Python tracker 

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

[issue17200] telnetlib.read_until() timeout uses the wrong units

[Reuben D'Netto]

Reuben D'Netto added the comment:

Sure, no problem. I'll upload the completed patch once I've got it working.

--

___
Python tracker 

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

[issue17202] Add .bat line to .hgeol

[Zachary Ware]

New submission from Zachary Ware:

Most times (though not all, for some reason) I try to use Doc\make.bat update, 
it fails with "The system cannot find the batch label specified - update" even 
though it is obviously there.  The reason for this appears to be the fact that 
the file uses UNIX line endings[1].  As a fix, I think it would make the most 
sense to add a "**.bat = CRLF" line to .hgeol.

The attached patch makes that change and includes the changes that that change 
entails.  The complete list of affected files is as follows:

Doc\make.bat
Lib\ctypes\macholib\fetch_macholib.bat
Lib\idlelib\idle.bat
Modules\_decimal\tests\runall.bat
PCbuild\build.bat
PCbuild\build_env.bat
PCbuild\build_pgo.bat
PCbuild\build_ssl.bat
PCbuild\env.bat
PCbuild\idle.bat
PCbuild\rt.bat
Tools\buildbot\build-amd64.bat
Tools\buildbot\build.bat
Tools\buildbot\buildmsi.bat
Tools\buildbot\clean-amd64.bat
Tools\buildbot\clean.bat
Tools\buildbot\external-amd64.bat
Tools\buildbot\external-common.bat
Tools\buildbot\external.bat
Tools\buildbot\test-amd64.bat
Tools\buildbot\test.bat
Tools\unicode\genwincodecs.bat

As far as I know, there is no reason to believe that the changes to line 
endings in these files would cause any change to behavior other than possibly 
avoid strange and random bugs in their execution, particularly in Doc\make.bat.

If we don't want to a blanket rule like this, I think we should at least add a 
rule for Doc\make.bat to convert it to CRLF line endings to avoid the bug with 
:update.

Thanks,

Zach

[1] 
http://stackoverflow.com/questions/232651/why-the-system-cannot-find-the-batch-label-specified-is-thrown-even-if-label-e/232674#232674

--
components: Windows
files: batch_eol_fix.diff
keywords: patch
messages: 182077
nosy: brian.curtin, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Add .bat line to .hgeol
versions: Python 3.4
Added file: http://bugs.python.org/file29070/batch_eol_fix.diff

___
Python tracker 

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

[issue17203] add long option names to unittest discovery docs

[Chris Jerdonek]

New submission from Chris Jerdonek:

Currently, unittest's discovery command-line documentation:

http://docs.python.org/dev/library/unittest.html#test-discovery

does not include the long option names (--start-directory, --pattern, and 
--top-level-directory):

http://hg.python.org/cpython/file/0f827775f7b7/Lib/unittest/main.py#l215

This issue is to add those.

--
assignee: docs@python
components: Documentation
keywords: easy
messages: 182078
nosy: chris.jerdonek, docs@python, ezio.melotti, michael.foord
priority: normal
severity: normal
stage: needs patch
status: open
title: add long option names to unittest discovery docs
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

___
Python tracker 

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