[issue8970] Tkinter Litmus Test

[Rick Johnson]

New submission from Rick Johnson :

There has been much discussion in the past and recently on c.l.p about how many 
python programmers *actually* use Tkinter. Recently i have been involved in a 
lengthy discussion on c.l.p about whether or not we should remove Tkinter, 
replace Tkinter, or fix Tkinter. 

However i feel a decision this important cannot be made from pydev, c.l.p, or 
anywhere. I believe the only proper way to proceed is to get a *real* vote from 
*real* python programmers out in the trenches. 

But how do we do that you may ask? Well thats a good question. Not every Python 
programmer lives on c.l.p, or any *one* place. The only way to truly reach 
everyone is thru Python itself in form of a Warning message. 

So i propose that an import warning be added to the next possible releases of 
Python 3.x and Python 3.x. This warning will be triggered upon importing 
Tkinter and should also be shown when starting IDLE. The message should read 
loosely as follows...

"""
-
 ModuleRemovalWarning: Tkinter (and dependencies)
-
The Tkinter module (Python's GUI module) is currently being considered for 
removal from the python stdlib FOREVER. We are providing this warning so that 
you can give the python devlopment team (and the wider community) your input on 
the subject. If you feel that Tkinter should or should not be removed we 
strongly incurage you to voice your opinion. You can do by casting your vote at 
"www.savetkinter.com". Whether your a complete noobie or a seasoned Pythonista 
we need to hear everyone. Voting will end on MM-DD-, so make sure your vote 
is counted!
"""

--
components: IDLE, Tkinter
messages: 107531
nosy: rantingrick
priority: normal
severity: normal
status: open
title: Tkinter Litmus Test
type: feature request
versions: Python 2.7, Python 3.3

___
Python tracker 

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

[issue8971] Tkinter Litmus Test

[Rick Johnson]

New submission from Rick Johnson :

There has been much discussion in the past and recently on c.l.p about how many 
python programmers *actually* use Tkinter. Recently i have been involved in a 
lengthy discussion on c.l.p about whether or not we should remove Tkinter, 
replace Tkinter, or fix Tkinter. 

However i feel a decision this important cannot be made from pydev, c.l.p, or 
anywhere. I believe the only proper way to proceed is to get a *real* vote from 
*real* python programmers out in the trenches. 

But how do we do that you may ask? Well thats a good question. Not every Python 
programmer lives on c.l.p, or any *one* place. The only way to truly reach 
everyone is through Python itself in form of a Warning message. 

So i propose that an import warning be added to the next possible releases of 
Python 2.x and Python 3.x. This warning will be triggered upon importing 
Tkinter and should also be shown when starting IDLE. The message should read 
loosely as follows...

"""
-
 ModuleRemovalWarning: Tkinter (and dependencies)
-
The Tkinter module (Python's GUI module) is currently being considered for 
removal from the python stdlib FOREVER. We are providing this warning so that 
you can give the python development team (and the wider community) your 
feedback on the subject. If you feel that Tkinter should or should not be 
removed we strongly encourage you to voice your opinion. You can do by casting 
your vote at "www.savetkinter.com". We need to hear everyone whether your a 
complete newbie or a seasoned Pythonista.  Voting will end on MM-DD-  so 
make sure your vote is counted!
"""

--
components: IDLE, Tkinter
messages: 107532
nosy: rantingrick
priority: normal
severity: normal
status: open
title: Tkinter Litmus Test
type: feature request
versions: Python 2.7, Python 3.3

___
Python tracker 

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

[issue8970] Tkinter Litmus Test

[Rick Johnson]

Changes by Rick Johnson :


--
status: open -> closed

___
Python tracker 

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

[issue8954] wininst regression: errors when building on linux

[anatoly techtonik]

anatoly techtonik  added the comment:

$ python setup.py build bdist_wininst
running build
running build_py
running bdist_wininst
installing to build/bdist.linux-i686/wininst
running install_lib
creating build/bdist.linux-i686/wininst
creating build/bdist.linux-i686/wininst/PURELIB
copying build/lib.linux-i686-2.6/wget.py -> 
build/bdist.linux-i686/wininst/PURELIB
running install_egg_info
Writing build/bdist.linux-i686/wininst/PURELIB/wget-0.6.egg-info
creating '/tmp/tmpQQZI5O.zip' and adding '.' to it
adding 'PURELIB/wget-0.6.egg-info'
adding 'PURELIB/wget.py'
creating dist
Warning: Can't read registry to find the necessary compiler setting
Make sure that Python modules _winreg, win32api or win32con are installed.
removing 'build/bdist.linux-i686/wininst' (and everything under it)
$ ls dist
wget-0.6.linux-i686.exe

--

___
Python tracker 

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

[issue8970] Tkinter Litmus Test

[Éric Araujo]

Changes by Éric Araujo :


--
resolution:  -> duplicate
superseder:  -> Tkinter Litmus Test

___
Python tracker 

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

[issue8924] Error in error message in logging

[Peter Landgren]

Peter Landgren  added the comment:

Answer to your first question:
- The variable s is of type 'unicode'
- The variable record.exc_text, which is what Formatter.formatException 
returns, is of type 'str'

For your second question; I'm not a python expert, so I can't follow you there. 
I don't know what to do to test this.

--

___
Python tracker 

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

[issue8954] wininst regression: errors when building on linux

[Éric Araujo]

Éric Araujo  added the comment:

The error comes from the msvccompiler module, which shouldn’t get used on 
non-Windows platforms unless I’m mistaken. Reading the module, I’m not sure at 
all this command was meant to be run on not-Windows OSes.

--
nosy: +merwok

___
Python tracker 

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

[issue8954] wininst regression: errors when building on linux

[anatoly techtonik]

anatoly techtonik  added the comment:

It did run ok on non-Windows OSes with previous Python versions.

--

___
Python tracker 

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

[issue2892] improve cElementTree iterparse error handling

[Hrvoje Nikšić]

Hrvoje Nikšić  added the comment:

Here is a small test case that demonstrates the problem, expected behavior and 
actual behavior:

{{{
for ev in xml.etree.cElementTree.iterparse(StringIO('rubbish'), 
events=('start', 'end')):
print ev
}}}

The above code should first print the two events (start and end), and then 
raise the exception.  In Python 2.7 it runs like this:

{{{
>>> for ev in xml.etree.cElementTree.iterparse(StringIO('rubbish'), 
>>> events=('start', 'end')):
...   print ev
... 
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 84, in next
cElementTree.ParseError: junk after document element: line 1, column 7
}}}

Expected behavior, obtained with my patch, is that it runs like this:

{{{
>>> for ev in my_iterparse(StringIO('rubbish'), events=('start', 'end')):
...  print ev
... 
('start', )
('end', )
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 26, in __iter__
cElementTree.ParseError: junk after document element: line 1, column 7
}}}

The difference is, of course, only visible when printing events.  A 
side-effect-free operation, such as building a list using list(iterparse(...)) 
would behave exactly the same before and after the change.

--

___
Python tracker 

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

[issue8362] Add Misc/maintainers.rst to 2.x branch

[Éric Araujo]

Éric Araujo  added the comment:

I am willing to maintain the maintainers file for 2.x with due diligence for 
the coming years. I think it has proven useful, and would like to see it in 2.6 
up to 3.2 (all current four branches, since it’s arguably a documentation 
issue). Do I need to find a unique committer willing to work with me for this 
to be accepted?

--

___
Python tracker 

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

[issue8188] Unified hash for numeric types.

[Mark Dickinson]

Mark Dickinson  added the comment:

Committed the Decimal-to-Fraction comparisons in r81893.  All numeric types 
should now compare nicely with each other.

--

___
Python tracker 

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

[issue8958] 2.7rc1 tarfile.py: `bltn_open(targetpath, "wb")` -> IOError: Is a directory

[Lars Gustäbel]

Lars Gustäbel  added the comment:

I found the problem. As of r76780 the default for the TarFile.errorlevel 
argument changed from 0 (suppress errors and write them to the debug log 
instead) to 1 (raise exceptions for fatal extraction errors). This change was 
not backported to the 2.6 branch back then (it was blocked in r76781).

This means, that Python 2.6 does not succeed either, but the error is simply 
suppressed.

Ergo, this is no regression but a simple filesystem issue.

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

[issue8971] Tkinter Litmus Test

[R. David Murray]

R. David Murray  added the comment:

Everyone who uses IDLE uses TKInter, and a lot of people use IDLE.

In any case, any such proposal should be discussed on python-ideas first, 
followed by python-dev if you actually get a consensus about it.

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

[issue8947] Provide as_integer_ratio() method to Decimal

[Mark Dickinson]

Mark Dickinson  added the comment:

Here's a patch.

--
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file17626/issue8947.patch

___
Python tracker 

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

[issue8947] Provide as_integer_ratio() method to Decimal

[Mark Dickinson]

Mark Dickinson  added the comment:

Updated patch, taking into account comments from merwok and exarkun on 
#python-dev:

 - remove doctests for infinity and nan, replace with a sentence
   explaining what happens for such inputs.
 - replace 'snAN' with saner spelling 'snan'.

--
Added file: http://bugs.python.org/file17627/issue8947_2.patch

___
Python tracker 

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

[issue8972] subprocess.list2cmdline doesn't quote the & character

[shypike]

New submission from shypike :

subprocess.py/list2cmdline should also put double quotes around strings that 
contain ampersands (&), but no spaces.
If not, the Windows command processor will split the command into two separate 
parts. In short, '&' needs the same treatment as '|'.

--
components: Windows
messages: 107544
nosy: shypike
priority: normal
severity: normal
status: open
title: subprocess.list2cmdline doesn't quote the & character
type: behavior
versions: Python 2.5, Python 2.6

___
Python tracker 

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

[issue5094] datetime lacks concrete tzinfo impl. for UTC

[Mark Dickinson]

Mark Dickinson  added the comment:

I'm not sure if I missed this in the earlier discussion:  is there a reason to 
prevent subclassing of timezone?

--

___
Python tracker 

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

[issue5094] datetime lacks concrete tzinfo impl. for UTC

[Mark Dickinson]

Mark Dickinson  added the comment:

Some comments from playing with this patch (without having looked at the 
implementation):

- As noted above, the 'timezone' class can't be subclassed.  Is this 
deliberate?  I notice that Brett said "let users subclass as needed to add DST 
support" in msg107008.

- If I try to do  timezone(timedelta(hours=24)), I get an error message:
"ValueError: offset must be a timedelta between timedelta(1) and 
-timedelta(1)." and I have to think for a bit to remember that 'timedelta(1)' 
means 'timedelta(days=1)'.  Any chance of making this more explicit:  e.g. 
"between timedelta(hours=-24) and timedelta(hours=24)"?

- The existing docs say, at one point: "if utcoffset does not return None,
dst() should not return None either."  And yet it seems that this is exactly 
what happens for timezone instances:  utcoffset doesn't return None, but dst 
does.  Was there a reason for the explicit restriction in the docs, and are we 
sure that that reason is no longer valid?

- I find it strange that mytimezone.utcoffset(1+3j) works;  similarly for 
tzname and dst.  Perhaps it should be checked at least that the argument is a 
datetime.  Similarly for tzname and dst.

- And it also seems clunky that an argument *has* to be supplied for utcoffset, 
tzname and dst, only to be ignored.  Would it be possible to make the argument 
optional?

- Any chance of a nice __str__ implementation for timezone instances?  (And/or 
possibly a nice __repr__ as well)?

- The docs for tzname are misleading:  they claim that the default name has the 
form "UTCsHHMM".  This isn't true for UTC+0, whose name seems to be just "UTC". 
 It actually wouldn't seem unreasonable to have this print as "UTC+", just 
for consistency (and for ease of parsing for anyone on the receiving end of 
such a string).  Or the docs could be fixed.

- I'm very confused about utcoffset:  why can't I supply a UTC datetime (i.e. 
an aware datetime with tzinfo = timezone.utc) to this?  I suspect I'm 
misunderstanding something here...

- In the docs, replace "timezeone" with "timezone"

--

___
Python tracker 

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

[issue5094] datetime lacks concrete tzinfo impl. for UTC

[Mark Dickinson]

Mark Dickinson  added the comment:

One more: there's a footnote marked in the docs (line 36 of datetime.rst), but 
no corresponding footnote as far as I can see.

--

___
Python tracker 

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

[issue5094] datetime lacks concrete tzinfo impl. for UTC

[Mark Dickinson]

Mark Dickinson  added the comment:

And another minor doc issue:  the docs still say:

"The datetime module does not supply any concrete subclasses of tzinfo."

--

___
Python tracker 

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

[issue6641] strptime doesn't support %z format ?

[Mark Dickinson]

Mark Dickinson  added the comment:

It's a little awkward to review this patch independently of the issue 5094 
patch.  Can we work on issue 5094 first, and then come back to this one?

--

___
Python tracker 

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

[issue3129] struct allows repeat spec. without a format specifier

[Mark Dickinson]

Mark Dickinson  added the comment:

Thanks for the patch; I'll take a look.

--
assignee: belopolsky -> mark.dickinson
nosy: +mark.dickinson

___
Python tracker 

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

[issue1697943] msgfmt cannot cope with BOM

[Éric Araujo]

Changes by Éric Araujo :


--
nosy: +merwok

___
Python tracker 

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

[issue5094] datetime lacks concrete tzinfo impl. for UTC

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

On Fri, Jun 11, 2010 at 10:23 AM, Mark Dickinson  wrote:
..
> Some comments from playing with this patch (without having looked at the 
> implementation):
>
thank you very much for your comments.  As we are fine-tuning the
timezone class, do you think it would be helpful to go back to Brett's
suggestion and add datetime.py with just from _datetime import * and
keep parallel Python and C implementations of timezone class only
until full datetime.py is available?

I was deliberate in a sense that I thought about it, but there was no
substantial discussion.  Original patch did not allow subclassing of
the UTC class and I thought it was right.  (See msg106415 and
msg106422.) subclassing FixedOffsetTimeZone makes more sense, but I
was hoping to keep timezone complete and eventually stop supporting
tzinfo API (not allow passing datetime in the methods.)  More on this
below.  I would very much prefer not to open the subclassing debate.
If you support subclassing, I will add a flag. My only objection is
that it is much easier to add this functionality in the future than to
remove it if it gets abused.  Can we postpone this decision until real
life use case comes in?  (Subclass to change dst() in itself is not a
use case.  Why do you need legacy timetuple interface to work is the
first question.)

> - If I try to do  timezone(timedelta(hours=24)), I get an error message:
> "ValueError: offset must be a timedelta between timedelta(1) and 
> -timedelta(1)." and I have to think for a bit to
> remember that 'timedelta(1)' means 'timedelta(days=1)'.  Any chance of making 
> this more explicit:  e.g. "between > timedelta(hours=-24) and 
> timedelta(hours=24)"?
>

Please make a call and I'll implement it.  The competing spellings are:

1. timedelta(hours=24)
2. 24 hours (I rejected this because it may be confused with an int)
3. timedelta(days=1)
4. in the range [-timedelta(hours=23, minutes=59), timedelta(hours=23,
minutes=59)]

Yes, there was a reason, but I don't think it is a good one.  The
default implementation of fromutc() does not work if utcoffset()
returns timedelta but dst() returns None.  The dst() value used to
detect DST ambiguities.  Remember, fromutc() despite the name is
defined to operate on local times and some local times are ambiguous
and some are invalid.  The default implementation attempts to detect
that.  This is the issue that I am trying to avoid in my design.

The test is easy to add.  My longer term plan is to disallow passing
argument to constant methods, so adding check is somewhat wasteful.
Will do.

> - And it also seems clunky that an argument *has* to be supplied for 
> utcoffset, tzname and dst, only to be i
> gnored.  Would it be possible to make the argument optional?

Yes.  this was my transition plan.  Make it optional.  Modify datetime
methods to first try to get offset/name/dst without passing time
argument and fall back to passing self.  Remove optional argument from
timezone methods.

Yes.  I want parseable __repr__ as well.  I've been torn between
'datetime.timezone(datetime.timedelta(..)[, ..])'  and
'timezone(timedelta(..)[, ..])'. Opinions welcome.  Similarly, should
str(timezone.utc) be '+' or 'UTC' or '+00:00'?

You are reading my mind.  I planned to tear out conditional logic that
supports plain 'UTC', but apparently forgot.  Will do.

> - I'm very confused about utcoffset:  why can't I supply a UTC datetime (i.e. 
> an aware datetime with
> tzinfo = timezone.utc) to this?  I suspect I'm misunderstanding something 
> here...

You are not alone! :-)  My understanding is that utcoffset was
designed around the notion that if you add a day to 12 noon the day
before DST change, you should still get 12 noon the next day.
Supporting this requires deriving local timezone from local time which
is impossible for some datetime values.  Most business applications
can ignore this because nobody schedules meetings between 1 and 2 am
and those who do are smart enough to catch an exception and ask the
user to clarify what time he/she means.

Good catch.  Thanks for the review.

--

___
Python tracker 

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

[issue8515] idle "Run Module" (F5) does not set __file__ variable

[Tal Einat]

Tal Einat  added the comment:

I believe IDLE runs modules via execfile(), so I would expect the behavior to 
be similar, and execfile() does not set __file__. Doing "Run Module" is also 
IMO equivalent to doing execfile(), so this behavior retains consistency.

However, I would expect __file__ to be set when running IDLE -r 

[issue3129] struct allows repeat spec. without a format specifier

[Mark Dickinson]

Mark Dickinson  added the comment:

Patch looks great!   Please apply (with suitable Misc/NEWS entry).  Since the 
bug is fairly harmless, I think it's fine just to apply this to py3k, and not 
to backport to 2.x or to 3.1.

I also noticed some dependence on undefined behaviour in prepare_s, but I'll 
fix that separately.

BTW, please do add me to the nosy on any struct issues you encounter;  I'm 
currently acting as maintainer of this module (for my sins).

--

___
Python tracker 

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

[issue3129] struct allows repeat spec. without a format specifier

[Mark Dickinson]

Changes by Mark Dickinson :


--
assignee: mark.dickinson -> belopolsky
resolution:  -> accepted

___
Python tracker 

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

[issue5094] datetime lacks concrete tzinfo impl. for UTC

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

I have to stop replying to emails.  There is no reason behind roundup remove 
">" comments logic.   Reposting my message:

"""
On Fri, Jun 11, 2010 at 10:23 AM, Mark Dickinson  wrote:
..
> Some comments from playing with this patch (without having looked at the 
> implementation):
>
thank you very much for your comments.  As we are fine-tuning the
timezone class, do you think it would be helpful to go back to Brett's
suggestion and add datetime.py with just from _datetime import * and
keep parallel Python and C implementations of timezone class only
until full datetime.py is available?

> - As noted above, the 'timezone' class can't be subclassed.  Is this 
> deliberate?
>  I notice that Brett said "let users subclass as needed to add DST support" 
> in msg107008.
>
I was deliberate in a sense that I thought about it, but there was no
substantial discussion.  Original patch did not allow subclassing of
the UTC class and I thought it was right.  (See msg106415 and
msg106422.) subclassing FixedOffsetTimeZone makes more sense, but I
was hoping to keep timezone complete and eventually stop supporting
tzinfo API (not allow passing datetime in the methods.)  More on this
below.  I would very much prefer not to open the subclassing debate.
If you support subclassing, I will add a flag. My only objection is
that it is much easier to add this functionality in the future than to
remove it if it gets abused.  Can we postpone this decision until real
life use case comes in?  (Subclass to change dst() in itself is not a
use case.  Why do you need legacy timetuple interface to work is the
first question.)


> - If I try to do  timezone(timedelta(hours=24)), I get an error message:
> "ValueError: offset must be a timedelta between timedelta(1) and 
> -timedelta(1)." and I have to think for a bit to
> remember that 'timedelta(1)' means 'timedelta(days=1)'.  Any chance of making 
> this more explicit:  e.g. "between > timedelta(hours=-24) and 
> timedelta(hours=24)"?
>

Please make a call and I'll implement it.  The competing spellings are:

1. timedelta(hours=24)
2. 24 hours (I rejected this because it may be confused with an int)
3. timedelta(days=1)
4. in the range [-timedelta(hours=23, minutes=59), timedelta(hours=23,
minutes=59)]


> - The existing docs say, at one point: "if utcoffset does not return None,
> dst() should not return None either."  And yet it seems that this is exactly 
> what happens for timezone instances: > utcoffset doesn't return None, but dst 
> does.
>  Was there a reason for the explicit restriction in the docs, and are we sure 
> that that reason is no longer valid?
>
Yes, there was a reason, but I don't think it is a good one.  The
default implementation of fromutc() does not work if utcoffset()
returns timedelta but dst() returns None.  The dst() value used to
detect DST ambiguities.  Remember, fromutc() despite the name is
defined to operate on local times and some local times are ambiguous
and some are invalid.  The default implementation attempts to detect
that.  This is the issue that I am trying to avoid in my design.


> - I find it strange that mytimezone.utcoffset(1+3j) works;  similarly
> for tzname and dst.  Perhaps it should be
> checked at least that the argument is a datetime.  Similarly for
> tzname and dst.
>
The test is easy to add.  My longer term plan is to disallow passing
argument to constant methods, so adding check is somewhat wasteful.
Will do.

> - And it also seems clunky that an argument *has* to be supplied for
> utcoffset, tzname and dst, only to be ignored.
>  Would it be possible to make the argument optional?

Yes.  this was my transition plan.  Make it optional.  Modify datetime
methods to first try to get offset/name/dst without passing time
argument and fall back to passing self.  Remove optional argument from
timezone methods.

I can make the arg optional now.
>
> - Any chance of a nice __str__ implementation for timezone instances?
>  (And/or possibly a nice __repr__ as well)?
>
Yes.  I want parseable __repr__ as well.  I've been torn between
'datetime.timezone(datetime.timedelta(..)[, ..])'  and
'timezone(timedelta(..)[, ..])'. Opinions welcome.  Similarly, should
str(timezone.utc) be '+' or 'UTC' or '+00:00'?

> - The docs for tzname are misleading:  they claim that the default name has 
> the form "UTCsHHMM".  This isn't
> true for UTC+0, whose name seems to be just "UTC".  It actually wouldn't seem 
> unreasonable to have this print
> as "UTC+", just for consistency (and for ease of parsing for anyone on 
> the receiving end of such a string).
> Or the docs could be fixed.
>
You are reading my mind.  I planned to tear out conditional logic that
supports plain 'UTC', but apparently forgot.  Will do.

> - I'm very confused about utcoffset:  why can't I supply a UTC datetime (i.e. 
> an aware datetime with
> tzinfo = timezone.utc) to this?  I suspect I'm misunderstanding something 
> here...

You are not 

[issue6641] strptime doesn't support %z format ?

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

On Fri, Jun 11, 2010 at 10:43 AM, Mark Dickinson  wrote:
..
> It's a little awkward to review this patch independently of the issue 5094 
> patch.
>  Can we work on issue 5094 first, and then come back to this one?

Sure.  Unfortunately, I think I fixed a few timezone doc warts here
and did not update 5094.  I will fix that.

--

___
Python tracker 

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

[issue8973] Inconsistent docstrings in struct module

[Alexander Belopolsky]

New submission from Alexander Belopolsky :

Module level pack, unpack etc. methods have similar functionality with Struct 
instance methods, but docs are different.  The immediate issue is the lack of 
signature in the module level methods' docstrings.


$ ./python.exe -m pydoc struct.Struct.pack
Help on method_descriptor in struct.Struct:

struct.Struct.pack = pack(...)
S.pack(v1, v2, ...) -> bytes

Return a bytes containing values v1, v2, ... packed according to this
Struct's format. See struct.__doc__ for more on format strings.

and

$ ./python.exe -m pydoc struct.pack
Help on built-in function pack in struct:

struct.pack = pack(...)
Return bytes containing values v1, v2, ... packed according to fmt.

--
components: Extension Modules
messages: 107556
nosy: belopolsky, mark.dickinson
priority: normal
severity: normal
status: open
title: Inconsistent docstrings in struct module
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

[issue8973] Inconsistent docstrings in struct module

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

Two more bits:

1. "See struct.__doc__", while technically correct, is not user friendly.  If 
you copy struct.__doc__ to >>> prompt, you get an ugly repr of a multiline 
string.  I suggest s/struct.__doc__/help(struct)/.

2.  For some reason struct.Struct does not show up in help(struct).

--

___
Python tracker 

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

[issue8973] Inconsistent docstrings in struct module

[Mark Dickinson]

Mark Dickinson  added the comment:

Thanks for the reports;  I'll look at this a little later.

--
assignee:  -> mark.dickinson

___
Python tracker 

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

[issue5464] msgfmt.py does not work with plural form

[Éric Araujo]

Changes by Éric Araujo :


--
nosy: +merwok
stage:  -> committed/rejected

___
Python tracker 

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

[issue8502] proposal: encourage xgettext rather than pygettext.py in gettext docs

[Éric Araujo]

Éric Araujo  added the comment:

Does the fixing of #5464 solve your problem?

--
nosy: +merwok

___
Python tracker 

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

[issue2504] Add gettext.pgettext() and variants support

[Éric Araujo]

Éric Araujo  added the comment:

The patch needs to be updated for the 3.x trunk (py3k branch), since the last 
2.x version is already rc.

Everyone, thanks for expressing interest for the development of Python, but 
posting “me too” messages does not further the discussion, and actually takes 
time from already busy people. Use cases, patches, reviews and the occasional 
bump (one is enough) are helpful. :)

--
nosy: +merwok

___
Python tracker 

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

[issue4391] optparse: use proper gettext plurals forms

[Éric Araujo]

Éric Araujo  added the comment:

Thanks for your patch. I have some remarks:
1) please produce a patch from the top level of a Python checkout (cf. 
http://www.python.org/dev/patches/);
2) wrap lines under 80 characters;
3) bug with %-formatting: the singular message takes one arg, the plural two 
(optparse bug, not your patch’s bug, but the patch should fix it too);
4) “usage” has been used for decades in command line parsing, it’s fine.

I’m adding Armin to the nosy list since he’s listed in py3k/Misc/maintainers.rst

--
nosy: +aronacher, merwok

___
Python tracker 

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

[issue1288056] pygettext - provide comments to help translators

[Éric Araujo]

Éric Araujo  added the comment:

Translator comments seem to me nicer than contexts 
(http://bugs.python.org/issue2504), but I’m not sure which one is recommended 
when they overlap.

I’m -1 on the same line restriction. Python style is to put comments on the 
previous line.

The 2.x line does not accept new features, so your patch needs to be ported to 
3.x (branch name py3k).

FWIW, Babel uses a different style of comments, on the preceding line: 
http://babel.edgewall.org/wiki/Documentation/messages.html#translator-comments

--
nosy: +merwok

___
Python tracker 

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

[issue8974] svnmerge errors in msgfmt.py

[Éric Araujo]

New submission from Éric Araujo :

svnmerge for r81698 introduced incorrect print(sys.stderr, ...) calls. Attached 
patch fixes it. Apply with patch -p1.

--
assignee: loewis
components: Demos and Tools
files: strange-print.diff
keywords: patch
messages: 107563
nosy: loewis, merwok
priority: normal
severity: normal
status: open
title: svnmerge errors in msgfmt.py
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file17628/strange-print.diff

___
Python tracker 

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

[issue8975] Bug in cookiejar

[Popa Claudiu]

New submission from Popa Claudiu :

Hello. This is my first report, sorry if I won't do it right.
I found a bug in cookielib, which looks like this(a traceback):

"""C:\Python31\lib\http\cookiejar.py:1586: UserWarning: http.cookiejar bug!
Traceback (most recent call last):
  File "C:\Python31\lib\http\cookiejar.py", line 1584, in make_cookies
parse_ns_headers(ns_hdrs), request)
  File "C:\Python31\lib\http\cookiejar.py", line 1541, in _cookies_from_attrs_se
t
cookie = self._cookie_from_cookie_tuple(tup, request)
  File "C:\Python31\lib\http\cookiejar.py", line 1460, in _cookie_from_cookie_tu
ple
version = int(version)
ValueError: invalid literal for int() with base 10: '1.0'

  _warn_unhandled_exception()"""

--
components: Library (Lib)
messages: 107564
nosy: Popa.Claudiu
priority: normal
severity: normal
status: open
title: Bug in cookiejar
type: crash
versions: Python 3.1

___
Python tracker 

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

[issue8975] Bug in cookiejar

[Éric Araujo]

Éric Araujo  added the comment:

Thanks for your report. Can you copy the code provoking the bug?

--
nosy: +merwok

___
Python tracker 

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

[issue8971] Tkinter Litmus Test

[Éric Araujo]

Changes by Éric Araujo :


--
nosy: +merwok
resolution: rejected -> 
status: closed -> open

___
Python tracker 

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

[issue8971] Tkinter Litmus Test

[Éric Araujo]

Changes by Éric Araujo :


--
status: open -> closed

___
Python tracker 

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

[issue8971] Tkinter Litmus Test

[Éric Araujo]

Changes by Éric Araujo :


--
resolution:  -> rejected

___
Python tracker 

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

[issue8975] Bug in cookiejar

[Popa Claudiu]

Popa Claudiu  added the comment:

"""CHttp.__init__(self,1,proxy = 
shared.setts.currentGoogleProxy)
self.timeout = shared.setts.cGglHttpTimeout

self.proxy = 
globShare.currentGoogleProxy[globShare.currentGoogleIndex]
if self.proxy:
proxy_support = 
urllib.request.ProxyHandler({'http':self.proxy,'https':self.proxy,'ftp':self.proxy})
else:
proxy_support = urllib.request.ProxyHandler({})
#socket.setdefaulttimeout(30)

#self._cp = 
urllib.request.HTTPCookieProcessor(http.cookiejar.CookieJar())

self._cj = http.cookiejar.MozillaCookieJar()
self._opener1 = 
urllib.request.build_opener(proxy_support,self._cp)
. openedUrl = self._opener1.open(req)"""

The script was a crawler that searches for pdf's on internet. One thread 
printed the untreated exception.

--

___
Python tracker 

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

[issue8362] Add Misc/maintainers.rst to 2.x branch

[Éric Araujo]

Changes by Éric Araujo :


Removed file: http://bugs.python.org/file16853/maintainers.rst

___
Python tracker 

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

[issue8362] Add Misc/maintainers.rst to 2.x branch

[Éric Araujo]

Changes by Éric Araujo :


Removed file: http://bugs.python.org/file16854/maintainers.diff

___
Python tracker 

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

[issue8362] Add Misc/maintainers.rst to 2.x branch

[Éric Araujo]

Changes by Éric Araujo :


Added file: http://bugs.python.org/file17629/maintainers.rst

___
Python tracker 

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

[issue8362] Add Misc/maintainers.rst to 2.x branch

[Éric Araujo]

Changes by Éric Araujo :


Added file: http://bugs.python.org/file17630/maintainers.diff

___
Python tracker 

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

[issue8362] Add Misc/maintainers.rst to 2.x branch

[Éric Araujo]

Éric Araujo  added the comment:

Updating the files. haypo, your move! :)

--

___
Python tracker 

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

[issue8975] Bug in cookiejar

[Éric Araujo]

Éric Araujo  added the comment:

Could you provide a minimal usable script? We can’t run your excerpt to
reproduce the bug, and reproducing is the first step to debugging. I
think we’ll also need the site address, or the cookie header, or the
cookies file that provoke the bug.

--

___
Python tracker 

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

[issue5094] datetime lacks concrete tzinfo impl. for UTC

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

I am attaching a new patch, issue5094e.diff which addresses most of Mark's 
comments.  I left out repr() because two opinions were voiced on IRC with 
respect to datetime. prefix.  I would like to give it some more thought even 
though I am leaning towards compatibility with existing reprs.

I did not make td argument optional and did not allow timezone o be subclassed 
because these seem to be mutually exclusive options.  (If td is optional in 
base class, it must be optional in subclasses per Liskov's principle severely 
limiting utility of subclasses.)  Let's address this separately.

--
Added file: http://bugs.python.org/file17631/issue5094e.diff

___
Python tracker 

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

[issue6608] asctime does not check its input

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

Downgrading further.  If anyone has interest in supplying a patch, please step 
in.  Otherwise I plan to add a note to documentation and leave the code as is.

--
priority: critical -> low
title: asctime causing python to crash -> asctime does not check its input
type: crash -> behavior
versions:  -Python 2.6, Python 2.7, Python 3.1

___
Python tracker 

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

[issue3129] struct allows repeat spec. without a format specifier

[Mark Dickinson]

Mark Dickinson  added the comment:

On second thoughts, I think I *would* like to see this backported to 2.7.  Not 
to the maintenance branches, though.

--

___
Python tracker 

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

[issue6608] asctime does not check its input

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Hmm... it's still a crash, though. I really think this should be fixed. 
Crashing on invalid input is bad.

--
type: behavior -> crash

___
Python tracker 

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

[issue8976] subprocess module causes segmentation fault

[Chris Blazick]

New submission from Chris Blazick :

platform: Linux x86_64 (CentOS)
kernel: 2.6.18-128.1.10.el5.centos.plus
python version: 2.4.3
PyQt versin: 4.7.3

subprocess is generating a segmentation fault.

I am running a proprietary quicktime generating script inside my own (Qt) 
script using the subprocess module.  I am piping both stdout and stderr into my 
script.  I have tried reading these two with .communicate() and with the 
.stdout / .stderr properties.  Both end up generating the 
following error:

*** glibc detected *** /usr/bin/python: corrupted double-linked list: 
0x161c5c50 ***
Segmentation fault

running my script, and using os.system() to run the proprietary script works 
just fine

The (C++ compiled) proprietary script does not appear to have any problems 
crashing under normal circumstances, and I am assuming if there was a problem 
with the proprietary script, it wouldn't cascade to crashing my own script

--
components: Extension Modules
messages: 107573
nosy: Chris.Blazick
priority: normal
severity: normal
status: open
title: subprocess module causes segmentation fault
type: crash
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

[issue2892] improve cElementTree iterparse error handling

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +flox

___
Python tracker 

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

[issue8362] Add Misc/maintainers.rst to 2.x branch

[STINNER Victor]

STINNER Victor  added the comment:

I added Misc/maintainers.rst in 2.7 (r81899). But I don't want to maintain it, 
so merwork, will have to send me your patches ;-)

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

[issue2892] improve cElementTree iterparse error handling

[Fredrik Lundh]

Fredrik Lundh  added the comment:

Note that this was fixed in upstream 1.3 (and verified by the selftests), but 
the fix and test was apparently lost when that code was merged into 2.7.  Since 
2.7 is supposed to ship with 1.3, this is a regression, not a feature request.

(But 2.7 is in rc, and I'm on vacation, so I guess it's a bit too late to do 
anything about that.  I'll leave the final decision to flox and the python-dev 
crowd.)

--
assignee: effbot -> flox
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

[issue8362] Add Misc/maintainers.rst to 2.x branch

[Éric Araujo]

Éric Araujo  added the comment:

We’ve agreed on that :) Thanks.

--
stage:  -> committed/rejected

___
Python tracker 

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

[issue8959] WINFUNCTYPE wrapped ctypes callbacks not functioning correctly in Python 2.7

[Thomas Heller]

Thomas Heller  added the comment:

The commit that breaks the examples is revision 80761.

Tested on WinXP 32 bit.

Someone should test on Win 64bit too ;-).

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

[issue8959] WINFUNCTYPE wrapped ctypes callbacks not functioning correctly in Python 2.7

[Thomas Heller]

Thomas Heller  added the comment:

Problem in py3k branch also.

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

[issue8949] PyArg_Parse*(): "z" should not accept bytes

[STINNER Victor]

STINNER Victor  added the comment:

Some examples of functions using "s" format:
 * str.encode(encoding, errors), bytes.decode(encoding, errors): both arguments 
have to be unicode strings
 * compile(source, filename, mode, ...): filename and mode have to be unicode 
strings
 * crypt.crypt(word, salt): both arguments have to be unicode strings

I think that crypt() should also accept bytes, but not str.encode() nor 
bytes.decode().

Some examples of functions using "z" format:
 * _locale.bindtextdomain(domain, dirname): dirname uses "z" format and so 
accepts str, bytes or buffer compatible object. It should use 
PyUnicode_FSConverter() instead. But I agree that bytes is welcomed here.
 * readline.(write_history_file|read_init_file|read_history_file) functions do 
use "z" to parse a filename. PyUnicode_FSConverter() would also be better, but 
in this case "z" is better than "s" :-)

I don't know why "s" and "z" are different about bytes, but it will be 
difficult to change it without changing a lot ot code (all functions using 
these formats). I tried to reject types different than str for "z": most tests 
of the test suite fail. I tried to accept bytes for "s" format: 
"unicode".encode(b'abc') does segfault.

--

___
Python tracker 

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

[issue8515] idle "Run Module" (F5) does not set __file__ variable

[Bruce Frederiksen]

Bruce Frederiksen  added the comment:

No, IDLE compiles the module (with the 'compile' built-in using the 'exec'
option) and then does an 'exec' on the code (in PyShell.py).  It has several
lines of code that it runs before this exec to prepare the environment that
the code is run in.  It appears to be an oversight that the __file__
variable is not being set as a part of this preparation code to match the
behavior of the python CLI.  The patch that I included only changes one line
of this preparation code to also set the __file__ variable and that fixes
the problem.  If you examine the IDLE code in the immediate vicinity of my
patch you will see this.

I have several use cases where I'm relying on the __file__ variable in my
module so that it can find other non .py files that it needs in the same
directory that it's in.  This works under all combinations of uses from the
CLI, but fails in IDLE using Run Module.

The language reference
manualstates
under "Module":

Predefined (writable) attributes: __name__ is the module’s name; __doc__ is
> the module’s documentation string, or None if unavailable; __file__ is the
> pathname of the file from which the module was loaded, if it was loaded from
> a file. The __file__ attribute is not present for C modules that are
> statically linked into the interpreter; for extension modules loaded
> dynamically from a shared library, it is the pathname of the shared library
> file.
>

The python CLI honors this definition in all cases, but IDLE/Run Module does
not.

On Fri, Jun 11, 2010 at 11:11 AM, Tal Einat  wrote:

>
> Tal Einat  added the comment:
>
> I believe IDLE runs modules via execfile(), so I would expect the behavior
> to be similar, and execfile() does not set __file__. Doing "Run Module" is
> also IMO equivalent to doing execfile(), so this behavior retains
> consistency.
>
> However, I would expect __file__ to be set when running IDLE -r 

[issue8977] Globalize lonely augmented assignment

[Demur Rumed]

New submission from Demur Rumed :

A=[1,2,3]
def f(x):
A+=x,

This throws an error. The solution: state "global a". I find it odd that 
augmented assignment should be viewed the same as assignment in descerning 
local variables. This patch repairs such to maintain a as a variable of the 
global namespace

Some might find the following an issue

def f(x):
if x:
A+=4,
else:
A=[3]
print("f",x,A)
def g(x):
if not x:
A=[3]
else:
A+=4,
print("g",x,A)

In f, A is a global variable. In g, A is a local variable. Thus g(1) throws 
UnboundLocalError while f(1) appends 4 to A

--
components: Interpreter Core
files: symtable.diff
keywords: patch
messages: 107581
nosy: serprex
priority: normal
severity: normal
status: open
title: Globalize lonely augmented assignment
type: feature request
versions: Python 3.1
Added file: http://bugs.python.org/file17633/symtable.diff

___
Python tracker 

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

[issue8977] Globalize lonely augmented assignment

[Demur Rumed]

Demur Rumed  added the comment:

A note on the patch, ste->ste_tmpname... lines, along with changes to 
Lambda_kind, were not added by me. The additional newlines prior to 
symtable_visit_stmt's declaration are accidental, apologies. I'll avoid 
patching a snapshot and then pull the old version from hg after realizing I 
need the old version to run diff on next time

--

___
Python tracker 

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

[issue8977] Globalize lonely augmented assignment

[Demur Rumed]

Changes by Demur Rumed :


--
type: feature request -> behavior

___
Python tracker 

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

[issue8949] PyArg_Parse*(): "z" should not accept bytes

[STINNER Victor]

STINNER Victor  added the comment:

> I tried to reject types different than str for "z": 
> most tests of the test suite fail

Wait, what? No. I modified the wrong line of code :-) The whole test suite pass 
without any error if "z" doesn't accept bytes anymore.

--

___
Python tracker 

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

[issue8977] Globalize lonely augmented assignment

[Mark Dickinson]

Mark Dickinson  added the comment:

This seems evil to me, when you consider the effect of this patch on immutable 
types:

>>> A = 3
>>> def f():
... A += 5
... 
>>> f()
>>> A
8

I find the possibility that a function can implicitly (i.e., without any 
'global' declarations) mutate my global module constants... disturbing.

Anyway, such a fundamental change would need proper discussion;  the right 
place for that is the python-ideas mailing list rather than the tracker:

http://mail.python.org/mailman/listinfo/python-ideas

Note also that there's a moratorium on core language changes in effect at the 
moment, so the earliest this could change is Python 3.3.

I'm going to close this issue for now;  if the idea gets a good reception on 
python-ideas it can be reopened.

--
nosy: +mark.dickinson
resolution:  -> rejected
status: open -> closed
versions: +Python 3.3 -Python 3.1

___
Python tracker 

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

[issue8976] subprocess module causes segmentation fault

[R. David Murray]

R. David Murray  added the comment:

Well, without a non-proprietary way to reproduce the failure it is going to be 
a little hard to debug.  You could try debugging it with gdb.

--
nosy: +r.david.murray
stage:  -> unit test needed

___
Python tracker 

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

[issue8515] idle "Run Module" (F5) does not set __file__ variable

[Éric Araujo]

Changes by Éric Araujo :


Removed file: http://bugs.python.org/file17632/unnamed

___
Python tracker 

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

[issue8977] Globalize lonely augmented assignment

[Guido van Rossum]

Guido van Rossum  added the comment:

It's not that much more evil than this:

A = []

def f(x):
  A.append(x)

print(A)  # []
f(4)
print(A)  # [4]

I've always thought this is a borderline case.

--
nosy: +gvanrossum

___
Python tracker 

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

[issue8978] "tarfile.ReadError: file could not be opened successfully" if compiled without zlib

[Florent Xicluna]

New submission from Florent Xicluna :

When Python is compiled without zlib support, the error message is not very 
helpful when trying to untar an archive.

>>> tarfile.open('sample.tar.gz')
tarfile.ReadError: file could not be opened successfully

It happens when you run "python distribute_setup.py", for example.
 ( http://s3.pixane.com/pip_distribute.png )

--
components: Extension Modules
messages: 107587
nosy: flox
priority: low
severity: normal
status: open
title: "tarfile.ReadError: file could not be opened successfully" if compiled 
without zlib
type: behavior
versions: Python 2.7, Python 3.2

___
Python tracker 

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

[issue8941] utf-32be codec failing on UCS-2 python build for 32-bit value

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Fixed in r81907 (trunk), r81908 (py3k), r81909 (2.6), r81910 (3.1).

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

[issue8978] "tarfile.ReadError: file could not be opened successfully" if compiled without zlib

[STINNER Victor]

STINNER Victor  added the comment:

Which message do you suggest?

--
nosy: +haypo

___
Python tracker 

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

[issue8966] ctypes: remove implicit conversion between unicode and bytes

[STINNER Victor]

STINNER Victor  added the comment:

I commited ctypes_s_set.patch in Python 3.2 (r81911) because it does fix a real 
bug.

--

___
Python tracker 

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

[issue8978] "tarfile.ReadError: file could not be opened successfully" if compiled without zlib

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
assignee:  -> lars.gustaebel
nosy: +lars.gustaebel

___
Python tracker 

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

[issue8966] ctypes: remove implicit conversion between unicode and bytes

[STINNER Victor]

STINNER Victor  added the comment:

Update ctypes_tests.patch against last changes: ctypes_tests-2.patch.

--
Added file: http://bugs.python.org/file17634/ctypes_tests-2.patch

___
Python tracker 

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

[issue8966] ctypes: remove implicit conversion between unicode and bytes

[STINNER Victor]

Changes by STINNER Victor :


Removed file: http://bugs.python.org/file17613/ctypes_tests.patch

___
Python tracker 

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

[issue8978] "tarfile.ReadError: file could not be opened successfully" if compiled without zlib

[Florent Xicluna]

Florent Xicluna  added the comment:

something like :
  raise CompressionError("zlib module is not available")

--

___
Python tracker 

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

[issue8978] "tarfile.ReadError: file could not be opened successfully" if compiled without zlib

[Florent Xicluna]

Changes by Florent Xicluna :


--
components: +Library (Lib) -Extension Modules

___
Python tracker 

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

[issue8515] idle "Run Module" (F5) does not set __file__ variable

[Tal Einat]

Tal Einat  added the comment:

Why doesn't execfile() set __file__? I would be surprised if this is due to an 
oversight by the Python devs. In both execfile and IDLE's "Run Module" I can't 
think of a reason not to set __file__, but perhaps this was intentional? 
Googling a bit hasn't brought up much.

I am currently of the opinion that both IDLE and execfile() should set __file__ 
(with execfile() perhaps requiring more thinking about edge-cases, since it can 
be passes locals and globals dictionaries).

--

___
Python tracker 

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

[issue8977] Globalize lonely augmented assignment

[Mark Dickinson]

Mark Dickinson  added the comment:

True.  I guess there's a mismatch either way around:  currently,
"A += [4]" and "A.append(4)" behave differently for (e.g.,) a list A.  With the 
proposed change, "n += 3" and "n = n + 3" behave differently for a integer n.  
I'm not sure why I find the latter idea more disturbing than the former.

--

___
Python tracker 

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

[issue8965] test_imp fails on OSX when LANG is set

[STINNER Victor]

STINNER Victor  added the comment:

I commited issue8965-test-1.diff (r81916) with a minor changes: .strip() => 
.rstrip() and use @unittest.skipUnless().

--

___
Python tracker 

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

[issue6608] asctime does not check its input

[Alexandre Vassalotti]

Alexandre Vassalotti  added the comment:

How about checking the preconditions before calling asctime()? If the check 
fails, then we can raise an exception without crashing.

--

___
Python tracker 

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

[issue8502] proposal: encourage xgettext rather than pygettext.py in gettext docs

[jhg]

jhg  added the comment:

It looks like msgfmt.py now parses 'msgid_plural' but pygettext.py does not 
produce these. It is still oblivious to plurals as produced by ngettext(). My 
originally proposed change to the documentation was to point people to the GNU 
xgettext/msgfmt tools rather than the pygettext.py/msgfmt.py pair because of 
this limitation.

This has not changed.

--

___
Python tracker 

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

[issue8924] Error in error message in logging

[Vinay Sajip]

Vinay Sajip  added the comment:

Fix checked into trunk and release26-maint.

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

[issue8502] proposal: encourage xgettext rather than pygettext.py in gettext docs

[Éric Araujo]

Éric Araujo  added the comment:

What about the more ambitious approach, fixing pygettext?

--

___
Python tracker 

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

[issue8949] PyArg_Parse*(): "z" should not accept bytes

[STINNER Victor]

STINNER Victor  added the comment:

I patched readline (r81918) and locale (r81914) modules to use 
PyUnicode_FSConverter(). They don't use "z" format anymore to parse a filename.

I checked last functions using "z" format (not "z#" or "z*", only "z") and I 
think that it's ok ("z" can be patched to reject bytes). You can get the full 
list using:

grep -n 'PyArg_Parse[^(]*([^"]*"[^";:]*z[^#*]' */*.c

--

About the difference between s/z and s*/s#/z*/z#: I don't understand why they 
are different, but I think that it's too late to change that. Too much 
functions (and third party modules?) suppose that s*/s#/z*/z# supports buffer 
compatible objects.

--

___
Python tracker 

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

[issue8924] Error in error message in logging

[Éric Araujo]

Éric Araujo  added the comment:

Suggestion: To help people involved in the discussion or landing here from a 
Web search, you can write “fixed in rNNN” to make Roundup produce a link link 
this one: r81919 Thanks!

--
nosy: +merwok
stage:  -> committed/rejected

___
Python tracker 

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

[issue8965] test_imp fails on OSX when LANG is set

[STINNER Victor]

STINNER Victor  added the comment:

One more patch to check sys.getfilesystemencoding() on any OS (r81920).

--

___
Python tracker 

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

[issue8977] Globalize lonely augmented assignment

[Guido van Rossum]

Guido van Rossum  added the comment:

Because the latter (n += 1) is more fundamental, since it uses integers 
(arguably the most fundamental type).

This is why we've never done it before.

--

___
Python tracker 

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

[issue8976] subprocess module causes segmentation fault

[Stefan Krah]

Stefan Krah  added the comment:

> python version: 2.4.3

I'd suggest to try this with Python 2.6 or later. 2.4 and 2.5 are in
security-fix only mode.

--
nosy: +skrah
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

[issue6608] asctime does not check its input

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

That's what CERT recommends.  Their code can be reused as is:

int validate_tm(struct tm* time) {
  /* 
   * The range of valid values of the tm_sec member is [0, 60] 
   * inclusive (to allow for leap seconds).
   */
  if (time->tm_sec < 0 || time->tm_sec > 60) return 0;
  if (time->tm_min < 0 || time->tm_min >= 60) return 0;
  if (time->tm_hour < 0 || time->tm_hour >= 24) return 0;
  if (time->tm_mday <= 0 || time->tm_mday > 31) return 0;
  if (time->tm_mon < 0 || time->tm_mon >= 12) return 0;
  /* While other years are legit, they may overflow asctime()'s buffer */
  if (time->tm_year < -999 || time->tm_year > ) return 0;
  if (time->tm_wday < 0 || time->tm_wday >= 7) return 0;
  if (time->tm_yday < 0 || time->tm_yday >= 366) return 0;
  return 1;
}

--

___
Python tracker 

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

[issue6608] asctime does not check its input

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

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

[issue8939] Use C type names (PyUnicode etc;) in the C API docs

[STINNER Victor]

STINNER Victor  added the comment:

I commited a first part of the patch: r81923 (3.2), r81924 (3.1).

--

___
Python tracker 

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

[issue8939] Use C type names (PyUnicode etc;) in the C API docs

[STINNER Victor]

STINNER Victor  added the comment:

"PyUnicodeObject*" is not the best choice for the description of the function, 
and I don't really like "PyUnicode". Can't we use C types in the function 
prototype and Python types in the description?

Example:
---
s (PyUnicodeObject* or None) [char *]
Convert a null-terminated C string to a Python unicode object using 'utf-8' 
encoding. If the C string pointer is NULL, None is used.
-
PyUnicodeObject will be a link to the C type, and unicode a link to the  Python 
type.

--

___
Python tracker 

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

[issue8951] PyArg_Parse*(): factorize code of 's' and 'z' formats, and 'u' and 'Z' formats

[STINNER Victor]

Changes by STINNER Victor :


--
dependencies: +PyArg_Parse*(): "z" should not accept bytes

___
Python tracker 

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

[issue5094] datetime lacks concrete tzinfo impl. for UTC

[akira]

akira <4kir4...@gmail.com> added the comment:

Minor notes:

msg107186:
   1. The constructor now accepts only whole number of minutes in [-23:59, 
23:59] range.

rfc 3339 provides the following example:

   1937-01-01T12:00:27.87+00:20

   This represents the same instant of time as noon, January 1, 1937,
   Netherlands time.  Standard time in the Netherlands was exactly 19
   minutes and 32.13 seconds ahead of UTC by law from 1909-05-01 through
   1937-06-30.  This time zone cannot be represented exactly using the
   HH:MM format, and this timestamp uses the closest representable UTC
   offset.

The presence of fractions of seconds in time zone is an exception so
it might not be worth to support it but it exists.


msg107552:
   Similarly, should str(timezone.utc) be '+' or 'UTC' or '+00:00'?

Excerpts in favor for '+00:00' from rfc 3339:

   Attempts to label local offsets with alphabetic
   strings have resulted in poor interoperability in the past [IMAIL],
   [HOST-REQ].  As a result, RFC2822 [IMAIL-UPDATE] has made numeric
   offsets mandatory.

   If the time in UTC is known, but the offset to local time is unknown,
   this can be represented with an offset of "-00:00".  This differs
   semantically from an offset of "Z" or "+00:00", which imply that UTC
   is the preferred reference point for the specified time.

--
nosy: +akira

___
Python tracker 

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

[issue8784] tarfile/Windows: Don't use mbcs as the default encoding

[STINNER Victor]

STINNER Victor  added the comment:

Ok. I commited the patch to set the default encoding to utf-8 on Windows: 
r81925.

--

___
Python tracker 

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

[issue8784] tarfile/Windows: Don't use mbcs as the default encoding

[STINNER Victor]

Changes by STINNER Victor :


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