Re: [Python-Dev] Is this a bug or a feature?

[M.-A. Lemburg]

Please report such problems on our bug tracker:

http://bugs.python.org/

In your case, Python doesn't appear to find the (right) libz
shared library, which is a bit odd, but it's better to track this
down on the tracker :-)

On 16.02.2017 21:33, Patrick Wallinger wrote:
> I'm brand new to python and was trying to install the newest version
> (3.6.0) on my ubuntu 16.04.1 but couldn't get it to build error free. I
> tried searching the bugs but didn't see a match for what I am seeing.
> 
> Thanks for any help,
> Patrick
> 
> Here is the report:
> patrick@ubuntu-MacBook:~/Programs/Python-3.6.0$ ./python -m test -v
> test_venv
> == CPython 3.6.0 (default, Feb 16 2017, 13:20:29) [GCC 5.4.0 20160609]
> ==   Linux-4.4.0-62-generic-x86_64-with-debian-stretch-sid little-endian
> ==   hash algorithm: siphash24 64bit
> ==  cwd: /home/patrick/Programs/Python-3.6.0/build/test_python_20536
> ==  encodings: locale=UTF-8, FS=utf-8
> Testing with flags: sys.flags(debug=0, inspect=0, interactive=0,
> optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0,
> ignore_environment=0, verbose=0, bytes_warning=0, quiet=0,
> hash_randomization=1, isolated=0)
> Run tests sequentially
> 0:00:00 [1/1] test_venv
> test_defaults (test.test_venv.BasicTest) ... ok
> test_executable (test.test_venv.BasicTest) ... ok
> test_executable_symlinks (test.test_venv.BasicTest) ... ok
> test_isolation (test.test_venv.BasicTest) ... ok
> test_overwrite_existing (test.test_venv.BasicTest) ... ok
> test_prefixes (test.test_venv.BasicTest) ... ok
> test_prompt (test.test_venv.BasicTest) ... ok
> test_symlinking (test.test_venv.BasicTest) ... ok
> test_unoverwritable_fails (test.test_venv.BasicTest) ... ok
> test_upgrade (test.test_venv.BasicTest) ... ok
> test_devnull (test.test_venv.EnsurePipTest) ... ok
> test_explicit_no_pip (test.test_venv.EnsurePipTest) ... ok
> test_no_pip_by_default (test.test_venv.EnsurePipTest) ... ok
> test_with_pip (test.test_venv.EnsurePipTest) ... FAIL
> 
> ==
> FAIL: test_with_pip (test.test_venv.EnsurePipTest)
> --
> Traceback (most recent call last):
>   File "/home/patrick/Programs/Python-3.6.0/Lib/test/test_venv.py", line
> 372, in test_with_pip
> with_pip=True)
> subprocess.CalledProcessError: Command '['/tmp/tmp51me85og/bin/python',
> '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit
> status 1.
> 
> During handling of the above exception, another exception occurred:
> 
> Traceback (most recent call last):
>   File "/home/patrick/Programs/Python-3.6.0/Lib/test/test_venv.py", line
> 378, in test_with_pip
> self.fail(msg.format(exc, details))
> AssertionError: Command '['/tmp/tmp51me85og/bin/python', '-Im',
> 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1.
> 
> **Subprocess Output**
> Traceback (most recent call last):
>   File "/home/patrick/Programs/Python-3.6.0/Lib/runpy.py", line 193, in
> _run_module_as_main
> "__main__", mod_spec)
>   File "/home/patrick/Programs/Python-3.6.0/Lib/runpy.py", line 85, in
> _run_code
> exec(code, run_globals)
>   File "/home/patrick/Programs/Python-3.6.0/Lib/ensurepip/__main__.py",
> line 4, in 
> ensurepip._main()
>   File "/home/patrick/Programs/Python-3.6.0/Lib/ensurepip/__init__.py",
> line 189, in _main
> default_pip=args.default_pip,
>   File "/home/patrick/Programs/Python-3.6.0/Lib/ensurepip/__init__.py",
> line 102, in bootstrap
> _run_pip(args + [p[0] for p in _PROJECTS], additional_paths)
>   File "/home/patrick/Programs/Python-3.6.0/Lib/ensurepip/__init__.py",
> line 27, in _run_pip
> import pip
> zipimport.ZipImportError: can't decompress data; zlib not available
> 
> 
> --
> Ran 14 tests in 1.278s
> 
> FAILED (failures=1)
> test test_venv failed
> test_venv failed
> 
> 1 test failed:
> test_venv
> 
> Total duration: 1 sec
> Tests result: FAILURE
> 
> 
> 
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/mal%40egenix.com
> 

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Feb 17 2017)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   

Re: [Python-Dev] Is this a bug or a feature?

[Patrick Wallinger]

Oleg,

After installing a fresh zlib package from here:
http://packages.ubuntu.com/xenial/zlib1g
I was able to build and install Python-3.6.0
seems to me if the zlib module sent out with the 3.6.0 release package
doesn't build (which it doesn't) then that's a bug.

thanks for your time,
Patrick

On Thu, Feb 16, 2017 at 3:46 PM, Oleg Broytman  wrote:

> Hello.
>
>We are sorry but we cannot help you. This mailing list is to work on
> developing Python (adding new features to Python itself and fixing bugs);
> if you're having problems learning, understanding or using Python, please
> find another forum. Probably python-list/comp.lang.python mailing list/news
> group is the best place; there are Python developers who participate in it;
> you may get a faster, and probably more complete, answer there. See
> http://www.python.org/community/ for other lists/news groups/fora. Thank
> you for understanding.
>
>
> On Thu, Feb 16, 2017 at 02:33:19PM -0600, Patrick Wallinger <
> the.hi...@gmail.com> wrote:
> > I'm brand new to python and was trying to install the newest version
> > (3.6.0) on my ubuntu 16.04.1 but couldn't get it to build error free. I
> > tried searching the bugs but didn't see a match for what I am seeing.
> >
> > Thanks for any help,
> > Patrick
> >
> > Here is the report:
> > patrick@ubuntu-MacBook:~/Programs/Python-3.6.0$ ./python -m test -v
> > test_venv
> [skip]
> > zipimport.ZipImportError: can't decompress data; zlib not available
>
>Seems yoy don't have zlib or haven't had zlib headers when you
> compiled python. Install zlib and zlib-dev packages and recompile
> python.
>
> Oleg.
> --
>  Oleg Broytmanhttp://phdru.name/p...@phdru.name
>Programmers don't die, they just GOSUB without RETURN.
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Is this a bug or a feature?

[Oleg Broytman]

Hello.

   We are sorry but we cannot help you. This mailing list is to work on
developing Python (adding new features to Python itself and fixing bugs);
if you're having problems learning, understanding or using Python, please
find another forum. Probably python-list/comp.lang.python mailing list/news
group is the best place; there are Python developers who participate in it;
you may get a faster, and probably more complete, answer there. See
http://www.python.org/community/ for other lists/news groups/fora. Thank
you for understanding.


On Thu, Feb 16, 2017 at 02:33:19PM -0600, Patrick Wallinger 
 wrote:
> I'm brand new to python and was trying to install the newest version
> (3.6.0) on my ubuntu 16.04.1 but couldn't get it to build error free. I
> tried searching the bugs but didn't see a match for what I am seeing.
> 
> Thanks for any help,
> Patrick
> 
> Here is the report:
> patrick@ubuntu-MacBook:~/Programs/Python-3.6.0$ ./python -m test -v
> test_venv
[skip]
> zipimport.ZipImportError: can't decompress data; zlib not available

   Seems yoy don't have zlib or haven't had zlib headers when you
compiled python. Install zlib and zlib-dev packages and recompile
python.

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Is this a bug or a feature?

[Chris Angelico]

On Fri, Feb 17, 2017 at 7:33 AM, Patrick Wallinger  wrote:
> zipimport.ZipImportError: can't decompress data; zlib not available
>

There may very well be a bug here of the form of "zlib dependency is
considered soft, but then something else breaks". However, in your
current situation, my recommendation would be to install the zlib
development libraries and retry the build. You may be able to get that
with:

$ sudo apt-get build-dep python3

or possibly search your package manager for "zlib*-dev" (on my Debian,
it's zlib1g-dev). That should give you the full de/compression suite,
which will in turn make ensurepip work.

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] I cannot create bug reports

[Ian Cordasco]

The first thing that comes to mind is that your session expired and
you need to log-in again. After logging in myself I see the form in
all of it's glory.

On Wed, Apr 24, 2013 at 2:35 PM, Daniel Wong allyourc...@gmail.com wrote:
 Glorious members of python-dev,

 I'd like to submit a patch, but I cannot create a bug report. As of this
 morning (US West Coast), when I go to
 http://bugs.python.org/issue?@template=item I get no form fields.

 I went there last night, and I was able to get a form. I kept that tab open
 over night, and tried to submit this morning. When I did that, I got
 permission denied errors. It seems that something weird has happened to my
 account, or bug tracker itself changed in my sleep.

 Anyone have any idea what's going on here?

 Daniel

 ___
 Python-Dev mailing list
 Python-Dev@python.org
 http://mail.python.org/mailman/listinfo/python-dev
 Unsubscribe:
 http://mail.python.org/mailman/options/python-dev/graffatcolmingov%40gmail.com

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] I cannot create bug reports

[Daniel Wong]

Thank you. That was the problem.

I feel kind of stupid now. In my defense, the error message could have been
more helpful, and requesting the bug creation form could have thrown up a
login error instead of showing up blank. File another bug?


On Wed, Apr 24, 2013 at 11:45 AM, Ian Cordasco
graffatcolmin...@gmail.comwrote:

 The first thing that comes to mind is that your session expired and
 you need to log-in again. After logging in myself I see the form in
 all of it's glory.

 On Wed, Apr 24, 2013 at 2:35 PM, Daniel Wong allyourc...@gmail.com
 wrote:
  Glorious members of python-dev,
 
  I'd like to submit a patch, but I cannot create a bug report. As of this
  morning (US West Coast), when I go to
  http://bugs.python.org/issue?@template=item I get no form fields.
 
  I went there last night, and I was able to get a form. I kept that tab
 open
  over night, and tried to submit this morning. When I did that, I got
  permission denied errors. It seems that something weird has happened to
 my
  account, or bug tracker itself changed in my sleep.
 
  Anyone have any idea what's going on here?
 
  Daniel
 
  ___
  Python-Dev mailing list
  Python-Dev@python.org
  http://mail.python.org/mailman/listinfo/python-dev
  Unsubscribe:
 
 http://mail.python.org/mailman/options/python-dev/graffatcolmingov%40gmail.com
 

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] I cannot create bug reports

[Brian Curtin]

On Wed, Apr 24, 2013 at 1:55 PM, Daniel Wong allyourc...@gmail.com wrote:
 Thank you. That was the problem.

 I feel kind of stupid now. In my defense, the error message could have been
 more helpful, and requesting the bug creation form could have thrown up a
 login error instead of showing up blank. File another bug?

Bugs about the bug tracker go to http://psf.upfronthosting.co.za/roundup/meta/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython: ../bug-fixes/http_error_interface/.hg/last-message.txt

[Senthil Kumaran]

Looks like I used hg commit -m /path/to/.hg/last-message.txt instead
of hg commit -l /path/to/.hg/last-message.txt
I have amended it, merged it and pushed it again.

On Tue, Mar 19, 2013 at 12:04 PM, senthil.kumaran
python-check...@python.org wrote:
 http://hg.python.org/cpython/rev/4f2080e9eee2
 changeset:   82765:4f2080e9eee2
 parent:  82763:4c6463b96a2c
 user:Senthil Kumaran sent...@uthcode.com
 date:Tue Mar 19 12:07:43 2013 -0700
 summary:
   ../bug-fixes/http_error_interface/.hg/last-message.txt

 files:
   Lib/test/test_urllib2.py |  39 +--
   1 files changed, 19 insertions(+), 20 deletions(-)


 diff --git a/Lib/test/test_urllib2.py b/Lib/test/test_urllib2.py
 --- a/Lib/test/test_urllib2.py
 +++ b/Lib/test/test_urllib2.py
 @@ -1387,6 +1387,10 @@

  class MiscTests(unittest.TestCase):

 +def opener_has_handler(self, opener, handler_class):
 +self.assertTrue(any(h.__class__ == handler_class
 +for h in opener.handlers))
 +
  def test_build_opener(self):
  class MyHTTPHandler(urllib.request.HTTPHandler): pass
  class FooHandler(urllib.request.BaseHandler):
 @@ -1439,10 +1443,22 @@
  self.assertEqual(b1234567890, request.data)
  self.assertEqual(10, request.get_header(Content-length))

 +def test_HTTPError_interface(self):
 +
 +Issue 13211 reveals that HTTPError didn't implement the URLError
 +interface even though HTTPError is a subclass of URLError.

 -def opener_has_handler(self, opener, handler_class):
 -self.assertTrue(any(h.__class__ == handler_class
 -for h in opener.handlers))
 + msg = 'something bad happened'
 + url = code = fp = None
 + hdrs = 'Content-Length: 42'
 + err = urllib.error.HTTPError(url, code, msg, hdrs, fp)
 + assert hasattr(err, 'reason')
 + err.reason
 +'something bad happened'
 + assert hasattr(err, 'headers')
 + err.headers
 +'Content-Length: 42'
 +

  class RequestTests(unittest.TestCase):

 @@ -1514,23 +1530,6 @@
  req = Request(url)
  self.assertEqual(req.get_full_url(), url)

 -def test_HTTPError_interface():
 -
 -Issue 13211 reveals that HTTPError didn't implement the URLError
 -interface even though HTTPError is a subclass of URLError.
 -
 - msg = 'something bad happened'
 - url = code = fp = None
 - hdrs = 'Content-Length: 42'
 - err = urllib.error.HTTPError(url, code, msg, hdrs, fp)
 - assert hasattr(err, 'reason')
 - err.reason
 -'something bad happened'
 - assert hasattr(err, 'headers')
 - err.headers
 -'Content-Length: 42'
 -
 -
  def test_main(verbose=None):
  from test import test_urllib2
  support.run_doctest(test_urllib2, verbose)

 --
 Repository URL: http://hg.python.org/cpython

 ___
 Python-checkins mailing list
 python-check...@python.org
 http://mail.python.org/mailman/listinfo/python-checkins

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] http.server - reference to bug #427345

[Antoine Pitrou]

On Tue, 23 Nov 2010 22:35:10 -0600
Brian Curtin brian.cur...@gmail.com wrote:
 On Tue, Nov 23, 2010 at 22:28, Glenn Linderman
 v+pyt...@g.nevcal.comv%2bpyt...@g.nevcal.com
  wrote:
 
   Where might I find the bug #427345 that is referred to in a comment inside
  http.server ?  Here is a code excerpt:
 
  # throw away additional data [see bug #427345]
  while select.select([self.rfile._sock], [], [], 0)[0]:
  if not self.rfile._sock.recv(1):
  break
 
 
 http://bugs.python.org/issue427345
 
 http://bugs.python.org/ has a box on the left-hand side where you can enter
 issue numbers.

And of course you can also reverse-engineer the clever URL scheme used
by Roundup bug entries ;)

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] is this a bug? no environment variables

[Glenn Linderman]

On 11/22/2010 8:33 AM, Guido van Rossum wrote:

On Sun, Nov 21, 2010 at 9:40 PM, Glenn Lindermanv+pyt...@g.nevcal.com  wrote:

  In reviewing my notes from my experimentations with CGIHTTPServer
  (Python2.6) and then http.server (Python 3.2a4), I note one behavior I
  haven't reported as a bug, nor do I know where to start to figure it out,
  other than experimentally.

  The experiment: launching CGIHTTPServer without environment variables, by
  the simple expedient of using a batch file to unset all the existing
  environment variables, and then launching Python2.6 with CGIHTTPServer.

  So it failed early: random.py fails at line 110 (Python 2.6).

What specific traceback do you get? In my copy of the code that line says

 a = long(_hexlify(_urandom(16)), 16)

and I could just imagine that _urandom() fails for some reason to do
with the environment (it is a reference to os.urandom()), which, being
part of the C library code, might depend on the environment.

But you're not giving enough info to debug this.


OK, here is the traceback.  I've upgraded the application from Python 
2.6 + CGIHTTPServer.py + bugfixes to Python 3.2a4 + http.server + 
bugfixes, hoping that it would fix it, but since it didn't that the 
traceback would be more relevant.  It seems that _urandom is the likely 
culprit.


Traceback (most recent call last):
  File d:\my\web\areliabl\0test\https.py, line 5, in module
import server
  File d:\my\web\areliabl\0test\server.py, line 88, in module
import email.message
  File C:\Python32\lib\email\message.py, line 17, in module
from email import utils
  File C:\Python32\lib\email\utils.py, line 27, in module
import random
  File C:\Python32\lib\random.py, line 698, in module
_inst = Random()
  File C:\Python32\lib\random.py, line 90, in __init__
self.seed(x)
  File C:\Python32\lib\random.py, line 108, in seed
a = int.from_bytes(_urandom(32), 'big')
WindowsError: [Error -2146893818] Invalid Signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] is this a bug? no environment variables

[Amaury Forgeot d'Arc]

Hi,

2010/11/23 Glenn Linderman v+pyt...@g.nevcal.com:
   File C:\Python32\lib\random.py, line 108, in seed
     a = int.from_bytes(_urandom(32), 'big')
 WindowsError: [Error -2146893818] Invalid Signature

In the subprocess documentation http://docs.python.org/library/subprocess.html
On Windows, in order to run a side-by-side assembly the specified
env *must* include a valid SystemRoot.

Can you keep this variable and start again?

-- 
Amaury Forgeot d'Arc
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] is this a bug? no environment variables

[Martin v. Löwis]

Am 23.11.2010 11:55, schrieb Amaury Forgeot d'Arc:
 Hi,
 
 2010/11/23 Glenn Linderman v+pyt...@g.nevcal.com:
   File C:\Python32\lib\random.py, line 108, in seed
 a = int.from_bytes(_urandom(32), 'big')
 WindowsError: [Error -2146893818] Invalid Signature
 
 In the subprocess documentation http://docs.python.org/library/subprocess.html
 On Windows, in order to run a side-by-side assembly the specified
 env *must* include a valid SystemRoot.

Indeed, setting SystemRoot might solve this problem. According to

http://jpassing.com/2009/12/28/the-hidden-danger-of-forgetting-to-specify-systemroot-in-a-custom-environment-block/

CrypoAPI, in Windows 7, requires this variable be set. Failure to
find the enhanced crypto provider would explain why the random
module of Python fails to work.

The specific cause is in the registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Cryptography\Defaults\Provider\Microsoft
Strong Cryptographic Provider has as it's ImagePath value

%SystemRoot%\system32\rsaenh.dll

So the registry (and COM) do rely on environment variables.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] is this a bug? no environment variables

[Glenn Linderman]

On 11/23/2010 3:55 AM, Martin v. Löwis wrote:

Am 23.11.2010 11:55, schrieb Amaury Forgeot d'Arc:

Hi,

2010/11/23 Glenn Lindermanv+pyt...@g.nevcal.com:

   File C:\Python32\lib\random.py, line 108, in seed
 a = int.from_bytes(_urandom(32), 'big')
WindowsError: [Error -2146893818] Invalid Signature

In the subprocess documentation http://docs.python.org/library/subprocess.html
On Windows, in order to run a side-by-side assembly the specified
env *must* include a valid SystemRoot.

Indeed, setting SystemRoot might solve this problem. According to

http://jpassing.com/2009/12/28/the-hidden-danger-of-forgetting-to-specify-systemroot-in-a-custom-environment-block/

CrypoAPI, in Windows 7, requires this variable be set. Failure to
find the enhanced crypto provider would explain why the random
module of Python fails to work.

The specific cause is in the registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Cryptography\Defaults\Provider\Microsoft
Strong Cryptographic Provider has as it's ImagePath value

%SystemRoot%\system32\rsaenh.dll

So the registry (and COM) do rely on environment variables.

Regards,
Martin


I find it sad but hilarious that after working so hard to remove the 
need for environment variables from Windows that M$ has introduced new 
dependencies on them.


I wonder if this particular registry variable is simply an oversight/bug 
on M$' part, that they will eventually fix, or if it a turnaround toward 
the use of more environment variables in the future.  Hmm.  Time will 
tell, I suppose.  I'm unaware of any benefits in _changing_ SystemRoot 
to other values, so not pre-expanding it in that registry location seems 
only to add an unnecessary dependency on the environment.


Indeed, preserving that one environment variable allows my version of 
http.server to proceed with, as far as initial testing can determine, 
proper behavior.  Thanks for your help in figuring this out.  That was a 
lot faster than a binary search to choose which variable(s) to preserve.


My purpose in such testing was two-fold: firstly, web servers, for 
security purposes, generally limit the number of environment variables 
that are seen by CGI programs, and secondly, in debugging whether or not 
http.server was properly setting the necessary environment variables, 
the many other environment variables were cluttering up log dumps of all 
environment variables.  It will be nicer to limit the passed through 
environment variables to SystemRoot, as see how things go.


I have read some about side-by-side assemblies but had considered them a 
good reason to stick with the outdated M$VC 6.0 compiler, which doesn't 
seem to need to create them, and their myriad requirements, which seem 
far from necessary for simply compiling a program.  I was disappointed 
to realize that Python was heading down the path of using the newer 
tools that create side-by-side assemblies, but I suppose using an old 
and crufty compiler like M$VC 6.0 cannot support some of the newer 
features of Windows, which may seem to be necessary to some like 
64-bit support, which does seem necessary, even to me.


I was well aware that shortcuts and the registry _may_ refer to 
environment variables, and have a number of environment variables of my 
own which leverage that capability, to avoid hard-coded drive letters 
and paths in certain areas, and for the convenience of shorting the 
specification of some of the long-winded path names that Windows foists 
upon us (some of those have been significantly shortened in Windows 6.1, 
and maybe 6.0 which I used only for 2 months with disgust; 6.1 has 
helped alleviate the disgust, but I still recommend XP for people that 
don't need 64-bit capabilities).



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] is this a bug? no environment variables

[Glenn Linderman]

On 11/22/2010 2:56 PM, Tim Lesher wrote:

On Mon, Nov 22, 2010 at 16:54, Glenn Lindermanv+pyt...@g.nevcal.com  wrote:

I suppose it is possible that some environment variables are used by Python
directly (but I can't seem to find a documented list of them) although I
would expect that usage to be optional, with fall-back defaults when they
don't exist.

I can verify that that's the case: Python (at least through 3.1.2)
runs fine on Windows platforms when environment variables are
completely unavailable.  I know that from running our port for Windows
CE (which has no environment variables at all), cross-compiled for
Windows XP.


Is the Windows CE port generally available?  From where?  The CE ports I 
have found in past searches seem to have been quite outdated and not 
much on-going activity.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] is this a bug? no environment variables

[Martin v. Löwis]

 I have read some about side-by-side assemblies but had considered them a
 good reason to stick with the outdated M$VC 6.0 compiler, which doesn't
 seem to need to create them, and their myriad requirements, which seem
 far from necessary for simply compiling a program.  I was disappointed
 to realize that Python was heading down the path of using the newer
 tools that create side-by-side assemblies, but I suppose using an old
 and crufty compiler like M$VC 6.0 cannot support some of the newer
 features of Windows, which may seem to be necessary to some like
 64-bit support, which does seem necessary, even to me.

The rationale for moving along with the releases is different, though:
you cannot obtain the old versions anymore, except perhaps on Ebay.
So new developers coming to Python would not be able to build Python
extensions if we didn't always try to use a compiler that is still
available (and we are stressing that a little bit: 3.2 will use
VS 2008, even though it has been already superceded).

In any case, VS 2010 will stop using SxS for the CRT.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] is this a bug? no environment variables

[Glenn Linderman]

On 11/23/2010 12:33 PM, Martin v. Löwis wrote:

In any case, VS 2010 will stop using SxS for the CRT.


Good news!  Maybe M$VC will become a useful compiler yet again :)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] http.server - reference to bug #427345

[Brian Curtin]

On Tue, Nov 23, 2010 at 22:28, Glenn Linderman
v+pyt...@g.nevcal.comv%2bpyt...@g.nevcal.com
 wrote:

  Where might I find the bug #427345 that is referred to in a comment inside
 http.server ?  Here is a code excerpt:

 # throw away additional data [see bug #427345]
 while select.select([self.rfile._sock], [], [], 0)[0]:
 if not self.rfile._sock.recv(1):
 break


http://bugs.python.org/issue427345

http://bugs.python.org/ has a box on the left-hand side where you can enter
issue numbers.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] is this a bug? no environment variables

[Guido van Rossum]

On Sun, Nov 21, 2010 at 9:40 PM, Glenn Linderman v+pyt...@g.nevcal.com wrote:
 In reviewing my notes from my experimentations with CGIHTTPServer
 (Python2.6) and then http.server (Python 3.2a4), I note one behavior I
 haven't reported as a bug, nor do I know where to start to figure it out,
 other than experimentally.

 The experiment: launching CGIHTTPServer without environment variables, by
 the simple expedient of using a batch file to unset all the existing
 environment variables, and then launching Python2.6 with CGIHTTPServer.

 So it failed early: random.py fails at line 110 (Python 2.6).

What specific traceback do you get? In my copy of the code that line says

a = long(_hexlify(_urandom(16)), 16)

and I could just imagine that _urandom() fails for some reason to do
with the environment (it is a reference to os.urandom()), which, being
part of the C library code, might depend on the environment.

But you're not giving enough info to debug this.

 I suppose it is possible that some environment variables are used by Python
 directly (but I can't seem to find a documented list of them) although I
 would expect that usage to be optional, with fall-back defaults when they
 don't exist.

That is certainly the idea, but the fallbacks may not always be nice.

Environment variables used by Python or the stdlib itself are supposed
to be named PYTHONwhatever if they are Python-specific, and there's
a way to disable all of these (-E). But there are other environment
variables (HOME and PATH come to mind) that have a broader definition
and that are used in some part of the stdlib. Plus, as I mentioned,
who knows what the non-Python C library uses (well, somebody probably
knows, but I don't know of a central source that we can actually trust
across the many platforms where Python runs).

 I suppose it is even possible that some Windows APIs might
 depend on some environment variables, but I expected that the registry had
 replaced such usage completely, by now, with the environment variables
 mostly being a convenience tool for batch files, or for optional, temporary
 alteration of particular settings.

That sounds like wishful thinking. :-)

 If anyone knows of documentation listing what environment variables are
 required by Python on Windows, I would appreciate a pointer, searches and
 doc browsing having not turned it up.

 I'll attempt to recreate the test situation later this week with Python
 3.2a4, if no one responds, but the only debug technique I can think of is to
 slowly remove environment variables until I find the minimum set required to
 run http.server successfully for my tests with CGI files.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] is this a bug? no environment variables

[Glenn Linderman]

On 11/22/2010 8:33 AM, Guido van Rossum wrote:

On Sun, Nov 21, 2010 at 9:40 PM, Glenn Lindermanv+pyt...@g.nevcal.com  wrote:

In reviewing my notes from my experimentations with CGIHTTPServer
(Python2.6) and then http.server (Python 3.2a4), I note one behavior I
haven't reported as a bug, nor do I know where to start to figure it out,
other than experimentally.

The experiment: launching CGIHTTPServer without environment variables, by
the simple expedient of using a batch file to unset all the existing
environment variables, and then launching Python2.6 with CGIHTTPServer.

So it failed early: random.py fails at line 110 (Python 2.6).

What specific traceback do you get? In my copy of the code that line says

 a = long(_hexlify(_urandom(16)), 16)

and I could just imagine that _urandom() fails for some reason to do
with the environment (it is a reference to os.urandom()), which, being
part of the C library code, might depend on the environment.

But you're not giving enough info to debug this.


Yep, that's the line.  I'll have to re-run the scenario, but will do it 
on 3.2a4, hopefully tonight or tomorrow, to get the traceback.




I suppose it is possible that some environment variables are used by Python
directly (but I can't seem to find a documented list of them) although I
would expect that usage to be optional, with fall-back defaults when they
don't exist.

That is certainly the idea, but the fallbacks may not always be nice.

Environment variables used by Python or the stdlib itself are supposed
to be named PYTHONwhatever  if they are Python-specific, and there's
a way to disable all of these (-E). But there are other environment
variables (HOME and PATH come to mind) that have a broader definition
and that are used in some part of the stdlib. Plus, as I mentioned,
who knows what the non-Python C library uses (well, somebody probably
knows, but I don't know of a central source that we can actually trust
across the many platforms where Python runs).


OK, thanks for the philosophy statement.  That's what I didn't know, 
being new.



I suppose it is even possible that some Windows APIs might
depend on some environment variables, but I expected that the registry had
replaced such usage completely, by now, with the environment variables
mostly being a convenience tool for batch files, or for optional, temporary
alteration of particular settings.

That sounds like wishful thinking. :-)


Well, wishful thinking from me regarding the Windows and the registry is 
that Windows would be better off without a registry.  But it seemed like 
their direction was instead to do away with environment variables, but 
in any case, I have little idea if they've achieved it, but should have 
achieved something in 6.1 versions of Windows!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] is this a bug? no environment variables

[Tim Lesher]

On Mon, Nov 22, 2010 at 16:54, Glenn Linderman v+pyt...@g.nevcal.com wrote:
 I suppose it is possible that some environment variables are used by Python
 directly (but I can't seem to find a documented list of them) although I
 would expect that usage to be optional, with fall-back defaults when they
 don't exist.

I can verify that that's the case: Python (at least through 3.1.2)
runs fine on Windows platforms when environment variables are
completely unavailable.  I know that from running our port for Windows
CE (which has no environment variables at all), cross-compiled for
Windows XP.
-- 
Tim Lesher tles...@gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] binary operation heuristics -- bug or undocumented?

[Mark Dickinson]

On Fri, Mar 19, 2010 at 12:46 PM, Alex A. Naanou alex.na...@gmail.com wrote:
 A friend of mine stumbled upon the following behavior:


 ---cut---

 class A(object): pass
 ...
 class B(object):
 ...     def __add__(self, other):
 ...         print 'B: adding B and %s objects.' % other.__class__.__name__
 ...
 class C(object):
 ...     def __radd__(self, other):
 ...         print 'C: adding C and %s objects.' % other.__class__.__name__
 ...
 a, b, c = A(), B(), C()

 b + c
 B: adding B and C objects.

 a + c
 C: adding C and A objects.


 # so far, quite logical. now let's do this:

 1 + c
 C: adding C and int objects.


 --uncut--

 My first expectation would be to get a TypeError here, as ints indeed
 have an __add__ method, and they do not know anything about C objects
 (obviously :) ).

Yes:  the int.__add__ method is tried first.  Since it doesn't know
anything about C objects it returns NotImplemented, and then
C.__radd__ is given a chance to do the addition.  The rules are
documented here:

http://docs.python.org/reference/datamodel.html#coercion-rules

Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] binary operation heuristics -- bug or undocumented?

[Michael Foord]

On 19/03/2010 12:46, Alex A. Naanou wrote:

[snip...]

class C(object):
 

... def __radd__(self, other):
... print 'C: adding C and %s objects.' % other.__class__.__name__
...
   

a, b, c = A(), B(), C()
1 + c
 

C: adding C and int objects.


   


That is the whole point of the __radd__ method. ints don't know how to 
add themselves to C objects, so int.__add__ will return NotImplemented 
and then Python will try C.__radd__.


All the best,

Michael


--uncut--

My first expectation would be to get a TypeError here, as ints indeed
have an __add__ method, and they do not know anything about C objects
(obviously :) ). On second thought, giving client code priority to
handle things has it's merits.

The problem is that I found no mention of this behavior in the docs.


P.S. tested in 2.5 through 3.0 and PyPy

Thanks.

   



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of 
your employer, to release me from all obligations and waivers arising from any 
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, 
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and 
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your 
employer, its partners, licensors, agents and assigns, in perpetuity, without 
prejudice to my ongoing rights and privileges. You further represent that you 
have the authority to release me from any BOGUS AGREEMENTS on behalf of your 
employer.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] binary operation heuristics -- bug or undocumented?

[Alex A. Naanou]

Thanks!

On Fri, Mar 19, 2010 at 16:05, Michael Foord fuzzy...@voidspace.org.uk wrote:
 On 19/03/2010 12:46, Alex A. Naanou wrote:

 [snip...]

 class C(object):


 ...     def __radd__(self, other):
 ...         print 'C: adding C and %s objects.' % other.__class__.__name__
 ...


 a, b, c = A(), B(), C()
 1 + c


 C: adding C and int objects.




 That is the whole point of the __radd__ method. ints don't know how to add
 themselves to C objects, so int.__add__ will return NotImplemented and then
 Python will try C.__radd__.

 All the best,

 Michael

 --uncut--

 My first expectation would be to get a TypeError here, as ints indeed
 have an __add__ method, and they do not know anything about C objects
 (obviously :) ). On second thought, giving client code priority to
 handle things has it's merits.

 The problem is that I found no mention of this behavior in the docs.


 P.S. tested in 2.5 through 3.0 and PyPy

 Thanks.




 --
 http://www.ironpythoninaction.com/
 http://www.voidspace.org.uk/blog

 READ CAREFULLY. By accepting and reading this email you agree, on behalf of
 your employer, to release me from all obligations and waivers arising from
 any and all NON-NEGOTIATED agreements, licenses, terms-of-service,
 shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure,
 non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have
 entered into with your employer, its partners, licensors, agents and
 assigns, in perpetuity, without prejudice to my ongoing rights and
 privileges. You further represent that you have the authority to release me
 from any BOGUS AGREEMENTS on behalf of your employer.

P.S. like the licence :)







-- 
Alex.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] binary operation heuristics -- bug or undocumented?

[Terry Reedy]

On 3/19/2010 8:46 AM, Alex A. Naanou wrote:


A friend of mine stumbled upon the following behavior:

[snip]
Questions like this are more appropriately posted to python-list, where 
you would have gotten the same answer.


tjr


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Is this a bug of the HTMLParser?

[Zhang Chiyuan]

filed: http://bugs.python.org/issue7311

On Thu, Nov 12, 2009 at 12:24 AM, Michael Foord
fuzzy...@voidspace.org.ukwrote:

 Hello Zhang Chiyuan,

 Can you file a bug on the Python issue tracker please:

   http://bugs.python.org

 Thanks

 Michael Foord

 Zhang Chiyuan wrote:

 Hi all,

 I'm using BeautifulSoup to parsing an HTML page and find it refused to
 parse the page. By looking at the backtrace, I found it is a problem
 with the python built-in HTMLParser.py. In fact, the web page I'm
 parsing is with some Chinese characters. there is a tag like img
 src=/foo/bar.png alt=中文 , note this is legacy html page where the
 attributes are not quoted. However, the regexp defined in
 HTMLParser.py is :

  attrfind = re.compile(
 r'\s*([a-zA-Z_][-.:a-zA-Z_0-9]*)(\s*=\s*'
 r'(\'[^\']*\'|[^]*|[-a-zA-Z0-9./,:;+*%?!$\(\)_...@]*))?')

 Note that the Chinese character (also any other non-english
 characters), so it fire an error parsing this. I'm not sure whether
 the HTML standard allow un-quoted non-ASCII characters in the
 attributes. If it allows, this seems to be a bug. and the regexp to
 better be [^\s] IMHO.

 BTW: It seems something like :

 script
 var st = a/;
 /script

 can not be parsed. :-/

 --
 pluskid
 http://blog.pluskid.org
 ___
 Python-Dev mailing list
 Python-Dev@python.org
 http://mail.python.org/mailman/listinfo/python-dev
 Unsubscribe:
 http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk




 --
 http://www.ironpythoninaction.com/




-- 
pluskid
http://blog.pluskid.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Is this a bug of the HTMLParser?

[Michael Foord]

Hello Zhang Chiyuan,

Can you file a bug on the Python issue tracker please:

   http://bugs.python.org

Thanks

Michael Foord

Zhang Chiyuan wrote:

Hi all,

I'm using BeautifulSoup to parsing an HTML page and find it refused to
parse the page. By looking at the backtrace, I found it is a problem
with the python built-in HTMLParser.py. In fact, the web page I'm
parsing is with some Chinese characters. there is a tag like img
src=/foo/bar.png alt=中文 , note this is legacy html page where the
attributes are not quoted. However, the regexp defined in
HTMLParser.py is :

 attrfind = re.compile(
 r'\s*([a-zA-Z_][-.:a-zA-Z_0-9]*)(\s*=\s*'
 r'(\'[^\']*\'|[^]*|[-a-zA-Z0-9./,:;+*%?!$\(\)_...@]*))?')

Note that the Chinese character (also any other non-english
characters), so it fire an error parsing this. I'm not sure whether
the HTML standard allow un-quoted non-ASCII characters in the
attributes. If it allows, this seems to be a bug. and the regexp to
better be [^\s] IMHO.

BTW: It seems something like :

script
var st = a/;
/script

can not be parsed. :-/

--
pluskid
http://blog.pluskid.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
  



--
http://www.ironpythoninaction.com/

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Old libc's isspace() bug on FreeBSD brings back on Mac OS X?

[Ronald Oussoren]

On 3 Oct, 2009, at 1:40, INADA Naoki wrote:


Confirmed on 10.6 for 2.6.3 and 2.7a0. For 3.2a0 both asserts fail.


OK.
`s = '\xa0'` should be `s = b'\xa0'`.

Should I file a bug?


Please do, that helps us remember that the issue exists.

Ronald



--
Naoki INADA  songofaca...@gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com




smime.p7s
Description: S/MIME cryptographic signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Old libc's isspace() bug on FreeBSD brings back on Mac OS X?

[INADA Naoki]

I filed as issue7072.

On Tue, Oct 6, 2009 at 10:49 PM, Ronald Oussoren ronaldousso...@mac.com wrote:

 On 3 Oct, 2009, at 1:40, INADA Naoki wrote:

 Confirmed on 10.6 for 2.6.3 and 2.7a0. For 3.2a0 both asserts fail.

 OK.
 `s = '\xa0'` should be `s = b'\xa0'`.

 Should I file a bug?

 Please do, that helps us remember that the issue exists.

 Ronald


 --
 Naoki INADA  songofaca...@gmail.com
 ___
 Python-Dev mailing list
 Python-Dev@python.org
 http://mail.python.org/mailman/listinfo/python-dev
 Unsubscribe:
 http://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com





-- 
Naoki INADA  songofaca...@gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Old libc's isspace() bug on FreeBSD brings back on Mac OS X?

[Ronald Oussoren]

 
On Friday, 02 October, 2009, at 04:07AM, INADA Naoki songofaca...@gmail.com 
wrote:
I found this hg's issue.
http://mercurial.selenic.com/bts/msg8375

I think below fix is not enabled on Mac OS X.
http://svn.python.org/view/python/trunk/Include/pyport.h?view=diffpathrev=43219r1=36792r2=36793

I can't confirm it because I am not Mac OS X user.
Can anyone confirm it?

Do you have a testcase that shows what the problem is?

Ronald

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Old libc's isspace() bug on FreeBSD brings back on Mac OS X?

[INADA Naoki]

 Do you have a testcase that shows what the problem is?

 Ronald

 s = '\xa0'
 assert s.strip() == s
 import locale
 locale.setlocale(locale.LC_ALL, 'en_US.UTF-8')
'en_US.UTF-8'
 assert s.strip() == s

Second assert failed on Snow Leopard.

-- 
Naoki INADA  songofaca...@gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Old libc's isspace() bug on FreeBSD brings back on Mac OS X?

[Jan Hosang]

Confirmed on 10.6 for 2.6.3 and 2.7a0. For 3.2a0 both asserts fail.

On 02.10.2009, at 10:29, INADA Naoki wrote:


Do you have a testcase that shows what the problem is?

Ronald



s = '\xa0'
assert s.strip() == s
import locale
locale.setlocale(locale.LC_ALL, 'en_US.UTF-8')

'en_US.UTF-8'

assert s.strip() == s


Second assert failed on Snow Leopard.

--
Naoki INADA  songofaca...@gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/jan.hosang%40gmail.com


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Old libc's isspace() bug on FreeBSD brings back on Mac OS X?

[INADA Naoki]

 Confirmed on 10.6 for 2.6.3 and 2.7a0. For 3.2a0 both asserts fail.

OK.
`s = '\xa0'` should be `s = b'\xa0'`.

Should I file a bug?

-- 
Naoki INADA  songofaca...@gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Roundup keywords for bug tracking

[anatoly techtonik]

On Sat, Jun 6, 2009 at 4:07 AM, Daniel Diniz aja...@gmail.com wrote:
 anatoly techtonik wrote:

 It is impossible to edit roundup keywords and this takes away the
 flexibility in selecting bugs related to a module/function/test or
 some other aspect of development. For example, I need to gather all
 subprocess bugs in one query and things that won't be fixed in
 deprecated os.popen() into another. In Trac I would use subprocess
 and os.popen keywords. On ohloh I would add similar tags (if bugs
 were software) without, but I can't do anything about Python roundup.
 Is there any reason for such restriction?

 Well, keywords are used as a very restricted set of tags, so only
 users in the Developer group can create them. We've discussed free
 form issue tags that any user can create or edit in #python-dev and
 tracker-discuss[0]. I'm pretty sure they'd cover your use-case. I've
 submitted a patch to Rietveld[1], but it seems I never filled it in
 the meta-tracker, oopsie.

From [0] discussion it seems that tags are planned to be a replacement
for component or keywords field, but in my vision they should be just
tags that doesn't have any specific meaning or administration
interface. Autocomplete with ajax lookup is nice, but no drop-down
lists etc.

I made some comments in Rietveld at [1], but was unable to test it
live, because [2] is offline.

 If you (or anyone else) want to test-drive the tags feature, I can
 create an account in the experimental tracker[2] (which needs some
 attention anyway). I should be able to submit the patch to the
 meta-tracker during the weekend.

Hope this went well. I would definitely like to see how far this
feature from how I imagine it, but b.p.o. deployment could be a better
alternative for a real testing.

 Also, if you would like to bookmark arbitrary sets of issues, the
 bookmarklet and form in http://static.bot.bio.br/tool.html may be of
 help. You can paste the ids into the search page's ID field and create
 a query for a given (static) set of issues.

Seems like it can come in handy. Thanks.

-- 
anatoly t.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Roundup keywords for bug tracking

[Georg Brandl]

Daniel Diniz schrieb:
 anatoly techtonik wrote:

 It is impossible to edit roundup keywords and this takes away the
 flexibility in selecting bugs related to a module/function/test or
 some other aspect of development. For example, I need to gather all
 subprocess bugs in one query and things that won't be fixed in
 deprecated os.popen() into another. In Trac I would use subprocess
 and os.popen keywords. On ohloh I would add similar tags (if bugs
 were software) without, but I can't do anything about Python roundup.
 Is there any reason for such restriction?
 
 Well, keywords are used as a very restricted set of tags, so only
 users in the Developer group can create them. We've discussed free
 form issue tags that any user can create or edit in #python-dev and
 tracker-discuss[0]. I'm pretty sure they'd cover your use-case. I've
 submitted a patch to Rietveld[1], but it seems I never filled it in
 the meta-tracker, oopsie.
 
 If you (or anyone else) want to test-drive the tags feature, I can
 create an account in the experimental tracker[2] (which needs some
 attention anyway). I should be able to submit the patch to the
 meta-tracker during the weekend.

I'm not sure it will get well tested on the experimental tracker.  If it
basically works, and no one has any real objections, I'd just add it to
the live tracker and try out how and if it is used.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Roundup keywords for bug tracking

[Terry Reedy]

anatoly techtonik wrote:

It is impossible to edit roundup keywords and this takes away the
flexibility in selecting bugs related to a module/function/test or
some other aspect of development. For example, I need to gather all
subprocess bugs in one query 


At the moment, search for 'subprocess' in text and component = library 
returns 53 open issues.  A quick scan of the titles suggests that about 
40 are for the subprocess module.  So changing the search to 
'subprocess' in title might be better.



and things that won't be fixed in

deprecated os.popen() into another. In Trac I would use subprocess
and os.popen keywords. On ohloh I would add similar tags (if bugs
were software) without, but I can't do anything about Python roundup.
Is there any reason for such restriction?


If every module and built-in and keyword were added to the drop-down 
list, it would be pretty long.  But I agree that better sorting could 
help. G. Polo, for one, made his own app to download canned search 
results (for tk and idle) and store them in a local db, where he could 
add annotations.


tjr

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Roundup keywords for bug tracking

[Daniel Diniz]

anatoly techtonik wrote:

 It is impossible to edit roundup keywords and this takes away the
 flexibility in selecting bugs related to a module/function/test or
 some other aspect of development. For example, I need to gather all
 subprocess bugs in one query and things that won't be fixed in
 deprecated os.popen() into another. In Trac I would use subprocess
 and os.popen keywords. On ohloh I would add similar tags (if bugs
 were software) without, but I can't do anything about Python roundup.
 Is there any reason for such restriction?

Well, keywords are used as a very restricted set of tags, so only
users in the Developer group can create them. We've discussed free
form issue tags that any user can create or edit in #python-dev and
tracker-discuss[0]. I'm pretty sure they'd cover your use-case. I've
submitted a patch to Rietveld[1], but it seems I never filled it in
the meta-tracker, oopsie.

If you (or anyone else) want to test-drive the tags feature, I can
create an account in the experimental tracker[2] (which needs some
attention anyway). I should be able to submit the patch to the
meta-tracker during the weekend.

Also, if you would like to bookmark arbitrary sets of issues, the
bookmarklet and form in http://static.bot.bio.br/tool.html may be of
help. You can paste the ids into the search page's ID field and create
a query for a given (static) set of issues.

Regards,
Daniel

[0] http://mail.python.org/pipermail/tracker-discuss/2009-April/002099.html
[1] http://codereview.appspot.com/40100/show
[2] http://bot.bio.br/python-dev-exp/issue5
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] possible string formatting bug

[Aahz]

On Mon, Oct 08, 2007, Eli Courtwright wrote:

 I've found what might be a bug in Python's % string formatting operator.
 Consider the following code:
 
 %%(%s)=%%s % hello
 
 On Python 2.5.1 (r251:54863, May 18 2007, 16:56:43) [GCC 3.4.4 (cygming
 special, gdc 0.12, using dmd 0.125)] on cygwin this produces the string
 %(hello)s=%s which is what I'd expect.
 
 On Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
 (Intel)] on win32 this produces the following exception:
 Traceback (most recent call last):
   File stdin, line 1, in module
 TypeError: not enough arguments for format string
 
 Note that this is the exact same revision running on the same machine, but
 it doesn't work for the win32 version and does work for the cygwin version.

Please submit a bug report to http://bugs.python.org/ -- that way it
won't get lost.
-- 
Aahz ([EMAIL PROTECTED])   * http://www.pythoncraft.com/

The best way to get information on Usenet is not to ask a question, but
to post the wrong information.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] possible string formatting bug

[Georg Brandl]

Eli Courtwright schrieb:
 Greetings,
 
 I've found what might be a bug in Python's % string formatting
 operator.  Consider the following code:
 
 %%(%s)=%%s % hello
 
 On Python 2.5.1 (r251:54863, May 18 2007, 16:56:43) [GCC 3.4.4 (cygming
 special, gdc 0.12, using dmd 0.125)] on cygwin this produces the string
 %(hello)s=%s which is what I'd expect.

There must be some confusion, because the above gives %(hello)=%s...
are you sure you tried the same format strings on both versions?

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] possible string formatting bug

[Facundo Batista]

2007/10/8, Eli Courtwright [EMAIL PROTECTED]:

 On Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
 (Intel)] on win32 this produces the following exception:
 Traceback (most recent call last):
   File stdin, line 1, in module
 TypeError: not enough arguments for format string

Please check it again, because in my machine...

Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
(Intel)] on win32
 %%(%s)=%%s % hello
'%(hello)=%s'


If you still think that something is wrong somewhere, feel free to
post a bug in the tracker:

  http://bugs.python.org/

Regards,

-- 
.Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] possible string formatting bug

[Steve Holden]

Facundo Batista wrote:
 2007/10/8, Eli Courtwright [EMAIL PROTECTED]:
 
 On Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
 (Intel)] on win32 this produces the following exception:
 Traceback (most recent call last):
   File stdin, line 1, in module
 TypeError: not enough arguments for format string
 
 Please check it again, because in my machine...
 
 Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
 (Intel)] on win32
 %%(%s)=%%s % hello
 '%(hello)=%s'
 
 If you still think that something is wrong somewhere, feel free to
 post a bug in the tracker:
 
   http://bugs.python.org/
 
It even works on my Cygwin build:

$ python
Python 2.5.1 (r251:54863, May 18 2007, 16:56:43)
[GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)] on cygwin
Type help, copyright, credits or license for more information.
  %%(%s)=%%s % hello
'%(hello)=%s'
 

I suspect the problem may lie somewhere else.

regards
  Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC/Ltd   http://www.holdenweb.com
Skype: holdenweb  http://del.icio.us/steve.holden

Sorry, the dog ate my .sigline so I couldn't cat it

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] possible string formatting bug

[Eli Courtwright]

Thanks for the quick responses.  Embarrassingly, this problem turned out to
be a typo on my part.  I visually double-and-triple-checked my code before
posting to this list, but I still didn't notice the typo.  Sorry to send
everyone on a wild goose chase.

- Eli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding NetworkIOError for bug 1706815

[Gregory P. Smith]

On Thu, Jul 05, 2007 at 12:05:01PM +0200, Guido van Rossum wrote:
 On 7/5/07, Gregory P. Smith [EMAIL PROTECTED] wrote:
 On Wed, Jul 04, 2007 at 11:03:42AM +0200, Guido van Rossum wrote:
  Why not simply inherit socket.error from EnvironmentError?
 
 True, that would be simpler; is it enough?  If we avoid adding the new
 exception, I really think it should inherit from IOError, not
 EnviromnentError because sockets are I/O.  urllib2.URLError was
 already a child of IOError; doing the same to to socket.error makes
 sense.
 
 OTOH, when os.read() returns an error, os.error (OSError) is raised.
 Is that not I/O?
 
 IMO this is all hairsplitting, and the exact inheritance hierarchy for
 these doesn't matter much -- nobody is going to write a handler that
 treats OSError or socket.error different than IOError.

Ah.  Given all that, the point of a NetworkIOError is moot.  I had
assumed read would raise an IOError but hadn't read the code.  Looks
like fileobject.c's file_read() raises IOError as I expected but
posixmodule.c's read() raises OSError (fair enough, its the os module).

Since socket objects are treated like file objects in many cases I
think IOError would be a more appropriate parent than
EnvironmentError.  There was a case at work recently that started me
down the path of looking at this where code caught IOError but not
socket.error.

Any objects to me just having socket.error inherit from IOError?

 PS for the person complaining that the url didn't work.  blame
sourceforge and go look the bug up by id yourself.  nothing i can
do about that.
 
 Try python.org/sf/1706815
 
 --Guido

ooo handy.  thanks.

-Greg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding NetworkIOError for bug 1706815

[Guido van Rossum]

On 7/5/07, Gregory P. Smith [EMAIL PROTECTED] wrote:
 On Wed, Jul 04, 2007 at 11:03:42AM +0200, Guido van Rossum wrote:
  Why not simply inherit socket.error from EnvironmentError?

 True, that would be simpler; is it enough?  If we avoid adding the new
 exception, I really think it should inherit from IOError, not
 EnviromnentError because sockets are I/O.  urllib2.URLError was
 already a child of IOError; doing the same to to socket.error makes
 sense.

OTOH, when os.read() returns an error, os.error (OSError) is raised.
Is that not I/O?

IMO this is all hairsplitting, and the exact inheritance hierarchy for
these doesn't matter much -- nobody is going to write a handler that
treats OSError or socket.error different than IOError.

(If you have different call sites that raise different exceptions,
each call site should have a separate try/except rather than a single
try/except with multiple handlers.)

 The patch makes URLError a child of NetworkIOError instead of IOError.
 Does that make sense?  URLs as an abstract concept may or may not
 imply network I/O behind the scenes though network i/o is the most
 common use.  I could take that argument further and suggest they don't
 necessarily even imply actual I/O if you've provided your own protocol
 handlers.

Well, as long as NetworkIOError inherits from IOError, the change is
compatible, but I don't think anyone would care. Making URLError a
child of EnvironmentError or socket.error could be defended too, and I
doubt it makes a difference for any real code. (Anyone with evidence
to the contrary, please speak up now).

 The question then becomes if there are any use cases for except
 NetworkIOError: that code wouldn't want to just use except IOError:
 for that using except socket.error: or except urllib2.URLError:
 are insufficient for.  My intuition is telling me: probably not.
 urllib2 code should catch socket.error everywhere internally and turn
 it into a URLError (the code appears to do this in many places though
 i haven't audited that it does everywhere).

Hm. I'm no fan of such renaming of exceptions (even though the
__cause__ mechanism from PEP 3134 (formerly 344) makes it a little
less problematic).

 -greg

 PS for the person complaining that the url didn't work.  blame
sourceforge and go look the bug up by id yourself.  nothing i can
do about that.

Try python.org/sf/1706815

--Guido

  On 7/4/07, Gregory P. Smith [EMAIL PROTECTED] wrote:
  In response to bug 1706815 and seeing messy code to catch errors in
  network apps I've implemented most of the ideas in the bug and added a
  NetworkIOError exception (child of IOError).  With this, socket.error
  would now inherit from NetworkIOError instead of being its own thing
  (the old one didn't even declare a parent!).
  
  Complete patch attached to the bug.  All unit tests pass.
  Documentation updates included.
  
   http://sourceforge.net/tracker/index.php?func=detailaid=1706816group_id=5470atid=105470
  
  Any thoughts?  I'm happy with it and would like to commit it if folks
  agree.



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding NetworkIOError for bug 1706815

[Guido van Rossum]

Why not simply inherit socket.error from EnvironmentError?

On 7/4/07, Gregory P. Smith [EMAIL PROTECTED] wrote:
 In response to bug 1706815 and seeing messy code to catch errors in
 network apps I've implemented most of the ideas in the bug and added a
 NetworkIOError exception (child of IOError).  With this, socket.error
 would now inherit from NetworkIOError instead of being its own thing
 (the old one didn't even declare a parent!).

 Complete patch attached to the bug.  All unit tests pass.
 Documentation updates included.

  
 http://sourceforge.net/tracker/index.php?func=detailaid=1706816group_id=5470atid=105470

 Any thoughts?  I'm happy with it and would like to commit it if folks
 agree.

 ___
 Python-Dev mailing list
 Python-Dev@python.org
 http://mail.python.org/mailman/listinfo/python-dev
 Unsubscribe: 
 http://mail.python.org/mailman/options/python-dev/guido%40python.org



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding NetworkIOError for bug 1706815

[Jean-Paul Calderone]

On Tue, 3 Jul 2007 23:58:44 -0700, Gregory P. Smith [EMAIL PROTECTED] wrote:
In response to bug 1706815 and seeing messy code to catch errors in
network apps I've implemented most of the ideas in the bug and added a
NetworkIOError exception (child of IOError).  With this, socket.error
would now inherit from NetworkIOError instead of being its own thing
(the old one didn't even declare a parent!).

Complete patch attached to the bug.  All unit tests pass.
Documentation updates included.

 http://sourceforge.net/tracker/index.php?func=detailaid=1706816group_id=5470atid=105470


FWIW, that page does not seem to be generally accessible.  It's difficult
to know what you're talking about without being able to see it.

Artifact: Invalid ArtifactID; this Tracker item may have moved to a
different Tracker since this URL was generated -- [Find the new location
of this Tracker item]

Following [Find the new location ...]:

Artifact: This Artifact Has Been Made Private. Only Group Members Can
View Private ArtifactTypes.

Any thoughts?  I'm happy with it and would like to commit it if folks
agree.


Jean-Paul
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] os.utime on directories: bug fix or new feature?

[Anthony Baxter]

On Sunday 15 October 2006 23:35, Aahz wrote:
 On Sun, Oct 15, 2006, Martin v. L?wis wrote:
  Should I backport the patch to 2.5, as it is a bug that you can modify
  the time stamps of regular files but not directories? Or should I
  not backport as it is a new feature that you can now adjust the time
  stamps of a directory, and couldn't before?

 My vote is that it's a bugfix but should be treated as a new feature and
 rejected for 2.5, based on the standard argument about capabilities and
 the problems with bugfix releases having new capabilities.

Since it wasn't possible in earlier than 2.5 either, I'd say it's on the 
edge of being a bugfix. Let's be conservative and not backport it, since it's 
also a pretty marginal feature.

Anthony
-- 
Anthony Baxter [EMAIL PROTECTED]
It's never too late to have a happy childhood.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [4suite] cDomlette deallocation bug?

[Jeremy Kloth]

I'm CC python-dev as this may be a bug in the gc module. Although this may be 
more of a c.l.p. post, I think that this usage shouldn't cause segfaults 
regardless.

On Tuesday 22 August 2006 3:06 pm, Robert Fleming wrote:
 [step 1 unnecessary]
 2. test program (test.c):
 / snip /
 #include Python.h

 #include stdio.h

 int main(int argc, char* argv[])
 {
   int i;
   for (i = 0; i10; i++)
 {
   printf(%d\n, i);

   Py_Initialize();
   (void)PyRun_SimpleString(import sys\n
sys.path.append('.')\n
import cDomlettec);

Change the string to just import gc and the segfault still happens.

   Py_Finalize();
 }

   return EXIT_SUCCESS;
 }
 /** snip /

 3. compile with:
 gcc -I/usr/include/python2.4 test.c -lpython2.4

 4. run program; output is:
 0
 1
 Segmentation fault

 Am I doing something wrong?  I'm pretty new to embedding Python, but I'm
 hoping to be able to cleanly load and unload 4Suite this way

It just so happens that cDomlettec imports gc internally which, by the change 
above shows, causes the segfault.  Hopefully someone with more knowledge of 
GC internals can comment on this.

-- 
Jeremy Kloth
http://4suite.org/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Is this a bug?

[Georg Brandl]

Georg Brandl wrote:
 Is this considered a bug? Sure, deleting modules from sys.modules
 isn't quite common, but it happened to me on one occasion.
 
 Python 2.4.3 (#1, Jul 29 2006, 10:52:20)
   import logging
   import sys
   del logging
   del sys.modules['logging']
   ^D
 Error in atexit._run_exitfuncs:
 Traceback (most recent call last):
File /usr/lib/python2.4/atexit.py, line 24, in _run_exitfuncs
  func(*targs, **kargs)
File /usr/lib/python2.4/logging/__init__.py, line 1328, in shutdown
  for h in _handlerList[:]: # was _handlers.keys():
 TypeError: unsubscriptable object
 Error in sys.exitfunc:
 Traceback (most recent call last):
File /usr/lib/python2.4/atexit.py, line 24, in _run_exitfuncs
  func(*targs, **kargs)
File /usr/lib/python2.4/logging/__init__.py, line 1328, in shutdown
  for h in _handlerList[:]: # was _handlers.keys():
 TypeError: unsubscriptable object

I've now fixed the logging issue, but what bothers me additionally is the
duplication of tracebacks here. The problem is in atexit._run_exitfuncs:

 exc_info = None
 while _exithandlers:
 func, targs, kargs = _exithandlers.pop()
 try:
 func(*targs, **kargs)
 except SystemExit:
 exc_info = sys.exc_info()
 except:
 import traceback
 print  sys.stderr, Error in atexit._run_exitfuncs:
 traceback.print_exc()
 exc_info = sys.exc_info()

 if exc_info is not None:
 raise exc_info[0], exc_info[1], exc_info[2]


So the last exception is always reraised and therefore also printed
by call_sys_exitfunc. Is this really wanted behavior?

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Is this a bug?

[Josiah Carlson]

Neal Norwitz [EMAIL PROTECTED] wrote:
 
 On 8/9/06, Josiah Carlson [EMAIL PROTECTED] wrote:
  2.4 performed these imports silently, while 2.5 complains SystemError:
  Parent module 'x' not loaded, which is actually a useful message, and
  helped me fix it.
 
 Can you make a small, self-contained test case?  The SystemError
 should be a normal exception and might indicate a deeper problem.


Create a module z.py whose contents are:

#z.py
import sys
import imp

sys.stdout = None
try:
y = imp.load_source('x.y', 'x/y.py', open('x/y.py'))
except:
raise
else:
print printing should raise an AttributeError, but doesn't

#end of listing for z.py

Create a module x/y.py whose contents are: (x/__init__.py not required)

#x/y.py
import sys

#end of listing for x/y.py


Running z.py in Python 2.3 and 2.4 produces:
printing should raise an AttributeError, but doesn't

Running z.py in Python 2.5b2 produces:
Traceback (most recent call last):
  File test.py, line 7, in module
y = imp.load_source('x.y', 'x/y.py', open('x/y.py'))
  File x/y.py, line 1, in module
import sys
SystemError: Parent module 'x' not loaded


 - Josiah

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Is this a bug?

[Nick Coghlan]

Josiah Carlson wrote:
 This is the case for Python 2.3, 2.4, and 2.5 beta.  prefixing the above
 two operations with:
 sys.modules['_oldmain'] = sys.modules['__main__']
 
 Is sufficient to prevent Python from tearing down everything after the
 sys.modules['__main__'] reassignment.  Not a big deal, but a sys.modules
 manipulation that has a gotcha.

Early versions of the PEP 338 implementation also ran into the problem of a 
module's globals getting cleared when the module itself goes away - that's why 
runpy makes sure to return a copy of the module's global namespace instead of 
the original.

The core of the problem in the atexit case seems to be the fact that holding 
on to a reference to a function from a module only holds a reference to the 
module's dict, rather than the module object itself.

If you kill the reference to the module from sys.modules, the module object 
goes away, and the dict gets cleared. However, any function objects being held 
elsewhere (e.g. in the atexit list, or as a result of a class being subclassed 
in a different module) still have a reference to the now defunct module 
namespace, and will misbehave when called later on if they attempt to access 
any global variables.

Are we really sure that explicitly clearing the module's globals when the 
module's refcount falls to zero solves more problems than it causes? Or is it 
primarily a legacy of the pre-cyclic GC days when it was absolutely essential 
to manually break the cycle between the module namespace and any functions it 
contained?

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Is this a bug?

[Matt Fleming]

On 09/08/06, Georg Brandl [EMAIL PROTECTED] wrote:
 Is this considered a bug? Sure, deleting modules from sys.modules
 isn't quite common, but it happened to me on one occasion.

 Python 2.4.3 (#1, Jul 29 2006, 10:52:20)
   import logging
   import sys
   del logging
   del sys.modules['logging']
   ^D
 Error in atexit._run_exitfuncs:
 Traceback (most recent call last):
File /usr/lib/python2.4/atexit.py, line 24, in _run_exitfuncs
  func(*targs, **kargs)
File /usr/lib/python2.4/logging/__init__.py, line 1328, in shutdown
  for h in _handlerList[:]: # was _handlers.keys():
 TypeError: unsubscriptable object
 Error in sys.exitfunc:
 Traceback (most recent call last):
File /usr/lib/python2.4/atexit.py, line 24, in _run_exitfuncs
  func(*targs, **kargs)
File /usr/lib/python2.4/logging/__init__.py, line 1328, in shutdown
  for h in _handlerList[:]: # was _handlers.keys():
 TypeError: unsubscriptable object

 Obviously, _handlerList (as a global) is already cleaned up, which is why
 the subscript fails.

 Georg

 ___


Could it be considered a bug in the atexit module (or is that what you
meant)? Seeing as there's no _decent_ way to recover from this error,
perhaps it could just slip silently passed?

-- 
Matt

http://mattssanctuary.blogspot.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Is this a bug?

[Josiah Carlson]

Georg Brandl [EMAIL PROTECTED] wrote:
 
 Is this considered a bug? Sure, deleting modules from sys.modules
 isn't quite common, but it happened to me on one occasion.
 
 Python 2.4.3 (#1, Jul 29 2006, 10:52:20)
   import logging
   import sys
   del logging
   del sys.modules['logging']
   ^D
 Error in atexit._run_exitfuncs:
 Traceback (most recent call last):
File /usr/lib/python2.4/atexit.py, line 24, in _run_exitfuncs
  func(*targs, **kargs)
File /usr/lib/python2.4/logging/__init__.py, line 1328, in shutdown
  for h in _handlerList[:]: # was _handlers.keys():
 TypeError: unsubscriptable object
 Error in sys.exitfunc:
 Traceback (most recent call last):
File /usr/lib/python2.4/atexit.py, line 24, in _run_exitfuncs
  func(*targs, **kargs)
File /usr/lib/python2.4/logging/__init__.py, line 1328, in shutdown
  for h in _handlerList[:]: # was _handlers.keys():
 TypeError: unsubscriptable object
 
 Obviously, _handlerList (as a global) is already cleaned up, which is why
 the subscript fails.

Interestingly enough, I recently ran into a series of errors relating to
manipulating sys.modules and using imp.load_module...

The imp.load_module and the 3 other simple variants involved importing a
module 'x.y' without the package 'x' having been imported first.  This
resulted in all C-modules being re-initialized (builtins, 3rd party, etc.),
causing things like sys.stdout wrappers to be removed, and in the case
of wx, segfaults galore (especially during shutdown).  Python 2.3 and
2.4 performed these imports silently, while 2.5 complains SystemError:
Parent module 'x' not loaded, which is actually a useful message, and
helped me fix it.


I have a use-case for replacing sys.modules['__main__'] with a different
module, and initial attempts to do:
sys.modules['__main__'] = other_module
other_module.main()

Resulted in:
AttributeError: 'NoneType' object has no attribute 'main'

This is the case for Python 2.3, 2.4, and 2.5 beta.  prefixing the above
two operations with:
sys.modules['_oldmain'] = sys.modules['__main__']

Is sufficient to prevent Python from tearing down everything after the
sys.modules['__main__'] reassignment.  Not a big deal, but a sys.modules
manipulation that has a gotcha.

 - Josiah

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Is this a bug?

[skip]

Matt Could it be considered a bug in the atexit module (or is that what
Matt you meant)?

Or a bug in the logging package?

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Is this a bug?

[Neal Norwitz]

On 8/9/06, Josiah Carlson [EMAIL PROTECTED] wrote:
 2.4 performed these imports silently, while 2.5 complains SystemError:
 Parent module 'x' not loaded, which is actually a useful message, and
 helped me fix it.

Can you make a small, self-contained test case?  The SystemError
should be a normal exception and might indicate a deeper problem.

Thanks,
n
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cgi.FieldStorage DOS (sf bug #1112549)

[Tim Peters]

[Chris McDonough, on 7/28/06]
  From the initial bugreport
 (http://sourceforge.net/tracker/index.php?
 func=detailaid=1112549group_id=5470atid=105470)

 
 Various parts of cgi.FieldStorage call its
 read_lines_to_outerboundary, read_lines and
 skip_lines methods. These methods use the
 readline method of the file object that represents an
 input stream. The input stream is typically data
 supplied by an untrusted source (such as a user
 uploading a file from a web browser). The input data
 is not required by the RFC 822/1521/1522/1867
 specifications to contain any newline characters. For
 example, it is within the bounds of the specification
 to supply a a multipart/form-data input stream with a
 file-data part that consists of a 2GB string composed
 entirely of x characters (which happens to be
 something I did that led me to noticing this bug).
 

 This bug has been around for about a year but I just worked up a
 patch yesterday that applies OK against current SVN.  It's attached
 to the issue.  Would someone be so kind as to check it in?  Guido has
 already reviewed it, I believe.

Are either of our 2.5 release managers/coordinators on the internal
Python security mailing list?  I am, but only the list admin can see
who's on that list.

Since this bug is thought to be a security hole (the DOS in the
subject line doesn't refer to your favorite operating system -- it's
the Denial-Of-Service flavor of DOS), it's important that someone with
sufficient power stare at this one and Pronounce on its fate for
2.5c1.  Here's a clicky thing:

http://www.python.org/sf/1112549
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] first draft of bug guidelines for www.python.org/dev/

[Oleg Broytmann]

On Thu, Jul 20, 2006 at 08:52:34PM -0700, Brett Cannon wrote:
 * Summary
 A one-line describing the problem so as to make it easy for
 developers to spot whether they have the expertise needed to work on
 the bug.

   Summary is also displayed as a title on index and search pages, so it is
important to make the summary right - short and descriptive.

Oleg.
-- 
 Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] first draft of bug guidelines for www.python.org/dev/

[Brett Cannon]

On 7/20/06, Fred L. Drake, Jr. [EMAIL PROTECTED] wrote:
On Friday 21 July 2006 00:10, Neil Hodgson wrote:  Brett Cannon:   But SourceForge does not support anonymous reporting.  SourceForge does support anonymous reporting. A large proportion of
  the fault reports I receive for Scintilla are anonymous as indicated  by nobody in the Submitted By column.SourceForge supports anonymous reporting, but the Python project determined
that the management cost of anonymous reports was higher than the value theyprovided.OK. Wording has been changed in my copy. 
It might be time to reconsider that decision (though my position hasn'tchanged).Sure. It can also wait until we begin discussing the transition to our next bug tracker.-Brett 

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] first draft of bug guidelines for www.python.org/dev/

[skip]

Brett Sure.  It can also wait until we begin discussing the transition
Brett to our next bug tracker.

Would be kinda nice if the new bug tracker allowed submitters to enter a
followup email address without formally logging in.  (Of course, email-based
submissions would go a long way to minimizing the problem.)

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] first draft of bug guidelines for www.python.org/dev/

[Kevin Jacobs [EMAIL PROTECTED]]

On 7/21/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Brett Sure.It can also wait until we begin discussing the transitionBrett to our next bug tracker.Would be kinda nice if the new bug tracker allowed submitters to enter afollowup email address without formally logging in.(Of course, email-based
submissions would go a long way to minimizing the problem.)It may just be bad karma, but SourceForge tends to lock or go off into lala land whenever I log in. Thus, I would file many bug reports, with a reply-to address, if non-login bug submissions where allowed. My long term hope is that you toss out SF and get something better.
Thanks,-Kevin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] first draft of bug guidelines for www.python.org/dev/

[Nick Coghlan]

Kevin Jacobs [EMAIL PROTECTED] wrote:
 It may just be bad karma, but SourceForge tends to lock or go off into 
 lala land whenever I log in.  Thus, I would file many bug reports, with 
 a reply-to address, if non-login bug submissions where allowed.   My long
 term hope is that you toss out SF and get something better.

You're not the only one with that hope. With at least Trac, Jira and Roundup 
to choose from, the PSF's current tracker shootout should find us that 
replacement :)

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] first draft of bug guidelines for www.python.org/dev/

[Neil Hodgson]

Brett Cannon:

 But SourceForge does not support anonymous reporting.

   SourceForge does support anonymous reporting. A large proportion of
the fault reports I receive for Scintilla are anonymous as indicated
by nobody in the Submitted By column.
https://sourceforge.net/tracker/?group_id=2439atid=102439

   Neil
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] first draft of bug guidelines for www.python.org/dev/

[Fred L. Drake, Jr.]

On Friday 21 July 2006 00:10, Neil Hodgson wrote:
  Brett Cannon:
   But SourceForge does not support anonymous reporting.
 
 SourceForge does support anonymous reporting. A large proportion of
  the fault reports I receive for Scintilla are anonymous as indicated
  by nobody in the Submitted By column.

SourceForge supports anonymous reporting, but the Python project determined 
that the management cost of anonymous reports was higher than the value they 
provided.

It might be time to reconsider that decision (though my position hasn't 
changed).


  -Fred

-- 
Fred L. Drake, Jr.   fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] urllib.quote and unicode bug resuscitation attempt

[Mike Brown]

Stefan Rank wrote:
 Well, originally, I would have expected it to return a byte str(ing),

I'd assume unicode in, unicode out, and str in, str out, but since it's
always going to produce ASCII-range characters, it wouldn't matter.
Moot point anyway.

 BUT
 I am now converted and think it is best to raise a TypeError for 
 unicode, and leave the encoding decisions to higher level code.
 
 So I'll repeat the patch #1, slightly modified::
 
   if isinstance(s, unicode):
   raise TypeError(quote expects an encoded byte string as argument)
 
 Is it safe to assume that code that breaks because of this change was 
 already broken?

Yes. The patch seems fine to me, although maybe

if not isinstance(s, str)

would be better?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] urllib.quote and unicode bug resuscitation attempt

[Mike Brown]

Stefan Rank wrote:
 on 12.07.2006 07:53 Martin v. Löwis said the following:
  Anthony Baxter wrote:
  The right thing to do is IRIs. 
  For 2.5, should we at least detect that it's unicode and raise a 
  useful error?
  
  That can certainly be done, sure.
  
  Martin
 
 That would be great.
 
 And I agree that updating urllib.quote for unicode should be part of a 
 grand plan that updates all of urllib[2] and introduces an irilib / 
 urischemes / uriparse module in 2.6 as Martin and John J Lee suggested.
   =)
 
 cheers,
 stefan

Put me down as +1 on raising a useful error instead of a KeyError or whatever,
and +1 on having an irilib, but -1 on working toward accepting unicode in the
URI-oriented urllib.quote(), because (a.) user expectations for strings that
contain non-ASCII-range characters will vary, and (b.) percent-encoding is
supposed to only operate on a byte-encoded view of non-URI information, not
the information itself.

Longer explanation:

I, too, initially thought that quote() was outdated since it choked on unicode
input, but eventually I came to realize that it's wise to reject such input,
because to attempt to percent-encode characters, rather than bytes, reflects a
fundamental misunderstanding of the level at which percent-encoding is
intended to operate.

This is one of the hardest aspects of URI processing to grok, and I'm not
very good at explaining it, even though I've tried my best in the Wikipedia
articles. It's basically these 3 points:

1. A URI can only consist of 'unreserved' characters, as I'm sure you know. 
It's a specific set that has varied slightly over the years, and is a subset 
of printable ASCII.

2. A URI scheme is essentially a mapping of non-URI information to a sequence
of URI characters. That is, it is a method of producing a URI from non-URI
information within a particular information domain ...and vice-versa.

3. A URI scheme should (though may not do so very clearly, especially the
older it is!) tell you that the way to represent a particular bit of non-URI
information, 'info', in a URI is to convert_to_bytes(info), and then, as per
STD 66, make the bytes that correspond, in ASCII, to unreserved characters
manifest as those characters, and all others manifest as their percent-encoded
equivalents. In urllib parlance, this step is 'quoting' the bytes.

3.1. [This isn't crucial to my argument, but has to be mentioned to complete
the explanation of percent-encoding.] In addition, those bytes corresponding,
in ASCII, to some 'reserved' characters are exempt from needing to be
percent-encoded, so long as they're not being used for their reserved purpose
(if any) in whatever URI component they're going into -- Semantically, there's
no difference between such bytes when expressed in the URI as a literal
reserved character or as a percent-encoded byte. URI scheme specs vary greatly
in how they deal with this nuance. In any case, urllib.quote() has the 'safe' 
argument which can be used to specify the exempt reserved characters.



In the days when the specs that urllib was based on were relevant, 99% of the
time, the bytes being 'quoted' were ASCII-encoded strings representing ASCII
character-based non-URI information, so quite a few of us, including many URI
scheme authors, were tempted to think that what was being
'quoted'/percent-encoded *was* the original non-URI information, rather than a
bytewise view of it mandated by a URI scheme.  That's what I was doing when I
thought that quote(some_unicode_path) should 'work', especially in light of
Python's treat all strings alike guideline.  But if you accept all of the
above, which is what I believe the standard requires, then unicode input is a
very different situation from str input; it's unclear whether and how the
caller wants the input to be converted to bytes, if they even understand what
they're doing at all.

See, right now, quote('abc 123%') returns 'abc%20123%25', as you would expect. 
Similarly, everyone would probably expect u'abc 123%' to return
u'abc%20123%25', and if we were to implement that, there'd probably be no harm 
done.

But look at quote('\xb7'), which, assuming you accept everything I've said
above is correct, rightfully returns '%B7'.  What would someone expect
quote(u'\xb7') to return?  Some might want u'%B7' because they want the same
result type as the input they gave, with no other changes from how it would
normally be handled. Some might want u'%C2%B7' because they're conflating the
levels of abstraction and expect, say, UTF-8 conversion to be done on their
input.  Some (like me) might want a TypeError or ValueError because we
shouldn't be handing such ambiguous data to quote() in the first place. And 
then there's the u'\u0100'-and-up input to worry about; what does a user
expect to be done with that?

I would prefer to see quote() always reject unicode input with a TypeError. 
Alternatively, if it accepts unicode, it should produce unicode, and since it
can only reasonably assume what 

Re: [Python-Dev] urllib.quote and unicode bug resuscitation attempt

[Stefan Rank]

on 13.07.2006 10:26 Mike Brown said the following:
 Stefan Rank wrote:
 on 12.07.2006 07:53 Martin v. Löwis said the following:
 Anthony Baxter wrote:
 The right thing to do is IRIs. 
 For 2.5, should we at least detect that it's unicode and raise a 
 useful error?
 That can certainly be done, sure.

snip

 Put me down as +1 on raising a useful error instead of a KeyError or whatever,
 and +1 on having an irilib, but -1 on working toward accepting unicode in the
 URI-oriented urllib.quote(), because

snip convincing explanation

 See, right now, quote('abc 123%') returns 'abc%20123%25', as you would 
 expect. 
 Similarly, everyone would probably expect u'abc 123%' to return
 u'abc%20123%25', and if we were to implement that, there'd probably be no 
 harm 
 done.

Well, originally, I would have expected it to return a byte str(ing),
BUT
I am now converted and think it is best to raise a TypeError for 
unicode, and leave the encoding decisions to higher level code.

So I'll repeat the patch #1, slightly modified::

  if isinstance(s, unicode):
  raise TypeError(quote expects an encoded byte string as argument)

Is it safe to assume that code that breaks because of this change was 
already broken?

stefan

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] urllib.quote and unicode bug resuscitation attempt

[Stefan Rank]

on 12.07.2006 07:53 Martin v. Löwis said the following:
 Anthony Baxter wrote:
 The right thing to do is IRIs. 
 For 2.5, should we at least detect that it's unicode and raise a 
 useful error?
 
 That can certainly be done, sure.
 
 Martin

That would be great.

And I agree that updating urllib.quote for unicode should be part of a 
grand plan that updates all of urllib[2] and introduces an irilib / 
urischemes / uriparse module in 2.6 as Martin and John J Lee suggested.
  =)

cheers,
stefan

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] urllib.quote and unicode bug resuscitation attempt

[skip]

Stefan According to a message I found on quixote-users,
Stefan http://mail.mems-exchange.org/durusmail/quixote-users/5363/ it
Stefan might have worked prior to 2.4.2.

Confirmed with 2.3.5.

Stefanif isinstance(s, unicode):
Stefans = s.encode('utf-8')

Stefan as suggested in
Stefan http://www.w3.org/International/O-URL-code.html
Stefan and rfc3986.

Seems like the right way to do it to me.

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] urllib.quote and unicode bug resuscitation attempt

[John J Lee]

On Tue, 11 Jul 2006, Stefan Rank wrote:

 urllib.quote fails on unicode strings and in an unhelpful way::
[...]
urllib.quote(u'a\xf1a')
   Traceback (most recent call last):
 File stdin, line 1, in ?
 File C:\Python24\lib\urllib.py, line 1117, in quote
   res = map(safe_map.__getitem__, s)
   KeyError: u'\xf1'

More helpful than silently producing the wrong answer.


[...]
 I suggest to add (after 2.5 I assume) one of the following to the
 beginning of urllib.quote to either fail early and consistently on
 unicode arguments and improve the error message::

   if isinstance(s, unicode):
   raise TypeError(quote needs a byte string argument, not unicode,
use `argument.encode('utf-8')` first.)

Won't this break existing code that catches the KeyError, for no big 
benefit?  If nobody is yet sure what the Right Thing is (see below), I 
think we should not change this yet.


 or to do The Right Thing (tm), which is utf-8 encoding::

   if isinstance(s, unicode):
   s = s.encode('utf-8')

 as suggested in
 http://www.w3.org/International/O-URL-code.html
 and rfc3986.

You seem quite confident of that.  You may be correct, but have you read 
all of the following?  (not trying to claim superior knowledge by asking 
that, I just dunno what the right thing is yet: I haven't yet read RFC 
2617 or got my head around what the unicode issues are or how they should 
apply to the Python stdlib)

http://www.ietf.org/rfc/rfc2617.txt

http://www.ietf.org/rfc/rfc2616.txt

http://en.wikipedia.org/wiki/Percent-encoding

http://mail.python.org/pipermail/python-dev/2004-September/048944.html


Also note the recent discussions here about a module named uriparse or 
urischemes, which fits in to this somewhere.  It would be good to make 
all the following changes in a single Python release (2.6, with luck):

  - extend / modify urllib and urllib2 to handle unicode input

  - address the urllib.quote issue you raise above (+ consider the other
utility functions in that module)

  - add the urischemes module


In summary, I agree that your suggested fix (and all of the rest I refer 
to above) should wait for 2.6, unless somebody (Martin?) who understands 
all these issues is quite confident your suggested change is OK. 
Presumably the release managers wouldn't allow it in 2.5 anyway.


John
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] urllib.quote and unicode bug resuscitation attempt

[Martin v. Löwis]

Stefan Rank wrote:
 I suggest to add (after 2.5 I assume) one of the following to the 
 beginning of urllib.quote to either fail early and consistently on 
 unicode arguments and improve the error message::
 
if isinstance(s, unicode):
raise TypeError(quote needs a byte string argument, not unicode,
 use `argument.encode('utf-8')` first.)
 
 or to do The Right Thing (tm), which is utf-8 encoding::

The right thing to do is IRIs. This is more complicated than encoding
the Unicode string as UTF-8, though: for the host part of the URL, you
have to encode it with IDNA (and there are additional complicated rules
in place, e.g. when the Unicode string already contains %).

Contributions are welcome, as long as they fix this entire issue for
good (i.e. in all URL-processing code, and considering all relevant
RFCs).

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] urllib.quote and unicode bug resuscitation attempt

[Anthony Baxter]

On Wednesday 12 July 2006 07:16, Martin v. Löwis wrote:
 Stefan Rank wrote:
  I suggest to add (after 2.5 I assume) one of the following to the
  beginning of urllib.quote to either fail early and consistently
  on unicode arguments and improve the error message::
 
 if isinstance(s, unicode):
 raise TypeError(quote needs a byte string argument, not
  unicode,  use `argument.encode('utf-8')` first.)
 
  or to do The Right Thing (tm), which is utf-8 encoding::

 The right thing to do is IRIs. This is more complicated than
 encoding the Unicode string as UTF-8, though: for the host part of
 the URL, you have to encode it with IDNA (and there are additional
 complicated rules in place, e.g. when the Unicode string already
 contains %).

 Contributions are welcome, as long as they fix this entire issue
 for good (i.e. in all URL-processing code, and considering all
 relevant RFCs).

For 2.5, should we at least detect that it's unicode and raise a 
useful error?


-- 
Anthony Baxter [EMAIL PROTECTED]
It's never too late to have a happy childhood.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] urllib.quote and unicode bug resuscitation attempt

[Martin v. Löwis]

Anthony Baxter wrote:
 The right thing to do is IRIs. 
 
 For 2.5, should we at least detect that it's unicode and raise a 
 useful error?

That can certainly be done, sure.

Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Beta 1 schedule ? (Bug in stringobject?)

[M.-A. Lemburg]

Neal Norwitz wrote:
 On 6/16/06, M.-A. Lemburg [EMAIL PROTECTED] wrote:
 Fredrik Lundh wrote:
 
  what's the beta 1 status ?  fixing this should be trivial, but I
 don't have any
  cycles to spare today.

 Good question. PEP 356 says beta 1 was planned two days
 ago...

 http://www.python.org/dev/peps/pep-0356/
 
 beta 1 won't be released until the tests pass consistently.  That
 hasn't happened much this week.  I updated the PEP's schedule.
 Hopefully we can release early next week.  This means the code freeze
 is likely to happen as early as Sunday (more likely Monday or
 Tuesday).
 
 http://mail.python.org/pipermail/python-checkins/2006-June/054104.html
 
 I'd also like to get the new winerror module in before
 beta1 is released - documentation will follow next week:

 https://sourceforge.net/tracker/?func=detailatid=305470aid=1505257group_id=5470


 Is it OK to first check in a pure Python version and then
 replace this with a C implementation having the same interface
 later on in the beta cycle ?
 
 My answer is no. 

Is that no to adding the winerror Python module or no to
replacing it with a C module later on in the beta cycle ?

Note that winerror is a new module, so it can't really
break anything.

 We've had too much breakage.  There are so many
 things already in 2.5.  We really don't need one more thing to break.
 There will be a 2.6.  winerror has limited impact.  At this point, I'd
 rather not see any checkins except to fix something that's broken.
 tests, doc, and bugfixes.  I seem to recall a bunch of checkins
 recently that didn't have a test.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 17 2006)
 Python/Zope Consulting and Support ...http://www.egenix.com/
 mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
 mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/

2006-07-03: EuroPython 2006, CERN, Switzerland  15 days left

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Beta 1 schedule ? (Bug in stringobject?)

[Anthony Baxter]

On Saturday 17 June 2006 07:06, M.-A. Lemburg wrote:
 Fredrik Lundh wrote:
  M.-A. Lemburg wrote:
  Since replace() only works on string objects, it appears
  as if a temporary string object would have to be created.
  However, this would involve an unnecessary allocation
  and copy process... it appears as if the refactoring
  during the NFS sprint left out that case.
 
  what's the beta 1 status ?  fixing this should be trivial, but I
  don't have any cycles to spare today.

I just confirmed that Martin and Fred are ready to do this on Tuesday. 
We slipped a couple of days because of pretty bad builbot breakage. 

 I'd also like to get the new winerror module in before
 beta1 is released - documentation will follow next week:

Hm. A new python module should be OK - but I was under the impression 
that then large piles of the standard library would be updated to use 
this new module. I'm less happy (much less) about this happening for 
2.5. 

 Is it OK to first check in a pure Python version and then
 replace this with a C implementation having the same interface
 later on in the beta cycle ?

How big is it likely to be? How much of a pain will it be to make it 
work with various versions of Windows?

Anthony
-- 
Anthony Baxter [EMAIL PROTECTED]
It's never too late to have a happy childhood.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Beta 1 schedule ? (Bug in stringobject?)

[M.-A. Lemburg]

Fredrik Lundh wrote:
 M.-A. Lemburg wrote:
 Since replace() only works on string objects, it appears
 as if a temporary string object would have to be created.
 However, this would involve an unnecessary allocation
 and copy process... it appears as if the refactoring
 during the NFS sprint left out that case.
 
 what's the beta 1 status ?  fixing this should be trivial, but I don't have 
 any
 cycles to spare today.

Good question. PEP 356 says beta 1 was planned two days
ago...

http://www.python.org/dev/peps/pep-0356/

I'd also like to get the new winerror module in before
beta1 is released - documentation will follow next week:

https://sourceforge.net/tracker/?func=detailatid=305470aid=1505257group_id=5470

Is it OK to first check in a pure Python version and then
replace this with a C implementation having the same interface
later on in the beta cycle ?

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 16 2006)
 Python/Zope Consulting and Support ...http://www.egenix.com/
 mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
 mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Beta 1 schedule ? (Bug in stringobject?)

[Neal Norwitz]

On 6/16/06, M.-A. Lemburg [EMAIL PROTECTED] wrote:
 Fredrik Lundh wrote:
 
  what's the beta 1 status ?  fixing this should be trivial, but I don't have 
  any
  cycles to spare today.

 Good question. PEP 356 says beta 1 was planned two days
 ago...

 http://www.python.org/dev/peps/pep-0356/

beta 1 won't be released until the tests pass consistently.  That
hasn't happened much this week.  I updated the PEP's schedule.
Hopefully we can release early next week.  This means the code freeze
is likely to happen as early as Sunday (more likely Monday or
Tuesday).

http://mail.python.org/pipermail/python-checkins/2006-June/054104.html

 I'd also like to get the new winerror module in before
 beta1 is released - documentation will follow next week:

 https://sourceforge.net/tracker/?func=detailatid=305470aid=1505257group_id=5470

 Is it OK to first check in a pure Python version and then
 replace this with a C implementation having the same interface
 later on in the beta cycle ?

My answer is no.  We've had too much breakage.  There are so many
things already in 2.5.  We really don't need one more thing to break.
There will be a 2.6.  winerror has limited impact.  At this point, I'd
rather not see any checkins except to fix something that's broken.
tests, doc, and bugfixes.  I seem to recall a bunch of checkins
recently that didn't have a test.

n
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] correction of a bug

[skip]

draconux I found a bug in python I'm using python 2.4 with debian etch

draconux string.lstrip(source/old_prog,source/) return ld_prog
draconux instead of old_prog

The above is the same as

source/old_prog.lstrip(source/)

String methods are defined in the Objects/stringobject.c file of the source
distribution.

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] correction of a bug

[Heiko Wundram]

Am Samstag 13 Mai 2006 17:30 schrieb draconux:
 I found a bug in python
 I'm using python 2.4 with debian etch

 string.lstrip(source/old_prog,source/) return ld_prog instead of
 old_prog

This is not a bug, but rather expected behaviour. Read the specification of 
lstrip() correctly.

--- Heiko.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] correction of a bug

[Edward Loper]

draconux wrote:
 
 Hello all ,
 string.lstrip(source/old_prog,source/) return ld_prog instead of 
 old_prog

You are misunderstanding what the second argument to lstrip does.  It is 
interpreted as a list of characters; and lstrip will remove the maximal 
prefix of the string that consists of these characters.  E.g.:

  'aaabbbcccaax'.lstrip('abc')
'x'

The first character in your string that is not one of the characters 
's', 'o', 'u', 'r', 'c', 'e', or '/' is 'l', so it strips all characters 
up to that one.

-Edward
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] site triggering a bug in urllib2

[Aahz]

On Tue, Jan 17, 2006, Thomas Mangin wrote:

 I am contacting the list in the hope that someone will be able to 
 understand what I am seeing.

You'll probably get more help by subscribing and posting to
comp.lang.python.
-- 
Aahz ([EMAIL PROTECTED])   * http://www.pythoncraft.com/

19. A language that doesn't affect the way you think about programming,
is not worth knowing.  --Alan Perlis
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] site triggering a bug in urllib2

[Bill Janssen]

Or the Web-SIG mailing list.

Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] site triggering a bug in urllib2

[John J Lee]

On Tue, 17 Jan 2006, Thomas Mangin wrote:
[...]
 I have hit a bug with python 2.4.2 (on Mandriva 2006) using urllib2.
 The code which trigger the bug is as follow..

 import urllib2
 req = urllib2.Request(http://66.117.37.13/;)

 # makes no difference ..
 req.add_header('Connection', 'close')

 handle = urllib2.urlopen(req)
 data = handle.read()
 print data

 using a timeout on the socket does not work neither.

This is a real bug, I think.  I filed a report on the SF bug tracker:

http://python.org/sf/1411097


The problem seems to be the (ab)use of socket._fileobject in urllib2 (I 
believe this was introduced when urllib2 switched to using 
httplib.HTTPConnection).  The purpose of the hack (as commented in 
AbstractHTTPHandler.do_open()) is to provide .readline() and .readlines() 
methods on the response object returned by urllib2.urlopen().

Workaround if you're not using .readline() or .readlines() (against 2.4.2, 
but should apply against current SVN):

--- urllib2.py.orig Fri Jan 20 20:10:56 2006
+++ urllib2.py  Fri Jan 20 20:12:07 2006
@@ -1006,8 +1006,7 @@
  # XXX It might be better to extract the read buffering code
  # out of socket._fileobject() and into a base class.

-r.recv = r.read
-fp = socket._fileobject(r)
+fp = r.fp

  resp = addinfourl(fp, r.msg, req.get_full_url())
  resp.code = r.status


Not sure yet what the actual problem/cure is...


John
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Weekly Python Patch/Bug Summary

[Michael Hudson]

Kurt B. Kaiser [EMAIL PROTECTED] writes:

 Patch / Bug Summary
 ___

 Patches :  903 open (+551) /  5222 closed (+2324) /  6125 total (+2875)

Err ... ?

Cheers,
mwh

-- 
  LaTeX, pah. Don't be silly. I'm using a homebrew markup system
  that I wrote in Common Lisp. ;-) 
  -- Peter Seibel, comp.lang.lisp, talking
about his book Practical Lisp
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

python.org/sf URLs aren't working? Re: [Python-Dev] Weekly Python Patch/Bug Summary

[Jeff Epler]

I get 500 Internal Server Error messages when I try to access the URLs
in the recent patch summary.

Is this happening to anybody else?

Jeff


pgpOUL7H5Sr5t.pgp
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: python.org/sf URLs aren't working? Re: [Python-Dev] Weekly Python Patch/Bug Summary

[Oleg Broytmann]

On Thu, Mar 31, 2005 at 09:37:27AM -0600, Jeff Epler wrote:
 I get 500 Internal Server Error messages when I try to access the URLs
 in the recent patch summary.
 
 Is this happening to anybody else?

   Just visited http://python.org/sf/754022 to test - no problems,
normal redirect to the SF tracker.
   Can you show an URL that's not working?

Oleg.
-- 
 Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: python.org/sf URLs aren't working? Re: [Python-Dev] Weekly Python Patch/Bug Summary

[Kurt B. Kaiser]

Jeff Epler [EMAIL PROTECTED] writes:

 I get 500 Internal Server Error messages when I try to access the URLs
 in the recent patch summary.

Yes, it seems that the python.org/sf/ special facility is having a
problem.  IDs over 1 100 000 or so don't work.  I sent a message to
[EMAIL PROTECTED] since I don't know who wrote that code.

-- 
KBK
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: python.org/sf URLs aren't working? Re: [Python-Dev] Weekly Python Patch/Bug Summary

[Skip Montanaro]

 Jeff == Jeff Epler [EMAIL PROTECTED] writes:

Jeff I get 500 Internal Server Error messages when I try to access the
Jeff URLs in the recent patch summary.

Jeff Is this happening to anybody else?

Yup.

I don't have time to look into the problem, however...

Here's a traceback:

Traceback (most recent call last):
  File /usr/local/apache/cgi-bin/sf, line 82, in ?
log_type(report, tracker)
  File /usr/local/apache/cgi-bin/sf, line 42, in log_type
os.unlink(idsfile+.lck)
OSError: [Errno 2] No such file or directory: '/tmp/sourceforge-ids.txt.lck'

and here's the script.  It looks like lock file creation is failing but
log_type() isn't returning, so in the finally clause deletion fails.

Skip



sf
Description: Binary data
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: python.org/sf URLs aren't working? Re: [Python-Dev] Weekly Python Patch/Bug Summary

[Guido van Rossum]

I forwarded this to MvL, who wrote the code; he'll look into it but
probably not before Sunday.


On Thu, 31 Mar 2005 11:37:40 -0500, Kurt B. Kaiser [EMAIL PROTECTED] wrote:
 Jeff Epler [EMAIL PROTECTED] writes:
 
  I get 500 Internal Server Error messages when I try to access the URLs
  in the recent patch summary.
 
 Yes, it seems that the python.org/sf/ special facility is having a
 problem.  IDs over 1 100 000 or so don't work.  I sent a message to
 [EMAIL PROTECTED] since I don't know who wrote that code.
 
 --
 KBK
 ___
 Python-Dev mailing list
 Python-Dev@python.org
 http://mail.python.org/mailman/listinfo/python-dev
 Unsubscribe: 
 http://mail.python.org/mailman/options/python-dev/guido%40python.org
 


-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: python.org/sf URLs aren't working? Re: [Python-Dev] Weekly Python Patch/Bug Summary

[Martin v. Löwis]

Skip Montanaro wrote:
Here's a traceback:
Traceback (most recent call last):
  File /usr/local/apache/cgi-bin/sf, line 82, in ?
log_type(report, tracker)
  File /usr/local/apache/cgi-bin/sf, line 42, in log_type
os.unlink(idsfile+.lck)
OSError: [Errno 2] No such file or directory: '/tmp/sourceforge-ids.txt.lck'
and here's the script.  It looks like lock file creation is failing but
log_type() isn't returning, so in the finally clause deletion fails.
Somebody took world write permission on /tmp away; I don't know 
whether this was intentional - I have restored them for a moment.

The script actually has two errors: it is not os.sleep, but time.sleep
(so it would only try one time, not ten times); plus (and I'm glad
you did not catch that, either :-) the finally block is always executed,
even if the file was not created, and even if the function is left
through return.
I've fixed the script, however, if somebody takes away o+w on /tmp
again, it will mean that the caching silently stops.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: python.org/sf URLs aren't working? Re: [Python-Dev] Weekly Python Patch/Bug Summary

[Martin v. Löwis]

Guido van Rossum wrote:
I forwarded this to MvL, who wrote the code; he'll look into it but
probably not before Sunday.
Actually, now that I saw that it is a permission problem, it turned
out to be fixable quite easily.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: python.org/sf URLs aren't working? Re: [Python-Dev] Weekly Python Patch/Bug Summary

[Jeff Epler]

It's working again for me now.  thanks!

Jeff


pgpVnAYyEVx3l.pgp
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] mmap feature or bug?

[Martin v. Löwis]

Josiah Carlson wrote:
Is mmap's inability to be subclassed a feature or bug?
No.
It's a missing feature: it's not a bug, because nobody says this should
work, and anybody trying will find out that it doesn't work, so nobody
is tricked into believing it should work. The mmap type is not even
documented; mmap.mmap is a function.
It's not a feature, because (atleast IMO) there would be nothing wrong
with making mmap.mmap a subclassable type.
Is one's inability to use a = mmapinstance.__setslice__;a(1,2,'a') (and
others) a feature or bug?
That is a bug. Slice assignments are supported, and so should
__setslice__.
Regards,
Martin
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com