[issue6280] calendar.timegm() belongs in time module, next to time.gmtime()

[Francesco Del Degan]

Francesco Del Degan  added the comment:

Hi, i started to produce a patch for timemodule.c.

Working into it, i found that we have almost 3 way to do that:

1. Use timegm(3) function where HAVE_TIMEGM is defined (i have a working patch 
for it)

2. Implement a more portable timegm function with tzset and mktime where 
HAVE_MKTIME and 
HAVE_WORKING_TZSET is defined (i have a working patch for it)

3. Doing some calculation taking calendar.timegm as example.


What do you think about it?

Thanks,
Francesco "pr0gg3d" Del Degan

--
nosy: +pr0gg3d

___
Python tracker 

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

[issue6280] calendar.timegm() belongs in time module, next to time.gmtime()

[Simon Cross]

Changes by Simon Cross :


--
nosy: +hodgestar

___
Python tracker 

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

[issue6646] test_pickle fails on AIX -- 6.9999999999999994e-308 != 6.9999999999999984e-308

[Mark Dickinson]

Changes by Mark Dickinson :


--
assignee:  -> marketdickinson
nosy: +marketdickinson

___
Python tracker 

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

[issue6646] test_pickle fails on AIX -- 6.9999999999999994e-308 != 6.9999999999999984e-308

[Mark Dickinson]

Mark Dickinson  added the comment:

Thanks for the report!

What's the underlying hardware on your machine?

Here's a Python 2.6 interpreter session on my machine (OS X 10.5/Intel).  
Would it be possible for you to execute the same commands on your machine 
and tell me what you get?

Python 2.6.2 (r262:71600, Jun 17 2009, 09:08:27) 
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from sys import float_info
>>> float_info
sys.floatinfo(max=1.7976931348623157e+308, max_exp=1024, max_10_exp=308, 
min=2.2250738585072014e-308, min_exp=-1021, min_10_exp=-307, dig=15, 
mant_dig=53, epsilon=2.2204460492503131e-16, radix=2, rounds=1)
>>> from pickle import dumps, loads
>>> x = 7e-308
>>> x
7.0004e-308
>>> p = [dumps(x, proto) for proto in range(3)]
>>> p
['F7.0004e-308\n.', 'G\x00)*\xee\xa4Z\xae\xe0.', 
'\x80\x02G\x00)*\xee\xa4Z\xae\xe0.']
>>> up = [loads(z) for z in p]
>>> up
[7.0004e-308, 7.0004e-308, 7.0004e-
308]

--

___
Python tracker 

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

[issue6656] locale.format_string fails on escaped percentage

[Christoph Burgmer]

New submission from Christoph Burgmer :

locale.format_string doesn't return same result as a normal
"string" % format
directive, but raises a TypeError. See attached test case for Python
2.6.

>>> locale.format_string('%f%%', 1.0)
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.5/locale.py", line 195, in format_string
return new_f % val
TypeError: not enough arguments for format string
>>> '%f%%' % 1.0
'1.00%'

--
components: Library (Lib)
files: locale_percents_test.diff
keywords: patch
messages: 91352
nosy: christoph
severity: normal
status: open
title: locale.format_string fails on escaped percentage
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file14665/locale_percents_test.diff

___
Python tracker 

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

[issue6656] locale.format_string fails on escaped percentage

[Christoph Burgmer]

Christoph Burgmer  added the comment:

This patch removes '%%' entities from the regex results and only
replaces other matches with '%s' which later then get replaced by
localized versions so that escaped percentage entities don't show up in
localized parsing anymore.

Removing case '%%' from the regex completely does not sound feasible
and will result in '%%d' having a match '%d', though d should be a
normal character.

The replacing of regex matches does not look that beautiful, feel free
to rewrite said part.

--
Added file: http://bugs.python.org/file14666/locale_percents.diff

___
Python tracker 

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

[issue6657] Copy documentation section

[Sheepherd]

New submission from Sheepherd :

The enumerated part in about the exact usage of the conversion specifier
in "String Formatting Operations"
http://docs.python.org/library/stdtypes.html#string-formatting should be
copied to http://docs.python.org/library/string.html#formatspec to make
the usage of the specifier clear.

--
assignee: georg.brandl
components: Documentation
messages: 91354
nosy: Sheepherd, georg.brandl
severity: normal
status: open
title: Copy documentation section
versions: Python 2.6

___
Python tracker 

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

[issue6658] typo in buffer api docs

[Alexey Shamrin]

New submission from Alexey Shamrin :

Typo in PyObject_GetBuffer docs: "...handle all the complexibity..."

Links:

http://docs.python.org/c-api/buffer.html#buffer-related-functions
http://docs.python.org/dev/c-api/buffer.html#buffer-related-functions
http://docs.python.org/3.1/c-api/buffer.html#buffer-related-functions
http://docs.python.org/dev/py3k/c-api/buffer.html#buffer-related-functions

--
assignee: georg.brandl
components: Documentation
messages: 91355
nosy: ash, georg.brandl
severity: normal
status: open
title: typo in buffer api docs
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

___
Python tracker 

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

[issue6658] typo in buffer api docs

[Alexey Shamrin]

Alexey Shamrin  added the comment:

Well, there's another typo in buffer documentation (PyBuffer_Release):

"This shouldd be called..."

Only in 2.x series:

http://docs.python.org/c-api/buffer.html#PyBuffer_Release
http://docs.python.org/dev/c-api/buffer.html#PyBuffer_Release

--

___
Python tracker 

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

[issue6659] buffer c-api: memoryview object documentation

[Alexey Shamrin]

New submission from Alexey Shamrin :

"A memoryview object is an extended buffer object that could replace the
buffer object (but doesn’t have to as that could be kept as a simple 1-d
memoryview object)."

Well, buffer object was dropped Python 3, wasn't it?

http://docs.python.org/dev/py3k/c-api/buffer.html#memoryview-objects
http://docs.python.org/3.1/c-api/buffer.html#memoryview-objects

--
assignee: georg.brandl
components: Documentation
messages: 91357
nosy: ash, georg.brandl
severity: normal
status: open
title: buffer c-api: memoryview object documentation
versions: Python 3.1, Python 3.2

___
Python tracker 

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

[issue6632] Include more fullwidth chars in the decimal codec

[Mark Dickinson]

Mark Dickinson  added the comment:

Python's current support for localization in int and float seems largely 
accidental, as far as I can tell.  But I appreciate the argument that
despite the current inconsistencies, we shouldn't add extra support 
without a standard to base it on.

I'm not sure how relevant TR35 is to this situation;  that seems to be 
about localization, and I don't really understand why it should be the 
job of int and float to deal with localization (even though they 
currently do, to some extent).  I'd even argue for removing support[*] 
for anything other than ASCII digits from int and float, except that 
that would likely break existing applications, and annoy people.  Out of 
curiosity, I asked on #python about this, and found that there are 
people working with CJK alphabets who find it convenient that int 
currently accepts fullwidth digits.  I don't know whether there's anyone 
who cares that int and float currently accept e.g., Devanagari digits.

I guess I'm +0.2 for preserving the status quo, for now.

([*] I'm aware that I'm being a bit inconsistent here, since I was 
recently arguing that the Decimal type should accept non-European 
decimal digits partly based on the fact that int and float do.  But in 
the case of Decimal there's an underlying standard that recommends 
acceptance of these digits, and compliance with that standard has 
generally taken precedence over consistency with Python's other numeric 
types.)

--

___
Python tracker 

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

[issue1537721] csv module: add header row to DictWriter

[djc]

Changes by djc :


--
nosy: +djc

___
Python tracker 

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

[issue1628205] socket.readline() interface doesn't handle EINTR properly

[Gregory P. Smith]

Gregory P. Smith  added the comment:

nice test case rhettg.

This is a correctness issue to prevent data loss on EINTR.

I've attached a patch that builds on rhettg's but allows the EINTR signal 
to propagate upwards as desired by loweis and jorend for both read() and 
readline() calls.

--
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith
Added file: http://bugs.python.org/file14667/issue1628205-gps01.diff.txt

___
Python tracker 

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

[issue6632] Include more fullwidth chars in the decimal codec

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Mark Dickinson wrote:
> Python's current support for localization in int and float seems largely 
> accidental, as far as I can tell.

Not at all. The support for non-ASCII numeric characters
in int() and float() is by design - however, I did not look
at things like decimal points, minus/plus signs, etc. at the
time and only included support for numeric values associated
with a number of code points, such as ½ for 1/2.

> But I appreciate the argument that
> despite the current inconsistencies, we shouldn't add extra support 
> without a standard to base it on.
> 
> I'm not sure how relevant TR35 is to this situation;  that seems to be 
> about localization, and I don't really understand why it should be the 
> job of int and float to deal with localization (even though they 
> currently do, to some extent).  I'd even argue for removing support[*] 
> for anything other than ASCII digits from int and float, except that 
> that would likely break existing applications, and annoy people.  Out of 
> curiosity, I asked on #python about this, and found that there are 
> people working with CJK alphabets who find it convenient that int 
> currently accepts fullwidth digits.  I don't know whether there's anyone 
> who cares that int and float currently accept e.g., Devanagari digits.

My suggestion is to wait for the Unicode locale project to collect
locale based information on numeric formatting. I'm sure that some
of this information will be entered back into the Unicode database
in form of code point properties for e.g. decimal points, signs, etc.

--

___
Python tracker 

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

[issue6582] test_telnetlib doesn't test Telnet.write

[Rodrigo Steinmuller Wanderley]

Rodrigo Steinmuller Wanderley  added the comment:

Did only minor modifications to TelnetSocketSendall class.

Please review the following patch.

--
keywords: +patch
nosy: +rwanderley
Added file: http://bugs.python.org/file14668/write_test.patch

___
Python tracker 

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

[issue6632] Include more fullwidth chars in the decimal codec

[Mark Dickinson]

Mark Dickinson  added the comment:

[Mark Dickinson]
> Python's current support for localization in int and float seems
> largely accidental, as far as I can tell.

[MAL]
> Not at all. [...]

Apologies;  'accidental' was a poor choice of word here.

> however, I did not look
> at things like decimal points, minus/plus signs, etc. at the
> time and only included support for numeric values associated
> with a number of code points, such as ½ for 1/2.

I'm less concerned about decimal points and the like, and more bothered by 
the fact that e.g., int(x, 16) accepts some, but not all, characters with 
the Hex_Digit property.  This seems counter to the intent of the Unicode 
standard.

[MAL]
> My suggestion is to wait for the Unicode locale project to collect
> locale based information on numeric formatting. [...]

Sounds fine to me.

--

___
Python tracker 

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

[issue6622] [RFC] wrong variable used in Lib/poplib.py

[Mark Dickinson]

Mark Dickinson  added the comment:

> Could someone ensure the attached unittest does the job, I blindly
> copied from above...

Unfortunately it doesn't, because the apop method needs a timestamp in the 
welcome message in order to work.  I've adapted it to make this work---see 
attached patch 'issue6622.patch'.

> I don't know how to launch an unittest with the svn 'Lib', it takes
> the system one and just messing with PYTHONPATH won't work either.

I'm not entirely sure what you're asking here.  On OS X, I usually do 
something like the following at a Terminal prompt:

newton:py3k dickinsm$ ./python.exe Lib/test/test_poplib.py

For better control over output and various other things, use the regrtest 
module:

newton:py3k dickinsm$ ./python.exe Lib/test/regrtest.py -v test_poplib

(execute Lib/test/regrtest.py --help to see a list of options).

--
Added file: http://bugs.python.org/file14669/issue6622.patch

___
Python tracker 

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

[issue6622] [RFC] wrong variable used in Lib/poplib.py

[Mark Dickinson]

Mark Dickinson  added the comment:

Adding Giampaolo Rodola to the nosy list, since he worked on the test code 
recently.  Giampaolo, any comments?

--
nosy: +giampaolo.rodola

___
Python tracker 

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

[issue6622] [RFC] wrong variable used in Lib/poplib.py

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:

@Mark
I can't test your patch right now as I don't have a Python 3.x installed
here but it looks good to me.

--

___
Python tracker 

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

[issue6622] [RFC] wrong variable used in Lib/poplib.py

[Mark Dickinson]

Mark Dickinson  added the comment:

Patch committed, r74330 (py3k) and r74331 (release31-maint).
Thanks, Giampaolo and Vincent!

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

[issue2333] Backport set and dict comprehensions

[Mark Dickinson]

Mark Dickinson  added the comment:

Alexandre, I can't get this to apply cleanly to my svn trunk checkout 
(r74328) (see attached log).  Am I doing something stupid?

--
nosy: +marketdickinson
Added file: http://bugs.python.org/file14670/patch_failure.log

___
Python tracker 

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

[issue2333] Backport set and dict comprehensions

[Mark Dickinson]

Mark Dickinson  added the comment:

Ah, that works.  Thanks!  (I'll pay more attention to the tracker 
Dependencies field in future.)

--

___
Python tracker 

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

[issue2333] Backport set and dict comprehensions

[Alexandre Vassalotti]

Alexandre Vassalotti  added the comment:

You need to apply the set literal patch I posted in issue2335 first.

--

___
Python tracker 

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

[issue6658] typo in buffer api docs

[Georg Brandl]

Georg Brandl  added the comment:

Thanks, fixed in r74333, will be merged to the other branches eventually.

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

[issue6659] buffer c-api: memoryview object documentation

[Georg Brandl]

Georg Brandl  added the comment:

Benjamin is listed as the section author.

--
assignee: georg.brandl -> benjamin.peterson
nosy: +benjamin.peterson

___
Python tracker 

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

[issue6657] Copy documentation section

[Georg Brandl]

Georg Brandl  added the comment:

I'm not sure which "enumerated part" you mean.  Can you propose a patch?

--

___
Python tracker 

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

[issue6660] Desire python.org documentation link to user contribution wiki (per function)

[kee nethery]

New submission from kee nethery :

Proposal: For each permalink headline in the official documentation, 
link to a wiki page specific to that headline. Allow users to easily 
view and contribute comments and examples around that specific 
documentation headline. For example:
http://docs.python.org/reference/lexical_analysis.html#string-literal-
concatenation
would have an auto-generated link in the main docs of (for example):
http://wiki.docs.python.org/2.6.2#reference#lexical_analysis.html#string
-literal-concatenation
Easy to create, self administering, perhaps valuable to new users, 
completely unofficial.

Newbies need examples, lots of examples. Newbies have noob questions 
about things they are stumbling across that experienced users have 
forgotten was once confusing. For experienced users that knowledge is 
now part of their Python DNA. According to people on the "python-list" 
other languages have wiki style user contribution areas that allow 
newbies to document the things they found confusing (and the answers) 
and to provide lots of code examples. Periodically this newbie 
information is rolled back into the official mainline docs. Requiring 
newbies to join this tracking system and to submit bugs is just way to 
complex for something that is now trivial to do with a wiki and it 
obviously causes the new user contributions to be pretty non-existent. 
Python would be a much easier language to learn if newbies could easily 
contribute through the main documentation web site.

--
assignee: georg.brandl
components: Documentation
messages: 91373
nosy: georg.brandl, keenethery, nnorwitz
severity: normal
status: open
title: Desire python.org documentation link to user contribution wiki (per 
function)
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

___
Python tracker 

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

[issue6648] codecs documentation does not mention surrogateescape

[Georg Brandl]

Georg Brandl  added the comment:

Thanks, fixed in r74334.

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

[issue6660] Desire python.org documentation link to user contribution wiki (per function)

[Georg Brandl]

Georg Brandl  added the comment:

This is already in planning; Sphinx will grow a webapp system that also
allows suggestions for changes.

--
resolution:  -> later
status: open -> closed

___
Python tracker 

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

[issue6659] buffer c-api: memoryview object documentation

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Well, the terminology in these docs is not very precise and helpful.
There are two things here:
- the buffer /struct/ a.k.a Py_buffer, which can only be used from C
code and using the dedicated "new buffer API"
- the memoryview, which is a Python object (a PyObject *) wrapping a
buffer struct; as a PyObject *, it can be used everywhere a regular
Python object is expected (whether in C or in Python)

Then, as you point out, there's a third thing: the old "buffer" object
from Python 2.x; but it should not be mentioned at all in the 3.x docs,
since it's completely gone.

Endly... to be honest, I don't understand what the sentence you've
quoted is supposed to mean :-(, so I don't know how to correct it.

--
nosy: +pitrou

___
Python tracker 

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

[issue6594] json C serializer performance tied to structure depth on some systems

[Antoine Pitrou]

Antoine Pitrou  added the comment:

As Raymond said, and besides, when you talk about "penalty", please
explain what the baseline is. Otherwise it's a bit hard to follow.

(and I stress again that SPARC is a nich platform, even Niagara :-);
moreover, Niagara is throughput-oriented rather than latency-oriented,
so poor single-threaded performance shouldn't be much of a surprise)

--

___
Python tracker 

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

[issue6598] calling email.utils.make_msgid frequently has a non-trivial probability of generating colliding ids

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Is it ok if the message id is predictable?
Besides, _gen_next_number() can more efficiently be written as:

_gen_next_number = itertools.cycle(xrange(N))

--
nosy: +pitrou

___
Python tracker 

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

[issue6594] json C serializer performance tied to structure depth on some systems

[Shawn]

Shawn  added the comment:

First, I want to apologise for not providing more detail initially. 
Notably, one thing you may want to be aware of is that I'm using python
2.4.4 with the latest version of simplejson.  So my timings and
assumptions here are based on the fact that simplejson was adopted as
the 'json' module in python, and I filed the bug here as it appeared
that is where bugs are being tracked for the json module.

To answer your questions though, no, I can't say with certainty that
recursion depth is the issue.  That's just a theory proposed by a
developer intimately familiar with SPARC architecture, who said register
windows on SPARC tend to cause recursive call structures to execute
poorly.  It also seemed to play itself out empirically throughout
testing I performed where any reduction in the depth of the structure
would shave seconds off the write times on the SPARC systems I tested.

I'm also willing to try many of the other things you listed, but I will
have to get back to you on that as I have a project coming due soon.

With that said, I can provide sample data soon, and will do so.  I'll
attach the resulting gzip'd JSON file to make it easy to read and dump.

I would also note that:

* I have tried serialising using cStringIO, which made no significant
difference in performance.

* I have tried different memory allocators, which only seemed to make
things slower, or made little difference.

* Writing roughly the same amount of data (in terms of megabytes), but
in a flatter structure, also increased the performance of the serializer.

* In my testing, it seemed dict serialisation in particular was
problematic from a performance standpoint.

* If I recall correctly from the profile I did, iterencode_dict was
where most of the time was eaten, but I can redo the profile for a more
accurate analysis.

As for Antoine's comments:

I'd like to believe Python is very useful software, and any platform it
it runs on means that the respective market capitalization of the
platform is irrelevant; better performing Python is always good.

--
versions:  -Python 3.2

___
Python tracker 

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

[issue6646] test_pickle fails on AIX -- 6.9999999999999994e-308 != 6.9999999999999984e-308

[Sridhar Ratnakumar]

Sridhar Ratnakumar  added the comment:

It is a powerpc 64-bit AIX machine:

>>> os.uname()
('AIX', 'asaixv5152', '1', '5', '000C763E4C00')
>>> platform.uname()
('AIX', 'asaixv5152', '1', '5', '000C763E4C00', 'powerpc')

The commands you have requested:

>>> from sys import float_info
>>> float_info
sys.floatinfo(max=1.7976931348623157e+308, max_exp=1024, 
max_10_exp=308, min=2.2250738585072014e-308, min_exp=-1021, 
min_10_exp=-307, dig=15, mant_dig=53, epsilon=2.2204460492503131e-16, 
radix=2, rounds=1)
>>> from pickle import dumps, loads
>>> x = 7e-308
>>> x
6.9994e-308
>>> p = [dumps(x, proto) for proto in range(3)]
>>> p
['F6.9994e-308\n.', 'G\x00)*\xee\xa4Z\xae\xdf.', '\x80\x02G
\x00)*\xee\xa4Z\xae\xdf.']
>>> up = [loads(z) for z in p]
>>> up
[6.9984e-308, 6.9994e-308, 
6.9994e-308]
>>>

--

___
Python tracker 

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

[issue2637] urllib.quote() escapes characters unnecessarily and contrary to docs

[Rodrigo Steinmuller Wanderley]

Rodrigo Steinmuller Wanderley  added the comment:

> Unreserved characters can be escaped without changing the semantics
> of the URI, but this should not be done unless the URI is being used
> in a context that does not allow the unescaped character to appear.

How can we identify "a context that does not allow the unescaped
character to appear"?

--
nosy: +rwanderley

___
Python tracker 

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

[issue6646] test_pickle fails on AIX -- 6.9999999999999994e-308 != 6.9999999999999984e-308

[Mark Dickinson]

Mark Dickinson  added the comment:

Thanks.  So pickle protocol 0 is where it's failing;  protocols 1 and 2 
are okay.  It looks as though there's a problem with double <-> string 
(i.e., binary <-> decimal) conversion here.

This probably also means that there are more serious problems on AIX, 
e.g., that float(repr(x)) == x fails for at least some Python floats x.  
That is, on my system:

>>> x = 7e-308
>>> float(repr(x)) == x
True

I expect that you'd get 'False' for this.  Is that right?  If you do get 
False, does this happen for any randomly chosen float x, or is it just 
very small values like the above that are problematic?

Is there any chance the FPU rounding mode has somehow been set to 
something other than round-to-nearest?  (It seems unlikely, but it's 
worth checking.)

These bits of Python are based on the assumption that conversion of an 
IEEE 754-format C double to a decimal string with 17 significant digits 
and back again recovers the original double.  A conforming hosted 
implementation of C99 that defines __STDC_IEC_559__ should satisfy this 
assumption (see Appendix F of the standard, especially section F.5);  
the IEEE 754 standard also recommends this behaviour.

So if your C implementation defines __STDC_IEC_559__ then this can 
reasonably be considered a platform bug.  Does it?

--

___
Python tracker 

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

[issue6661] Transient test_multiprocessing failure

[Antoine Pitrou]

New submission from Antoine Pitrou :

I just got the following test_multiprocessing error (cannot reproduce,
though):

test test_multiprocessing failed -- Traceback (most recent call last):
  File
"/home/antoine/cpython/seek-6629/Lib/test/test_multiprocessing.py", line
232, in test_active_children
self.assertTrue(p in self.active_children())
AssertionError: False is not True

--
assignee: jnoller
components: Library (Lib), Tests
messages: 91383
nosy: jnoller, pitrou
priority: normal
severity: normal
status: open
title: Transient test_multiprocessing failure
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

[issue6661] Transient test_multiprocessing failure

[Jesse Noller]

Jesse Noller  added the comment:

ugh. that's not useful. Dunno how I'm going to track down seemingly random 
and unreproducible issues.

--

___
Python tracker 

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

[issue6661] Transient test_multiprocessing failure

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I know, I was posting it for completeness, and it case someone else
witnesses it.

--

___
Python tracker 

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

[issue6661] Transient test_multiprocessing failure

[Jesse Noller]

Jesse Noller  added the comment:

I know, just makes me :(

--

___
Python tracker 

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

[issue6603] Compilation error if configuref --with-computed-gotos

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I'm afraid you'll have to investigate a bit by yourself, or wait for a
core developer to get the same problem :-/

--

___
Python tracker 

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

[issue6629] seek doesn't properly handle file buffer, leads to silent data corruption

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I've committed the patch + tests in r74336 (trunk), r74338 (py3k) and
r74339 (3.1).
Thanks for the report, and don't hesitate to do more stress testing of
the IO lib!

--
resolution:  -> fixed
status: open -> closed
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

[issue6660] Desire python.org documentation link to user contribution wiki (per function)

[kee nethery]

kee nethery  added the comment:

Georg,
So there will be a link next to each numbered section in the  
documentation that links to a user editable wiki page about that  
section?
That will be highly useful. Glad to hear it. I know I'd like to  
contribute the gotchas I was confused by and the sample code snippets  
that solved a specific generic problem. Having more sample code linked  
from each numbered section in the docs would make my life easier when  
trying to learn Python.
Kee Nethery

On Aug 6, 2009, at 10:56 AM, Georg Brandl wrote:

>
> Georg Brandl  added the comment:
>
> This is already in planning; Sphinx will grow a webapp system that  
> also
> allows suggestions for changes.
>
> --
> resolution:  -> later
> status: open -> closed
>
> ___
> Python tracker 
> 
> ___

-
I check email roughly 2 to 3 times per business day.
Kagi main office: +1 (510) 550-1336

--

___
Python tracker 

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

[issue6660] Desire python.org documentation link to user contribution wiki (per function)

[Georg Brandl]

Georg Brandl  added the comment:

There will be comments for each function/class etc., as well as a
feature to suggest a change for the proper text of a section.

--

___
Python tracker 

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

[issue3600] Include Tcl/Tk 8.5.4 in the windows binary for the upcoming beta3

[Guilherme Polo]

Changes by Guilherme Polo :


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

___
Python tracker 

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

[issue3438] PyCF_DONT_IMPLY_DEDENT can be used to activate the with statement

[Guilherme Polo]

Guilherme Polo  added the comment:

This isn't going to happen, closing.

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

[issue6662] HTMLParser.HTMLParser doesn't handle malformed charrefs

[Dave Day]

New submission from Dave Day :

When HTMLParser.HTMLParser encounters a malformed charref (for example 
&#bad;) it no longer parsers the following HTML correctly.

For example:
  &#bad;
Recognises the starttag "p" but considers the rest to be data.

To reproduce:
class MyParser(HTMLParser.HTMLParser):
  def handle_starttag(self, tag, attrs):
print 'Start "%s"' % tag
  def handle_endtag(self,tag):
print 'End "%s"' % tag
  def handle_charref(self, ref):
print 'Charref "%s"' % ref
  def handle_data(self, data):
print 'Data "%s"' % data
parser = MyParser()
parser.feed('&#bad;')
parser.close()

Expected output:
Start "p"
Data "&#bad;"
End "p"

Actual output:
Start "p"
Data "&#bad;"

--
components: Library (Lib)
messages: 91392
nosy: dayveday
severity: normal
status: open
title: HTMLParser.HTMLParser doesn't handle malformed charrefs
type: behavior
versions: Python 2.4, Python 2.5

___
Python tracker 

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

[issue6663] re.findall does not always return a list of strings

[Phillip M. Feldman]

New submission from Phillip M. Feldman :

As per the Python documentation, the following regular expression should
produce a list containing the strings '6.7', 7.33', and '9':

re.findall('(-?\d+[.]\d+)|(-?\d+[.]?)|(-?[.]\d+)', 'asdf6.77.33ff9')

Instead, it generates a list of tuples.  Either the documentation should
be changed to make it consistent with what re.findall is actually doing,
or, better yet, re.findall should be fixed.

--
components: Regular Expressions
messages: 91393
nosy: pfeld...@verizon.net
severity: normal
status: open
title: re.findall does not always return a list of strings
type: behavior
versions: Python 2.5

___
Python tracker 

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