[ python-Bugs-1187437 ] TypeError message on bad iteration is misleading

[SourceForge.net]

Bugs item #1187437, was opened at 2005-04-21 16:58
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1187437&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: 2
Submitted By: Roy Smith (roysmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: TypeError message on bad iteration is misleading

Initial Comment:
>>> for i in 5:
... pass
...
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: iteration over non-sequence

I know this is kind of a trivial point, but the message
"iteration of non-sequence" should really be something
like "iteration of non-iterable object", since not all
iterable things are sequences.


--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-05 12:46

Message:
Logged In: YES 
user_id=1188172

Seems reasonable to me.

--

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

[ python-Bugs-1184380 ] example broken in section 1.12 of Extending & Embedding

[SourceForge.net]

Bugs item #1184380, was opened at 2005-04-16 21:36
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1184380&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.4
>Status: Closed
>Resolution: Fixed
Priority: 1
Submitted By: bamoore (bamoore)
Assigned to: Nobody/Anonymous (nobody)
Summary: example broken in section 1.12 of Extending & Embedding

Initial Comment:
In section 1.12 of Extending and Embedding the Python
Interpreter Release 2.4, the example (spammodule) does
not compile on linux with distutils.  I get the following:
~/sandbox/python/c_api_test$ python2.4 spam-setup.py build
running build
running build_ext
building 'spam' extension
creating build
creating build/temp.linux-i686-2.4
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -fPIC -I/usr/include/python2.4 -c
spammodule.c -o build/temp.linux-i686-2.4/spammodule.o
spammodule.c:7: error: conflicting types for
`PySpam_System'
spammodule.h:21: error: previous declaration of
`PySpam_System'
error: command 'gcc' failed with exit status 1

I think the solution is to change line 12 of the
spammodule header file listing from:

#define PySpam_System_PROTO (char *command)

to:

#define PySpam_System_PROTO (const char *command)

as that seems to compile for me.  (though not tested
from another C extension).

--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-05 12:57

Message:
Logged In: YES 
user_id=1188172

Thanks, fixed as Doc/ext/extending.tex r1.33, r1.30.4.3

--

Comment By: Luis Bruno (lbruno)
Date: 2005-04-21 16:05

Message:
Logged In: YES 
user_id=1263795

AIUI, your solution is correct; a cursory glance through the
PyArg_ParseTuple() documentation and the system() manual
page leads me to believe we're expecting a const char *.

I'll submit a patch.

--

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

[ python-Bugs-1193849 ] os.path.expanduser documentation wrt. empty $HOME

[SourceForge.net]

Bugs item #1193849, was opened at 2005-05-02 17:02
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193849&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Wummel (calvin)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: os.path.expanduser documentation wrt. empty $HOME

Initial Comment:
If $HOME is unset, an initial "~" should not be
expanded according to the documentation. But instead it
somehow is expanded, perhaps through the pwd module:

$ env -u HOME python -c "import os.path; print
os.path.expanduser('~/foo')"
/home/calvin/foo

The result should be "~/foo" instead of "/home/calvin/foo".

I suggest adjusting the documentation to state the also
a single "~" is looked up in the pwd module, not only
"~user".

--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-05 14:29

Message:
Logged In: YES 
user_id=1188172

Attached a patch which fixes the docs. Okay to checkin?

--

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

[ python-Bugs-1183585 ] try to open /dev/null as directory

[SourceForge.net]

Bugs item #1183585, was opened at 2005-04-15 10:56
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183585&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: Invalid
Priority: 5
Submitted By: Roberto A. Foglietta (robang)
Assigned to: Nobody/Anonymous (nobody)
Summary: try to open /dev/null as directory

Initial Comment:

bash-2.05b# strace python 2>&1 | grep open | grep null
open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1
ENOTDIR (Not a directory) 

--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-05 14:49

Message:
Logged In: YES 
user_id=1188172

I think this isn't Python's fault, as isandler's post shows.
I would rather look for a bug in the C lib.

--

Comment By: Ilya Sandler (isandler)
Date: 2005-05-17 07:02

Message:
Logged In: YES 
user_id=971153


2 questions though:

1. Does this cause any problems?

2. I observe exactly the same behaviour for ls! (I'm on
Debian, kernel 2.4.25)


 bagira:~> strace ls | & grep open | grep null
 open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1
ENOTDIR (Not a directory)

 and for du:

  bagira:~> strace du /etc | & grep open |grep null
  open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1
ENOTDIR (Not a directory)

So, I'm almost ready to say that even if it's a bug, it's
not a python's bug... (Search for /dev/null in python source
also does not find anything interesting)..




--

Comment By: Roberto A. Foglietta (robang)
Date: 2005-04-20 20:02

Message:
Logged In: YES 
user_id=36141

I downloaded the python-2.4.1 sources and compiled under
slack 10 and Mandrake 10.1 and in both case it tried to open
/dev/null as a directory.
Some debian users reported me the same behaviure.

[EMAIL PROTECTED] roberto]$ uname -ar
Linux wsraf.sad.it 2.6.8.1-24mdksmp #1 SMP Thu Jan 13
23:11:43 MST 2005 i686 Intel(R) Pentium(R) 4 CPU 2.80GHz
unknown GNU/Linux



--

Comment By: Georg Brandl (gbrandl)
Date: 2005-04-16 09:54

Message:
Logged In: YES 
user_id=849994

I don't quite understand what you're trying to tell us here.

Are you just calling Python this way and observing the
system calls? Then, what system do you use? What version?
What kernel, etc.

--

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

[ python-Bugs-1215146 ] int('x',radix) puzzle

[SourceForge.net]

Bugs item #1215146, was opened at 2005-06-05 06:11
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=1215146&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
Submitted By: elgordo (azgordo)
Assigned to: Nobody/Anonymous (nobody)
Summary: int('x',radix) puzzle

Initial Comment:
I don’t understand the built-in function int(x, radix). Or 
its documentation in the Library Reference section 2.1 – 
Built-In Functions. I’m using Python 2.4.1 on Windows 
XP Pro w/SP2, And I get the following on IDLE:

>>> int(9)
9
>>> int('9')
9
>>> int('9',2)

Traceback (most recent call last):
  File "", line 1, in -toplevel-
int('9',2)
ValueError: invalid literal for int(): 9
>>> int('9',8)

Traceback (most recent call last):
  File "", line 1, in -toplevel-
int('9',8)
ValueError: invalid literal for int(): 9
>>> int('9',10)
9
>>> int('9',16)
9
>>> int('19',16)
25
>>>


--

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

[ python-Bugs-1215146 ] int('x',radix) puzzle

[SourceForge.net]

Bugs item #1215146, was opened at 2005-06-05 15:11
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215146&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: Closed
>Resolution: Invalid
Priority: 5
Submitted By: elgordo (azgordo)
Assigned to: Nobody/Anonymous (nobody)
Summary: int('x',radix) puzzle

Initial Comment:
I don’t understand the built-in function int(x, radix). Or 
its documentation in the Library Reference section 2.1 – 
Built-In Functions. I’m using Python 2.4.1 on Windows 
XP Pro w/SP2, And I get the following on IDLE:

>>> int(9)
9
>>> int('9')
9
>>> int('9',2)

Traceback (most recent call last):
  File "", line 1, in -toplevel-
int('9',2)
ValueError: invalid literal for int(): 9
>>> int('9',8)

Traceback (most recent call last):
  File "", line 1, in -toplevel-
int('9',8)
ValueError: invalid literal for int(): 9
>>> int('9',10)
9
>>> int('9',16)
9
>>> int('19',16)
25
>>>


--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-05 16:08

Message:
Logged In: YES 
user_id=1188172

The function is behaving as expected. The radix argument
specifies which base the number system in the string has.
Radix 2 means binary, for example, and radix 16 hexadecimal.
>From that, it is clear that '9' is an invalid binary or
octal number.

In the future, please direct such questions to the Newsgroup
comp.lang.python.

Closing as Invalid.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215146&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-1175686 ] add "reload" function

[SourceForge.net]

Feature Requests item #1175686, was opened at 2005-04-03 03:48
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1175686&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: IDLE
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: add "reload" function

Initial Comment:
The file menu in Editor windows could benefit from a
"reload" function that re-reads the file from disc and
loads it into the editor, replacing what's currently in
the editor.  That's useful for those of us who like to
edit with Emacs in another window while running the
code under Idle.  To get really fancy, it might be cool
to optionally display a diff between the in-editor
version and the on-disk version allowing merging
changes, but that's maybe over the top.

Other editors usually do have commands like this,
e.g.M-x Revert-file in Emacs or ":e!" in vi.

--

>Comment By: Kurt B. Kaiser (kbk)
Date: 2005-06-05 09:32

Message:
Logged In: YES 
user_id=149084

Responding to your "misplaced" post, I use emacs for
everything also; basically I live in emacs.  However, my
question still stands.  Have you tried IDLE with the 
autosave and F5 to run?  If IDLE had incremental search
it would be pretty close or maybe even better.  I used to
use emacs to develop IDLE but I find I'm increasingly 
using IDLE for that purpose.

--

Comment By: Kurt B. Kaiser (kbk)
Date: 2005-05-26 11:20

Message:
Logged In: YES 
user_id=149084

I like the Revert idea better.  It probably should be
above "Close" in the File menu.  Otherwise, if it's
next to "Recent Files", someday someone is going
to select it by mistake and be really ticked.

I think the suggestion violates KISS.  Over time, it's
ideas like this that cause creeping features and a
boated interface.

But again, why not use IDLE instead of emacs to
edit Python code?  One button Save/Run!  What is
the killer feature that's missing from IDLE?  That would
be the real thing to work on.

--

Comment By: Kurt B. Kaiser (kbk)
Date: 2005-04-18 21:55

Message:
Logged In: YES 
user_id=149084

Why do you use Emacs instead of IDLE? (I use emacs
myself sometimes, but I'm curious what your reasons
are these days.)

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-18 17:48

Message:
Logged In: YES 
user_id=80475

If added, it should definitely be called "revert" instead of
"reload".  The latter already has a specific meaning in
Python that relates to imports.  The former seems to be
standard terminology across a number of editing tools from
emacs to photoshop.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1175686&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-563141 ] fileinput/gzip modules should play well

[SourceForge.net]

Feature Requests item #563141, was opened at 2002-06-01 02:27
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=563141&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: Greg White (groggygreggy)
Assigned to: Nobody/Anonymous (nobody)
Summary: fileinput/gzip modules should play well

Initial Comment:
It seems to be nearly impossible to use the fileinput 
module to read gzip files, even though gzip support is 
available in the gzip module.

As a first step, it would be nice if the fileinput.FileInput 
class provided an overridable method that let outsiders 
glue the gzip module in place.

It would also be nice if there was a way to make fileinput 
just automatically support gzip files (if, for instance, it 
saw a .gz extension).

--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-05 16:52

Message:
Logged In: YES 
user_id=1188172

See patch #1215184.

--

Comment By: Brett Cannon (bcannon)
Date: 2003-05-13 04:25

Message:
Logged In: YES 
user_id=357491

The hook is reasonable, the automatic opening of gzip is not.  No need to 
have magic done based purely on extension.

Any chance you could write a patch to expose the hook?

--

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

[ python-Bugs-1215146 ] int('x',radix) puzzle

[SourceForge.net]

Bugs item #1215146, was opened at 2005-06-05 06:11
Message generated for change (Comment added) made by azgordo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215146&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: Closed
Resolution: Invalid
Priority: 5
Submitted By: elgordo (azgordo)
Assigned to: Nobody/Anonymous (nobody)
Summary: int('x',radix) puzzle

Initial Comment:
I don’t understand the built-in function int(x, radix). Or 
its documentation in the Library Reference section 2.1 – 
Built-In Functions. I’m using Python 2.4.1 on Windows 
XP Pro w/SP2, And I get the following on IDLE:

>>> int(9)
9
>>> int('9')
9
>>> int('9',2)

Traceback (most recent call last):
  File "", line 1, in -toplevel-
int('9',2)
ValueError: invalid literal for int(): 9
>>> int('9',8)

Traceback (most recent call last):
  File "", line 1, in -toplevel-
int('9',8)
ValueError: invalid literal for int(): 9
>>> int('9',10)
9
>>> int('9',16)
9
>>> int('19',16)
25
>>>


--

>Comment By: elgordo (azgordo)
Date: 2005-06-05 07:52

Message:
Logged In: YES 
user_id=1291540

OK --- I was confused by the documentation. I'd like to 
propose the following replacement for the documentation:

int([x[, b]])
Converts base b numbers specified by the inputs to their 
decimal integer equivalents. When the base b is absent x 
may be either (i) the string representation of a possibly 
signed decimal integer (possibly embedded in whitespace), 
or (ii) a possibly signed decimal integer or floating point 
number (floating point numbers are truncated towards zero). If 
the base b is present and non-zero, it must be an integer in 
the range [2, 36] and x must be the possibly signed string 
representation of an integer in base b notation. When x is a 
string and the base b is zero, the base actually used is 
guessed by interpreting the string x in the same way as for 
integer literals.  When b is present then (i) if  x is not a string 
a TypeError is raised, and (ii) if the string x does not 
represent an integer then a ValueError is raised. Returns 0 if 
no arguments are given.


--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-05 07:08

Message:
Logged In: YES 
user_id=1188172

The function is behaving as expected. The radix argument
specifies which base the number system in the string has.
Radix 2 means binary, for example, and radix 16 hexadecimal.
>From that, it is clear that '9' is an invalid binary or
octal number.

In the future, please direct such questions to the Newsgroup
comp.lang.python.

Closing as Invalid.

--

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

[ python-Bugs-1215146 ] int('x',radix) puzzle

[SourceForge.net]

Bugs item #1215146, was opened at 2005-06-05 06:11
Message generated for change (Comment added) made by azgordo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215146&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: Closed
Resolution: Invalid
Priority: 5
Submitted By: elgordo (azgordo)
Assigned to: Nobody/Anonymous (nobody)
Summary: int('x',radix) puzzle

Initial Comment:
I don’t understand the built-in function int(x, radix). Or 
its documentation in the Library Reference section 2.1 – 
Built-In Functions. I’m using Python 2.4.1 on Windows 
XP Pro w/SP2, And I get the following on IDLE:

>>> int(9)
9
>>> int('9')
9
>>> int('9',2)

Traceback (most recent call last):
  File "", line 1, in -toplevel-
int('9',2)
ValueError: invalid literal for int(): 9
>>> int('9',8)

Traceback (most recent call last):
  File "", line 1, in -toplevel-
int('9',8)
ValueError: invalid literal for int(): 9
>>> int('9',10)
9
>>> int('9',16)
9
>>> int('19',16)
25
>>>


--

>Comment By: elgordo (azgordo)
Date: 2005-06-05 07:54

Message:
Logged In: YES 
user_id=1291540

OK --- I was confused by the documentation. I'd like to 
propose the following replacement for the documentation:

int([x[, b]])
Converts base b numbers specified by the inputs to their 
decimal integer equivalents. When the base b is absent x 
may be either (i) the string representation of a possibly 
signed decimal integer (possibly embedded in whitespace), 
or (ii) a possibly signed decimal integer or floating point 
number (floating point numbers are truncated towards zero). If 
the base b is present and non-zero, it must be an integer in 
the range [2, 36] and x must be the possibly signed string 
representation of an integer in base b notation. When x is a 
string and the base b is zero, the base actually used is 
guessed by interpreting the string x in the same way as for 
integer literals.  When b is present then (i) if  x is not a string 
a TypeError is raised, and (ii) if the string x does not 
represent an integer then a ValueError is raised. Returns 0 if 
no arguments are given.


--

Comment By: elgordo (azgordo)
Date: 2005-06-05 07:52

Message:
Logged In: YES 
user_id=1291540

OK --- I was confused by the documentation. I'd like to 
propose the following replacement for the documentation:

int([x[, b]])
Converts base b numbers specified by the inputs to their 
decimal integer equivalents. When the base b is absent x 
may be either (i) the string representation of a possibly 
signed decimal integer (possibly embedded in whitespace), 
or (ii) a possibly signed decimal integer or floating point 
number (floating point numbers are truncated towards zero). If 
the base b is present and non-zero, it must be an integer in 
the range [2, 36] and x must be the possibly signed string 
representation of an integer in base b notation. When x is a 
string and the base b is zero, the base actually used is 
guessed by interpreting the string x in the same way as for 
integer literals.  When b is present then (i) if  x is not a string 
a TypeError is raised, and (ii) if the string x does not 
represent an integer then a ValueError is raised. Returns 0 if 
no arguments are given.


--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-05 07:08

Message:
Logged In: YES 
user_id=1188172

The function is behaving as expected. The radix argument
specifies which base the number system in the string has.
Radix 2 means binary, for example, and radix 16 hexadecimal.
>From that, it is clear that '9' is an invalid binary or
octal number.

In the future, please direct such questions to the Newsgroup
comp.lang.python.

Closing as Invalid.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215146&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-644940 ] Support file path concat with " /"

[SourceForge.net]

Feature Requests item #644940, was opened at 2002-11-27 21:44
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=644940&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: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Mark VanTassel (markvantassel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Support file path concat with "/" 

Initial Comment:
A very useful feature is to overload the "/" operator for 
strings to support path concatenation - that is, to concat 
the left and right arguments in such a way that there is 
exactly one slash between them, regardless of which 
argument(s) did or didn't include slashes:

dir = "/this/that"
file = "whatever.py"
print dir / file 
#prints "/this/that/whatever.py"

It seems silly, but when you're not 100% in control of 
things (such as when reading paths from config files, 
user input, etc), it's great to be sure that the right thing 
will happen without writing/testing a lot of icky code. 
And even when you are 100% in control, it's nice to not 
have to worry about it so much.

This doesn't seem to conflict with any existing usage or 
syntax, so I don't think it can possibly break any 
existing behaviour (except, of course, those who were 
counting on having an exception thrown!)

I've already coded this as a minor tweak to the Python 
2.2.2 release, and I'd be happy to share the fix with the 
powers that be, if there's general concensus that this is 
a good thing. Feedback is solicited and appreciated 
(this is my first foray into open-source development, so 
be gentle!)

--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-05 19:08

Message:
Logged In: YES 
user_id=1188172

I think this can be closed. If someone wants that
functionality in the Python distribution, he should ask for
a module like
http://www.jorendorff.com/articles/python/path/ in the
stdlib (which I would support too).

--

Comment By: Walter Dörwald (doerwalter)
Date: 2002-12-09 19:30

Message:
Logged In: YES 
user_id=89016

IMHO implementing str / str as a duplicate of os.path.join
blurs what a string is. The meaning of a type should be tied
to the type and not to various sets of operators (for + a
str instance is treated as a string, for / as a filename).

And if we add /, where should we stop? str.open(),
str.exists(), str.stat() etc.? If we duplicate every
function in os.path we might get name clashes. IMHO string
and filename APIs should be kept separate.

So the clearer solution would to be implement a separate
filename class. Whether this is a subclass of str or not is
IMHO unclear. What about Unicode filenames?


--

Comment By: Martin v. Löwis (loewis)
Date: 2002-12-03 19:24

Message:
Logged In: YES 
user_id=21627

Please notice that there is an established function in
Python that has the same effect: os.path.join:

>>> dir = "/this/that"
>>> file = "whatever.py"
>>> import os
>>> print os.path.join(dir,file)
/this/that/whatever.py

There is, in general, reluctance to add new syntax to Python
if you can achieve the same effect with a function - in
particular if the function has been there for a long time.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-11-29 21:00

Message:
Logged In: YES 
user_id=33168

How often do you really need this?  Is it that bad/hard to
use os.path.join?

There are always problems with adding new features which
overload existing operations, like using "/".  It's true
that it would raise an exception today, so could be
acceptable to implement str / str.  However, unless this is
for a very common task, is it worth it?  Using / to join
path components is not obvious to me.  I doubt it would be
generally obvious.  Would it be confusing?

There is the cost of not being able to use / for something
possibly more meaningful and more common if this were
implemented.

--

Comment By: Mark VanTassel (markvantassel)
Date: 2002-11-29 14:02

Message:
Logged In: YES 
user_id=658048

Having used a C++ string class with overloaded "/", I can 
assure you it's quite useful. Aside from the executable being 
about 100 bytes larger, I can't see how it hurts anything.

The righthandside absolute path (assuming you mean with a 
non-empty leftside path) is a semantic problem. You could 
reasonably say that if the right side starts with a slash, ignore 
the left side.

Similarly, if the rightside starts with "X:" (under windows), 
ignore the left si

[ python-Feature Requests-798520 ] os.popen with invalid mode differs on Windows and POSIX

[SourceForge.net]

Feature Requests item #798520, was opened at 2003-09-01 14:34
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=798520&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: Andrew Gaul (gaul)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.popen with invalid mode differs on Windows and POSIX

Initial Comment:
On Windows, os.popen with an invalid mode throw a
ValueError and on POSIX systems it throws an OSError.

Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32
bit (Intel)] on win32
Type "help", "copyright", "credits" or 
"license" for
more information.
>>> import os
>>> os.popen('dir', '')
Traceback (most recent call last):
  File "", line 1, in ?
ValueError: popen() arg 2 must be 'r' or 'w'

Python 2.3 (#167, Sep  1 2003, 06:38:18)
[GCC 3.0.4] on linux2
Type "help", "copyright", "credits" or 
"license" for
more information.
>>> import os
>>> os.popen('ls', '')
Traceback (most recent call last):
  File "", line 1, in ?
OSError: [Errno 22] Invalid argument

Additionally, the ValueError message is incorrect; arg
2 can be 'r', 'rb', 'rt', 'w', 'wb', or 'wt'.

--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-05 19:26

Message:
Logged In: YES 
user_id=1188172

Should the exceptions be synchronized?

--

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

[ python-Bugs-412436 ] compileall doesn't notice syntax errors

[SourceForge.net]

Bugs item #412436, was opened at 2001-03-30 12:59
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=412436&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: Closed
Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Jeremy Hylton (jhylton)
Summary: compileall doesn't notice syntax errors

Initial Comment:
compileall.py returns an exit code to indicate the
success or failure of compilation.  This feature was
added in compileall.py revision 1.7 in response to
distutils message 
http://mail.python.org/pipermail/distutils-sig/1999-March/000201.html

This is not as useful as it looks because a prior
change to py_compile.py (revision 1.13) catches syntax
errors, hiding them completely from compileall.py, so
compileall.py can't report the failure to its caller.


--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-05 19:34

Message:
Logged In: YES 
user_id=1188172

Closing as Fixed, then.

--

Comment By: Ilya Sandler (isandler)
Date: 2005-04-27 05:58

Message:
Logged In: YES 
user_id=971153


I did a small test

   ~>echo '"garab' > garbage.py 
   ~>python -m compileall .

and got expected:
SyntaxError: EOL while scanning single-quoted string

and exit status of 1

So the problem is fixed in latest python and bug can be closed

--

Comment By: Just van Rossum (jvr)
Date: 2003-01-05 22:01

Message:
Logged In: YES 
user_id=92689

The change to compileall.py has been in CVS for a long time.
The strange thing is that the accompanying py_compile.py
patch wasn't checked in. All I did was update that change
for current CVS. Jeremy?

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-05 21:25

Message:
Logged In: YES 
user_id=33168

I definitely think Just's change to py_compile.py (return 0
or 1 from compile()) should be checked in.  This doesn't
hurt and is backwards compatible.  I think a NEWS entry and
doc updates (Doc/lib/libpycompile.tex) should be done as well.

The change to compileall.py is also probably ok, but I
didn't look as closely (the patch failed to apply for me in
2.3).

--

Comment By: Just van Rossum (jvr)
Date: 2003-01-03 13:29

Message:
Logged In: YES 
user_id=92689

Reopening this bug as it's entirely unclear why the
py_compile.py change wasn't checked in. This has resulted in
a new bug, #653301.

I've attached a patch that's updated for current CVS (rev.
1.23 of py_compile.py).

Since py_compile.py is crucial to the install process I'd
rather have someone else make the decision to check this in
or not.

--

Comment By: Peter Maxwell (pm67nz)
Date: 2001-09-10 05:31

Message:
Logged In: YES 
user_id=320286

I don't see how this can be fixed in compileall.py since the
problem 
is with py_compile.py.  py_compile.compile (up to and
including the 
latest version I see in CVS, revision 1.18) only ever
returns None, 
so the code in compileall.py revision 1.19 that says:
   ok = py_compile.compile(fullname, None, dfile)
and 
   if ok == 0:
can't possibly work.
Caveat: this comment based on reading code, not running it.


--

Comment By: Jeremy Hylton (jhylton)
Date: 2001-04-18 03:23

Message:
Logged In: YES 
user_id=31392

Fixed in rev 1.9 of compileall.py.  Note that this fix
causes a bunch of changes to the test suite, so that files
containing syntaxerrors are not compiled by compileall.


--

Comment By: Jeremy Hylton (jhylton)
Date: 2001-04-13 23:16

Message:
Logged In: YES 
user_id=31392

Will fix following the 2.1 release


--

Comment By: Jeremy Hylton (jhylton)
Date: 2001-04-13 16:31

Message:
Logged In: YES 
user_id=31392

I think this is easy enough to fix, but I don't know what
unintended side-effects the fix will have.

--

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

[ python-Bugs-504219 ] locale.resetlocale is broken

[SourceForge.net]

Bugs item #504219, was opened at 2002-01-16 05:56
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=504219&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
Submitted By: Syver Enstad (syvere)
Assigned to: Mark Hammond (mhammond)
Summary: locale.resetlocale is broken

Initial Comment:
locale.setlocale doesn't recognize the the format that 
locale.py uses to set the locale, ie. no_NO and 
friends.

The only way I've succeeded in setting the locale on 
Python 2.1 is to use the format described in the 
Visual C++ C-runtime library docs for setlocale where 
a more verbose format is used to set the locale.

--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-05 20:04

Message:
Logged In: YES 
user_id=1188172

As this is not Windows specific, setting Category to Library.

--

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-11-08 19:59

Message:
Logged In: YES 
user_id=469548

Still reproducible with Python 2.4:

Python 2.4b2 (#19, Nov  8 2004, 11:15:07)
[GCC 3.3.5 (Debian 1:3.3.5-2)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> import locale
>>> locale.getdefaultlocale()
['en_US', 'utf']
>>> locale.resetlocale()
Traceback (most recent call last):
  File "", line 1, in ?
  File "/home/johannes/python/Lib/locale.py", line 389, in
resetlocale
_setlocale(category, _build_localename(getdefaultlocale()))
locale.Error: unsupported locale setting

Note that if I run python with 'LANG=nl_NL python', the
error does not occur.

http://python.org/sf/813449 seems to be the same bug, BTW.

--

Comment By: Syver Enstad (syvere)
Date: 2002-01-16 14:39

Message:
Logged In: YES 
user_id=428736

Sorry, I forgot to mention the testcase I am using. The 
test case that fails is the locale module itself, when 
running it as a standalone application that is.

To be more specific:
  File "d:\devtools\python21\lib\locale.py", line 384, in 
resetlocale
_setlocale(category, _build_localename(getdefaultlocale
()))
locale.Error: locale setting not supported

And to clarify what input getdefaultlocale returns on my 
machine:

>>> locale.getdefaultlocale()
('no_NO', 'cp1252')

and:
>>> locale._build_localename(locale.getdefaultlocale())
'no_NO.cp1252'

By the way, is this bug fixed in python 2.2?


--

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-16 12:50

Message:
Logged In: YES 
user_id=21627

Can you provide a detailed test case? AFAIK, no_NO is indeed
no supported locale name on Windows, and I don't think
Python aanywhere uses it without the application explicitly
saying so.

--

Comment By: Tim Peters (tim_one)
Date: 2002-01-16 06:07

Message:
Logged In: YES 
user_id=31435

Mark, know anything about this?  I don't.

--

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

[ python-Bugs-755617 ] os module: Need a better description of " mode"

[SourceForge.net]

Bugs item #755617, was opened at 2003-06-17 02:13
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755617&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.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Shomphe (mshomphe)
Assigned to: Nobody/Anonymous (nobody)
Summary: os module: Need a better description of "mode"

Initial Comment:
The page  says the following 
about the function os.chmod:

chmod(path, mode) 
Change the mode of path to the numeric mode. 
Availability: Unix, Windows. 

The "mode" values are unclear.  It turns out that the 
UNIX file permission set (e.g., 0666 for read/writeable) 
works with the Windows set (where 0666 translates to  
33206).

Is it possible to describe the file permissions in more 
detail in the documentation at this point?

Attached is an email thread discussing this 
documentation issue.

--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-05 20:28

Message:
Logged In: YES 
user_id=1188172

I think the wording suggested by logistix would be a good
addition to the docs.

--

Comment By: logistix (logistix)
Date: 2003-06-17 21:31

Message:
Logged In: YES 
user_id=699438

Something like:

"NOTE: Although Windows supports chmod, it incorporates 
much different functionality than a typical Unix user would 
expect.  Please refer to Microsoft’s documentation for more 
details."

would be nice.

--

Comment By: Christopher Blunck (blunck2)
Date: 2003-06-17 17:18

Message:
Logged In: YES 
user_id=531881

Tim-

I captured what Matthew Shomphe recommended into patch 755677
(http://www.python.org/sf/755677).  Hope this helps.

-c

--

Comment By: Tim Peters (tim_one)
Date: 2003-06-17 16:49

Message:
Logged In: YES 
user_id=31435

Then please suggest the actual text you want to see in the 
docs.  I can't do it for you (for example, chmod has always 
done exactly what I've wanted it to do on Windows -- but 
then I've never wanted to do anything with it on Windows 
beyond fiddling the readonly bit).

--

Comment By: logistix (logistix)
Date: 2003-06-17 07:35

Message:
Logged In: YES 
user_id=699438

All I'm saying is that although chmod is valid windows call, it 
will not produce the effect that most users expect.  There's 
no harm in calling it, but it's not going to accomplish what 
most users want it to do.  This information is more important 
to a user than other inconsistencies in the Windows 
implementation.  (i.e. os.stat returning a value that is 
different than chmod set)

--

Comment By: Christopher Blunck (blunck2)
Date: 2003-06-17 05:37

Message:
Logged In: YES 
user_id=531881

see patch 755677

sheesh neal, you couldn't patch this?  ;-)


--

Comment By: Tim Peters (tim_one)
Date: 2003-06-17 05:28

Message:
Logged In: YES 
user_id=31435

Well, let's not overreact here -- MS's _chmod simply calls the 
Win32 SetFileAttributes(), and the only thing it can change is 
the FILE_ATTRIBUTE_READONLY flag.  That's all part of 
Windows base services, and makes sense on FAT too.

--

Comment By: logistix (logistix)
Date: 2003-06-17 04:51

Message:
Logged In: YES 
user_id=699438

Realistically, you should NEVER intentionally use chmod to set 
file permissions on Windows.  The FAT filesystem has no 
permissions, and NTFS has ACLs which are much too complex 
to map to a chmod style call.  MS only has chmod support so 
they can claim some level of posix compliance.

I'm not saying you should drop the ability to call os.chmod on 
windows, but perhaps the docs should say that its not the 
recommended way of doing things.  Unfortunately, there's not 
a recommended way of setting security that'll work on all 
Windows platforms either (although I'd start with os.popen
("cacls ...")  Even win32security requires some serious 
programming just to get started with manipulating ACLs.

Typical security looks something like this:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\grant>xcacls "\Program files"
C:\Program Files BUILTIN\Users:R
 BUILTIN\Users:(OI)(CI)(IO)(special access:)
   GENERIC_REA

[ python-Bugs-1215146 ] int('x',radix) puzzle

[SourceForge.net]

Bugs item #1215146, was opened at 2005-06-05 08:11
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215146&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: Closed
Resolution: Invalid
Priority: 5
Submitted By: elgordo (azgordo)
Assigned to: Nobody/Anonymous (nobody)
Summary: int('x',radix) puzzle

Initial Comment:
I don’t understand the built-in function int(x, radix). Or 
its documentation in the Library Reference section 2.1 – 
Built-In Functions. I’m using Python 2.4.1 on Windows 
XP Pro w/SP2, And I get the following on IDLE:

>>> int(9)
9
>>> int('9')
9
>>> int('9',2)

Traceback (most recent call last):
  File "", line 1, in -toplevel-
int('9',2)
ValueError: invalid literal for int(): 9
>>> int('9',8)

Traceback (most recent call last):
  File "", line 1, in -toplevel-
int('9',8)
ValueError: invalid literal for int(): 9
>>> int('9',10)
9
>>> int('9',16)
9
>>> int('19',16)
25
>>>


--

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-05 16:52

Message:
Logged In: YES 
user_id=80475

I find the current wording to be preferable.   

At some point, adding more words and excessively detailed
doc results in docs that are less readable and less
communicative.

--

Comment By: elgordo (azgordo)
Date: 2005-06-05 09:54

Message:
Logged In: YES 
user_id=1291540

OK --- I was confused by the documentation. I'd like to 
propose the following replacement for the documentation:

int([x[, b]])
Converts base b numbers specified by the inputs to their 
decimal integer equivalents. When the base b is absent x 
may be either (i) the string representation of a possibly 
signed decimal integer (possibly embedded in whitespace), 
or (ii) a possibly signed decimal integer or floating point 
number (floating point numbers are truncated towards zero). If 
the base b is present and non-zero, it must be an integer in 
the range [2, 36] and x must be the possibly signed string 
representation of an integer in base b notation. When x is a 
string and the base b is zero, the base actually used is 
guessed by interpreting the string x in the same way as for 
integer literals.  When b is present then (i) if  x is not a string 
a TypeError is raised, and (ii) if the string x does not 
represent an integer then a ValueError is raised. Returns 0 if 
no arguments are given.


--

Comment By: elgordo (azgordo)
Date: 2005-06-05 09:52

Message:
Logged In: YES 
user_id=1291540

OK --- I was confused by the documentation. I'd like to 
propose the following replacement for the documentation:

int([x[, b]])
Converts base b numbers specified by the inputs to their 
decimal integer equivalents. When the base b is absent x 
may be either (i) the string representation of a possibly 
signed decimal integer (possibly embedded in whitespace), 
or (ii) a possibly signed decimal integer or floating point 
number (floating point numbers are truncated towards zero). If 
the base b is present and non-zero, it must be an integer in 
the range [2, 36] and x must be the possibly signed string 
representation of an integer in base b notation. When x is a 
string and the base b is zero, the base actually used is 
guessed by interpreting the string x in the same way as for 
integer literals.  When b is present then (i) if  x is not a string 
a TypeError is raised, and (ii) if the string x does not 
represent an integer then a ValueError is raised. Returns 0 if 
no arguments are given.


--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-05 09:08

Message:
Logged In: YES 
user_id=1188172

The function is behaving as expected. The radix argument
specifies which base the number system in the string has.
Radix 2 means binary, for example, and radix 16 hexadecimal.
>From that, it is clear that '9' is an invalid binary or
octal number.

In the future, please direct such questions to the Newsgroup
comp.lang.python.

Closing as Invalid.

--

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

[ python-Bugs-1207379 ] class property fset not working

[SourceForge.net]

Bugs item #1207379, was opened at 2005-05-23 17:02
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207379&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: Master_Jaf (master_jaf)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: class property fset not working

Initial Comment:
Classes which are not instantiated from 'object',
containing properties, are not working as expected. The
GET method is working but not the SET method. Tested
with python 2.4.1 und 2.3.5.
See sample code file.

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-04 05:27

Message:
Logged In: YES 
user_id=1188172

Attaching a patch for the Tutorial. It adds the following
sentence:

+Note that with Python 2.2, a new kind of classes was
introduced:
+A class deriving from \class{object} is called a
\emph{new-style class}.
+The differences to classic classes are mostly internal, but
there are
+some features (like properties and static methods) that are
only
+available for new-style classes.
+


--

Comment By: Master_Jaf (master_jaf)
Date: 2005-05-26 13:59

Message:
Logged In: YES 
user_id=1140154

>From my point of view (I'm just learning Python) there is only a
simple difference between old and new style classes, just the
(object) while defining a class.
For sure, we can close this. My questions were answered :-)

So my suggestions for adding info to the documentation:

"Python Tutorial": Chap. 9.3., ex.
With Python 2.2 new style classes were introduced. These new 
style classes are inherited from 'object' base class and
supporting
newer features like properties, slots etc.. It is
recommended to use
new style classes.

"Python Library Reference": Chap. 2.1 Built-in Functions, ex.
property([fget[, fset[, fdel[, doc)
  []
New in Python 2.2. Properties only can applied to new style
classes. See also "D. Glossary" -> new style classes for more
details.

--

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-05-26 11:37

Message:
Logged In: YES 
user_id=593130

For people who learned Python with old-style classes, it 
is 'obvious' that properties are a new addition that came with and 
work with new-style classes.  Can you suggest specific places in 
the docs where clarification could be made?  Or should be close 
this?

(I suspect that setting is more complicated than getting but would 
not have expected even the get method to work.)

--

Comment By: Master_Jaf (master_jaf)
Date: 2005-05-24 07:27

Message:
Logged In: YES 
user_id=1140154

After reading some more documentation I've found at Python
Tutorial "D. Glossary" more hints.

Any class that inherits from object. This includes all
built-in types like list and dict. Only new-style classes
can use Python's newer, versatile features like __slots__,
descriptors, properties, __getattribute__(), class methods,
and static methods.

Fine. OK, understood..
I'm tending to agree with mwh's opinion, that this is a
documentation bug, although I don't fully understand why the
GET descriptor is working but unlikly not the SET descriptor.

--

Comment By: Michael Hudson (mwh)
Date: 2005-05-24 02:58

Message:
Logged In: YES 
user_id=6656

At the very limit, this is a documentation bug.  Why did you think 
properties could be attached to old-style classes?

--

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

[ python-Bugs-887946 ] segfault if redirecting directory

[SourceForge.net]

Bugs item #887946, was opened at 2004-01-31 11:42
Message generated for change (Comment added) made by mbp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=887946&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: Open
Resolution: None
Priority: 6
Submitted By: Inyeol Lee (inyeol)
Assigned to: Nobody/Anonymous (nobody)
Summary: segfault if redirecting directory

Initial Comment:
If redirecting directory, python crashes.

$ uname -a
SunOS x 5.8 Generic_108528-18 sun4u sparc
SUNW,Sun-Blade-1000
$ python
Python 2.3.2 (#1, Oct  9 2003, 18:59:04) 
[GCC 2.95.3 20010315 (release)] on sunos5
Type "help", "copyright", "credits" or "license" for
more information.
>>> ^D
$ mkdir foo
$ ls -F
foo/
$ python < foo
Segmentation Fault

-Inyeol Lee

--

Comment By: Martin Pool (mbp)
Date: 2005-06-06 15:20

Message:
Logged In: YES 
user_id=521

I doubt if libc checks whether the input is a directory;
there are possible (though extremely obscure) cases where
you might want to do that.

I think you probably need something along the lines of
fstat(0, &buf), then check the st_mode.  Remember that fifos
and chardevs ought to be allowed.

--

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-11-22 23:32

Message:
Logged In: YES 
user_id=1038590

Python's C main function assumes stdin, stdout and stderr
are all valid FILE pointers.

A little experimentation on a Linux box should establish
what glibc is providing when the input pipe isn't a proper
file (probably stdin == NULL given the symptoms, but that's
just a guess)

A sanity check on stdin should then be possible near the
start of the main function.

--

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-11-22 23:24

Message:
Logged In: YES 
user_id=1038590

Win XP SP 1 - 

C:\Python24>python < Lib
"Access is Denied"

--

Comment By: Inyeol Lee (inyeol)
Date: 2004-11-05 06:10

Message:
Logged In: YES 
user_id=595280

I did some more test among different versions;
2.4b1/Solaris - segfault
2.3.3/Linux - segfault
2.3.2/Solaris - segfault
2.1.1/Linux - OK
1.5.2/Linux - OK


--

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

[ python-Bugs-887946 ] segfault if redirecting directory

[SourceForge.net]

Bugs item #887946, was opened at 2004-01-31 11:42
Message generated for change (Comment added) made by mbp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=887946&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: Open
Resolution: None
Priority: 6
Submitted By: Inyeol Lee (inyeol)
Assigned to: Nobody/Anonymous (nobody)
Summary: segfault if redirecting directory

Initial Comment:
If redirecting directory, python crashes.

$ uname -a
SunOS x 5.8 Generic_108528-18 sun4u sparc
SUNW,Sun-Blade-1000
$ python
Python 2.3.2 (#1, Oct  9 2003, 18:59:04) 
[GCC 2.95.3 20010315 (release)] on sunos5
Type "help", "copyright", "credits" or "license" for
more information.
>>> ^D
$ mkdir foo
$ ls -F
foo/
$ python < foo
Segmentation Fault

-Inyeol Lee

--

Comment By: Martin Pool (mbp)
Date: 2005-06-06 15:32

Message:
Logged In: YES 
user_id=521

Here is another failure, which might have the same root cause:

$ python /tmp
$ echo $?
0

I'd expect this to give an error.

--

Comment By: Martin Pool (mbp)
Date: 2005-06-06 15:20

Message:
Logged In: YES 
user_id=521

I doubt if libc checks whether the input is a directory;
there are possible (though extremely obscure) cases where
you might want to do that.

I think you probably need something along the lines of
fstat(0, &buf), then check the st_mode.  Remember that fifos
and chardevs ought to be allowed.

--

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-11-22 23:32

Message:
Logged In: YES 
user_id=1038590

Python's C main function assumes stdin, stdout and stderr
are all valid FILE pointers.

A little experimentation on a Linux box should establish
what glibc is providing when the input pipe isn't a proper
file (probably stdin == NULL given the symptoms, but that's
just a guess)

A sanity check on stdin should then be possible near the
start of the main function.

--

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-11-22 23:24

Message:
Logged In: YES 
user_id=1038590

Win XP SP 1 - 

C:\Python24>python < Lib
"Access is Denied"

--

Comment By: Inyeol Lee (inyeol)
Date: 2004-11-05 06:10

Message:
Logged In: YES 
user_id=595280

I did some more test among different versions;
2.4b1/Solaris - segfault
2.3.3/Linux - segfault
2.3.2/Solaris - segfault
2.1.1/Linux - OK
1.5.2/Linux - OK


--

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