[ python-Bugs-1277098 ] imaplib Imap.select() uses comparison to 'None' for boolean

2005-08-31 Thread SourceForge.net 
Bugs item #1277098, was opened at 2005-08-31 15:52
Message generated for change (Comment added) made by pierslauder
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277098&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Thorne (jerub)
Assigned to: Piers Lauder (pierslauder)
Summary: imaplib Imap.select() uses comparison to 'None' for boolean

Initial Comment:
The imap class's method for selecting a mailbox in read
only mode is subtly broken. Calling i.select('INBOX',
readonly=0) will cause the imap library to open the
mailbox in EXAMINE mode, not SELECT.

 def select(self, mailbox='INBOX', readonly=None):
 if readonly is not None:
 name = 'EXAMINE'
 else:
 name = 'SELECT'

So passing what seems to be a boolean option into the
function causes unexpected circumstances in client code.

Recommend that the comparison be changed to 'if readonly:'.

I have verified this code exists in python2.3 and in
python cvs head.

--

>Comment By: Piers Lauder (pierslauder)
Date: 2005-08-31 20:32

Message:
Logged In: YES 
user_id=196212

The manual suggests that "set"ing the 'readonly' flag will
disable modifications, and I agree the suggested change
would produce the expected behaviour - will check in a fix...


--

Comment By: Stephen Thorne (jerub)
Date: 2005-08-31 15:54

Message:
Logged In: YES 
user_id=100823

assigned to pierslauder as per abaxter's request.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277098&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1277098 ] imaplib Imap.select() uses comparison to 'None' for boolean

2005-08-31 Thread SourceForge.net 
Bugs item #1277098, was opened at 2005-08-31 15:52
Message generated for change (Comment added) made by pierslauder
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277098&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Stephen Thorne (jerub)
Assigned to: Piers Lauder (pierslauder)
Summary: imaplib Imap.select() uses comparison to 'None' for boolean

Initial Comment:
The imap class's method for selecting a mailbox in read
only mode is subtly broken. Calling i.select('INBOX',
readonly=0) will cause the imap library to open the
mailbox in EXAMINE mode, not SELECT.

 def select(self, mailbox='INBOX', readonly=None):
 if readonly is not None:
 name = 'EXAMINE'
 else:
 name = 'SELECT'

So passing what seems to be a boolean option into the
function causes unexpected circumstances in client code.

Recommend that the comparison be changed to 'if readonly:'.

I have verified this code exists in python2.3 and in
python cvs head.

--

>Comment By: Piers Lauder (pierslauder)
Date: 2005-08-31 20:48

Message:
Logged In: YES 
user_id=196212

Suggested change checked in.


--

Comment By: Piers Lauder (pierslauder)
Date: 2005-08-31 20:32

Message:
Logged In: YES 
user_id=196212

The manual suggests that "set"ing the 'readonly' flag will
disable modifications, and I agree the suggested change
would produce the expected behaviour - will check in a fix...


--

Comment By: Stephen Thorne (jerub)
Date: 2005-08-31 15:54

Message:
Logged In: YES 
user_id=100823

assigned to pierslauder as per abaxter's request.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277098&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1277016 ] Sentence fragment in urlparse documentation

2005-08-31 Thread SourceForge.net 
Bugs item #1277016, was opened at 2005-08-31 01:57
Message generated for change (Comment added) made by doerwalter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277016&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Chad Whitacre (whit537)
Assigned to: Nobody/Anonymous (nobody)
Summary: Sentence fragment in urlparse documentation

Initial Comment:
The urlparse documentation contains this sentence fragment:

"This should generally be used instead of urlparse() if
the more recent URL syntax allowing parameters to be
applied to each segment of the path portion of the URL
(see RFC 2396)."[1]

>From the context, I infer that the sentence should read
something like:

"This should generally be used instead of urlparse() if
you do not wish to support the more recent URL syntax
allowing parameters to be applied to each segment of
the path portion of the URL (see RFC 2396)."


-

[1]
http://www.python.org/dev/doc/devel/lib/module-urlparse.html

--

>Comment By: Walter Dörwald (doerwalter)
Date: 2005-08-31 13:05

Message:
Logged In: YES 
user_id=89016

Checked in a different fix (by appending " is wanted" to the
sentence fragment).

Thanks for the report!

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277016&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Feature Requests-1275677 ] add a get() method to sets

2005-08-31 Thread SourceForge.net 
Feature Requests item #1275677, was opened at 2005-08-29 15:49
Message generated for change (Comment added) made by pitrou
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1275677&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Antoine Pitrou (pitrou)
Assigned to: Raymond Hettinger (rhettinger)
Summary: add a get() method to sets

Initial Comment:
Hi,

I would like to propose a new method for the builtin
set objects. Currently we have a pop() method which
pops an element from the set. What I often need,
though, is a method that gets an arbitrary element
without removing it (because adding / removing stuff is
dealt with in
another part of the program).

Right now the simplest way to do that is :
value = iter(my_set).next()

There are two problems with this:
1. it's ugly and not very intuitive
2. it is not atomic; this means if another thread
updates the set, I can get a "RuntimeError: dictionary
changed size during iteration" (btw, the message is
slightly wrong, it should be "set" instead of "dictionary")

Although the first problem is rather minor (but
annoying nevertheless), the second one is a real
showstopper in some cases - yes, I did encounter it for
real.

There is a way to avoid the second problem :
value = list(my_set)[0]
But of course, not only it is still ugly, but it is
also highly inefficient when the set is big. So in the
end I am forced to use an explicit lock around the
aforementioned construct (value = iter(my_set).next())
as well as around any other piece of code that can
update the set from another thread. This is tedious and
error-prone, and probably a bit inefficient.

So for the bottom line: it would be in some cases very
useful to have an atomic get() method in addition to
the pop() method on sets. (it could probably be applied
to frozensets and dicts too)

The implementation would probably not be very
difficult, since it's the same as pop() with the
removal feature removed. ;) But I'm not familiar with
the Python internals.

What do you think ?

Regards

Antoine.


--

>Comment By: Antoine Pitrou (pitrou)
Date: 2005-08-31 15:50

Message:
Logged In: YES 
user_id=133955

> Those two answers suggest this RFE is unnecessary.  If you
> guys agree, please close.  If not, I'll ponder it further. 
> Right now, I'm disinclined to introduce a method that I
> think is awkward to use.

Well, closing the request is fine for me. Although I don't
think choose() would be very awkward to use, we can probably
live without it.


--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-08-30 22:06

Message:
Logged In: YES 
user_id=80475

For the record, here are some research results.

Java's set objects do not have a choose() method:
http://java.sun.com/j2se/1.4.2/docs/api/java/util/Set.html

In contrast, SETL does provide a function for extracting
arbitrary elements.  The empty set case is handled by
returning Om which is a singleton object guaranteed not to
be an element of any set.  The Om value is especially useful
in SETL because it can be passed upward through other
functions (much in the same way that NANs can trickle
through a calculation without killing it).  Python has no
equivalent of Om.
  http://www.cs.nyu.edu/~bacon/setl-doc.html#arb

Core Perl only has arrays and hashes.

Mathematica provides set operations on lists (union,
intersection, complement).  Rather than having a set
specific function for extraction, list functions are used. 
The one providing choose-like functionality is First().  It
is equivalent to indexing:  a[0]
http://documents.wolfram.com/mathematica/functions/First



--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-08-30 13:47

Message:
Logged In: YES 
user_id=80475

> > Question for everyone:  Is there any known application for
> > choose() that isn't met by pop()/add() irrespective of
> > whether it "feels right"?
[Antoine]
> I don't think so indeed. 

[mwh]
> Mmm, the "v, = s" approach hadn't occurred to me and it 
> seems ok. 

Those two answers suggest this RFE is unnecessary.  If you
guys agree, please close.  If not, I'll ponder it further. 
Right now, I'm disinclined to introduce a method that I
think is awkward to use.

--

Comment By: Michael Hudson (mwh)
Date: 2005-08-30 09:03

Message:
Logged In: YES 
user_id=6656

Mmm, the "v, = s" approach hadn't occurred to me and it seems ok.  The 
others are all rather horribly indirect... (and, obviously, it's not about 
"need").

--

[ python-Bugs-1235646 ] codecs.StreamRecoder.next doesn't encode

2005-08-31 Thread SourceForge.net 
Bugs item #1235646, was opened at 2005-07-10 18:55
Message generated for change (Comment added) made by doerwalter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235646&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Sebastian Wangnick (wangnick)
Assigned to: M.-A. Lemburg (lemburg)
Summary: codecs.StreamRecoder.next doesn't encode

Initial Comment:
Codecs.StreamRecode.next does't encode the data it 
gets from self.reader.next. This breaks the "for line in 
codecs.EncodedFile(...)" idiom.

--

>Comment By: Walter Dörwald (doerwalter)
Date: 2005-08-31 18:11

Message:
Logged In: YES 
user_id=89016

Here's a simple patch

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235646&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1212195 ] str.lower() to have an IMPORTANT NOTE or it's for magicians

2005-08-31 Thread SourceForge.net 
Bugs item #1212195, was opened at 2005-05-31 20:56
Message generated for change (Comment added) made by doerwalter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212195&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nikos Kouremenos (nkour)
Assigned to: M.-A. Lemburg (lemburg)
Summary: str.lower() to have an IMPORTANT NOTE or it's for magicians

Initial Comment:
lower() {maybe others} should mention that if used with
string object [not unicode object] it's likely the that
encoding will change unde some locales [eg pl_PL makes
it from utf8 to latin2]!!

or this hsould be put in the beginning of the doc in
str as a general WARNING/NOTE:

--

>Comment By: Walter Dörwald (doerwalter)
Date: 2005-08-31 18:52

Message:
Logged In: YES 
user_id=89016

I'd like to see an example that shows this change from utf8
to latin2.

--

Comment By: Peter van Kampen (pterk)
Date: 2005-06-26 00:05

Message:
Logged In: YES 
user_id=174455

I tried to come up with a doc-patch:

https://sourceforge.net/tracker/index.php?func=detail&aid=1227545&group_id=5470&atid=305470

--

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-06-02 13:48

Message:
Logged In: YES 
user_id=38388

A doc-patch would be nice.

I don't like the general situation either. Unicode doesn't
behave like this and I don't think string.lower() and
.upper()  should either, but there are users out there who
think differently, so we might want to add a parameter which
then allows modifying the type of mapping:

string.lower(map='ascii')
string.upper(map='latin-1')

etc.

Just an idea. 

PS: I'll be offline for two weeks now, so don't expect any
more comments before then.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-01 23:43

Message:
Logged In: YES 
user_id=80475

Mark, do you have any thoughts on this one?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212195&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1200686 ] SyntaxError raised on win32 for correct files

2005-08-31 Thread SourceForge.net 
Bugs item #1200686, was opened at 2005-05-12 16:19
Message generated for change (Comment added) made by doerwalter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1200686&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Federico Di Gregorio (fog)
Assigned to: Nobody/Anonymous (nobody)
Summary: SyntaxError raised on win32 for correct files

Initial Comment:
Try to import the attached file (dt.py) on Windows with
Python 2.4 or 2.4.1 and you'll get a SyntaxError (the
file was written a long time ago, and worked perfectly
well on Python 2.1, 2.2 and 2.3.) The same does not
happen when importing the same module on Linux (tested
with 2.4 and 2.4.1). When the module imports fine
you'll get an ImportError (don't want to attach all
dependencies here) but the SyntaxError comes before that.

Also note that compiling the file with
compiler.compileFile("dt.py") generates a perfectly
good .pyc file that can be later imported just fine
(tested with 2.4 and 2.4.1 on Windows).


--

>Comment By: Walter Dörwald (doerwalter)
Date: 2005-08-31 18:56

Message:
Logged In: YES 
user_id=89016

Copying codecs.py from current CVS (2.4 branch) over your
codecs.py (making a backup first) should be sufficient to
test this. You can this version from
http://cvs.sourceforge.net/viewcvs.py/*checkout*/python/python/dist/src/Lib/codecs.py?rev=1.35.2.9


--

Comment By: Julien Sagnard (julien_sagnard)
Date: 2005-07-20 11:37

Message:
Logged In: YES 
user_id=1181710

It's ok if I remove coding declaration.
I have no access to current cvs, but if someone send me a
zip with latest version, I can try it.

--

Comment By: Walter Dörwald (doerwalter)
Date: 2005-07-19 18:19

Message:
Logged In: YES 
user_id=89016

This bug should be fixed in the current CVS version. So, can
you retry with current CVS? As a workaround you might also
want to remove the PEP 263 coding declaration if you don't
have any special character in your file.

--

Comment By: Julien Sagnard (julien_sagnard)
Date: 2005-07-19 18:05

Message:
Logged In: YES 
user_id=1181710

I have a similar problem with an other file (log.py).
On my computer ( Windows 2000 ) this 2 files ( log.py and
dt.py ) works with python 2.4 but raise a syntax error on
python 2.4.1 :

D:\dvt\tmp\bug2_4_1>python -c "import log"
Traceback (most recent call last):
  File "", line 1, in ?
  File "D:\dvt\tmp\bug2_4_1\log.py", line 356
  w = 72
   ^
SyntaxError: invalid syntax


--

Comment By: Greg Chapman (glchapman)
Date: 2005-05-18 16:15

Message:
Logged In: YES 
user_id=86307

I'm fairly sure this is caused by the bug described here:
  
   www.python.org/sf/1175396

The module imports without syntax error on my Windows system
(with a patched codecs.py to work around the above bug).

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1200686&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1189248 ] Seg Fault when compiling small program

2005-08-31 Thread SourceForge.net 
Bugs item #1189248, was opened at 2005-04-25 07:00
Message generated for change (Comment added) made by doerwalter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1189248&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Reginald B. Charney (rcharney)
Assigned to: Nobody/Anonymous (nobody)
Summary: Seg Fault when compiling small program

Initial Comment:
I am using SuSE 9.2. When trying to compile/interpret
the attached file, the python interpreter seg faults
with no other information.

Please note: the attached test file does not end in a
new line.

--

>Comment By: Walter Dörwald (doerwalter)
Date: 2005-08-31 19:18

Message:
Logged In: YES 
user_id=89016

Martins patch to pythonrun.c (2.216/2.211.2.2) should have
finally fixed this completely. On Linux I get "SyntaxError:
'unknown encoding: evilascii' (evil.py, line 1)". Closing as
out of date.

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-04 13:45

Message:
Logged In: YES 
user_id=1188172

I believe it is fixed, too... can't reproduce here.

--

Comment By: Michael Hudson (mwh)
Date: 2005-04-25 09:56

Message:
Logged In: YES 
user_id=6656

I think this is fixed in Python 2.4.1... what version are you using?

--

Comment By: Reginald B. Charney (rcharney)
Date: 2005-04-25 08:42

Message:
Logged In: YES 
user_id=411372

It turns out that the seg fault was caused by the first line
of the program:

# coding: evil

It seems that specifying an invalid character encoding
causes a seg fault.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1189248&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1277718 ] Lambda and deepcopy

2005-08-31 Thread SourceForge.net 
Bugs item #1277718, was opened at 2005-08-31 14:10
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277718&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Joshua Ginsberg (jaginsberg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Lambda and deepcopy

Initial Comment:
Howdy --

I have a class that has an attribute that is a
dictionary that contains an object that has a kword
argument that is a lambda. Confused yet? Simplified
example:

import copy

class Foo:
def __init__(self, fn=None):
self.fn = fn

class Bar:
d = {'foobar': Foo(fn=lambda x: x*x)}

def cp(self):
self.xerox = copy.deepcopy(self.d)

When I execute:

b = Bar()
b.cp()

Using Python version:

Python 2.3 (#1, Sep 13 2003, 00:49:11)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on
darwin

I get:

Traceback (most recent call last):
  File "", line 1, in ?
  File "", line 5, in cp
  File
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy.py",
line 179, in deepcopy
y = copier(x, memo)
  File
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy.py",
line 270, in _deepcopy_dict
y[deepcopy(key, memo)] = deepcopy(value, memo)
  File
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy.py",
line 179, in deepcopy
y = copier(x, memo)
  File
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy.py",
line 307, in _deepcopy_inst
state = deepcopy(state, memo)
  File
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy.py",
line 179, in deepcopy
y = copier(x, memo)
  File
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy.py",
line 270, in _deepcopy_dict
y[deepcopy(key, memo)] = deepcopy(value, memo)
  File
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy.py",
line 206, in deepcopy
y = _reconstruct(x, rv, 1, memo)
  File
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy.py",
line 338, in _reconstruct
y = callable(*args)
  File
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy_reg.py",
line 92, in __newobj__
return cls.__new__(cls, *args)
TypeError: function() takes at least 2 arguments (0 given)

I've googled for deepcopy and lambda and found somebody
else asking the same question on a LUG somewhere, but
they gave no advice and nobody else seems to have run
into this. Any ideas on what the problem is/how to get
around it? Thanks!

-jag



--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277718&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1212195 ] str.lower() to have an IMPORTANT NOTE or it's for magicians

2005-08-31 Thread SourceForge.net 
Bugs item #1212195, was opened at 2005-05-31 20:56
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212195&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Nikos Kouremenos (nkour)
Assigned to: M.-A. Lemburg (lemburg)
Summary: str.lower() to have an IMPORTANT NOTE or it's for magicians

Initial Comment:
lower() {maybe others} should mention that if used with
string object [not unicode object] it's likely the that
encoding will change unde some locales [eg pl_PL makes
it from utf8 to latin2]!!

or this hsould be put in the beginning of the doc in
str as a general WARNING/NOTE:

--

>Comment By: M.-A. Lemburg (lemburg)
Date: 2005-08-31 22:43

Message:
Logged In: YES 
user_id=38388

Closing the bug report.

Please see follow-ups on the doc-patch.

--

Comment By: Walter Dörwald (doerwalter)
Date: 2005-08-31 18:52

Message:
Logged In: YES 
user_id=89016

I'd like to see an example that shows this change from utf8
to latin2.

--

Comment By: Peter van Kampen (pterk)
Date: 2005-06-26 00:05

Message:
Logged In: YES 
user_id=174455

I tried to come up with a doc-patch:

https://sourceforge.net/tracker/index.php?func=detail&aid=1227545&group_id=5470&atid=305470

--

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-06-02 13:48

Message:
Logged In: YES 
user_id=38388

A doc-patch would be nice.

I don't like the general situation either. Unicode doesn't
behave like this and I don't think string.lower() and
.upper()  should either, but there are users out there who
think differently, so we might want to add a parameter which
then allows modifying the type of mapping:

string.lower(map='ascii')
string.upper(map='latin-1')

etc.

Just an idea. 

PS: I'll be offline for two weeks now, so don't expect any
more comments before then.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-01 23:43

Message:
Logged In: YES 
user_id=80475

Mark, do you have any thoughts on this one?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212195&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1235646 ] codecs.StreamRecoder.next doesn't encode

2005-08-31 Thread SourceForge.net 
Bugs item #1235646, was opened at 2005-07-10 18:55
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235646&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Sebastian Wangnick (wangnick)
>Assigned to: Walter Dörwald (doerwalter)
Summary: codecs.StreamRecoder.next doesn't encode

Initial Comment:
Codecs.StreamRecode.next does't encode the data it 
gets from self.reader.next. This breaks the "for line in 
codecs.EncodedFile(...)" idiom.

--

>Comment By: M.-A. Lemburg (lemburg)
Date: 2005-08-31 22:58

Message:
Logged In: YES 
user_id=38388

Looks good, Walter.

Please check it in.

Thanks.

--

Comment By: Walter Dörwald (doerwalter)
Date: 2005-08-31 18:11

Message:
Logged In: YES 
user_id=89016

Here's a simple patch

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235646&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1202493 ] RE parser too loose with {m,n} construct

2005-08-31 Thread SourceForge.net 
Bugs item #1202493, was opened at 2005-05-15 23:59
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Regular Expressions
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: RE parser too loose with {m,n} construct

Initial Comment:
This seems wrong to me:

>>> re.match("(UNIX{})", "UNIX{}").groups()
('UNIX',)

With no numbers or commas, "{}" should not be considered
special in the pattern.  The docs identify three numeric
repetition possibilities: {m}, {m,} and {m,n}.  There's no
description of {} meaning anything.  Either the docs should
say {} implies {1,1}, {} should have no special meaning, or
an exception should be raised during compilation of the
regular expression.


--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-08-31 23:55

Message:
Logged In: YES 
user_id=1188172

Any more objections against treating "{}" as literal?

The impact on existing code will be minimal, as I presume no
one will write "{}" in a RE instead of "{1,1}" (well, who
writes "{1,1}" anyway...).

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-03 21:10

Message:
Logged In: YES 
user_id=1188172

Then, I think, we should follow Perl's behaviour and treat
"{}" as a literal, just like every other brace construct
that isn't a repeat specifier.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-03 20:46

Message:
Logged In: YES 
user_id=80475

Hmm, it looks like they cannot be treated differently
without breaking backwards compatability.

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-03 20:00

Message:
Logged In: YES 
user_id=1188172

Raymond said that braces should always be considered
special. This includes constructs like "{(?P.*)}"
which the string module uses, and which would be a syntax
error then.

--

Comment By: Skip Montanaro (montanaro)
Date: 2005-06-03 17:13

Message:
Logged In: YES 
user_id=44345

Can you elaborate?  I fail to see what the string module
has to do with the re module.  Can you give an example
of code that would break?

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-03 10:01

Message:
Logged In: YES 
user_id=1188172

I just realized that e.g. the string module uses unescaped
braces, so I think we should not become overly strict as it
would break much code...

Perhaps the original patch (sre-brace-diff) is better...

--

Comment By: Skip Montanaro (montanaro)
Date: 2005-06-02 13:16

Message:
Logged In: YES 
user_id=44345

In the absence of strong technical reasons, I'd vote to do what Perl
does.  I believe the assumption all along has been that most people 
coming to Python who already know how to use regular expressions are 
Perl programmers.  It wouldn't seem to make sense to throw little land
mines in their paths.  I realize that explicit is better than implicit, but
practicality beats purity.

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-01 23:32

Message:
Logged In: YES 
user_id=1188172

Okay. Attaching patch which does that.

BTW, these things are currently allowed too (treated as
literals):

"{"
"{x"
"{x}"
"{x,y}"
"{1,x}"
etc.

The patch changes that, too.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-01 23:07

Message:
Logged In: YES 
user_id=80475

I prefer Skip's third option, raising an exception during
compilation.  This is an re syntax error.  Treat it the same
way that we handle similar situations with regular Python:

>>> a[]
SyntaxError: invalid syntax

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-01 22:30

Message:
Logged In: YES 
user_id=1188172

So, should a {} raise an error, or warn like in Ruby?

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-01 22:25

Message:
Logged In: YES 
user_id=80475

IMO, the simplest rule is that braces always be considered
special.  This accommodates future extensions, simplifies
the re compiler, and

[ python-Bugs-691733 ] Let assign to as raise SyntaxWarning as well

2005-08-31 Thread SourceForge.net 
Bugs item #691733, was opened at 2003-02-23 18:08
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=691733&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.5
Status: Open
Resolution: None
Priority: 2
Submitted By: Gerrit Holl (gerrit)
Assigned to: Nobody/Anonymous (nobody)
Summary: Let assign to as raise SyntaxWarning as well

Initial Comment:
according to the Python Language Reference Manual:
> In some future version of Python, the identifiers
> as and None will both become keywords.

Hence, it seems natural to me to raise a SyntaxWarning
when assigning to
either of these. However, the current Python
implementation doesn't:

103 >>> None="foo"
:1: SyntaxWarning: assignment to None
104 >>> as="foo"
105 >>>

For consistency and cleanliness, assignment to 'as'
should raise a SyntaxWarning as well. Currently, it's
possible to not know it'll be a keyword and use it as a
variable; people shouldn't, so a SyntaxWarning would be
good.

--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-08-31 23:59

Message:
Logged In: YES 
user_id=1188172

For Py2.5, "with" and "as" will become keywords. However,
that will need "from __future__ import with_statement".

So I suggest to raise SyntaxWarning in 2.5 without this
statement if with or as are used as names.

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-05-31 13:23

Message:
Logged In: YES 
user_id=1188172

This may be too late if as becomes a keyword in the new
with/do/whatever-statement...

--

Comment By: Gerrit Holl (gerrit)
Date: 2003-02-23 18:21

Message:
Logged In: YES 
user_id=13298

I'm not sure whether this should be considered as a feature.
I'd call it a minor wart... I'm also not sure about the
category, is this 'Python interpreter core' or am I right
with 'parser/compiler'?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=691733&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-750328 ] Pickle fails to restore new-style class instance in a cycle

2005-08-31 Thread SourceForge.net 
Bugs item #750328, was opened at 2003-06-06 23:13
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=750328&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Type/class unification
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Phillip J. Eby (pje)
Assigned to: Nobody/Anonymous (nobody)
Summary: Pickle fails to restore new-style class instance in a cycle

Initial Comment:
Here is code to demonstrate the problem.  All asserts
succeed except the last, showing that pickle and
cPickle both handle a "classic" cycle correctly, but
only cPickle handles new-style cycles correctly.  It
would appear that the problem is that the pure-Python
pickle isn't putting the object into its 'memo' until
*after* the object's state has been pickled.  Thus, the
identity is not preserved on unpickling.  This may be
true for other object types that use __reduce__, but I
have not verified this.


import pickle, cPickle

class X: pass

x = X()
x.x = x

x2 = cPickle.loads(cPickle.dumps(x))
assert x2.x is x2

x2 = pickle.loads(pickle.dumps(x))
assert x2.x is x2

class Y(object): pass

y = Y()
y.y = y

y2 = cPickle.loads(cPickle.dumps(y))
assert y2.y is y2

# this fails
y2 = pickle.loads(pickle.dumps(y))
assert y2.y is y2   


--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-09-01 00:04

Message:
Logged In: YES 
user_id=1188172

Runs find in 2.5cvs too.

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-05-31 13:34

Message:
Logged In: YES 
user_id=1188172

Runs fine in Py2.4.1 too, so should it be considered fixed?

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-07-01 05:00

Message:
Logged In: YES 
user_id=80475

Another datapoint:  This above script runs fine in Py2.3b2.

--

Comment By: Steven Taschuk (staschuk)
Date: 2003-06-08 22:23

Message:
Logged In: YES 
user_id=666873

Compare bug 702858, which observes the same behaviour for 
copy.deepcopy.

The common parts of pickle and copy really ought to be merged.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=750328&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-763007 ] dl module not installed with 2.2.3

2005-08-31 Thread SourceForge.net 
Bugs item #763007, was opened at 2003-06-30 07:08
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763007&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.2.3
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Mike Messmore (salmo)
Assigned to: Nobody/Anonymous (nobody)
Summary: dl module not installed with 2.2.3

Initial Comment:
I'm running Redhat 7.3 on an older PII.  I was
attemping to try out the python bindings for gstreamer
when I discovered my build of python 2.2.3 was lacking
the 'dl' module.  I've installed RPMS built from the
SRPMS available on the python.org site (with the
non-redhat9 spec file).  Looking around I have not
found a reason for this, nor a way to go about fixing
it, so I assume it is a bug.  Whenever I try to run a
gst-python example I get an ImportError stating the the
dl module does not exist, as well as when I try to run
test_dl.py in my /usr/lib/python2.2/test/ directory.

--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-09-01 00:05

Message:
Logged In: YES 
user_id=1188172

Considered as out of date.

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-05-31 13:36

Message:
Logged In: YES 
user_id=1188172

Is this still an issue? The group is Python 2.2.3, so should
it be considered out of date?

--

Comment By: Mike Messmore (salmo)
Date: 2003-07-01 07:31

Message:
Logged In: YES 
user_id=121084

>From the output it seems to never try to compile dlmodule.c.
 I ran 'rpm --rebuild python2-2.2.3-1.src.rpm 2&>1
>python_build.txt' and grepped the resulting text for
dlmodule.c and only found it placing the file in the build
directory.  It found dlfcn.h fine.  If you need me to I can
attach the python_build.txt file here, but I can't find any
visable errors in the building process.  By the way, feel
free to let me know at any point if I'm doing something
retarded.  

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-30 17:22

Message:
Logged In: YES 
user_id=33168

What is the error when building dlmodule.c?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763007&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-761452 ] HTMLParser chokes on my.yahoo.com output

2005-08-31 Thread SourceForge.net 
Bugs item #761452, was opened at 2003-06-26 23:11
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761452&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Robert Walsh (rjwalsh)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: HTMLParser chokes on my.yahoo.com output

Initial Comment:
The HTML parser chokes on the output produced by
http://my.yahoo.com/.  The problem appears to be that
the HTML Yahoo is producing contains stuff like this:

[ python-Bugs-1202493 ] RE parser too loose with {m,n} construct

2005-08-31 Thread SourceForge.net 
Bugs item #1202493, was opened at 2005-05-15 21:59
Message generated for change (Comment added) made by niemeyer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Regular Expressions
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: RE parser too loose with {m,n} construct

Initial Comment:
This seems wrong to me:

>>> re.match("(UNIX{})", "UNIX{}").groups()
('UNIX',)

With no numbers or commas, "{}" should not be considered
special in the pattern.  The docs identify three numeric
repetition possibilities: {m}, {m,} and {m,n}.  There's no
description of {} meaning anything.  Either the docs should
say {} implies {1,1}, {} should have no special meaning, or
an exception should be raised during compilation of the
regular expression.


--

>Comment By: Gustavo Niemeyer (niemeyer)
Date: 2005-08-31 22:11

Message:
Logged In: YES 
user_id=7887

I support Skip's opinion on following whatever perl is currently doing, if
that won't lead to unexpected errors on current running code which was
considered sane (expecting {} to behave like {1,1} is not sane :-).
  
Your original patch looks under-optimal though (look at the tests around 
it). I'll fix it, or if you prefer to do it by yourself, I may apply the 
patch/review it/whatever. :-) 

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-08-31 21:55

Message:
Logged In: YES 
user_id=1188172

Any more objections against treating "{}" as literal?

The impact on existing code will be minimal, as I presume no
one will write "{}" in a RE instead of "{1,1}" (well, who
writes "{1,1}" anyway...).

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-03 19:10

Message:
Logged In: YES 
user_id=1188172

Then, I think, we should follow Perl's behaviour and treat
"{}" as a literal, just like every other brace construct
that isn't a repeat specifier.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-03 18:46

Message:
Logged In: YES 
user_id=80475

Hmm, it looks like they cannot be treated differently
without breaking backwards compatability.

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-03 18:00

Message:
Logged In: YES 
user_id=1188172

Raymond said that braces should always be considered
special. This includes constructs like "{(?P.*)}"
which the string module uses, and which would be a syntax
error then.

--

Comment By: Skip Montanaro (montanaro)
Date: 2005-06-03 15:13

Message:
Logged In: YES 
user_id=44345

Can you elaborate?  I fail to see what the string module
has to do with the re module.  Can you give an example
of code that would break?

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-03 08:01

Message:
Logged In: YES 
user_id=1188172

I just realized that e.g. the string module uses unescaped
braces, so I think we should not become overly strict as it
would break much code...

Perhaps the original patch (sre-brace-diff) is better...

--

Comment By: Skip Montanaro (montanaro)
Date: 2005-06-02 11:16

Message:
Logged In: YES 
user_id=44345

In the absence of strong technical reasons, I'd vote to do what Perl
does.  I believe the assumption all along has been that most people 
coming to Python who already know how to use regular expressions are 
Perl programmers.  It wouldn't seem to make sense to throw little land
mines in their paths.  I realize that explicit is better than implicit, but
practicality beats purity.

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-01 21:32

Message:
Logged In: YES 
user_id=1188172

Okay. Attaching patch which does that.

BTW, these things are currently allowed too (treated as
literals):

"{"
"{x"
"{x}"
"{x,y}"
"{1,x}"
etc.

The patch changes that, too.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-01 21:07

Message:
Logged In: YES 
user_id=80475

I prefer Skip's third option, raising an exception during
compilation.  This is an re syntax error.  Treat it the same
way that we handle similar situations with regular Python:

>>> a[]
S

[ python-Bugs-1202493 ] RE parser too loose with {m,n} construct

2005-08-31 Thread SourceForge.net 
Bugs item #1202493, was opened at 2005-05-15 23:59
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Regular Expressions
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: RE parser too loose with {m,n} construct

Initial Comment:
This seems wrong to me:

>>> re.match("(UNIX{})", "UNIX{}").groups()
('UNIX',)

With no numbers or commas, "{}" should not be considered
special in the pattern.  The docs identify three numeric
repetition possibilities: {m}, {m,} and {m,n}.  There's no
description of {} meaning anything.  Either the docs should
say {} implies {1,1}, {} should have no special meaning, or
an exception should be raised during compilation of the
regular expression.


--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-09-01 00:16

Message:
Logged In: YES 
user_id=1188172

No, you're the expert, so you'll get the honor of fixing it. :P

--

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2005-09-01 00:11

Message:
Logged In: YES 
user_id=7887

I support Skip's opinion on following whatever perl is currently doing, if
that won't lead to unexpected errors on current running code which was
considered sane (expecting {} to behave like {1,1} is not sane :-).
  
Your original patch looks under-optimal though (look at the tests around 
it). I'll fix it, or if you prefer to do it by yourself, I may apply the 
patch/review it/whatever. :-) 

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-08-31 23:55

Message:
Logged In: YES 
user_id=1188172

Any more objections against treating "{}" as literal?

The impact on existing code will be minimal, as I presume no
one will write "{}" in a RE instead of "{1,1}" (well, who
writes "{1,1}" anyway...).

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-03 21:10

Message:
Logged In: YES 
user_id=1188172

Then, I think, we should follow Perl's behaviour and treat
"{}" as a literal, just like every other brace construct
that isn't a repeat specifier.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-03 20:46

Message:
Logged In: YES 
user_id=80475

Hmm, it looks like they cannot be treated differently
without breaking backwards compatability.

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-03 20:00

Message:
Logged In: YES 
user_id=1188172

Raymond said that braces should always be considered
special. This includes constructs like "{(?P.*)}"
which the string module uses, and which would be a syntax
error then.

--

Comment By: Skip Montanaro (montanaro)
Date: 2005-06-03 17:13

Message:
Logged In: YES 
user_id=44345

Can you elaborate?  I fail to see what the string module
has to do with the re module.  Can you give an example
of code that would break?

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-03 10:01

Message:
Logged In: YES 
user_id=1188172

I just realized that e.g. the string module uses unescaped
braces, so I think we should not become overly strict as it
would break much code...

Perhaps the original patch (sre-brace-diff) is better...

--

Comment By: Skip Montanaro (montanaro)
Date: 2005-06-02 13:16

Message:
Logged In: YES 
user_id=44345

In the absence of strong technical reasons, I'd vote to do what Perl
does.  I believe the assumption all along has been that most people 
coming to Python who already know how to use regular expressions are 
Perl programmers.  It wouldn't seem to make sense to throw little land
mines in their paths.  I realize that explicit is better than implicit, but
practicality beats purity.

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-01 23:32

Message:
Logged In: YES 
user_id=1188172

Okay. Attaching patch which does that.

BTW, these things are currently allowed too (treated as
literals):

"{"
"{x"
"{x}"
"{x,y}"
"{1,x}"
etc.

The patch changes that, too.

--

Comment By: Raymond Hettinger (rhettinger)
Da

[ python-Bugs-1276587 ] dict('') doesn't raise a value error

2005-08-31 Thread SourceForge.net 
Bugs item #1276587, was opened at 2005-08-30 14:52
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276587&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Mike Foord (mjfoord)
Assigned to: Nobody/Anonymous (nobody)
Summary: dict('') doesn't raise a value error

Initial Comment:
The dict function will theoretically accept any sequence 
or bounded iterable that yields (key, value) tuples.

A side effect is that dict('') is valid - producing an emtpy 
dictionary.

dict(x) where x is *any* string other than '' fails with a 
ValueError. I suggest that dict('') ought to produce a 
ValueError to as a string is *never* a valid input to the 
dict function.

The current situation allows obscure errors to pass 
unnoticed.

--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-09-01 00:17

Message:
Logged In: YES 
user_id=1188172

Closing as Won't Fix, then.

--

Comment By: Tim Peters (tim_one)
Date: 2005-08-30 16:39

Message:
Logged In: YES 
user_id=31435

It's not theoretical:  it's a fact that dict() accepts any iterable 
producing iterables each producing 2 objects (the latter don't 
have to be tuples; a (key, value) tuple is just one kind of 
iterable producing 2 objects; e.g., dict(["ab"]) == {'a': 'b'}).

An empty str meets the input requirements, so there's no 
way to stop this without special-case type-sniffing.  That's 
very unattractive, in part because it's impossible to guess 
which kinds of empty iterables would necessarily lead to an 
exception when passed to dict() had they not been empty.  
For example, passing an empty array.array (of any flavor) to 
dict() also constructs an empty dict.  The universe of iterable 
objects is vast.

Keeping it uniform and easy to explain (an empty iterable 
produces an empty dict) seems better to me than adding a 
maze of special cases that's bound to change over time 
("except for an empty str" ... "oh, or an empty 
unicode" ... "oh, or an empty array.array" ... "oh, or an empty 
file" ... "oh, oops, guess not, cuz a file with two lines works 
fine" ... etc).

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276587&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1277903 ] logging module broken for multiple threads?

2005-08-31 Thread SourceForge.net 
Bugs item #1277903, was opened at 2005-08-31 23:49
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277903&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Lenny G. Arbage (alengarbage)
Assigned to: Nobody/Anonymous (nobody)
Summary: logging module broken for multiple threads?

Initial Comment:
After upgrading from python 2.2, I noticed that the
logging facility doesn't seem to work in my code anymore.

As far as I can tell, after spending a bit of time
isolating the problem, this is an issue with threading.
 In the main thread, logging works without a hitch.  In
the secondary thread (which is run via
twisted.reactor), any attempt to write to the log
results in:

Traceback (most recent call last):
  File "/usr/lib/python2.4/logging/__init__.py", line
712, in emit
self.stream.write(fs % msg)
ValueError: I/O operation on closed file

The code that initializes the logger is as follows:
logger = logging.getLogger('mylogger')
screenhandler = logging.StreamHandler()
screenhandler.setLevel(logging.INFO)
logger.addHandler(self.screenhandler)

logfile = "/tmp/testlog"
if os.path.isfile(logfile):
os.remove(logfile)
handler = logging.FileHandler(logfile)
formatter = logging.Formatter('%(asctime)s
%(levelname)s: %(message)s')
handler.setFormatter(formatter)
logger.addHandler(handler)
logger.setLevel(logging.INFO)

Alone, this works fine.  It is only when a the second
thread does a 'logger = logging.getLogger('mylogger')
and subsequently calls 'logger.log()' that the above
error is produced.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277903&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1278102 ] help() broken, especially on Windows

2005-08-31 Thread SourceForge.net 
Bugs item #1278102, was opened at 2005-08-31 23:37
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1278102&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bryan G. Olson (bryango)
Assigned to: Nobody/Anonymous (nobody)
Summary: help() broken, especially on Windows

Initial Comment:
The for loop that pydoc.Helper's __init__ uses to find the 
location of Python docs doesn't work. It will reject the 
standard setting of
'http://www.python.org/doc/current/lib/'. 
Also, the loop should probably break after setting
self.docdir.

On Windows, setting PYTHONDOCS to the installation's doc 
directory will not make it work, because the doc is now 
distributed as a single file, 'Python24.chm', so there
is no 
'lib' sub-directory.





--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1278102&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com