[issue11734] Add half-float (16-bit) support to struct module

[Eli Stevens]

Eli Stevens  added the comment:

More questions:

The current _PyFloat_Pack4 doesn't round to even:

fbits = (unsigned int)(f + 0.5); /* Round */

Is the mismatch going to be a problem?  Should I change the _PyFloat_Pack4 
implementation while I'm in there?

--

___
Python tracker 

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

[issue11725] httplib and urllib2 failed ssl connection httplib.BadStatusLine

[Ronald Oussoren]

Ronald Oussoren  added the comment:

Ned: we could work around this platform issue by including openssl 1.0d in the 
OSX installer.  I'm not sure if that's acceptable for a bugfix release though.

--

___
Python tracker 

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

[issue11747] unified_diff function product incorrect range information

[ysj.ray]

ysj.ray  added the comment:

Since if one of the two comparing files is empty, gnu diff regards the 
beginning line of differences as line 0 (there is not any lines), but difflib 
regards it as line 1(there is a line, but empty). Not sure weather is correct 
since the practice usage of diff output is feeding it to "patch" program which 
determine the different line location mostly based on context identical lines 
instead of the line numbers in the hunk headers, so it doesn't matter weather 
it's line 0 or line 1. But it is still better to keep consist with gnu diff.

In context_diff() it is correct since if there is less then 2 different lines 
in a hunk, only ending line number is display in hunk header.

Here is a patch which fix this.

--
keywords: +patch
nosy: +ysj.ray
type:  -> behavior
versions: +Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21539/issue_11747.diff

___
Python tracker 

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

[issue11764] inspect.getattr_static code execution w/ class body as non dict

[ysj.ray]

Changes by ysj.ray :


--
nosy: +ysj.ray

___
Python tracker 

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

[issue2736] datetime needs an "epoch" method

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Just to add another data point to this discussion:

mxDateTime, which in large parts inspired the Python datetime module,
has had a .ticks() method (for local time) and a .gmticks() method
(for UTC) for more than a decade now and so far, I haven't seen a
single complaint about any of the issues raised in this discussion.

The methods naturally return the Unix ticks value as float,
since that's what the time module uses as basis and the whole purpose
of those methods is to make interaction with the time module easy
and straight-forward. Likewise, the epoch is also the same as the time
module's one.

Victor's patch could easily be updated to return floats as well,
to make it compatible with the time module.

There's only one catch that Victor's patch doesn't include: mktime()
doesn't always work with DST set to anything but -1. mxDateTime
checks the API at module load time and then determines whether
it can be used with a DST setting or not (see the mxDateTime code
for details). Not sure whether today's mktime() implementations
still have any issues with this, but it's better to double-check
than to get wrong results.

http://www.egenix.com/products/python/mxBase/mxDateTime/

--
nosy: +lemburg

___
Python tracker 

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

[issue2736] datetime needs an "epoch" method

[STINNER Victor]

STINNER Victor  added the comment:

Marc, could you maybe write a new patching taking care of the DST and
maybe also the timezone? It looks like you have a long experience in
timestamps :-)

--

___
Python tracker 

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

[issue11703] Bug in python >= 2.7 with urllib2 fragment

[Andrew Svetlov]

Changes by Andrew Svetlov :


--
nosy: +asvetlov

___
Python tracker 

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

[issue11707] Create C version of functools.cmp_to_key()

[Roundup Robot]

Roundup Robot  added the comment:

New changeset a03fb2fc3ed8 by Raymond Hettinger in branch 'default':
Issue #11707: Fast C version of functools.cmp_to_key()
http://hg.python.org/cpython/rev/a03fb2fc3ed8

--
nosy: +python-dev

___
Python tracker 

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

[issue2736] datetime needs an "epoch" method

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

STINNER Victor wrote:
> 
> STINNER Victor  added the comment:
> 
> Marc, could you maybe write a new patching taking care of the DST and
> maybe also the timezone? It looks like you have a long experience in
> timestamps :-)

Sorry, but no. I'm not really a fan of the datetime module and
try to stay away from it whenever I can :-)

Note that dealing with DST in timezones other than the local time
zone, is bound to go wrong without direct access to the tz library.
The C lib doesn't provide any good way to access timezone
information other than the local timezone or UTC.

When dealing with date/time values, it is usually best to stay with
UTC and only transform those values into local times in user
interfaces on the front-end client.

Consequently, I'd suggest to only allow UTC and local timezone
conversions for the method in the datetime module.

--

___
Python tracker 

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

[issue11707] Create C version of functools.cmp_to_key()

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Thanks for the patch Filip.

Closing this.  If anyone wants to lobby the RM for a 3.2 backport, feel free to 
re-open and assign to the release manager for consideration.

--
status: open -> closed

___
Python tracker 

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

[issue11734] Add half-float (16-bit) support to struct module

[Eli Stevens]

Eli Stevens  added the comment:

Made the _PyFloat_Pack2 match the algo in _PyFloat_Pack4, and did similar for 
Unpack.  This should work on platforms that don't have IEEE 754 floats except 
for situations where an INF or NAN is unpacked (this is the same as the Unpack4 
behavior).

This also gets rid of any need for #ifdef'd code (an ad-hoc speed test showed 
no noticeable difference between the numpy-based version and the CPython-based 
version of the functions).

I've also added a bit of documentation to this version, as well as more tests.

I haven't changed anything about the native_table entry or Pack4's 
non-round-to-even behavior.

--
Added file: http://bugs.python.org/file21540/cpython-struct-float16-v4.patch

___
Python tracker 

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

[issue11707] Create C version of functools.cmp_to_key()

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 76ed6a061ebe by Victor Stinner in branch 'default':
Issue #11707: Fix compilation errors with Visual Studio
http://hg.python.org/cpython/rev/76ed6a061ebe

--

___
Python tracker 

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

[issue11707] Create C version of functools.cmp_to_key()

[STINNER Victor]

STINNER Victor  added the comment:

functools_cmp_to_key() doesn't check that the argument is a callable.

>>> table=list(range(3))
>>> table.sort(key=functools.cmp_to_key(3))
Traceback (most recent call last):
  File "", line 1, in 
TypeError: 'int' object is not callable

PyCallable_Check() should be used, something like:

if (!PyCallable_Check(cmp)) {
PyErr_SetString(PyExc_TypeError, "parameter must be callable");
return NULL;
}

--
nosy: +haypo

___
Python tracker 

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

[issue11766] test_multiprocessing failure (test_pool_worker_lifetime)

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

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

[issue11707] Create C version of functools.cmp_to_key()

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> functools_cmp_to_key() doesn't 
> check that the argument is a callable.

I don't think that is necessary; it will fail with a TypeError when the attempt 
is made to call it.  This is the approach we take elsewhere (look at the 
built-in filter() function for example).

That being said, if you really think the early check is necessary, feel free to 
check it in.

--

___
Python tracker 

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

[issue11277] test_zlib.test_big_buffer crashes under BSD (Mac OS X and FreeBSD)

[STINNER Victor]

Changes by STINNER Victor :


--
title: test_zlib crashes under Snow Leopard buildbot -> 
test_zlib.test_big_buffer crashes under BSD (Mac OS X and FreeBSD)

___
Python tracker 

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

[issue11757] test_subprocess.test_communicate_timeout_large_ouput failure on select(): negative timeout?

[STINNER Victor]

Changes by STINNER Victor :


--
title: test_subprocess failure -> 
test_subprocess.test_communicate_timeout_large_ouput failure on select(): 
negative timeout?

___
Python tracker 

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

[issue11770] inspect.dir_static

[Michael Foord]

New submission from Michael Foord :

A version of dir that returns all the members that can be seen by 
getattr_static.

--
assignee: michael.foord
components: Library (Lib)
messages: 133017
nosy: michael.foord
priority: low
severity: normal
stage: needs patch
status: open
title: inspect.dir_static
type: behavior
versions: Python 3.3

___
Python tracker 

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

[issue11757] test_subprocess.test_communicate_timeout_large_ouput failure on select(): negative timeout?

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 3664fc29e867 by Victor Stinner in branch 'default':
Issue #11757: subprocess ensures that select() and poll() timeout >= 0
http://hg.python.org/cpython/rev/3664fc29e867

--
nosy: +python-dev

___
Python tracker 

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

[issue9390] Error in sys.excepthook on windows when redirecting output of the script

[Michal Molhanec]

Michal Molhanec  added the comment:

I've got the same problem with 2.7.1 (both 32bit and 64bit versions) under W7 
SP1 64bit. Under WXP SP3 32bit it works OK. What's worse the output file is 
empty.

3.2 (tested 64bit version) behaves even worse -- it does not print the error 
like 2.7 but the resulting file is empty as well!

--
nosy: +Michal.Molhanec

___
Python tracker 

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

[issue1692335] Fix exception pickling: Move initial args assignment to BaseException.__new__

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

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

[issue11734] Add half-float (16-bit) support to struct module

[Mark Dickinson]

Mark Dickinson  added the comment:

> There's no disagreement, since they're different cases. [...]

What he said.

> Should I change the _PyFloat_Pack4 implementation while I'm in there?

No;  let's keep the patch as simple as possible.  We can open a separate issue 
for fixing _Pack4 if necessary.  Is the failure to round-to-even only for 
legacy formats, or is it for IEEE formats as well?  If the former, it's 
difficult to care much;  if the latter, it should definitely be fixed, but not 
as part of this issue.

> Made the _PyFloat_Pack2 match the algo in _PyFloat_Pack4, and did
> similar for Unpack.

Thanks;  haven't looked at the new patch yet, but hope to do so in the next few 
days.

--

___
Python tracker 

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

[issue11771] hashlib object cannot be pickled

[STINNER Victor]

New submission from STINNER Victor :

$ ./python 
Python 3.3a0 (default:76ed6a061ebe, Apr  5 2011, 12:25:00) 
>>> import hashlib, pickle
>>> hash=hashlib.new('md5')
>>> pickle.dumps(hash)
Traceback (most recent call last):
  File "", line 1, in 
_pickle.PicklingError: Can't pickle : attribute lookup 
_hashlib.HASH failed

The problem is that _hashlib.HASH is not accessible at Python level. There is a 
C define to make it accessible, but it is disabled by default: "#if 
HASH_OBJ_CONSTRUCTOR". This test is as old as the _hashlib module (#1121611, 
624918e1c1b2).

--
components: Library (Lib)
messages: 133021
nosy: haypo
priority: normal
severity: normal
status: open
title: hashlib object cannot be pickled
versions: Python 3.3

___
Python tracker 

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

[issue11605] EMail generator.flatten() disintegrates over non-ascii multipart/alternative

[ysj.ray]

Changes by ysj.ray :


--
nosy: +ysj.ray

___
Python tracker 

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

[issue11771] hashlib object cannot be pickled

[STINNER Victor]

STINNER Victor  added the comment:

Oh, I don't know if it is possible to serialize a OpenSSL hash object 
(EVP_MD_CTX)...

--

___
Python tracker 

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

[issue9592] Limitations in objects returned by multiprocessing Pool

[STINNER Victor]

STINNER Victor  added the comment:

> 1) A multiprocessing worker can not return (return, not raise!) an
> Exception. (...) raise an error if multiple arguments are required:
> TypeError: ('__init__() takes exactly 2 arguments (1 given)', 
> , ())

This problem comes from pickle, not multiprocessing: issue #1692335.

> 2) A multiprocessing worker can not return an hashlib Object.
> If this is attempted, pickle returns an error:

It is related to pickle and hashlib: #11771

--

___
Python tracker 

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

[issue11734] Add half-float (16-bit) support to struct module

[Mark Dickinson]

Mark Dickinson  added the comment:

> Is the failure to round-to-even only for legacy formats, or is it for
> IEEE formats as well?

Ah;  I see it's just for the non-IEEE formats, so not really an issue.  When 
the float format is known, the code just depends on a (float) cast doing the 
right thing, which it generally will.

--

___
Python tracker 

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

[issue11734] Add half-float (16-bit) support to struct module

[Mark Dickinson]

Mark Dickinson  added the comment:

> I'd also suggest adding some more to the test suite here to verify that > 
> ties are rounding to the nearest even properly.

And I second this suggestion.

--

___
Python tracker 

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

[issue10977] Concrete object C API needs abstract path for subclasses of builtin types

[Nick Coghlan]

Nick Coghlan  added the comment:

I may have found another use case for this functionality. Currently, the Python 
code in heapq.py accepts arbitrary sequences (that are sufficiently compatible 
with the Sequence ABC), but the C code in _heapq only permits use of a concrete 
list.

The two currently available approaches to address that discrepancy are:
1. Use PyObject_* calls instead of PyList_* calls throughout the code (yuck, 
we'd be making the common case significantly worse in the name of semantic 
purity)
2. Sprinkle type checks throughout the _heapq code to decide whether or not to 
call the concrete APIs or their abstract equivalents

The extensive use of the PyList macro API in _heapq means that a little bit of 
2 might still be necessary even if the concrete API was updated as Raymond 
suggests, but I think there would be value in changing the meaning of the 
concrete APIs to include falling back to the abstract APIs if the type 
assumption is incorrect.

--

___
Python tracker 

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

[issue10977] Concrete object C API needs abstract path for subclasses of builtin types

[Nick Coghlan]

Nick Coghlan  added the comment:

I added a few commments on Daniel's draft patch. However, I'm getting nervous 
about the performance impact of all these extra pointer comparisons.

We should probably hold off on this until more of the macro benchmark suite 
runs on Py3k so we can get as hint as to the possible speed impact on real 
application code.

--

___
Python tracker 

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

[issue975330] Inconsistent newline handling in email module

[R. David Murray]

R. David Murray  added the comment:

Well, it's two years later, but I did look at this during the sprints at PyCon, 
though I didn't get as far as posting it then (I only just now rediscovered the 
patch on my laptop).

Python3 no longer has a "binary" flag on base64mime.encode, so here is a 
proposed patch for Python3.  I'm not sure if this should be backported or not, 
but I'm leaning that way.  Theoretically it should be only an improvement, but 
I can easily imagine unix-only programs unknowingly depending on the previous 
non-translation of newlines.  Still, since email is about intermachine 
communication and this clearly makes it more RFC compliant, the change is a 
legitimate bug fix and the chance of breakage is relatively small.

Tests are still needed.

--
Added file: http://bugs.python.org/file21541/crlf-body-encode.patch

___
Python tracker 

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

[issue11772] email header wrapping edge case failure

[R. David Murray]

New submission from R. David Murray :

I discovered the attached failure case in the process of investigating another 
issue.  The bug (a continuation line with no leading white space) doesn't exist 
in 2.7, but in 2.7 the extra whitespace is not preserved (that is, the output 
of the new test looks just like the output of the Face2 test), which is 
consistent with email4's handling of header whitespace in general.

--
assignee: r.david.murray
components: Library (Lib)
files: test_email_extra_test.patch
keywords: patch
messages: 133029
nosy: r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: email header wrapping edge case failure
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21542/test_email_extra_test.patch

___
Python tracker 

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

[issue11771] hashlib object cannot be pickled

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Why on Earth would you want to serialize a hashlib object?
It makes as much sense as serializing, say, a JSONEncoder.

--
nosy: +gregory.p.smith, pitrou

___
Python tracker 

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

[issue11767] Maildir iterator leaks file descriptors by default

[Antoine Pitrou]

Changes by Antoine Pitrou :


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

[issue10963] "subprocess" can raise OSError (EPIPE) when communicating with short-lived processes

[Roundup Robot]

Roundup Robot  added the comment:

New changeset c10d55c51d81 by Ross Lagerwall in branch '2.7':
Issue #10963: Ensure that subprocess.communicate() never raises EPIPE.
http://hg.python.org/cpython/rev/c10d55c51d81

New changeset 158495d49f58 by Ross Lagerwall in branch '3.1':
Issue #10963: Ensure that subprocess.communicate() never raises EPIPE.
http://hg.python.org/cpython/rev/158495d49f58

--
nosy: +python-dev

___
Python tracker 

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

[issue10977] Concrete object C API needs abstract path for subclasses of builtin types

[Benjamin Peterson]

Benjamin Peterson  added the comment:

I find this extremely ugly. The correct way to handle this is to use the 
generic methods themselves. Really, the type-specific names should only be used 
when you have just created the type or done PyXXX_CheckExact() yourself on it.

--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue10963] "subprocess" can raise OSError (EPIPE) when communicating with short-lived processes

[Ross Lagerwall]

Ross Lagerwall  added the comment:

Committed, thanks.

--
assignee:  -> rosslagerwall
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
type: feature request -> behavior

___
Python tracker 

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

[issue11652] urlib{, 2} returns a pair of integers as the content-length value

[James Whisnant]

James Whisnant  added the comment:

Varnish on the sourceforge server has been upgraded and/or reconfigured 
(yesterday) to fix the issue that was happening with this file (and others).

Just an FYI that you will no longer be able to re-create the triggering error.

'content-length': '289519',
'via': '1.1 varnish'

--
nosy: +jwhisnant

___
Python tracker 

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

[issue6040] bdist_msi does not deal with pre-release version

[anatoly techtonik]

anatoly techtonik  added the comment:

Metadata can be automatically figured out using regexp matching like 
^\d+(\.\d+){2,3}, but for explicit handling there should be should some 
callback or msi-specific version property in metadata. In the end it is pretty 
logical if binary distribution process can be configured using distribution 
specific (bdist_* specific) properties.

In the meanwhile here is the workaround:
{{{

from distutils.command.bdist_msi import bdist_msi

class bdist_msi_version_hack(bdist_msi):
""" bdist_msi requires version to be in x.x.x format
because it is embedded into MSI
"""
def run(self):
# strip suffix from version, i.e. from 11.0.0+r3443
saved = self.distribution.metadata.version
self.distribution.metadata.version = saved.split('+')[0]
bdist_msi.run(self)
saved_version = self.distribution.metadata.version

setup(
...
cmdclass={'bdist_msi': bdist_msi_version_hack},
)
}}}

--

___
Python tracker 

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

[issue6040] bdist_msi does not deal with pre-release version

[anatoly techtonik]

anatoly techtonik  added the comment:

Wrong code. The last line in the bdist_msi_version_hack override should be:

  self.distribution.metadata.version = saved

--

___
Python tracker 

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

[issue2736] datetime needs an "epoch" method

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

On Tue, Apr 5, 2011 at 4:33 AM, Marc-Andre Lemburg
 wrote:
..
> mxDateTime, which in large parts inspired the Python datetime module,
> has had a .ticks() method (for local time) and a .gmticks() method
> (for UTC) for more than a decade now

Yes, mxDateTime's gmticks()/ticks() pair of functions present a much
more mature design than anything that has been proposed here.  It is
telling, however, that no one has mentioned mxDateTime's gmticks() on
this issue in four years.  On a duplicate issue 1673409, Marc did
bring it up, but as far as I can tell, no one responded.  See
msg75411.

Google code search,

http://www.google.com/codesearch?hl=en&sa=N&q=gmticks+lang:python

returns only 13 hits for "gmticks".  In several instances, the
resulting float is immediately converted to int, in other instances
"gmticks" is mentioned in comments and the code works around its bugs.

I would not use Google Code search as an ultimate arbiter on the
popularity of a feature, so I would really like to hear from the
proponents about real life uses of gmticks() or any other examples
where a similar method "has been reimplemented over and over again."

> so far, I haven't seen a single complaint about any of the issues raised in 
> this discussion.

Well, search for gmticks does not return too many hits outside of
mxDateTime code and manuals, but I had no trouble finding this:

"""
 okay, all the MySQLdb dataobject tick-based time handling methods are
  broken in various ways -- reconstruct GMT ticks from time module's
  mktime...
"""
http://viewvc.tigris.org/ds/viewMessage.do?dsForumId=4251&dsMessageId=656863

Follow the link for some more colorful language describing developer's
experience with the feature.

Note that it is likely that the bug MySQLdb developer complained about
was fixed in mxDateTime at some point,
, but
this shows that implementing gmticks() correctly is not as trivial as
those who never tried might think.

>
> The methods naturally return the Unix ticks value as float,
> since that's what the time module uses as basis

Which in turn is a mistake IMO.  Note that POSIX does not use float
timestamps for a reason.

> and the whole purpose
> of those methods is to make interaction with the time module easy
> and straight-forward.

This is not the goal that I would support.  I would rather see code
that uses datetime module not require time module methods at all.

> Victor's patch could easily be updated to return floats as well,
> to make it compatible with the time module.
>

Victor reported implementing two methods, one to return a float and
another to return a tuple. See msg124259.  I am not sure I've seen
that code.

> There's only one catch that Victor's patch doesn't include ...

No, it is not  about "only one catch". Victor's patch is simply wrong.
 For an aware datetime instance it extracts DST flag from tzinfo, but
ignores the offset.

--

___
Python tracker 

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

[issue11773] Unicode compared using "is" results in abnormal behavior

[Abhijeet Rastogi]

New submission from Abhijeet Rastogi :

>>> a = u'0'
>>> a is u'0'
False
>>> a == u'0'
True
>>>

--
components: Unicode
messages: 133038
nosy: shadyabhi
priority: normal
severity: normal
status: open
title: Unicode compared using "is" results in abnormal behavior
type: behavior
versions: Python 2.7

___
Python tracker 

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

[issue2736] datetime needs an "epoch" method

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

MAL> Since most of the datetime module was inspired by mxDateTime,
MAL> I wonder why [ticks()/gmticks()] were left out. (msg75411)

"""
The datetime module intended to be an island of relative sanity.
Because the range of dates "timestamps" can represent varies across
platforms (and even "the epoch" varies), datetime doesn't even try to
produce timestamps directly -- datetime is more of an alternative to
"seconds from the epoch" schemes. Because datetime objects have
greater range and precision than timestamps, conversion is
problem-free in only one direction. It's not a coincidence that
that's the only direction datetime supplies ;-)
""" - Tim Peters
 
http://bytes.com/topic/python/answers/522572-datetime-timestamp

I will also add that fromtimestamp() is not invertible in the presence of DST.  
That's why mxDatetime.ticks() takes a DST flag making it effectively a 
multi-valued function.  Note that naive users, who just want to pass datetime 
values to an OS function expecting a float, most likely will not have means of 
properly obtaining DST flag.

--

___
Python tracker 

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

[issue11773] Unicode compared using "is" results in abnormal behavior

[Ezio Melotti]

Ezio Melotti  added the comment:

The fact that "is" works in this way here is just an implementation detail.  If 
you want to compare strings use ==, "is" is used to verify if two variables 
refer to the same object or not.

>>> x = 100
>>> x is 100
True
>>> x = 1000
>>> x is 1000
False

--
nosy: +ezio.melotti
resolution:  -> invalid
stage:  -> 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

[issue11605] EMail generator.flatten() disintegrates over non-ascii multipart/alternative

[Steffen Daode Nurpmeso]

Steffen Daode Nurpmeso  added the comment:

ysj.ray, this rude workaround manages it yet for me
(self._msg is a BytesParser() generated Message):


if not self._msg.is_multipart():
return
topmost = True
for part in self._msg.walk():
if topmost:
topmost = False
continue
ct = part.get_content_type()
if not ct.startswith('text'):
continue

try:
payload = part.get_payload()
charset = part.get_param('charset')
if charset is not None:
del part['content-transfer-encoding']
part.set_payload(payload, charset)
except:


Note you can't simply use encoders because those break
on byte messages.
(But it would be cool if you see quopri and base64 fail
and open issues for that!)

Have fun,
Steffen

--

___
Python tracker 

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

[issue11605] EMail generator.flatten() disintegrates over non-ascii multipart/alternative

[R. David Murray]

R. David Murray  added the comment:

I'm working on this.  It appears to be a bug in the bytes parser, rather than 
the generator.

--

___
Python tracker 

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

[issue1596321] KeyError at exit after 'import threading' in other thread

[hasenpfeffer]

hasenpfeffer  added the comment:

I encountered this issue recently in Python 3.2 and wanted to make some 
observations about it.

The real problem here is not the KeyError.  Though the suggested patches would 
fix the KeyError symptom, they do not fix the underlying issue.  The underlying 
issue is the threading module assumes that it is imported from the Python main 
thread.  When alien threads exist, the threading module may be imported 
(directly or indirectly) from a thread that is not the Python main thread, 
causing the wrong thread to be marked as the Python main thread.

The resulting problems of the wrong thread being marked as the Python main 
thread appear to be minor.  The KeyError at exit is one of them.  Another 
problem I encountered was with confusion in a threaded debugger that displayed 
my alien thread as the Python main thread, and the Python main thread as the 
alien thread.

In my project I can easily work around this by importing the threading module 
in a root package that is extremely likely to be imported from the Python main 
thread, causing the correct thread to be marked as the main thread.

Since I have a workaround for my project, in addition to the relatively minor 
issues that result from this behavior, I haven't spent any time looking into 
how to fix the underlying issue.  If I have the time, I'll suggest one.

--
nosy: +hasenpfeffer
versions: +Python 2.7, Python 3.2 -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

[issue11605] EMail generator.flatten() disintegrates over non-ascii multipart/alternative

[R. David Murray]

R. David Murray  added the comment:

Although there's a (different) bug in the generator, too, I think :)

--

___
Python tracker 

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

[issue4112] Subprocess: Popen'ed children hang due to open pipes

[Ross Lagerwall]

Ross Lagerwall  added the comment:

This has been fixed with all the subprocess improvements in between 3.1 and 3.2 
but the decision has been taken (msg125910) not to backport the fix to 3.1 and 
2.7 which would involve a C extension.

However, a workaround on 2.7 and 3.1 is to set close_fds=True.

Closing as "wont fix".

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

___
Python tracker 

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

[issue2320] Race condition in subprocess using stdin

[Ross Lagerwall]

Ross Lagerwall  added the comment:

Closing this as fixed since it has been fixed on 3.2 and decided not to be 
backported on 3.1 and 2.7.

--
nosy: +rosslagerwall
resolution: out of date -> fixed
status: open -> closed

___
Python tracker 

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

[issue9840] Recursive Repr

[Éric Araujo]

Éric Araujo  added the comment:

FTR, the answer to my interrogation in my previous message is contained in 
Raymond’s PyCon talk about API design: http://pycon.blip.tv/file/4883290/ :)

--

___
Python tracker 

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

[issue7101] tarfile: OSError with TarFile.add(..., recursive=True) about non-existing file

[Lars Gustäbel]

Lars Gustäbel  added the comment:

I kept this issue open, because I have not yet come to a decision. I don't 
think the current behaviour is a bug, but these kinds of errors could be 
handled more intelligently.
For example, errors during extraction can be hidden depending on the 
TarFile.errorlevel attribute. Something similar could be done for creation of 
archives. What exactly, I don't know... I have not yet managed to make up my 
mind.

--

___
Python tracker 

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

[issue6040] bdist_msi does not deal with pre-release version

[anatoly techtonik]

anatoly techtonik  added the comment:

The above workaround still doesn't isolate version modification to bdist_msi 
command, because bdist_msi is calling `build` and `install` targets before 
doing its own stuff.

Any ideas how to override version for MSI without copying while `bdist_msi` 
contents?

Definitely something to think about in distutils2.

--

___
Python tracker 

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

[issue6040] bdist_msi does not deal with pre-release version

[anatoly techtonik]

anatoly techtonik  added the comment:

s/while/whole/

Sorry.

--

___
Python tracker 

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

[issue9861] subprocess module changed exposed attributes

[Ross Lagerwall]

Ross Lagerwall  added the comment:

This changes seems to have been made from 2.5 to 2.6 which are security fix 
only.

Closing as "wont fix".

--
nosy: +rosslagerwall
resolution:  -> wont fix
status: open -> closed

___
Python tracker 

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

[issue3905] subprocess failing in GUI applications on Windows

[Todd Whiteman]

Todd Whiteman  added the comment:

I still see this problem (in Python 2.7.1 and Python 3.1.2).

When testing using idle, you'll need to launch using "pythonw.exe", i.e.:

pythonw.exe lib\idlelib\idle.py

--

___
Python tracker 

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

[issue2736] datetime needs an "epoch" method

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Alexander Belopolsky wrote:
> 
> Alexander Belopolsky  added the comment:
> 
> On Tue, Apr 5, 2011 at 4:33 AM, Marc-Andre Lemburg
>  wrote:
> ..
>> mxDateTime, which in large parts inspired the Python datetime module,
>> has had a .ticks() method (for local time) and a .gmticks() method
>> (for UTC) for more than a decade now
> 
> Yes, mxDateTime's gmticks()/ticks() pair of functions present a much
> more mature design than anything that has been proposed here.  It is
> telling, however, that no one has mentioned mxDateTime's gmticks() on
> this issue in four years.  On a duplicate issue 1673409, Marc did
> bring it up, but as far as I can tell, no one responded.  See
> msg75411.
> 
> Google code search,
> 
> http://www.google.com/codesearch?hl=en&sa=N&q=gmticks+lang:python
> 
> returns only 13 hits for "gmticks".  In several instances, the
> resulting float is immediately converted to int, in other instances
> "gmticks" is mentioned in comments and the code works around its bugs.
> 
> I would not use Google Code search as an ultimate arbiter on the
> popularity of a feature, so I would really like to hear from the
> proponents about real life uses of gmticks() or any other examples
> where a similar method "has been reimplemented over and over again."

mxDateTime needs those two methods, since it doesn't natively
use timezones. The .ticks() method is used for local time values,
.gmticks() for UTC ones; that's why there are two methods.

The .gmticks() method is always used when storing UTC values
in mxDateTime instances, which actually is the preferred way
of storing data in databases. Google Code doesn't really count
much, since it only scans a limited number of OSS code bases.
Most of our users are commercial users who use the tools
in-house.

Note that implementing .gmticks() is fairly easy on POSIX
conform systems. On most others, timegm() can be used. If
that doesn't exist, things get tricky, but that case should
be rare nowadays.

>> so far, I haven't seen a single complaint about any of the issues raised in 
>> this discussion.
> 
> Well, search for gmticks does not return too many hits outside of
> mxDateTime code and manuals, but I had no trouble finding this:
> 
> """
>  okay, all the MySQLdb dataobject tick-based time handling methods are
>   broken in various ways -- reconstruct GMT ticks from time module's
>   mktime...
> """
> http://viewvc.tigris.org/ds/viewMessage.do?dsForumId=4251&dsMessageId=656863
> 
> Follow the link for some more colorful language describing developer's
> experience with the feature.
> 
> Note that it is likely that the bug MySQLdb developer complained about
> was fixed in mxDateTime at some point,
> , but
> this shows that implementing gmticks() correctly is not as trivial as
> those who never tried might think.

Note that he was referring to the .ticks() method, not the .gmticks()
method. The patch doesn't say which version of mxDateTime he was
using. The bug mentioned in the changelog was fixed in 1998. It is
possible, however, that the mktime() on his system was broken - which
is why I added a test for it in mxDateTime.

>>
>> The methods naturally return the Unix ticks value as float,
>> since that's what the time module uses as basis
> 
> Which in turn is a mistake IMO.  Note that POSIX does not use float
> timestamps for a reason.

The time module is our reference in this case and this tries hard
to add fractions of a second to the value :-)

Note that sub-second accuracy relies on a number of factors,
the storage format most certainly is the least important
aspect ;-)

On many systems, you only get 1/100s accuracy, on others, the timer
ticks in fixed increments, giving you even weirder sub-second values
(e.g. time appears to stay constant between time.time() calls).

OTOH, there's a new set of APIs for nano-second accuracy available
now, which the datetime module objects cannot represent at all due
to the integer-based storage format.

BTW: The integer format was chose in order to keep the memory
footprint of the objects low.

>> and the whole purpose
>> of those methods is to make interaction with the time module easy
>> and straight-forward.
> 
> This is not the goal that I would support.  I would rather see code
> that uses datetime module not require time module methods at all.

No chance :-) In practice, the time module gets used a lot
for date/time storage or to quickly measure time deltas.
Some people also prefer time module ticks due to their lower
memory footprint, esp. when it comes to storing thousands of
time values in time series.

>> Victor's patch could easily be updated to return floats as well,
>> to make it compatible with the time module.
>>
> 
> Victor reported implementing two methods, one to return a float and
> another to return a tuple. See msg124259.  I am not sure I've seen
> that code.

I had a look at the last patch on this ticket.

[issue11576] timedelta subtraction glitch on big timedelta values

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

> What happens is the second value is negated (__neg__)
> which causes it to become less than timedelta.min and
> that is causing OverflowError.

Yes, and running the test case without C acceleration makes this obvious:

>>> import sys
>>> sys.modules['_datetime'] = None
>>> from datetime import *
>>> timedelta(9, 86399, 99) - timedelta(9, 86399, 98)
Traceback (most recent call last):
  File "", line 1, in 
  File "Lib/datetime.py", line 488, in __sub__
return self + -other
  File "Lib/datetime.py", line 501, in __neg__
-self._microseconds)
  File "Lib/datetime.py", line 426, in __new__
raise OverflowError("timedelta # of days is too large: %d" % d)
OverflowError: timedelta # of days is too large: -10

Attached patch fixes the issue.  I would like to think some more about C int 
overflow before committing.

--
assignee:  -> belopolsky
keywords: +patch
nosy: +mark.dickinson
stage:  -> patch review
Added file: http://bugs.python.org/file21543/issue11576.diff

___
Python tracker 

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

[issue7311] Bug on regexp of HTMLParser

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 7d4dea76c476 by Ezio Melotti in branch '2.7':
#7311: fix HTMLParser to accept non-ASCII attribute values.
http://hg.python.org/cpython/rev/7d4dea76c476

--
nosy: +python-dev

___
Python tracker 

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

[issue2736] datetime needs an "epoch" method

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Alexander Belopolsky wrote:
> 
> Alexander Belopolsky  added the comment:
> 
> MAL> Since most of the datetime module was inspired by mxDateTime,
> MAL> I wonder why [ticks()/gmticks()] were left out. (msg75411)
> 
> """
> The datetime module intended to be an island of relative sanity.
> Because the range of dates "timestamps" can represent varies across
> platforms (and even "the epoch" varies), datetime doesn't even try to
> produce timestamps directly -- datetime is more of an alternative to
> "seconds from the epoch" schemes. Because datetime objects have
> greater range and precision than timestamps, conversion is
> problem-free in only one direction. It's not a coincidence that
> that's the only direction datetime supplies ;-)
> """ - Tim Peters
>  
> http://bytes.com/topic/python/answers/522572-datetime-timestamp
> 
> I will also add that fromtimestamp() is not invertible in the presence of 
> DST.  That's why mxDatetime.ticks() takes a DST flag making it effectively a 
> multi-valued function.  Note that naive users, who just want to pass datetime 
> values to an OS function expecting a float, most likely will not have means 
> of properly obtaining DST flag.

IMHO, the whole concept of DST is broken, but that's not our fault :-)

Ditching the concept just because it is known to fail for
one hour out of 8760 you have in a typical year doesn't really
warrant breaking the "practicality beats purity" guideline.

Otherwise, we'd have to ditch the date support in the datetime module
too: after all, Feb 29 only exists every 4 years (well, most of the
time) - and that's one day out of 1461 in those 4 years, so an
even worse ratio :-)

And I'm not even starting to talk about ditching the concept
of Unix ticks to begin with, as a result of having leap seconds
causing POSIX ticks values not matching (real) UTC ticks.

In reality, all these things hardly ever matter and if they do,
users will either know that they have to make conscious decision,
simply don't care or decide not to care.

BTW: A "timestamp" usually refers to the combination of date and
time. The time.time() return value is "seconds since the Epoch".
I usually call those values "ticks" (not sure whether it's standard
term of not, but always writing "seconds since Epoch" wasn't an
option either ;-)).

Date/time is fun, isn't it ?

--

___
Python tracker 

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

[issue2193] Cookie Colon Name Bug

[Carsten Klein]

Carsten Klein  added the comment:

Guess you are right...

I did overlook the quoted-string reference in the RFC:

   av-pair =   attr ["=" value]; optional value
   attr=   token
   value   =   word
   word=   token | quoted-string

The actual production rules for quoted-string are not specified, so I guess 
that anything resembling unicode data would be allowed in that string provided 
that:

[...] from RFC 2109
10.1.3  Punctuation

   In Netscape's original proposal, the values in attribute-value pairs
   did not accept "-quoted strings.  Origin servers should be cautious
   about sending values that require quotes unless they know the
   receiving user agent understands them (i.e., "new" cookies).  A
   ("new") user agent should only use quotes around values in Cookie
   headers when the cookie's version(s) is (are) all compliant with this
   specification or later.

in RFC 2965 there is no such notice...

However, and this is important, the cookie values not matching token must be 
quoted by the origin server upon setting and the client must return these as 
quoted strings as well.

--

___
Python tracker 

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

[issue2736] datetime needs an "epoch" method

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

Let me state my position on this issue once again.  Converting datetime values 
to float is easy.   If your dt is a naive instance representing UTC time:

   timestamp = (dt - datetime(1970, 1, 1)) / timedelta(seconds=1)

If your dt is an aware instance:

   timestamp = (dt - datetime(1970, 1, 1, tzinfo=timezone.utc)) / 
timedelta(seconds=1)

These recipes are easy to adjust for your application needs.  One application 
may want millisecond or microsecond ticks, another might want to carry 
subsecond presision in a separate integer, third may want to avoid timestamps 
before 1970 or after 2038 or ignore microseconds altogether.  No matter what a 
hypothetical datetime.epoch() will provide, most of applications will need to 
add a line or two to its code to serve their needs. Applications that will use 
dt.epoch() naively without thinking what dt represents (say local or UTC) will 
be buggy.

The only related feature that I think is missing from datetime module is the 
ability to obtain local time as an aware datetime instance and to convert a 
naive datetime instance assumed to represent local time to an aware one.

This is the subject of #9527, but there is a resistance to adding that feature.

--

___
Python tracker 

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

[issue2193] Cookie Colon Name Bug

[Carsten Klein]

Carsten Klein  added the comment:

Ups forgot to also mention the production rule for token, which is defined in 
the HTTP RFC RFC2616:

   token  = 1*
   separators = "(" | ")" | "<" | ">" | "@"
  | "," | ";" | ":" | "\" | <">
  | "/" | "[" | "]" | "?" | "="
  | "{" | "}" | SP | HT

and here it clearly states that a value that is not a quoted string
must not contain colons, and other characters as is specified by separators.

--

___
Python tracker 

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

[issue11734] Add half-float (16-bit) support to struct module

[Eli Stevens]

Eli Stevens  added the comment:

All four changes suggested via review from Mark Dickinson have been made.  One 
note: the else if (!(e == 0 && f == 0.0)) { change was made; this makes the 
Pack2 function parallel the Pack4 function slightly less.  I agree that it's 
cleaner this way, but I've left the original if in as a comment for comparison 
to Pack4.  I'll remove the comment if it's decided that it's better to be clean 
than parallel.

The suggested test cases were added in the v4 patch, just in case that wasn't 
clear.

I'm going to assume that my questions about _struct.c aren't issues unless 
someone explicitly says they are.

Thanks for all of the review and feedback!  :)

--
Added file: http://bugs.python.org/file21544/cpython-struct-float16-v5.patch

___
Python tracker 

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

[issue11734] Add half-float (16-bit) support to struct module

[Eli Stevens]

Changes by Eli Stevens :


Removed file: http://bugs.python.org/file21497/cpython-struct-float16-v1.patch

___
Python tracker 

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

[issue11734] Add half-float (16-bit) support to struct module

[Eli Stevens]

Changes by Eli Stevens :


Removed file: http://bugs.python.org/file21499/cpython-struct-float16-v3.patch

___
Python tracker 

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

[issue2193] Cookie Colon Name Bug

[Carsten Klein]

Carsten Klein  added the comment:

Perhaps the best solution would be for the Python cookie module to
gracefully adapt to servers not quoting cookie values as is required
by the RFCs and make these quoted-strings instead?

--

___
Python tracker 

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

[issue11774] Issue tracker sends notification mails twice...

[Carsten Klein]

New submission from Carsten Klein :

Currently I am receiving duplicates of the notification mails by your issue 
tracker.

--
messages: 133062
nosy: carsten.kl...@axn-software.de
priority: normal
severity: normal
status: open
title: Issue tracker sends notification mails twice...

___
Python tracker 

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

[issue11774] Issue tracker sends notification mails twice...

[Carsten Klein]

Carsten Klein  added the comment:

It seems that it only happens when commenting upon an existing issue.

--

___
Python tracker 

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

[issue11774] Issue tracker sends notification mails twice...

[Carsten Klein]

Carsten Klein  added the comment:

Nope, it only happens on issue [issue2193] Cookie Colon Name Bug
but not for this one.

--

___
Python tracker 

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

[issue11774] Issue tracker sends notification mails twice...

[Brian Curtin]

Brian Curtin  added the comment:

http://psf.upfronthosting.co.za/roundup/meta is the bug tracker for the bug 
tracker.

Also, consider that if you are subscribed to any of the tracker mailing lists 
such as python-bugs-list, you might get multiple copies of tracker comments.

--
nosy: +brian.curtin
resolution:  -> invalid
stage:  -> 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

[issue11774] Issue tracker sends notification mails twice...

[Carsten Klein]

Carsten Klein  added the comment:

Ah, I see, thanks for the input. Will close this then.

--

___
Python tracker 

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

[issue11774] Issue tracker sends notification mails twice...

[Ezio Melotti]

Ezio Melotti  added the comment:

Your name appears twice in the nosy list.

--
nosy: +ezio.melotti

___
Python tracker 

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

[issue2193] Cookie Colon Name Bug

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy:  -carsten.klein

___
Python tracker 

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

[issue11774] Issue tracker sends notification mails twice...

[Carsten Klein]

Carsten Klein  added the comment:

I wonder how this happened...
Thanks for the finding!

--

___
Python tracker 

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

[issue2193] Cookie Colon Name Bug

[Carsten Klein]

Changes by Carsten Klein :


--
nosy: +carsten.klein -carsten.kl...@axn-software.de

___
Python tracker 

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

[issue11774] Issue tracker sends notification mails twice...

[Ezio Melotti]

Ezio Melotti  added the comment:

Maybe you changed your id or registered a new one?
I removed the duplicate one from #2193, if I got the wrong one feel free to fix 
it as you prefer.

--

___
Python tracker 

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

[issue11774] Issue tracker sends notification mails twice...

[Carsten Klein]

Carsten Klein  added the comment:

Actually I logged in using carsten.kl...@axn-software.de
and the tracker changed my login name to that...
Will issue a bug against the tracker...

--
nosy: +carsten.klein

___
Python tracker 

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

[issue11774] Issue tracker sends notification mails twice...

[Ezio Melotti]

Ezio Melotti  added the comment:

Yes, that sounds like a bug.

--

___
Python tracker 

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

[issue6191] HTMLParser attribute parsing - 2 test cases when it fails

[Ezio Melotti]

Changes by Ezio Melotti :


--
versions: +Python 3.2, Python 3.3 -Python 2.6

___
Python tracker 

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

[issue11774] Issue tracker sends notification mails twice...

[Carsten Klein]

Changes by Carsten Klein :


--
nosy:  -carsten.kl...@axn-software.de

___
Python tracker 

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

[issue2736] datetime needs an "epoch" method

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

On Tue, Apr 5, 2011 at 1:45 PM, Marc-Andre Lemburg
 wrote:
..
> BTW: A "timestamp" usually refers to the combination of date and
> time. The time.time() return value is "seconds since the Epoch".
> I usually call those values "ticks" (not sure whether it's standard
> term of not, but always writing "seconds since Epoch" wasn't an
> option either ;-)).

In Unix context, the term "timestamp" is usually associated with the
various time values that OS stores with the files.  I think this use
is due to the analogy with physical "received on" timestamps used on
paper documents.  Since it is well-known that Unix filesystems store
time values as seconds since Epoch, it is common to refer to these
values as "Unix timestamps".

See, for example:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/touch.html

--

___
Python tracker 

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

[issue11734] Add half-float (16-bit) support to struct module

[Mark Wiebe]

Mark Wiebe  added the comment:

Just a few small tweaks.

I think you meant to subtract the second term here:
+#('>e', b'\x80\x01', -2.0**-25 + 2.0**-35), # Rounds to minimum subnormal

Isn't the "x < 0" part unnecessary? Maybe a comment explaining why the signbit 
function is used, to preserve -0, would help people who otherwise might think 
to replace it with "x < 0".
+if (x < 0 || signbit(x)) {

This is creating a signaling nan. It would be better to create a quiet nan by 
setting the highest order bit instead of the lowest order bit.
+else if (isnan(x)) {
+e = 0x1f;
+bits = 1;
+}

Otherwise it looks great to me, good work!

--

___
Python tracker 

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

[issue11597] Can't get ConfigParser.write to write unicode strings

[Łukasz Langa]

Łukasz Langa  added the comment:

In my opinion we should unfortunately close this with WONTFIX because:

* adding a feature in a point release is not an option
* this may be poorly documented but most of the standard library in 2.x assumes 
bytestrings (and fails with Unicode strings). Same goes for instance for csv.
* storing encoded data internally enables for direct reading and writing to 
compatible files
* having Unicode instead requires the possibility to specify an `encoding` 
parameter to read* and write* methods. I added this parameter in 3.2 exactly 
for this reason.

So, unless I missed something obvious and there's more discussion, I am closing 
this issue next week.

--

___
Python tracker 

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

[issue7311] Bug on regexp of HTMLParser

[Ezio Melotti]

Ezio Melotti  added the comment:

With 3.2 the situation is more complicated because there is a strict and a 
non-strict mode.
The strict mode uses:
attrfind = re.compile(
r'\s*([a-zA-Z_][-.:a-zA-Z_0-9]*)(\s*=\s*'
r'(\'[^\']*\'|"[^"]*"|[-a-zA-Z0-9./,:;+*%?!&$\(\)_#=~@]*))?')

and the tolerant mode uses:
attrfind_tolerant = re.compile(
r'\s*([a-zA-Z_][-.:a-zA-Z_0-9]*)(\s*=\s*'
r'(\'[^\']*\'|"[^"]*"|[^>\s]*))?')

This means that the strict mode doesn't allow valid non-ASCII chars, and that 
tolerant mode is a little too permissive.

The attached patch changes the strict regex to be more permissive and leaves 
the tolerant regex unchanged. The difference between the two are now so small 
that the tolerant version could be removed, except that re.search is used 
instead of re.match when the tolerant regex is used.

--
nosy: +r.david.murray
Added file: http://bugs.python.org/file21545/issue7311-3.diff

___
Python tracker 

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

[issue11775] `bool(Counter({'a': 0'})) is True`

[Ram Rachum]

New submission from Ram Rachum :

bool(Counter({'a': 0'})) is True.

Is this wise? I want to be able to do:

if my_counter:
whatever

To check whether my counter has any elements. Currently this seems to be 
impossible because of this bug.

Will we have to keep this weird behavior because of backwards compatibility? If 
so, perhaps `.elements` could be turned into a smart object so we could at 
least do `if my_counter.elements():` and get the expected result.

If you want a patch let me know and I'll write one.

--
components: Library (Lib)
messages: 133076
nosy: cool-RR
priority: normal
severity: normal
status: open
title: `bool(Counter({'a': 0'})) is True`
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

[issue11775] `bool(Counter({'a': 0})) is True`

[Ram Rachum]

Changes by Ram Rachum :


--
title: `bool(Counter({'a': 0'})) is True` -> `bool(Counter({'a': 0})) is True`

___
Python tracker 

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

[issue11775] `bool(Counter({'a': 0})) is True`

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +ezio.melotti, rhettinger
stage:  -> test needed
type:  -> behavior

___
Python tracker 

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

[issue11775] `bool(Counter({'a': 0})) is True`

[Ram Rachum]

Ram Rachum  added the comment:

Before coding a test I want to know whether we can even make this change with 
regards to backwards compatibility.

--

___
Python tracker 

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

[issue11734] Add half-float (16-bit) support to struct module

[Eli Stevens]

Eli Stevens  added the comment:

Updated patch with changes suggested by Mark Wiebe.  I also removed the 
commented-out "if (!(e == 0 && f == 0.0))" part.

It feels like the patch is approaching an acceptable state; after both of you 
agree it's there, what do I need to do next?

--

___
Python tracker 

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

[issue11775] `bool(Counter({'a': 0})) is True`

[Matthew Barnett]

Matthew Barnett  added the comment:

It depends on what kind of object it's like. If it's like a dict then your 
example is clearly not empty, but if it's like a set then it /is/ empty, in 
which case it's empty if:

all(count == 0 for count in my_counter.values())

--
nosy: +mrabarnett

___
Python tracker 

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

[issue11597] Can't get ConfigParser.write to write unicode strings

[R. David Murray]

R. David Murray  added the comment:

No, the need for an encoding parameter for read/write makes it unambiguous that 
it is indeed a feature.

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

___
Python tracker 

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

[issue11775] `bool(Counter({'a': 0})) is True`

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Sorry, this is at odds with how Guido wants bool to work with containers.  The 
bool check is all about whether or not a container is empty, not about its 
contents.

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

[issue11775] `bool(Counter({'a': 0})) is True`

[Ram Rachum]

Ram Rachum  added the comment:

Hmm... So how about making `elements` a smart object which will implement 
`__bool__`? Then we could give it a `__len__` too and be rid of issue11733.

--

___
Python tracker 

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

[issue7311] Bug on regexp of HTMLParser

[R. David Murray]

R. David Murray  added the comment:

The goal of tolerant mode is to accept anything a typical browser would accept. 
 I suspect that means the tolerant regex should stay, but I don't remember the 
details.

As for the strictas far as I know the current module follows 4.01, not 5.  
I'm not sure what should be done about that.

--
nosy: +orsenthil

___
Python tracker 

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

[issue11605] EMail generator.flatten() disintegrates over non-ascii multipart/alternative

[R. David Murray]

R. David Murray  added the comment:

Here is a patch against 3.2, with test.  Simple fix, but it took me a while to 
track down the critical piece of code.

--
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file21546/parse_8bit_multipart.patch

___
Python tracker 

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

[issue11707] Create C version of functools.cmp_to_key()

[Filip Gruszczyński]

Filip Gruszczyński  added the comment:

I have a follow-up question: why keyobject_type needed traverse function? From 
what I read in docs I assumed it is required for GC tracked types. Why was it 
required here and how it is used?

--

___
Python tracker 

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

[issue11775] `bool(Counter({'a': 0})) is True`

[Raymond Hettinger]

Raymond Hettinger  added the comment:

We could do that, but that's not the Python way :-)

Really, you should be posting recipes somewhere else to see if there is 
interest and uptake.  The tracker is not the right place to toss one random 
idea after another.

We need to place some value on API simplicity.  At its core, a Counter is just 
a dict with an __missing__ method to supply implied zeros.  Much of its ease of 
use, speed, and flexibility all derive from that basic design.  For the most 
part, the best thing that could happen to this API is to become stable and 
remain completely untouched.  I only added subtract() in Py3.2 because there 
was substantial demand for it; otherwise, all the other ideas for expansion 
were rejected.

--

___
Python tracker 

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

[issue11670] configparser read_file now iterates over f, docs still say it calls readline

[Łukasz Langa]

Łukasz Langa  added the comment:

How about this? (available for review: http://codereview.appspot.com/4358054)

--
keywords: +patch
Added file: http://bugs.python.org/file21547/issue11670.patch

___
Python tracker 

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

[issue11733] Implement a `Counter.elements_count` method

[Raymond Hettinger]

Raymond Hettinger  added the comment:

After more thought, I've decided to close this feature request.  The operation 
is utterly trivial and isn't worth fattening the API.  I see no advantage in 
`c.total_count()` versus `sum(c.values())`.

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