[issue10254] unicodedata.normalize('NFC', s) regression

[Martin v . Löwis]

Martin v. Löwis  added the comment:

Am 17.12.2010 01:56, schrieb STINNER Victor:
> 
> STINNER Victor  added the comment:
> 
> "Ooops", sorry. I just applied the patch suggested by Marc-Andre
> Lemburg in msg22885 (#1054943). As the patch worked for the examples
> given in Unicode PRI 29 and the test suite passed, it was enough for
> me. I don't understand the normalization code, so I don't know how to
> fix it.

So lacking a new patch, I think we should revert the existing change
for now.

--

___
Python tracker 

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

[issue10254] unicodedata.normalize('NFC', s) regression

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> So lacking a new patch, I think we should revert the existing change
> for now.

Oops, I missed that Alexander has proposed a patch.

--

___
Python tracker 

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

[issue10254] unicodedata.normalize('NFC', s) regression

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> The logic suggested by Martin in msg120018 looks right to me, but the
> whole code seems to be unnecessarily complex.  (And comb1==comb may
> need to be changed to comb1>=comb.) I don't understand why linear
> search through "skipped" array is needed.  At the very least instead
> of adding their positions to the "skipped" list, used combining
> characters can be replaced by a non-character to be later skipped.

The skipped array keeps track of what characters have been integrated
into a base character, as they must not appear in the output.
Assume you have a sequence B,C,N,C,N,B (B: base character, C: combined,
N: not combined). You need to remember not to output C, whereas you
still need to output N. I don't think replacing them with a
non-character can work: which one would you chose (that cannot also
appear in the input)?

The worst case (wrt. cskipped) is the maximum number of characters that
can get combined into a single base character. It used to be (and I
hope still is) 20 (decomposition of U+FDFA).

--

___
Python tracker 

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

[issue10254] unicodedata.normalize('NFC', s) regression

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> Passing Part3 tests and not crashing on crash.py is probably good
> enough for a commit, but I don't have a proof that length 20 skipped
> buffer is always enough.

I would agree with that. I still didn't have time to fully review the
patch, but assuming it fixes the cases in msg119995, we should proceed
with it.

--

___
Python tracker 

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

[issue10724] socket.close close telnet with RST

[Charles-Francois Natali]

Charles-Francois Natali  added the comment:

> but sometimes socket.close will send TCP RST to disconnect the telnet and 
> with wrong sequence number

This is called a a "half-duplex" TCP close sequence. Your application is 
probably closing the socket while there are still data in the receive socket 
buffer (i.e. unread), so the TCP/IP stack sends a RST to inform the remote end 
that data has been lost. See RFC 1122 section 4.2.2.13.
Note that in your sample capture, I don't see any invalid sequence/ack number.
Your application should probably not close the connection at this time.

> This kind of RST will be considering as Network RST attack, and this packet 
> will be dropped, the telnet connection will still established and cannot be 
> closed.

There you firewell is broken. Sending a RST in this context is perfectly valid.

As far as I know, this issue is due to your application and firewall settings, 
and not to Python. Furthermore, Python just calls the underlying close(2) 
syscall, so even if there were an issue, it's an OS one, nothing Python could 
do about it.

--
nosy: +neologix

___
Python tracker 

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

[issue1195] Problems on Linux with Ctrl-D and Ctrl-C during raw_input

[Finkregh]

Changes by Finkregh :


--
nosy: +Finkregh

___
Python tracker 

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

[issue10725] Better cache instrumentation

[Raymond Hettinger]

New submission from Raymond Hettinger :

Nick, can you look at this?

--
assignee: ncoghlan
components: Library (Lib)
files: sized_cache.diff
keywords: patch
messages: 124194
nosy: ncoghlan, rhettinger
priority: normal
severity: normal
status: open
title: Better cache instrumentation
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file20092/sized_cache.diff

___
Python tracker 

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

[issue10716] Modernize pydoc to use CSS

[Éric Araujo]

Éric Araujo  added the comment:

[Raymond]
> I'm looking for a deeper fix, all the in-line styling replaced by a
> stylesheet.  Can you guys work together on bring this to fruition?
When I talked about the CSS reset, I was referring to a precise part of the 
file proposed by Ron, so we’re already discussing together :-)

I wonder how desirable it is to preserve the look and feel of the pages.  We 
all agree on externalizing the CSS and add a way for the users to add their own 
stylesheet; why not take the opportunity to also improve the style?  Huge 
blocks of colors are not that attractive to me :)

Regarding workflow, I’d find easier to start from bare HTML that works nice 
(yes, I test with w3m) and then add style.  Technically, I’d like to maintain 
the HTML as a small set of files (in pydoc_data) containing fragments of HTML 
with placeholders ({} or $): That’s easy to edit, to validate (a very simple 
script can put the fragments together) and to use.

I agree that the CSS file should be as short as possible (in content), but not 
too short (in file size).  For example, trailing commas in properties and 
brackets on their own line will allow nice diffs, just like Python.

(I won’t have much time for Python in December, but we have a lot of time 
before 3.3b1 :)

--

___
Python tracker 

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

[issue10726] pydoc: don’t display raw reST in key word help

[Éric Araujo]

New submission from Éric Araujo :

When one runs “pydoc with”, the output is a block of text marked up with reST.  
It would be more helpful to render it as text or HTML thanks to a minimal reST 
parser and transformer.

In http://mail.python.org/pipermail/python-dev/2010-July/101563.html, Martin 
Geisler (Mercurial dev) said:

“We're using light-weight ReST markup in the Mercurial help texts and
transform it into straight text upon display in the terminal.

We want no external dependencies for Mercurial, so I wrote a "mini ReST"
parser in about 400 lines of code. It cheats a lot and can only handle
simple constructs...” [A few messages later] “I would be happy to relicense it 
under the Python license.”

So, proposed battle plan:
1) Agree this feature request is desirable.

2) Agree on the inclusion of mg’s minirst, which provides an reST parser and a 
plain text formatter.

3) Add an HTML formatter.

4) Wire minirst into pydoc.

--
messages: 124196
nosy: eric.araujo
priority: normal
severity: normal
status: open
title: pydoc: don’t display raw reST in keyword help
type: feature request
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

[issue2736] datetime needs an "epoch" method

[Velko Ivanov]

Velko Ivanov  added the comment:

I'm very disappointed by the outcome of this discussion.

You are committing the biggest sin of modern times - instead of promoting the 
obtaining and usage of knowledge to solve things, you place restrictions to 
force the dumbheads into not doing mistakes. The big problem with that is that 
you can never foresee all usecases and all possible mistakes, thus you will 
always be sorrily bitten by dumbheads. What does that make of you?

Let me present you a situation - I have a system that passes data via JSON, 
datetime object is not JSON serializable. For few other reasons, like the epoch 
and float secs since epoch being defacto standard, and the fact that I 
absolutely make sure at-the-source that my timestamps are UTC and lack zone 
awareness, and the fact that I'm not going to display those, but only use them 
for comparison, and that I'm not going to do historical things and calculations 
and I don't actually need nanosecond precision, just a tenth of the second, and 
I'm fine with always using the '<' and '>', not the '==', and the fact that 90% 
of the cases when use datetimes I have exactly the same requirements and it has 
always been working fine for me - I choose the lightweight float representation 
at the one side of the system.
In the SQL DB I use tz unaware timestamps, not floats and my DB access layer 
returns datetime objects and I prefer them at this end of the system. So I only 
need to serialize the datetime object. Well, as a matter of fact I have a JSON 
object serialization already in place for some of my objects, but I do not need 
that for tz unaware datetimes.
So I look for a method that makes a float from a datetime, which I'm used to in 
PHP, Java, .NET, C, SQL and you name it. And I'm 2 hours into reading about 
time, datetime and calendar modules and I still haven't even invented the 
obscure time.mktime(dt.timetuple())+dt.microseconds*1e-6 . And to even think 
that this creates a timetuple internally ? I hate it instantly and I dismiss 
the possibility that the API could be so wrong and I keep searching -> on the 
internets -> which brings me here where all my illusions are finally buried 
into the dust.

2 Hours for something, that only needs a few warning lines in the docs?
Ok, the ultimately right thing is to actually serialize the datetime object and 
rework my other end of the system to use dt instead of float .. maybe .. but 
not now - now I'm only testing an idea for something completely different and I 
only need faithful and dutiful Python to give me a float from datetime so I can 
check something.
I love Python for being simple, logical and consistent and for giving me the 
tools and not telling me what to do with them. 
Not today ... Today Python goes - 'Here is your hammer, but you can not use it 
to hit straight down. If you hit straight down, and you are using a forge, and 
you miss your object and hit the forge instead, the hammer could ricochet and 
hit you back on the forehead, so you can't use it that way. As a matter of 
fact, there is a gyroscopic sensor embedded in the handle of the hammer and if 
you try to hit with an angle that is close to 90 degrees, it will detach the 
head of the hammer from the handle and prevent you from eventually endangering 
yourself' and I'm like 'WTF??! I'm nailing a nail into a wooden plank!'

Now I'm going to use the obscure one liner and hate it, because it is simply 
wrong and only someone that doesn't care of implementation detail might think 
it equal to a proper solution.
The worst thing is, that I learned today, that if I ever need operations with 
tz aware dates and time intervals in Python, I should actually send an SQL 
query for that, because my DB has a clean, simple and COMPLETE date/time API 
that works seamlessly. Yours is a jungle and I see you being asked to include a 
ready made patch to output a float from a dt, to which you respond by adding a 
locatime() method 2 years later. 
You seriously think, that #9527 solves this? I don't even see a connection.

With #9527 in the python library I would be exactly what I am now - overly 
frustrated and with the exactly same amount of time completely lost into 
studying a bunch of tools only to realize that I should avoid using them at all 
costs.

I'm sorry if I offend somebody by posting this emotional message, I just try to 
give you another point of view - don't put restrictions and hide the reasoning. 
Instead, support the thing that is widespread and advise that in certain 
conditions there are better things to do. And if it doesn't work for some edge 
cases, or even for half the cases - place a well elaborated warning. Then if 
programmers still make the mistake - well, let them learn by it. 'Cause that's 
the way people learn .. they make mistakes. By preventing them from making the 
mistake, you actually rob them of learning.

--
nosy: +vivanov

___
Python tracker 

[issue1449496] Python should use 3GB Address Space on Windows

[Martin Gfeller Martin Gfeller]

Martin Gfeller  Martin Gfeller  added 
the comment:

Martin, we're running with this for years and with many extensions modules, 
without an issue. What is 64-bit safe should be 32-bit safe, not only 31-bit 
safe. But you're right, this is not a proof, and we have switched to 64-bit 
ourselves.

--

___
Python tracker 

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

[issue10724] socket.close close telnet with RST

[R. David Murray]

R. David Murray  added the comment:

The source used to create _socket.pyd is in Modules/socketmodule.c in the 
source code tarball available from the python web site.  As neologix says, it 
is a thin wrapper around the OS level socket library.

--
nosy: +r.david.murray
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

[issue1449496] Python should use 3GB Address Space on Windows

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

> What is 64-bit safe should be 32-bit safe, not only 31-bit safe

Not here. Python uses "signed size_t" for various lengths and sizes.
On win32 this only gives you 31 bits...

--
nosy: +amaury.forgeotdarc

___
Python tracker 

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

[issue10726] pydoc: don’t display raw reST in key word help

[R. David Murray]

R. David Murray  added the comment:

I'm not necessarily opposed to this, but an alternative is to modify 
pyspecific.py so that it generates text output from the ReST when it builds the 
pydoc topic index.

--
components: +Demos and Tools
nosy: +georg.brandl, r.david.murray

___
Python tracker 

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

[issue10725] Better cache instrumentation

[Antoine Pitrou]

Antoine Pitrou  added the comment:

The _total_size thing looks like a wildly bad idea to me, since it's so poorly 
defined (and relying on a couple of special cases).

Also, "currsize" is quite bizarre. Why not simply "size"?

--
nosy: +pitrou

___
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

[R. David Murray]

R. David Murray  added the comment:

Alexander, I agree with Velko in that it isn't obvious to me how the addition 
of localtime would answer the desire expressed in this issue.  It addresses 
Antoine's complaint about aware datetimes, but I don't see that it does 
anything for the "conversion to epoch based timestamp" issue.  That is at the 
very least a documentation issue, since IMO we should be providing our users 
with the tools they need to interoperate with the systems they need to 
interoperate with.

Velko: on the other hand, given Victor's research, I don't see float seconds 
since an epoch appearing anywhere as a standard.  Where do you see this being 
used as a standard?  I also don't understand your complaint about the fact that 
the one-liner creates a timetuple.  datetime stores the date and time 
information as discrete fields, so generating a timetuple is a natural 
conversion path.  

Obviously one could avoid the creation of a Python tuple by calling the C 
mktime directly in the C code, as has been proposed.  I don't see, myself, what 
would be so bad about providing a 'to_crt_timestamp' method that would, in 
essence, be the kind of light wrapper around the system API that we provide in 
so many other places in Python.

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

[issue2736] datetime needs an "epoch" method

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Velko: on the other hand, given Victor's research, I don't see float
> seconds since an epoch appearing anywhere as a standard.

Well, given that we already have fromtimestamp(), this sounds like a
poor argument against a totimestamp() method (or whatever it gets
called).

--

___
Python tracker 

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

[issue10726] pydoc: don’t display raw reST in key word help

[Georg Brandl]

Georg Brandl  added the comment:

No need for any of that -- the output you see already is the text output from 
Sphinx.

--

___
Python tracker 

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

[issue10726] pydoc: don’t display raw reST in key word help

[Georg Brandl]

Changes by Georg Brandl :


--
resolution:  -> works for me
status: open -> closed

___
Python tracker 

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

[issue9011] ast_for_factor unary minus optimization changes AST

[Mark Dickinson]

Mark Dickinson  added the comment:

Yes, sorry;  I'm not likely to find time to do anything with this.  
Unassigning, and downgrading priority.

Is it worth leaving this open in case anyone wants to do something about it?

--
assignee: mark.dickinson -> 
priority: high -> normal

___
Python tracker 

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

[issue10726] pydoc: don’t display raw reST in key word help

[R. David Murray]

R. David Murray  added the comment:

Well, in that case, can we change the text style for code and related markup to 
be something prettier?  Normal single quotes, perhaps?

--

___
Python tracker 

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

[issue9011] ast_for_factor unary minus optimization changes AST

[R. David Murray]

R. David Murray  added the comment:

Given the long projected lifetime of 2.7, I suppose it is.

--

___
Python tracker 

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

[issue10726] pydoc: don’t display raw reST in key word help

[R. David Murray]

R. David Murray  added the comment:

s/prettier/more readable/

--

___
Python tracker 

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

[issue10726] pydoc: don’t display raw reST in key word help

[Georg Brandl]

Georg Brandl  added the comment:

Sure, I can do that for the next version.

--

___
Python tracker 

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

[issue10155] Add fixups for encoding problems to wsgiref

[Phillip J. Eby]

Phillip J. Eby  added the comment:

So, do you have any suggestions for a specific change to the patch?

--

___
Python tracker 

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

[issue8754] ImportError: quote bad module name in message

[Georg Brandl]

Georg Brandl  added the comment:

The change would be fine with me.  What happens with the PyUnicode_FromString() 
usage in the patch if the string cannot be decoded?  That should not lead to a 
UnicodeError being raised.

Also, the __main__ changes look gratuitous to me.

--

___
Python tracker 

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

[issue10454] Clarify compileall command-line options

[Georg Brandl]

Georg Brandl  added the comment:

+1 -- Didn't read through all of the diff, but in general I trust you enough to 
believe that the new version is better than the old :)

--
nosy: +georg.brandl

___
Python tracker 

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

[issue10723] Undocumented built-in exceptions

[Georg Brandl]

Georg Brandl  added the comment:

Basically fine, but the docs for indentation and tab error should document 
their inheritance more explicitly.

--
nosy: +georg.brandl

___
Python tracker 

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

[issue9234] argparse: aliases for positional arguments (subparsers)

[Steven Bethard]

Steven Bethard  added the comment:

The patch looks basically okay to me, though this line makes me nervous:

  dest += ' (%s)' % ', '.join(aliases)

Since this is just for help formatting, can't you just modify metavar instead? 
The dest is the attribute on the namespace where the result should be stored. 
The metavar is the value that should be displayed in help messages.

As to where the aliases should be printed, I don't have a strong preference. 
The svn aliases show up when you do a generic "svn help" (but not if you do a 
"svn help blame") and looks like:

Available subcommands:
   add
   blame (praise, annotate, ann)
   ...

The hg aliases show up when you do a "hg help commit" (but not if you do a "hg 
help") and looks like:

hg commit [OPTION]... [FILE]...

aliases: ci

I guess the patch makes it pretty easy to emulate the svn version.

--

___
Python tracker 

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

[issue9234] argparse: aliases for positional arguments (subparsers)

[Georg Brandl]

Georg Brandl  added the comment:

I can see that this is really useful; approved for beta2 as soon as Steven's 
issue from the last message is handled.

--
assignee: georg.brandl -> bethard
priority: normal -> release blocker

___
Python tracker 

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

[issue10559] NameError in tutorial/interpreter

[Georg Brandl]

Georg Brandl  added the comment:

"Use that list" doesn't make me happy, what about "access"?

--
nosy: +georg.brandl

___
Python tracker 

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

[issue10609] dbm documentation example doesn't work (iteritems())

[Georg Brandl]

Georg Brandl  added the comment:

Why not replace it with an example that uses get() or setdefault() then?

--
nosy: +georg.brandl

___
Python tracker 

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

[issue9938] Documentation for argparse interactive use

[Steven Bethard]

Steven Bethard  added the comment:

In the short term, just catch the SystemExit.

In the slightly longer term, we could certainly provide a subclass, say, 
ErrorRaisingArgumentParser, that overrides .exit and .error to do nothing but 
raise an exception with the message they would have printed. We'd probably have 
to introduce a new Exception subclass though, maybe ArgumentParserExit or 
something like that.

Anyway if you're interested in this, please file a new ticket (preferably  with 
a patch). Regardless of whether we ever provide the subclass, we certainly need 
to patch the documentation to tell people how to override error and exit.

--

___
Python tracker 

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

[issue8753] Py_ReprEnter and Py_ReprLeave are undocumented

[Georg Brandl]

Georg Brandl  added the comment:

Yep, looks good, please commit.

--
assignee: d...@python -> eric.araujo
nosy: +georg.brandl

___
Python tracker 

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

[issue9264] trace.py documentation is incomplete

[Georg Brandl]

Georg Brandl  added the comment:

Yes, it's the new recommended style.  (Please add to documenting/ when 
convenient :)

--
nosy: +georg.brandl

___
Python tracker 

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

[issue10559] NameError in tutorial/interpreter

[R. David Murray]

R. David Murray  added the comment:

Attached diff provides another suggested rewording that I think is clearer.

--
nosy: +r.david.murray
Added file: http://bugs.python.org/file20093/tut_argv.diff

___
Python tracker 

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

[issue10559] NameError in tutorial/interpreter

[Georg Brandl]

Georg Brandl  added the comment:

+1.

--

___
Python tracker 

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

[issue10559] NameError in tutorial/interpreter

[R. David Murray]

Changes by R. David Murray :


Removed file: http://bugs.python.org/file20093/tut_argv.diff

___
Python tracker 

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

[issue10559] NameError in tutorial/interpreter

[R. David Murray]

Changes by R. David Murray :


Added file: http://bugs.python.org/file20094/tut_argv.diff

___
Python tracker 

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

[issue10559] NameError in tutorial/interpreter

[R. David Murray]

R. David Murray  added the comment:

Committed in r87337.

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

___
Python tracker 

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

[issue2736] datetime needs an "epoch" method

[Velko Ivanov]

Velko Ivanov  added the comment:

> on the other hand, given Victor's research, I don't see float seconds since 
> an epoch appearing anywhere as a standard.  Where do you see this being used 
> as a standard?

Yes, I didn't mean standard as in RFCed and recommended and dominant, sorry if 
it sounded that way. I meant just that it is quite common in many places, big 
and small.

> I also don't understand your complaint about the fact that the one-liner 
> creates a timetuple.  datetime stores the date and time information as 
> discrete fields, so generating a timetuple is a natural conversion path.  

Well, the timetuple is not a tuple, but an object filled with attributes. It 
contains a few more than are required for this conversion and it doesn't 
contain one that is required. Therefore I really see that as an inelegant and 
ineffective way to do the conversion.

--

___
Python tracker 

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

[issue8154] os.execlp('true') crashes the interpreter on 2.x

[R. David Murray]

R. David Murray  added the comment:

OK, this went in to 2.7 without the OS conditional, and there has been no great 
hue and cry, so I guess it was safe enough :)

As for the difference in error message between execlp and execlpe, I think 
that's fine.  The execlpe index error message is accurate: execlpe requires an 
'env' arg, and it was missing.

--
resolution:  -> accepted
stage: needs patch -> 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

[issue10454] Clarify compileall command-line options

[R. David Murray]

R. David Murray  added the comment:

Committed in r87338.  Backporting the relevant bits will be a bit of a pain, 
anyone who feels like doing it is welcome to.  I may or may not get to it 
myself.

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

___
Python tracker 

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

[issue8753] Py_ReprEnter and Py_ReprLeave are undocumented

[Daniel Stutzbach]

Daniel Stutzbach  added the comment:

Committed in r87339.  Thanks everyone for the feedback!

--
assignee: eric.araujo -> stutzbach
keywords:  -needs review
resolution:  -> accepted
stage: patch review -> committed/rejected
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

[issue10155] Add fixups for encoding problems to wsgiref

[And Clover]

And Clover  added the comment:

No, not specifically. My patch is conservative about what variables it recodes, 
yours more liberal, but it's difficult to say which is the better approach, or 
what PEP  requires.

If you're happy with the current patch, go ahead, let's have it for 3.2; I 
don't foresee significant problems with it. It's unlikely anyone is going to be 
re-using the SSL_ or REDIRECT_ variable names for something other than what 
Apache uses them for. There might be some confusion from IIS users over what 
encoding REMOTE_USER should be in, but I can't see any consistent resolution 
for that issue, and we'll certainly be in a better position than we are now.

--

___
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 Fri, Dec 17, 2010 at 9:18 AM, R. David Murray  wrote:
>
> R. David Murray  added the comment:
>
> Alexander, I agree with Velko in that it isn't obvious to me how the addition 
> of localtime
> would answer the desire expressed in this issue.

Conversion of UTC datetime to time stamp is trivial:

EPOCH = datetime(1970, 1, 1)
def timestamp(t):
  return (t - EPOCH).total_seconds()

There are several reasons not to include this one-liner in stdlib
(other than it being a one-liner).

1. Different application may need different epoch and retained
precision depends on the choice of the epoch.

2. The code above works only on naive datetime objects assumed to be
in UTC.  Passing say a result of datetime.now() to it is likely to
result in a hard to find bug.

3. While it is not hard to extend the timestamp(t) code to cover aware
datetime objects that use fixed offset tzinfo such as those with
tzinfo set to a datetime.timezone instance, it is not well defined for
the "smart" tzinfo implementations that do automatic DST adjustment.
This is where the localtime (#9527) issue comes into play.

--

___
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

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> 1. Different application may need different epoch and retained
> precision depends on the choice of the epoch.

But then why does fromtimestamp() exist?
And returning a (seconds, microseconds) tuple does retain the precision.

> 2. The code above works only on naive datetime objects assumed to be
> in UTC.

So, if the "trivial" code doesn't work, you can't bring it up as an
argument against shipping this functionality, right?

> 3. While it is not hard to extend the timestamp(t) code to cover aware
> datetime objects that use fixed offset tzinfo such as those with
> tzinfo set to a datetime.timezone instance, it is not well defined for
> the "smart" tzinfo implementations that do automatic DST adjustment.

Still, fromtimestamp() exists and apparently fulfills people's
expectations. So why can't the same strategy be used for totimestamp()
as well?

--

___
Python tracker 

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

[issue4188] Lib/threading.py causes infinite recursion when running as verbose

[R. David Murray]

R. David Murray  added the comment:

I can confirm that the patch fixes the recursion problem if threading._VERBOSE 
is set to true, but the test Antoine mentioned hangs when the test suite is run.

_VERBOSE is an internal, undocumented facility, so perhaps the priority on this 
isn't really "high".

On the other hand, Antoine's patch takes things from non-functional to at least 
partially functional, so perhaps it is worth applying as is, pending someone 
figuring out where the test hang is coming from.

I looked in to this briefly, but I have no clue how to trigger this in a unit 
test, since it seems to happen when regrtest imports logging which imports 
threading, and appears to my threading-ignorant eyes to be tied to conditions 
that only exist at initial module import.

--
nosy: +r.david.murray
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

[issue10254] unicodedata.normalize('NFC', s) regression

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

On Fri, Dec 17, 2010 at 3:47 AM, Martin v. Löwis  wrote:
..
> The worst case (wrt. cskipped) is the maximum number of characters that
> can get combined into a single base character. It used to be (and I
> hope still is) 20 (decomposition of U+FDFA).
>

The C forms (NFC and NFKC) do canonical composition and U+FDFA is a
compatibility composite. (BTW, makeunicodedata.py checks that maximum
decomposed length of a character is < 19, but it would be better if it
would compute and define a named constant, say MAXDLENGTH, to be used
instead of literal 20.)  As far as I (and a two-line script) can tell
the maximum length of a canonical decomposition of a character is 4.

--

___
Python tracker 

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

[issue10711] Rip out HTTP 0.9 client support

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Patch committed in r87340.

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

___
Python tracker 

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

[issue4188] test_threading hang when running as verbose

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Ok, I committed the patch in r87341 (3.2), r87342 (3.1) and r87343 (2.7).

--
priority: high -> normal
stage: patch review -> needs patch
title: Lib/threading.py causes infinite recursion when running as verbose -> 
test_threading hang when running as verbose

___
Python tracker 

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

[issue10725] Better cache instrumentation

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Updated to use ABCs but still relies on user objects implementing __sizeof__.  
So it is accurate whenever sys.getsizeof() is accurate.

--
Added file: http://bugs.python.org/file20095/sized_cache2.diff

___
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 Fri, Dec 17, 2010 at 12:17 PM, Antoine Pitrou  wrote:
..
>> 1. Different application may need different epoch and retained
>> precision depends on the choice of the epoch.
>
> But then why does fromtimestamp() exist?

A better question is why datetime.utcfromtimestamp(s) exists given
that it is actually longer than equivalent EPOCH + timedelta(0, s)?  I
am not responsible for either of these methods, but at least
datetime.fromtimestamp(s, tz) is well defined for any timezone and
timestamp unlike its inverse.

> And returning a (seconds, microseconds) tuple does retain the precision.
>

It does, but it does not help much those who want a float - they would
still need another line of code.  Note that with divmod(timedelta,
timedelta), you can now easily extract   (seconds, microseconds)  or
any other tuple like (weeks, days, seconds. microseconds) from
timedelta objects.  See msg75904 above.

>> 2. The code above works only on naive datetime objects assumed to be
>> in UTC.
>
> So, if the "trivial" code doesn't work, you can't bring it up as an
> argument against shipping this functionality, right?
>

Well, no one has come up with the code that does work so far.  Note
that timetuple path does not work either because it does not fill
tm_isdst correctly.  The only solution I can think of for having
proper inverse to fromtimestamp() is to add isdst to datetime objects.
 This would allow correct round-tripping between datetime and
timetuple and datetime and timestamp.

>> 3. While it is not hard to extend the timestamp(t) code to cover aware
>> datetime objects that use fixed offset tzinfo such as those with
>> tzinfo set to a datetime.timezone instance, it is not well defined for
>> the "smart" tzinfo implementations that do automatic DST adjustment.
>
> Still, fromtimestamp() exists and apparently fulfills people's
> expectations. So why can't the same strategy be used for totimestamp()
> as well?

Because in certain timezones fromtimestamp() can return the same
datetime value for different timestamps and some datetime values do
not have a corresponding timestamp.  I have not seen a working
proposal on how to handle these issues yet.  You are asking to provide
an inverse to an existing function simply because the function exists.
 But the function in question is not invertible.

--

___
Python tracker 

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

[issue10680] argparse: titles and add_mutually_exclusive_group don't mix (even with workaround)

[Mads Michelsen]

Mads Michelsen  added the comment:

@eric.araujo: What you're saying is 'if you want it done, do it yourself'? :)

--

___
Python tracker 

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

[issue2226] Small _abcoll Bugs / Oddities

[Daniel Stutzbach]

Daniel Stutzbach  added the comment:

Raymond,

Do you have around 10 minutes today to look at the patch I submitted in Issue 
8743?  It appears to solve both this issue and that one, which have priorities 
critical and high, respectively.

It's a reasonably small patch: around 20 lines changed plus 20 lines added, all 
Python code.  Here's a direct link:

http://bugs.python.org/file20045/set-with-Set.patch

If it looks good to you, I'd like to commit it in time for 3.2b2 so that it 
gets as much exercise as possible before 3.2-final.

Earlier you had expressed that adding the __rand__ methods to collections.Set 
would be tricky issue, so I'm concerned that I have overlooked something 
important and obvious.

(Feedback from others is, of course, welcome as well)

--

___
Python tracker 

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

[issue6075] Patch for IDLE/OS X to work with Tk-Cocoa

[Ned Deily]

Ned Deily  added the comment:

Thank you very much for the patch. I have updated it and modified it somewhat 
to work with the latest tip for py3k (3.2b1), 3.1.3+, and 2.7.1+ and to work 
with both AquaTk Cocoa 8.5 and preserve current behavior with legacy AquaTk 
Carbon 8.4.

Since there are no automated tests for IDLE in the standard library and since 
the issues here had to do with differences in menu cascades and options, I 
created a program to introspect IDLE menus using the OS X GUI Scripting 
interface via py-appscript.  That allowed me to semi-automatically capture the 
menu configurations for the IDLE configurations of interest (in particular, 
Apple-supplied Tk vs ActiveState Tk).  The following Tcl/Tk configurations - 
all currently, or shortly to be, supported by python.org installers - were 
tested:

OS X  Tcl/Tk
  ==
10.6  64-bit  ActSt 8.5.9 Cocoa
10.6  64-bit  Apple 8.5.7 Cocoa
10.6  32-bit  ActSt 8.4.19 Carbon
10.6  32-bit  Apple 8.4.19 Carbon
10.5  32-bit  ActSt 8.4.19 Carbon
10.5  32-bit  Apple 8.4.7 Carbon
10.4  32-bit  ActSt 8.4.19 Carbon
10.4  32-bit  Apple 8.4.7 Carbon
10.3  32-bit  ActSt 8.4.19 Carbon

Each of those Tcl/Tk configurations was tested with both IDLE.app and bin/idle, 
each with both py3k(3.2b1+) and 2.7.1+ builds, and each of those with both IDLE 
Editor windows and IDLE shell windows (they have somewhat different menu 
configurations).  Note that testing on 10.3 was much more limited since 
appscript, and hence the menutester, is not supported there.  Also no 
regressions were noted when applied to 3.1.3+ in a 32-bit only build.

So far, the recently available ActiveState 64-bit Cocoa Tcl/Tk 8.5 has proven 
to be much more stable than the Apple-supplied 8.5 version in 10.6, which had 
rendered the 64-bit versions of IDLE virtually unusable up to now.  With the 
final patches applied, I found no regressions in the menu cascades for 
IDLE.app.  When running bin/idle (from the command line), there is a slight 
difference when using Cocoa Tk vs Carbon Tk.  Both variants of AquaTk 
automatically supplies the application names from the app bundle plist. Because 
of the way bin/idle is structured today, the app name appears as "Python" 
rather than "IDLE".  With Cocoa Tk, that appears in a couple more menu items 
("About app" and "app Help") than it already does with Carbon Tk.  While that 
would be nice to fix at some point, it is an existing cosmetic issue and  I 
assume most inexperienced users will use IDLE.app, where there is no 
discrepancy.

I believe this fix is ready to be applied and should go into 3.2 (and as soon 
as possible released for 2.7) in conjunction with building the 64-bit OS X 
installer to allow use of the ActiveState Cocoa 8.5.  This will fix a number of 
reported problems with the broken IDLE with previous 64-bit OS X installers.  
Still to be done prior to release is updating the installer README and 
documenting a few minor issues.  A longer-term issue is to make the menu 
introspection tests automatic enough to be added to the standard tests as an 
optional OS X test.

--
assignee: ned.deily -> ronaldoussoren
nosy: +benjamin.peterson, georg.brandl
priority: normal -> release blocker
stage:  -> patch review
Added file: http://bugs.python.org/file20096/issue6075_py3k.patch

___
Python tracker 

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

[issue6075] Patch for IDLE/OS X to work with Tk-Cocoa

[Ned Deily]

Changes by Ned Deily :


Added file: http://bugs.python.org/file20097/issue6075_27.patch

___
Python tracker 

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

[issue10725] Better cache instrumentation

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Another thing to work out:  not double counting duplicate objects: 
 
   [1000, 2000, 3000] is bigger than [None, None, None]

--
priority: normal -> low

___
Python tracker 

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

[issue10725] Better cache instrumentation

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Updated to use ABCs but still relies on user objects implementing
> __sizeof__.  So it is accurate whenever sys.getsizeof() is accurate.

I'm really -1 on this. It's better to give no measurement than to give a
totally wrong indication. The fact that you had to special-case
containers shows that getsizeof() is *not* the right solution for this.

(because if it was, you could rely on the containers' __sizeof__ instead
of overriding it)

The "size of an object and its contents" generally doesn't make any
sense, because the object graph is massively connected. getsizeof()
gives you the basic internal footprint of the object, but that's all.
It's really not a high-level tool for the everyday programmer, and
relying on it to say how much memory would be saved by getting rid of
certain objects is bogus.

--

___
Python tracker 

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

[issue9907] interactive mode TAB does not insert on OS X built with editline instead of GNU readline

[Ned Deily]

Ned Deily  added the comment:

I believe this fix should go into 3.2 (and 2.7) as it has been reported by a 
number of people in various places and the fix risk is low.

--
nosy: +benjamin.peterson, georg.brandl
priority: normal -> release blocker

___
Python tracker 

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

[issue10404] IDLE on OS X popup menus do not work: cannot set/clear breakpoints

[Ned Deily]

Ned Deily  added the comment:

I think this should be applied for 3.2 (and 2.7 and 3.1). The risk is low and 
the benefit to OS X IDLE users is great, since without it there is no way to 
use IDLE's breakpoint facility.

--
nosy: +georg.brandl

___
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

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> >> 1. Different application may need different epoch and retained
> >> precision depends on the choice of the epoch.
> >
> > But then why does fromtimestamp() exist?
> 
> A better question is why datetime.utcfromtimestamp(s) exists given
> that it is actually longer than equivalent EPOCH + timedelta(0, s)?

??? EPOCH is not even a constant in the datetime module.

And regardless, the point is *not* the number of characters typed, but
how easy it is to come up with the solution. Calling the appropriate
(and appropriately-named) method is much easier than coming up with the
right datetime arithmetic incantation. It's Python, not Perl. "There
should be one obvious way to do it".

> > And returning a (seconds, microseconds) tuple does retain the precision.
> >
> 
> It does, but it does not help much those who want a float - they would
> still need another line of code.

Yes, but a very obvious one at least.

> Note that with divmod(timedelta,
> timedelta), you can now easily extract   (seconds, microseconds)  or
> any other tuple like (weeks, days, seconds. microseconds) from
> timedelta objects.

Do you think many users even think of calling divmod() timedelta
objects? I don't, personally.

You apparently hold the opinion that the datetime module should be
reserved for experts in arithmetic over dates, times and timedeltas. But
it's not. It's the Python stdlib and it should provide reasonably
high-level tools to do the job.

--

___
Python tracker 

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

[issue10722] IDLE's subprocess didnit make connection ..... Python 2.7

[T Rink]

T Rink  added the comment:

Thanks for your comments.

I also expect the problem is the interation of Python with Windows, but
whether they fault lies by Python or Windows I cannot say.

I can say that the problem seems to come and go away.  Last night it did not
work. This morning it did. A few minutes ago it did.  Now it does not.

 I have to my knowledge a standard installation.  Checking Google, which is
where I started in looking for a solution, shows that the error message has
occured for other people as well.

Again any suggestions are appreciated.

Thanks.

On Fri, Dec 17, 2010 at 2:25 AM, R. David Murray wrote:

>
> R. David Murray  added the comment:
>
> Perhaps Terry will have some advice (I've added him as nosy), but you may
> have better luck asking on the python mailing list (see mail.python.orgfor 
> list of lists) or its linked newsgroup comp.lang.python, or on the
> #python irc channel (though they may tell you to dump Idle, depending on who
> is in channel at the time :)
>
> It is not likely that what you are experiencing is an actual bug in Ptyhon,
> since Idle on windows works for lots of people.  However understanding your
> problem and its solution might help us make the Idle experience more
> friendly, so I'll leave it to Terry to decide how he wants to handle this.
>
> --
> nosy: +r.david.murray
>
> ___
> Python tracker 
> 
> ___
>

--
Added file: http://bugs.python.org/file20098/unnamed

___
Python tracker 

___Thanks for your comments.I also expect the problem is the interation of 
Python with Windows, but whether they fault lies by Python or Windows I cannot 
say. I can say that the problem seems to come and go away.  Last night 
it did not work. This morning it did. A few minutes ago it did.  Now it does 
not.   
 I have to my knowledge a standard installation.  Checking Google, which 
is where I started in looking for a solution, shows that the error message has 
occured for other people as well.Again any suggestions are appreciated. 

Thanks.  On Fri, Dec 17, 2010 at 2:25 AM, 
R. David Murray rep...@bugs.python.org> 
wrote:

R. David Murray rdmur...@bitdance.com> added the 
comment:

Perhaps Terry will have some advice (I've added him as nosy), but you may 
have better luck asking on the python mailing list (see http://mail.python.org"; target="_blank">mail.python.org for list of 
lists) or its linked newsgroup comp.lang.python, or on the #python irc channel 
(though they may tell you to dump Idle, depending on who is in channel at the 
time :)


It is not likely that what you are experiencing is an actual bug in Ptyhon, 
since Idle on windows works for lots of people.  However understanding your 
problem and its solution might help us make the Idle experience more friendly, 
so I'll leave it to Terry to decide how he wants to handle this.


--
nosy: +r.david.murray

___
Python tracker rep...@bugs.python.org>
http://bugs.python.org/issue10722>
___

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

[issue6791] httplib read status memory usage

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Now that 0.9 client support has been removed, this can proceed (at least for 
3.2).

--

___
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 Fri, Dec 17, 2010 at 1:17 PM, Antoine Pitrou  wrote:
..
>> A better question is why datetime.utcfromtimestamp(s) exists given
>> that it is actually longer than equivalent EPOCH + timedelta(0, s)?
>
> ??? EPOCH is not even a constant in the datetime module.
>
No, and it does not belong there.  A higher level library that uses
seconds since epoch for interchange may define it (and make a decision
whether it should be a naive datetime(1970, 1, 1) or datetime(1970, 1,
1, tzinfo=timezone.utc)).

> And regardless, the point is *not* the number of characters typed, but
> how easy it is to come up with the solution. Calling the appropriate
> (and appropriately-named) method is much easier than coming up with the
> right datetime arithmetic incantation. It's Python, not Perl. "There
> should be one obvious way to do it".
>

I don't see anything obvious about the choice between
utcfromtimestamp(s), fromtimestamp(s) and utcfromtimestamp(s,
timezone.utc).

datetime(1970, 1, 1) + timedelta(seconds=s)

is obvious, self-contained,  short and does not require any knowledge
other than elementary school arithmetic to understand.  Compared to
this, "utcfromtimestamp" is a monstrosity that suggests that something
non-trivial, such as UTC leap seconds is been taken care of.

>> > And returning a (seconds, microseconds) tuple does retain the precision.
>> >
>>
>> It does, but it does not help much those who want a float - they would
>> still need another line of code.
>
> Yes, but a very obvious one at least.
>

Let's see:

def floattimestamp(t):
  s, us = t.totimestamp()
  return s + us * 1e-6

and

def floattimestamp(t):
  s, us = t.totimestamp()
  return s + us / 100

which one is *obviously* correct?  Are they *obviously* equivalent?

Note that when timedelta.total_seconds() was first committed, it
contained a numerical bug.  See issue8644.

>> Note that with divmod(timedelta,
>> timedelta), you can now easily extract   (seconds, microseconds)  or
>> any other tuple like (weeks, days, seconds. microseconds) from
>> timedelta objects.
>
> Do you think many users even think of calling divmod() timedelta
> objects? I don't, personally.
>
> You apparently hold the opinion that the datetime module should be
> reserved for experts in arithmetic over dates, times and timedeltas. But
> it's not. It's the Python stdlib and it should provide reasonably
> high-level tools to do the job.
>

Sure, but if the goal is to implement json serialization of datetime
objects, maybe stdlib should provide a high-level tool for *that* job?
  Using float representation of datetime is probably the worst option
for json: it is non-standard, may either loose information or
introduce spurious differences, and is not human-readable.

In any case, you ignore the hard question about totimestamp():
fromtimestamp() is not invertible in most real life timezones.  If you
have a solution that does not restrict totimestamp() to UTC, I would
like to hear it.  Otherwise, I don't see any problem with (t -
datetime(1970, 1, 1)).total_seconds() expression.  Maybe we can add
this recipe to utcfromtimestamp() documentation.

--

___
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

[Miki Tebeka]

Changes by Miki Tebeka :


--
nosy:  -tebeka

___
Python tracker 

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

[issue10254] unicodedata.normalize('NFC', s) regression

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> The C forms (NFC and NFKC) do canonical composition and U+FDFA is a
> compatibility composite. (BTW, makeunicodedata.py checks that maximum
> decomposed length of a character is < 19, but it would be better if it
> would compute and define a named constant, say MAXDLENGTH, to be used
> instead of literal 20.)  As far as I (and a two-line script) can tell
> the maximum length of a canonical decomposition of a character is 4.

Even better - so allowing for 20 characters should be safe.

--

___
Python tracker 

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

[issue10723] Undocumented built-in exceptions

[flashk]

flashk  added the comment:

I just attached a new patch that explicitly mentions the inheritance of 
IndentationError and TabError.

--
Added file: http://bugs.python.org/file20099/exceptions_2.diff

___
Python tracker 

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

[issue10254] unicodedata.normalize('NFC', s) regression

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

On Fri, Dec 17, 2010 at 2:08 PM, Martin v. Löwis  wrote:
..
>> As far as I (and a two-line script) can tell
>> the maximum length of a canonical decomposition of a character is 4.
>
> Even better - so allowing for 20 characters should be safe.

I don't disagree, but the number of "break" and "continue" statements
before cskipped++ makes me nervous.  This said, I am going to  add
test cases from the first post to test_unicodedata (I think it is a
better place than test_normalise because the latter is skipped by
default) and commit.

Improving the algorithm is a separate issue.

--

___
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

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> > ??? EPOCH is not even a constant in the datetime module.
> >
> No, and it does not belong there.

And so what was your point exactly?

> A higher level library that uses
> seconds since epoch for interchange

I don't think the "time" module can be named "higher level", and it
still handles such timestamps.

> datetime(1970, 1, 1) + timedelta(seconds=s)
> 
> is obvious, self-contained,  short and does not require any knowledge
> other than elementary school arithmetic to understand.

Sigh.
Again: it's so obvious that you're the only one who seems to easily come
up with those solutions. How many times does it have to be repeated?

> Compared to
> this, "utcfromtimestamp" is a monstrosity that suggests that something
> non-trivial, such as UTC leap seconds is been taken care of.

I don't see anything suggesting it is a monstrosity. The name is
grammatically bizarre, but that's all.

> Let's see:
> [snip]
>
> which one is *obviously* correct?  Are they *obviously* equivalent?

Both are obviously correct for whatever the non-perverted user has in
mind. People in real life don't care whether they will retain
microsecond precision when carrying a floating point timestamp around.
For the simple reason that the data source itself will not have such
precision.

> Note that when timedelta.total_seconds() was first committed, it
> contained a numerical bug.  See issue8644.

So? What is your point?

> In any case, you ignore the hard question about totimestamp():
> fromtimestamp() is not invertible in most real life timezones.  If you
> have a solution that does not restrict totimestamp() to UTC, I would
> like to hear it.

IMO, the solution would have the datetime object carry the offset from
UTC with it, rather than try to be smart and compute it dynamically.

--

___
Python tracker 

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

[issue10725] Better cache instrumentation

[Raymond Hettinger]

Changes by Raymond Hettinger :


Removed file: http://bugs.python.org/file20095/sized_cache2.diff

___
Python tracker 

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

[issue6791] httplib read status memory usage

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Here is a patch limiting line length everywhere in http.client, + tests (it 
also affects http.server since the header parsing routine is shared).

--
stage: needs patch -> patch review
Added file: http://bugs.python.org/file20100/httplinelength.patch

___
Python tracker 

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

[issue10727] intermittent test_cmd_line failure

[Antoine Pitrou]

New submission from Antoine Pitrou :

It really looks like a subprocess issue:

==
ERROR: test_usage (test.test_cmd_line.CmdLineTest)
--
Traceback (most recent call last):
  File 
"/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/test_cmd_line.py", 
line 43, in test_usage
rc, out, err = assert_python_ok('-h')
  File 
"/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py", 
line 50, in assert_python_ok
return _assert_python(True, *args, **env_vars)
  File 
"/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py", 
line 30, in _assert_python
env=env)
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/subprocess.py", 
line 721, in __init__
self.stdin = io.open(p2cwrite, 'wb', bufsize)
OSError: [Errno 9] Bad file descriptor


See 
http://www.python.org/dev/buildbot/all/builders/PPC%20Tiger%203.x/builds/1213/steps/test/logs/stdio

--
assignee: gregory.p.smith
components: Library (Lib)
messages: 124254
nosy: gregory.p.smith, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: intermittent test_cmd_line failure
type: behavior
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

[issue2736] datetime needs an "epoch" method

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

On Fri, Dec 17, 2010 at 2:35 PM, Antoine Pitrou  wrote:
..
> I don't think the "time" module can be named "higher level", and it
> still handles such timestamps.
>
>> datetime(1970, 1, 1) + timedelta(seconds=s)
>>
>> is obvious, self-contained,  short and does not require any knowledge
>> other than elementary school arithmetic to understand.
>
> Sigh.
> Again: it's so obvious that you're the only one who seems to easily come
> up with those solutions. How many times does it have to be repeated?
>

Remember, most of the code is written once, but read and edited many
times.  Show me one person who will have trouble understanding what
datetime(1970, 1, 1) + timedelta(seconds=s) means and show me another
who can understand datetime.utcfromtimestamp(s) without reading the
manual.

>> Compared to
>> this, "utcfromtimestamp" is a monstrosity that suggests that something
>> non-trivial, such as UTC leap seconds is been taken care of.
>
> I don't see anything suggesting it is a monstrosity. The name is
> grammatically bizarre, but that's all.
>

Yes, UTC not being a proper acronym in any human language is one
problem, Python datetime not being able to represent some valid UTC
times is another.

That's correct, but most users expect their timestamps to be the same
when saved on one system and read on another.  Granted, most users
expect the same from their floats as well, but this can only be solved
by education.   Calendaric calculations are complex enough that we
don't want to expose users to floating point gotchas at the same time.

>> Note that when timedelta.total_seconds() was first committed, it
>> contained a numerical bug.  See issue8644.
>
> So? What is your point?
>

I thought the point was obvious: conversion between time values and
float is non-trivial and error prone.  Users should not be encouraged
to casually convert (seconds, microseconds) tuples to floats.  If they
do, chances are they will do it differently in different parts of the
program.

>> In any case, you ignore the hard question about totimestamp():
>> fromtimestamp() is not invertible in most real life timezones.  If you
>> have a solution that does not restrict totimestamp() to UTC, I would
>> like to hear it.
>
> IMO, the solution would have the datetime object carry the offset from
> UTC with it, rather than try to be smart and compute it dynamically.
>

Ditto.  This is exactly what issue9527 is attempting to achieve.

--

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

Changes by Alexander Belopolsky :


--
nosy:  -Alexander.Belopolsky
versions: +Python 3.3 -Python 3.2

___
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

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Yes, UTC not being a proper acronym in any human language is one
> problem,

Ok. Too bad you don't live on the same planet than most of us. I bail
out.

--

___
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 Fri, Dec 17, 2010 at 3:26 PM, Antoine Pitrou  wrote:
..
>
>> Yes, UTC not being a proper acronym in any human language is one
>> problem,
>
> Ok. Too bad you don't live on the same planet than most of us. I bail
> out.

Sorry that my attempt at humor has proven to be too subtle.  I was
referring to the following fact:

"""
The International Telecommunication Union wanted Coordinated Universal
Time to have the same symbol in all languages. English and French
speakers wanted the initials of both their respective language's terms
to be used internationally: "CUT" for "coordinated universal time" and
"TUC" for "temps universel coordonné". This resulted in the final
compromise of "UTC".
"""

http://en.wikipedia.org/wiki/Coordinated_Universal_Time

--

___
Python tracker 

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

[issue2690] Precompute range length and enhance range subscript support

[Daniel Stutzbach]

Daniel Stutzbach  added the comment:

Doc change committed to py3k in r87346.  Thanks, SilentGhost!

I also committed r87349 to reverse r87162 (which was in the wrong branch).

--

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

It looks like it's not possible to choose between float and (int, int) output 
type for datetime.totimestamp(). One is more practical (and enough for people 
who doesn't need an exact result), and one is needed to keep the same 
resolution than the datetime object. I think that we can add two methods:
 * datetime.totimestamp()->float
 * datetime.totimestamptuple()->(int,int)

I choosed the shortest name for float because I suppose that most users prefer 
float than a tuple, and so the API is symmetrical:
 * datetime.fromtimestamp(float)->datetime
 * datetime.totimestamp()->float

My patch have to be updated to use the timezone (and the DST thing?) and also 
to update the Python implementation.

--

___
Python tracker 

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

[issue8753] Py_ReprEnter and Py_ReprLeave are undocumented

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Err... in r87339 there is a typo in all occurrences of 'Py_ReprEntr': 
Py_ReprEnter of course!

--
nosy: +amaury.forgeotdarc
status: closed -> open

___
Python tracker 

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

[issue8753] Py_ReprEnter and Py_ReprLeave are undocumented

[Daniel Stutzbach]

Daniel Stutzbach  added the comment:

On Fri, Dec 17, 2010 at 2:17 PM, Amaury Forgeot d'Arc wrote wrote:
> Err... in r87339 there is a typo in all occurrences of
> 'Py_ReprEntr': Py_ReprEnter of course!

Well, that's embarrassing.  Fixed in r87354.

--

___
Python tracker 

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

[issue8753] Py_ReprEnter and Py_ReprLeave are undocumented

[Daniel Stutzbach]

Changes by Daniel Stutzbach :


--
status: open -> closed

___
Python tracker 

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

[issue1449496] Python should use 3GB Address Space on Windows

[Jason Scheirer]

Jason Scheirer  added the comment:

I would like to see this reopened: we have a very large class of users that are 
not ready to entirely port to 64-bit and need this now.

When running a Python script from within a desktop application (which embeds 
Python and has /LARGEADDRESSAWARE set) or outside in Python.exe (which does 
not) results in the outputs from the tools calling out to these 32 bit 
libraries to produce different outputs because the amount of data they are able 
to allocate and process at the same time. The same Python script that gives 
correct output on a large dataset in this desktop app will not yield the same 
quality of results when run overnight as a stand-alone Python script. 
Essentially this discounts Python scripts as an option for automation in this 
case.

I understand that yes, applications still cannot allocate more CONTIGUOUS 
memory, but this is not a regression if it continues to be so. Allowing the 
process to allocate more TOTAL memory is a net benefit, especially on on 
complex software systems that can't simply be rebuilt in 64 bit mode due to 
third-party restraints (tied to a specific library version, lack of access to 
source, lengthy software approvals processes, etc.)

--

___
Python tracker 

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

[issue1449496] Python should use 3GB Address Space on Windows

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> When running a Python script from within a desktop application (which
> embeds Python and has /LARGEADDRESSAWARE set) [...]. Essentially this
> discounts Python scripts as an option for automation in this case.

Well, if you already embed Python in your application, you can probably also 
embed it in a simple console application which will enable automation, can't 
you?

--
nosy: +pitrou

___
Python tracker 

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

[issue10685] trace does not ignore --ignore-module

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Please try the recent 2.7.1 release. This needs to be tested with current 3.1.3 
or 3.1.b+ also.

--
nosy: +eli.bendersky, terry.reedy
title: trace does nto ignore --ignore-module -> trace does not ignore 
--ignore-module

___
Python tracker 

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

[issue10702] bytes and bytearray methods are not documented

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
nosy: +terry.reedy

___
Python tracker 

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

[issue10723] Undocumented built-in exceptions

[Terry J. Reedy]

Changes by Terry J. Reedy :


Removed file: http://bugs.python.org/file20084/exceptions.rst

___
Python tracker 

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

[issue9234] argparse: aliases for positional arguments (subparsers)

[Adrian Sampson]

Adrian Sampson  added the comment:

Thanks for the suggestion, Steven. I hadn't yet internalized the difference 
between dest and metavar.

This version of the patch modifies metavar instead. Because it looks like this 
issue is up for 3.2b2, I've modified NEWS and ACKS (I hope this was the right 
thing to do).

I also see the logic behind both help styles Steven depicts. If there's any 
interest, I can implement the other (hg) style or make it an option.

--
Added file: http://bugs.python.org/file20101/argparse-aliases.patch

___
Python tracker 

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

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

[STINNER Victor]

STINNER Victor  added the comment:

Version 9 of my patch:
 - Create PYTHONNOHANDLER environment variable: don't install the signal 
handler if the variable is set
 - Rename "Segfault" by "FaultHandler"
 - reverse_string() does nothing if len==0, even if it cannot occur when it's 
called by dump_decimal() and dump_hexadecimal().
 - _Py_DumpBacktrace() only writes the first 100 frames (arbitrary limit) to 
avoid unlimited loops

I don't know 100 frames is a good limit or not. Is it enough?

Summary of the patch:
 - Add a fault handler for SIGSEGV, SIGFPE, SIGBUS and SIGILL signals: display 
the Python backtrace and abort the process (call the debugger on Windows)
 - Add PYTHONNOHANDLER environment variable to disable the fault handler
 - The fault handler is implemented using only very simple instructions: it 
calls only signal-safe functions and it doesn't allocate memory (on the heap, 
only some bytes on the stack)
 - The fault handler uses an alternate stack to be able to display the 
backtrace (to be able to allocate memory on the stack and call functions)

The fault handler has no more the infinite loop issue (because the backtrace is 
truncated on frame loop).

--
Added file: http://bugs.python.org/file20102/segfault_handler-9.patch

___
Python tracker 

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

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

[STINNER Victor]

Changes by STINNER Victor :


Removed file: http://bugs.python.org/file19214/segfault_handler-5.patch

___
Python tracker 

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

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

[STINNER Victor]

Changes by STINNER Victor :


Removed file: http://bugs.python.org/file19227/segfault_handler-6.patch

___
Python tracker 

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

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

[STINNER Victor]

Changes by STINNER Victor :


Removed file: http://bugs.python.org/file19288/segfault_handler-7.patch

___
Python tracker 

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

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

[STINNER Victor]

Changes by STINNER Victor :


Removed file: http://bugs.python.org/file19289/segfault_handler-8.patch

___
Python tracker 

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

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

[STINNER Victor]

STINNER Victor  added the comment:

Oh, I'm tired...

> Summary of the patch:
> - ...abort the process (call the debugger on Windows)

(the debugger is only called if Python is compiled in debug mode)

> - Add PYTHONNOHANDLER environment variable ...

Oops, the correct name is PYTHONNOFAULTHANDLER (no fault handler).

--

___
Python tracker 

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

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Why was sys.setsegfaultenabled() omitted?
It may be useful to disable the handler from a script

--
nosy: +amaury.forgeotdarc

___
Python tracker 

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

[issue6454] Add "example" keyword argument to optparse constructor

[Greg Ward]

Greg Ward  added the comment:

> I understood Greg’s reply to mean that there was no need for an examples 
> keyword if simple paragraph splitting was added.

Right, but optparse has been superseded by argparse.  So my opinion is even 
less important than it was before 2.7.

--

___
Python tracker 

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

[issue1449496] Python should use 3GB Address Space on Windows

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> I would like to see this reopened: we have a very large class of
> users that are not ready to entirely port to 64-bit and need this
> now.

And I remain -1 to such requests. You can appeal to that by writing a
PEP, or finding a committer who is willing to make this change.

Alternatively, just provide these users with binaries that you built
yourself, or hire somebody to build such binaries for you.

> I understand that yes, applications still cannot allocate more
> CONTIGUOUS memory, but this is not a regression if it continues to be
> so. 

It would be a regression if Python started crashing because of that
change, which is my concern.

--

___
Python tracker 

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

[issue10728] argparse.ArgumentParser.print_help uses sys.stdout

[Silvio Ricardo Cordeiro]

New submission from Silvio Ricardo Cordeiro :

The documentation at http://docs.python.org/dev/library/argparse.html 
explicitly says that "If file is None, sys.stderr is assumed".

However, both print_usage and print_help assume sys.stdout when file=None. The 
helper method _print_message actually does it right, when called with file=None.

--
components: Library (Lib)
messages: 124271
nosy: silvioricardoc
priority: normal
severity: normal
status: open
title: argparse.ArgumentParser.print_help uses sys.stdout
type: behavior
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

[issue9907] interactive mode TAB does not insert on OS X built with editline instead of GNU readline

[R. David Murray]

R. David Murray  added the comment:

Committed to py3k in 87356 and 2.7 in r87358.

--
nosy: +r.david.murray
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue10728] argparse.ArgumentParser.print_help uses sys.stdout

[R. David Murray]

R. David Murray  added the comment:

I think this is a documentation bug, since IMO help should print on stdout, not 
stderr[1].  I would expect print_usage to do likewise, but for the error to 
tell print_usage to write to stderr when it calls it...which is exactly what 
the code does.

[1] I know some unix commands print help to stderr, and this really annoys me 
when I pipe long help output to lessand it *still* scrolls off the screen.

--
assignee:  -> d...@python
components: +Documentation -Library (Lib)
nosy: +bethard, d...@python, r.david.murray
stage:  -> needs patch

___
Python tracker 

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