[ python-Bugs-1645148 ] MIME renderer: wrong header line break with long subject?

[SourceForge.net]

Bugs item #1645148, was opened at 2007-01-26 11:04
Message generated for change (Comment added) made by kxroberto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1645148&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: 7
Private: No
Submitted By: kxroberto (kxroberto)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: MIME renderer: wrong header line break with long subject?

Initial Comment:
>>> from email.MIMEText import MIMEText
>>> o=MIMEText('hello')
>>> o['Subject']='1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4
5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 '
>>> o.as_string()
'Content-Type: text/plain; charset="us-ascii"\nMIME-Version: 1.0\nContent-Transf
er-Encoding: 7bit\nSubject: 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8
9 1 2 3 4 5 6 7 8\n\t9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 \n\
nhello'
>>>


The '6 7 8\n\t9 1 2 3'  clashes together to 6 7 89 1 2 3
without space between 89 in usual mail readers.
Is this an error and should be :

'6 7 8 \n\t9 1 2 3'


? 

as there is also the space preserved in 
'6 7 8 9 \n\nhello'


--

>Comment By: kxroberto (kxroberto)
Date: 2007-08-06 19:18

Message:
Logged In: YES 
user_id=972995
Originator: YES

the bug appears to be quite frequent now (once one knows it :-) ).
Possibly for the same reason one sees this kind of subject alteration by
one space often on the usenet.

--

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-06-09 07:19

Message:
Logged In: YES 
user_id=479790
Originator: NO

Quoting RFC2822 section 2.2.3
: 

"""The general rule is that wherever this standard allows for folding
white space (not simply WSP characters), a CRLF may be inserted before any
WSP. For example, the header field:

   Subject: This is a test

can be represented as:

   Subject: This
is a test

[...]Unfolding is accomplished by simply removing any CRLF that is
immediately followed by WSP."""

That is, folding is done by inserting ONLY the sequence CRLF before any
folding whitespace. When the header is interpreted, the whitespace is NOT
removed, only the CRLF. The posted Subject header should become "Subject: 1
2 3...7 8\n\r 9 1 2...'

I think this is a bug in the email.header.Header class; its __init__ says,
about the continuation_ws argument: "[it] must be RFC 2822 compliant
folding whitespace (usually either a space or a hard tab) which will be
prepended to continuation lines.". Folding does not involve *prepending*
any whitespace, just inserting CRLF right before *existing* whitespace.

Note that this is wrong even for the old RFC 822 (with slightly different
rules for line folding.)


--

Comment By: kxroberto (kxroberto)
Date: 2007-06-08 14:11

Message:
Logged In: YES 
user_id=972995
Originator: YES

What would be the RFC definition for a correct auto-line break in a
(subject) mail header line?
Wouldn't it be more simple to not do any auto-line break for the subject?
or is there a requirement for the line break in the RFC. Don't think any
reader program would fail because of >79 char subject header lines.

--

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2007-03-11 22:17

Message:
Logged In: YES 
user_id=12800
Originator: NO

Whoops, this wasn't supposed to be a response to Tokio, but instead the
OP.

--

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2007-03-11 22:16

Message:
Logged In: YES 
user_id=12800
Originator: NO

Tokio, I'm not so sure about adding that extra space.  I tested all the
mail readers at my disposal on Linux and OSX.  I don't have any Windows
machines available so I couldn't test Outlook or OE.  (If you have them,
please indicate  what they do in a comment here!)  Here's what I found:

OSX:
  Mail.app 2.1.1 -- the extra space produces an extra space between the 8
and 9 both in the message summary and in the Subject header in the preview
pane.  The no extra space message looks fine.
  Thunderbird 1.5.0.10 -- The extra space message produces an extra space
in the message summary, while the no extra space message looks fine here. 
But the weird thing is that in both the extra space and non-extra space
cases, the Subject header in the preview pane both have extra spaces.  It
looks to me like the leading tab is being inserted into the Subject header
view.
  Entourage 11.3.3 -- The extra space shows up in both the summary and
preview panes b

[ python-Bugs-1768767 ] tutorial

[SourceForge.net]

Bugs item #1768767, was opened at 2007-08-06 12:08
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=1768767&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Michael R Bax (mrbax)
Assigned to: Nobody/Anonymous (nobody)
Summary: tutorial

Initial Comment:
tutorial

--

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

[ python-Bugs-1768767 ] tutorial

[SourceForge.net]

Bugs item #1768767, was opened at 2007-08-06 12:08
Message generated for change (Settings changed) made by mrbax
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1768767&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: None
>Status: Deleted
Resolution: None
Priority: 5
Private: No
Submitted By: Michael R Bax (mrbax)
Assigned to: Nobody/Anonymous (nobody)
Summary: tutorial

Initial Comment:
tutorial

--

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

[ python-Bugs-1731717 ] race condition in subprocess module

[SourceForge.net]

Bugs item #1731717, was opened at 2007-06-06 08:19
Message generated for change (Comment added) made by abo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731717&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.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: dsagal (dsagal)
Assigned to: Peter Åstrand (astrand)
Summary: race condition in subprocess module

Initial Comment:
Python's subprocess module has a race condition: Popen() constructor has a call 
to global "_cleanup()" function on whenever a Popen object gets created, and 
that call causes a check for all pending Popen objects whether their subprocess 
has exited - i.e. the poll() method is called for every active Popen object.

Now, if I create Popen object "foo" in one thread, and then a.wait(), and 
meanwhile I create another Popen object "bar" in another thread, then a.poll() 
might get called by _clean() right at the time when my first thread is running 
a.wait(). But those are not synchronized - each calls os.waitpid() if 
returncode is None, but the section which checks returncode and calls 
os.waitpid() is not protected as a critical section should be.

The following code illustrates the problem, and is known to break reasonably 
consistenly with Python2.4. Changes to subprocess in Python2.5 seems to address 
a somewhat related problem, but not this one.

import sys, os, threading, subprocess, time

class X(threading.Thread):
  def __init__(self, *args, **kwargs):
super(X, self).__init__(*args, **kwargs)
self.start()

def tt():
  s = subprocess.Popen(("/bin/ls", "-a", "/tmp"), stdout=subprocess.PIPE,
  universal_newlines=True)
  # time.sleep(1)
  s.communicate()[0]

for i in xrange(1000):
  X(target = tt)

This typically gives a few dozen errors like these:
Exception in thread Thread-795:
Traceback (most recent call last):
  File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap
self.run()
  File "/usr/lib/python2.4/threading.py", line 422, in run
self.__target(*self.__args, **self.__kwargs)
  File "z.py", line 21, in tt
s.communicate()[0]
  File "/usr/lib/python2.4/subprocess.py", line 1083, in communicate
self.wait()
  File "/usr/lib/python2.4/subprocess.py", line 1007, in wait
pid, sts = os.waitpid(self.pid, 0)
OSError: [Errno 10] No child processes

Note that uncommenting time.sleep(1) fixes the problem. So does wrapping 
subprocess.poll() and wait() with a lock. So does removing the call to global 
_cleanup() in Popen constructor.

--

Comment By: Donovan Baarda (abo)
Date: 2007-08-07 05:45

Message:
Logged In: YES 
user_id=10273
Originator: NO

I can create a patch to make current head a bit cleaner, if anyone is
interested...

--

Comment By: Donovan Baarda (abo)
Date: 2007-08-04 07:29

Message:
Logged In: YES 
user_id=10273
Originator: NO

I just looked at subprocess in svs trunk and it looks like it might
already be fixed in both subprocess.py and popen2.py. The part where
__del__() adds abandoned Popen instances to _active and _cleanup() removes
them is already there. _cleanup() has been made more thread resistant by
catching and ignoring exceptions that arise when two _cleanups() try to
remove the same instances. Popen.poll() has been made more robust by having
it set self.returncode to an optional _deadstate argument value when poll
gets an os.error from os.pidwait() on a child that gets cleaned up by
another thread. I think there are still a few minor race conditions around
Popen.poll(), but it will only affect what non-zero returncode you get...
it's not so much "thread safe" as "thread robust".

I think the _deadstate argument approach to try and make Popen.poll()
thread-robust is a bit hacky. I would rather see _cleanup() be properly
threadsafe by having it remove the inst from _active before processing it
and re-adding it back if it is still not finished. However, as it is now it
looks like it is fixed...

--

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-08-04 06:11

Message:
Logged In: YES 
user_id=6380
Originator: NO

If you want this fixed in 2.5.x, a new release is just around the corner,
and time is very tight.  Otherwise, 2.6a1 is half a year off.

--

Comment By: Donovan Baarda (abo)
Date: 2007-08-04 05:26

Message:
Logged In: YES 
user_id=10273
Originator: NO

Actually, after thinking about it, there may be a way to make _cleanup()
threadsafe without using explicit locks by leveraging off the GIL. If
_active.pop() and _active.append() are atomic because of the GIL, then

[ python-Bugs-1731717 ] race condition in subprocess module

[SourceForge.net]

Bugs item #1731717, was opened at 2007-06-06 00:19
Message generated for change (Comment added) made by astrand
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731717&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.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: dsagal (dsagal)
Assigned to: Peter Åstrand (astrand)
Summary: race condition in subprocess module

Initial Comment:
Python's subprocess module has a race condition: Popen() constructor has a call 
to global "_cleanup()" function on whenever a Popen object gets created, and 
that call causes a check for all pending Popen objects whether their subprocess 
has exited - i.e. the poll() method is called for every active Popen object.

Now, if I create Popen object "foo" in one thread, and then a.wait(), and 
meanwhile I create another Popen object "bar" in another thread, then a.poll() 
might get called by _clean() right at the time when my first thread is running 
a.wait(). But those are not synchronized - each calls os.waitpid() if 
returncode is None, but the section which checks returncode and calls 
os.waitpid() is not protected as a critical section should be.

The following code illustrates the problem, and is known to break reasonably 
consistenly with Python2.4. Changes to subprocess in Python2.5 seems to address 
a somewhat related problem, but not this one.

import sys, os, threading, subprocess, time

class X(threading.Thread):
  def __init__(self, *args, **kwargs):
super(X, self).__init__(*args, **kwargs)
self.start()

def tt():
  s = subprocess.Popen(("/bin/ls", "-a", "/tmp"), stdout=subprocess.PIPE,
  universal_newlines=True)
  # time.sleep(1)
  s.communicate()[0]

for i in xrange(1000):
  X(target = tt)

This typically gives a few dozen errors like these:
Exception in thread Thread-795:
Traceback (most recent call last):
  File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap
self.run()
  File "/usr/lib/python2.4/threading.py", line 422, in run
self.__target(*self.__args, **self.__kwargs)
  File "z.py", line 21, in tt
s.communicate()[0]
  File "/usr/lib/python2.4/subprocess.py", line 1083, in communicate
self.wait()
  File "/usr/lib/python2.4/subprocess.py", line 1007, in wait
pid, sts = os.waitpid(self.pid, 0)
OSError: [Errno 10] No child processes

Note that uncommenting time.sleep(1) fixes the problem. So does wrapping 
subprocess.poll() and wait() with a lock. So does removing the call to global 
_cleanup() in Popen constructor.

--

>Comment By: Peter Åstrand (astrand)
Date: 2007-08-06 22:02

Message:
Logged In: YES 
user_id=344921
Originator: NO

>I can create a patch to make current head a bit cleaner, if anyone is
>interested...

Sure, this would be great. 

I would also love a test case that reproduces this problem. 

--

Comment By: Donovan Baarda (abo)
Date: 2007-08-06 21:45

Message:
Logged In: YES 
user_id=10273
Originator: NO

I can create a patch to make current head a bit cleaner, if anyone is
interested...

--

Comment By: Donovan Baarda (abo)
Date: 2007-08-03 23:29

Message:
Logged In: YES 
user_id=10273
Originator: NO

I just looked at subprocess in svs trunk and it looks like it might
already be fixed in both subprocess.py and popen2.py. The part where
__del__() adds abandoned Popen instances to _active and _cleanup() removes
them is already there. _cleanup() has been made more thread resistant by
catching and ignoring exceptions that arise when two _cleanups() try to
remove the same instances. Popen.poll() has been made more robust by having
it set self.returncode to an optional _deadstate argument value when poll
gets an os.error from os.pidwait() on a child that gets cleaned up by
another thread. I think there are still a few minor race conditions around
Popen.poll(), but it will only affect what non-zero returncode you get...
it's not so much "thread safe" as "thread robust".

I think the _deadstate argument approach to try and make Popen.poll()
thread-robust is a bit hacky. I would rather see _cleanup() be properly
threadsafe by having it remove the inst from _active before processing it
and re-adding it back if it is still not finished. However, as it is now it
looks like it is fixed...

--

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-08-03 22:11

Message:
Logged In: YES 
user_id=6380
Originator: NO

If you want this fixed in 2.5.x, a new release is just around the corner,
and time is very tight.  Otherwise, 2.6a1 is half a year off.

--

[ python-Bugs-1768858 ] Python - Operation time out problem

[SourceForge.net]

Bugs item #1768858, was opened at 2007-08-06 17:43
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=1768858&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.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: MASK (mohammedsk)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python - Operation time out problem 

Initial Comment:
I have a program that reads from a file some search terms. The script uses 
Medline record parser pub med dictionary.
Since I search so many terms, the script times out. Here is the error:

Traceback (most recent call last):
File "(stdin)", line1, in 
File "search_all.py",line71, in 
Cur_record = medline_dict [id]
File "C:\Python25\Lib\site-packages\PubMed.py", line 103,
in_getitem_raise Key Error,x
Key Error: IOError('socket error',error(10060,'Operation timed out'))

I looked online for solutions and one solution was to add the following to the 
script:

import socket
socket.setdefaulttimeout(value)


But this code did not do anything, the script continues on timing out. 

A complete Python script is attached.

Any help is appreciated.

Thanks,
Mohammed

--

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

[ python-Bugs-1767242 ] os.chmod failure

[SourceForge.net]

Bugs item #1767242, was opened at 2007-08-03 11:02
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1767242&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Richard Heck (rgheck)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.chmod failure

Initial Comment:
When running on Linux and accessing a FAT partition, os.chmod fails with 
otherwise sensible partitions:
>>> os.chmod("/media/IHP-100/Test.lyx", 400)
>>> os.chmod("/media/IHP-100/Test.lyx", 600)
Traceback (most recent call last):
  File "", line 1, in ?
OSError: [Errno 1] Operation not permitted: '/media/IHP-100/Test.lyx'
The only thing that seems to be allowed is `4'. 


--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-08-06 22:45

Message:
Logged In: YES 
user_id=33168
Originator: NO

Note:  you are *not* using octal in python, but the chmod program is using
octal:

Try prefixing 400/600 with a zero, ie:  0400 or 0600.

--

Comment By: Richard Heck (rgheck)
Date: 2007-08-03 13:39

Message:
Logged In: YES 
user_id=1072146
Originator: YES

Well, the shell's chmod doesn't return an error.

[EMAIL PROTECTED] scripts]$ chmod 600 /media/IHP-100/Test.lyx
[EMAIL PROTECTED] scripts]$ echo $?
0
[EMAIL PROTECTED] scripts]$ chmod 400 /media/IHP-100/Test.lyx
[EMAIL PROTECTED] scripts]$ echo $?
0
[EMAIL PROTECTED] scripts]$ chmod 700 /media/IHP-100/Test.lyx
[EMAIL PROTECTED] scripts]$ echo $?
0
[EMAIL PROTECTED] scripts]$ python
Python 2.4.4 (#1, Oct 23 2006, 13:58:00)
[GCC 4.1.1 20061011 (Red Hat 4.1.1-30)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.chmod("/media/IHP-100/Test.lyx", 400)
>>> os.chmod("/media/IHP-100/Test.lyx", 600)
Traceback (most recent call last):
  File "", line 1, in ?
OSError: [Errno 1] Operation not permitted: '/media/IHP-100/Test.lyx'

I don't know what would happen in C, say.

--

Comment By: Georg Brandl (gbrandl)
Date: 2007-08-03 13:25

Message:
Logged In: YES 
user_id=849994
Originator: NO

Why do you think this is Python's fault? os.chmod() is only a very thin
wrapper around the OS' chmod().

--

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

[ python-Bugs-1767933 ] Badly formed XML using etree and utf-16

[SourceForge.net]

Bugs item #1767933, was opened at 2007-08-05 08:01
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1767933&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: XML
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: BugoK (bugok)
>Assigned to: Fredrik Lundh (effbot)
Summary: Badly formed XML using etree and utf-16

Initial Comment:
Hello,

The bug occurs when writing an XML file using the UTF-16 encoding.
The problem is that the etree encodes every string to utf-16 by itself - 
meaning, inserting the 0xfffe BOM before every string (tag, text, attribute 
name, etc.), causing a badly formed utf=16 strings.

A possible solution, which was offered by a co-worker of mine, was to use a 
utf-16 writer (from codecs.getwriter('utf-16') to write the file.

Best,

BugoK.


--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-08-06 22:54

Message:
Logged In: YES 
user_id=33168
Originator: NO

Fredrik, could you take a look at this?

--

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

[ python-Bugs-1767933 ] Badly formed XML using etree and utf-16

[SourceForge.net]

Bugs item #1767933, was opened at 2007-08-05 17:01
Message generated for change (Comment added) made by effbot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1767933&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: XML
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: BugoK (bugok)
Assigned to: Fredrik Lundh (effbot)
Summary: Badly formed XML using etree and utf-16

Initial Comment:
Hello,

The bug occurs when writing an XML file using the UTF-16 encoding.
The problem is that the etree encodes every string to utf-16 by itself - 
meaning, inserting the 0xfffe BOM before every string (tag, text, attribute 
name, etc.), causing a badly formed utf=16 strings.

A possible solution, which was offered by a co-worker of mine, was to use a 
utf-16 writer (from codecs.getwriter('utf-16') to write the file.

Best,

BugoK.


--

>Comment By: Fredrik Lundh (effbot)
Date: 2007-08-07 08:20

Message:
Logged In: YES 
user_id=38376
Originator: NO

ET's standard serializer currently only supports ASCII-compatible
encodings.  See e.g.

http://effbot.python-hosting.com/ticket/47

The best workaround for ET 1.2 (Python 2.5) is probably to serialize as
"utf-8" and transcode:

out = unicode(ET.tostring(elem), "utf-8").encode(...)

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-08-07 07:54

Message:
Logged In: YES 
user_id=33168
Originator: NO

Fredrik, could you take a look at this?

--

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

[issue1] Test issue

[user]

New submission from user:

Hi there folks. This is just a test issue to make sure the e-mail
sending from the tracker that hopefully will be in production RSN
works as expected.

--
components: Build
messages: 17863
nosy: user
severity: normal
status: open
title: Test issue
type: rfe
versions: Python 2.3


Tracker <[EMAIL PROTECTED]>


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

[ python-Bugs-1769002 ] A paragraph about packages should be updated.

[SourceForge.net]

Bugs item #1769002, was opened at 2007-08-07 09:44
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=1769002&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: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Noam Raphael (noamr)
Assigned to: Nobody/Anonymous (nobody)
Summary: A paragraph about packages should be updated.

Initial Comment:
The page about packages says:
"
When packages are structured into subpackages (as with the Sound package in the 
example), there's no shortcut to refer to submodules of sibling packages - the 
full name of the subpackage must be used
...
"

This isn't true, a thing which becomes apparant once you read the next 
paragraph, about relative imports in Python 2.5.

Thanks,
Noam

--

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