[issue3329] API for setting the memory allocator used by Python

[Jukka Laurila]

Jukka Laurila <[EMAIL PROTECTED]> added the comment:

Brett, the ability to define the allocator dynamically at runtime could
be a compile time option, turned on by default only on small memory
platforms. On most platforms you can live with plain old malloc and may
want to avoid the indirection. If no other platform is interested in
this, we can just make it a Symbian-specific extension but I wanted to
see if there's general interest in this.

The application would control the lifecycle of the Python heap, and this
seemed like the most natural way for the application to tell the
interpreter which heap instance to use.

Adam, the cleanup would work by freeing the entire heap used by Python
after calling Py_Finalize. In the old PyS60 code we made Python 2.2.2
clean itself completely by freeing the Python-specific heap and making
sure all pointers to heap-allocated items are properly reinitialized.

Yes, there are various static pointers that are initially set to NULL,
initialized to point at things on the heap and not reset to NULL at
Py_Finalize, and these are currently an obstacle to calling
Py_Initialize again. I'm considering submitting a separate ticket about
that since it seems like the ability to free the heap combined with the
ability to reinitialize the static pointers could together make full
cleanup possible.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3287] Fraction constructor should raise TypeError instead of AttributeError

[Raymond Hettinger]

Raymond Hettinger <[EMAIL PROTECTED]> added the comment:

Applied in r64835.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3331] Possible inconsistency in behavior of list comprehensions vs. generator expressions

[Carl Johnson]

New submission from Carl Johnson <[EMAIL PROTECTED]>:

Compare the following behaviors:

Python 3.0a5 (r30a5:62856, May 10 2008, 10:34:28)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> def f(x):
...  if x > 5: raise StopIteration
...
 >>> [x for x in range(100) if not f(x)]
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 1, in 
  File "", line 2, in f
StopIteration
 >>> list(x for x in range(100) if not f(x))
[0, 1, 2, 3, 4, 5]

One might object that the behavior of the list comprehension is 
identical to that of a for-loop:

>>> r = []
>>> for x in range(100):
...  if not f(x):
...   r.append(x)
... 
Traceback (most recent call last):
  File "", line 2, in 
  File "", line 2, in f
StopIteration

However, it can be argued that in Python 3 list comprehensions should be 
thought of as "syntatic sugar" for ``list(generator expression)`` not a 
for-loop with an accumulator. (This seems to be the motivation for no 
longer "leaking" variables from list comprehensions into their enclosing 
namespace.)

One interesting question that this raises (for me at least) is whether 
the for-loop should also behave like a generator expression. Of course, 
the behavior of the generator expression can already be simulated by 
writing:

>>> r = []
>>> for x in range(100):
...  try:
...   if f(x):
...r.append(x)
...  except StopIteration:
...   break
... 
>>> r
[0, 1, 2, 3, 4, 5]

This raises the question, do we need both a ``break`` statement and 
``raise StopIteration``? Can the former just be made into syntatic sugar 
for the later?

--
components: Interpreter Core
messages: 69496
nosy: carlj
severity: normal
status: open
title: Possible inconsistency in behavior of list comprehensions vs. generator 
expressions
type: behavior
versions: Python 3.0

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3329] API for setting the memory allocator used by Python

[Nick Coghlan]

Nick Coghlan <[EMAIL PROTECTED]> added the comment:

Given where we are in the release cycle, I've bumped the target releases
to 2.7/3.1. So Symbian are probably going to have to do something
port-specific anyway in order to get 2.6/3.0 up and running.

And in terms of hooking into this kind of thing, some simple macros that
can be overriden in pyport.h (as Brett suggested) may be a better idea
than baking any specific approach into the core interpreter.

--
nosy: +ncoghlan
versions: +Python 2.7, Python 3.1 -Python 2.6, Python 3.0

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3274] Py_CLEAR(tmp) seg faults

[Nick Coghlan]

Nick Coghlan <[EMAIL PROTECTED]> added the comment:

A better option may be to append _tmp to the passed in token:

#define Py_CLEAR(op)\
do {\
if (op) {   \
PyObject *op##_tmp = (PyObject *)(op);  \
(op) = NULL;\
Py_DECREF(op##_tmp);\
}   \
} while (0)

--
nosy: +ncoghlan

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3329] API for setting the memory allocator used by Python

[Raymond Hettinger]

Raymond Hettinger <[EMAIL PROTECTED]> added the comment:

I think it is reasonable to get a macro definition change into 2.6.
The OP's request is essential for his application (running Python
on Nokia phones) and it would be a loss to wait two years for this.
Also, his request for a macro will enable another important piece
of functionality -- allowing a build to intercept and instrument all
calls to the memory allocator.

Barry, can you rule on whether to keep this open for consideration in 
2.6.   It seems daft to postpone this discussion indefinitely.  If we 
can agree to a simple, non-invasive solution while there is still yet 
another beta, then it makes sense to proceed.

--
assignee:  -> barry
nosy: +barry, rhettinger

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3274] Py_CLEAR(tmp) seg faults

[Daniel Stutzbach]

Daniel Stutzbach <[EMAIL PROTECTED]> added the comment:

Appending _tmp is a good idea, but it won't work when the parameter
isn't a simple symbol.  For example, there's a line in cPickle.c like
this: Py_CLEAR(*p).

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1700288] Armin's method cache optimization updated for Python 2.6

[Raymond Hettinger]

Changes by Raymond Hettinger <[EMAIL PROTECTED]>:


--
assignee: rhettinger -> 

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1568] PATCH: Armin's attribute lookup caching for 3.0

[Raymond Hettinger]

Changes by Raymond Hettinger <[EMAIL PROTECTED]>:


--
assignee: rhettinger -> 

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3332] DocTest and dict sort.

[Jens Diemer]

New submission from Jens Diemer <[EMAIL PROTECTED]>:

The doctest doesn't work good, if a function returns a dict.

Here a simple example:

def test(d):
"""
This works:
>>> test({"A":1, "B":2, "C":3})
{'A': 1, 'C': 3, 'B': 2}
   
This failed, because of different dict sort:
>>> test({"A":1, "B":2, "C":3})
{'A': 1, 'B': 2, 'C': 3}
   
The Error messages:

Failed example:
test({"A":1, "B":2, "C":3})
Expected:
{'A': 1, 'B': 2, 'C': 3}
Got:
{'A': 1, 'C': 3, 'B': 2}
"""
return d


The problem is IMHO that doctest.py [1] OutputChecker.check_output()
does compare the repr() of the dict and not the real dict as data.

One solution: Use eval() to convert the string repr. of the dict into
the real dict:

...
#--
try:
if eval(got) == eval(want):
return True
except:
pass #*pfeif* kein schoener stil, aber pragmatisch
#-
# We didn't find any match; return false.
return False

German discuss can be found here:
http://www.python-forum.de/topic-15321.html

[1] http://svn.python.org/view/python/trunk/Lib/doctest.py?view=markup

--
components: Extension Modules
messages: 69501
nosy: jedie
severity: normal
status: open
title: DocTest and dict sort.
type: behavior
versions: Python 2.5

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3301] DoS when lo is negative in bisect.insort_right() / _left()

[Raymond Hettinger]

Raymond Hettinger <[EMAIL PROTECTED]> added the comment:

Fixed in 64845.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3332] DocTest and dict sort.

[Tarek Ziadé]

Tarek Ziadé <[EMAIL PROTECTED]> added the comment:

This is not a bug: dict do not guarantee the ordering of the keys, so it
may change on every run.

A good practice is to test a sorted .items() output of your dict in your
doctest.

--
nosy: +tarek

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3332] DocTest and dict sort.

[Raymond Hettinger]

Raymond Hettinger <[EMAIL PROTECTED]> added the comment:

Closing as not a bug.

FWIW, here's the relevant text from the docs:
-
23.2.3.6 Warnings 
doctest is serious about requiring exact matches in expected output. If 
even a single character doesn't match, the test fails. This will 
probably surprise you a few times, as you learn exactly what Python 
does and doesn't guarantee about output. For example, when printing a 
dict, Python doesn't guarantee that the key-value pairs will be printed 
in any particular order, so a test like 


>>> foo()
{"Hermione": "hippogryph", "Harry": "broomstick"}

is vulnerable! One workaround is to do 


>>> foo() == {"Hermione": "hippogryph", "Harry": "broomstick"}
True

instead. Another is to do 


>>> d = foo().items()
>>> d.sort()
>>> d
[('Harry', 'broomstick'), ('Hermione', 'hippogryph')]

--
nosy: +rhettinger
resolution:  -> invalid
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3285] Fraction.from_any()

[Raymond Hettinger]

Raymond Hettinger <[EMAIL PROTECTED]> added the comment:

Adopted the solution used by functions in the math module.  Functions 
that accept floats also accept integral inputs.  This improves 
usability in face of mixed float/int data or decimal/int data.

See r64846.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3333] Need -3 warning for exec statement becoming a function

[Raymond Hettinger]

Changes by Raymond Hettinger <[EMAIL PROTECTED]>:


--
nosy: rhettinger
priority: high
severity: normal
status: open
title: Need -3 warning for exec statement becoming a function
versions: Python 2.6

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3330] webbrowser module doesn't correctly handle '|' character.

[Matt Giuca]

Matt Giuca <[EMAIL PROTECTED]> added the comment:

I was able to duplicate this, but it's an issue with Firefox, not
Python. webbrowser.open(url) just passes url as a command line argument
to the web browser; it doesn't do any manipulation.

Note that you get the exact same behaviour if you run Firefox from the
command line:

> firefox 'http://foo.com/bar.html?var=x|y|z'

Opens this URL in a new tab if it's already open, but splits on '|' and
opens in 3 separate tabs if Firefox isn't running.

Note also that while this string is a URL, it isn't properly normalized.

This works fine if you call

webbrowser.open("http://foo.com/bar.html?var=x%7Cy%7Cz";)

(Which you can only obtain programmatically by generating the URL
properly in the first place, by using urllib.urlencode, or urllib.quote
on the value string "x|y|z").

--
nosy: +mgiuca

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3331] Possible inconsistency in behavior of list comprehensions vs. generator expressions

[Matt Giuca]

Matt Giuca <[EMAIL PROTECTED]> added the comment:

You seem to be suggesting that a StopIteration raised in the body of a
for-loop should cause the loop to break. That isn't (as far as I know)
the point of StopIteration. StopIteration is only used to break the
for-loop when raised by the iterator, not the body.

Hence I think the list comprehension is behaving correctly, as the
for-loop is, in that they are both raising the StopIteration you threw,
not catching it. That's valid, because you didn't throw it in the
iterator, you threw it in the condition.

What's more strange (to me) is the fact that the generator expression
stops when it sees a StopIteration. Note that this also happens if you
do it in the head of the generator expression. eg

def f(x):
if x > 5:
raise StopIteration
return x

>>> list((f(x) for x in range(0, 100)))
[0, 1, 2, 3, 4, 5]

However, if you translate that into the full generator function version:

def my_generator_expr():
for x in range(0, 100):
yield f(x)

You see that it is behaving correctly.

So I think you discovered an interesting quirk, but it's hard to say
anything here is misbehaving.

By the way this is not a new issue with Python 3.0. Flagging it as a
Python 2.5 issue as well.

--
nosy: +mgiuca
versions: +Python 2.5

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3300] urllib.quote and unquote - Unicode issues

[Matt Giuca]

Matt Giuca <[EMAIL PROTECTED]> added the comment:

Setting Version back to Python 3.0. Is there a reason it was set to
Python 3.1? This proposal will certainly break a lot of code. It's *far*
better to do it in the big backwards-incompatible Python 3.0 release
than a later release.

--
versions: +Python 3.0 -Python 3.1

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3331] Possible inconsistency in behavior of list comprehensions vs. generator expressions

[Guido van Rossum]

Guido van Rossum <[EMAIL PROTECTED]> added the comment:

IMO the generator expression is wrong in interpreting the StopIteration
as a break. It should fail just like the list comprehension fails.

--
nosy: +gvanrossum

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3334] 2to3 looses indentation on import fix

[Christian Theune]

New submission from Christian Theune <[EMAIL PROTECTED]>:

I got this output from 2to3:

(This is from setuptools egg_info.py)

-import bdist_egg; bdist_egg.write_safety_flag(cmd.egg_info, safe)
+from . import bdist_egg; bdist_egg.write_safety_flag(cmd.egg_info, safe)

--
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 69510
nosy: collinwinter, ctheune
severity: normal
status: open
title: 2to3 looses indentation on import fix
versions: Python 3.0

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3329] API for setting the memory allocator used by Python

[Adam Olsen]

Adam Olsen <[EMAIL PROTECTED]> added the comment:

Basically you just want to kick the malloc implementation into doing
some housekeeping, freeing its caches?  I'm kinda surprised you don't
add the hook directly to your libc's malloc.

IMO, there's no use-case for this until Py_Finalize can completely tear
down the interpreter, which requires a lot of special work (killing(!)
daemon threads, unloading C modules, etc), and nobody intends to do that
at this point.

The practical alternative, as I said, is to run python in a subprocess.
 Let the OS clean up after us.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue874900] threading module can deadlock after fork

[Jesse Noller]

Jesse Noller <[EMAIL PROTECTED]> added the comment:

FWIW: the threading tests still hang for me with the latest patch. I'm 
confirming that the patch itself fixes the hanging MP tests though

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3316] Proposal for fix_urllib

[Collin Winter]

Collin Winter <[EMAIL PROTECTED]> added the comment:

- You should add tests to test_fixers to ensure that this does what you
expect. This will make it much easier for others to modify this fixer
later. You can probably just reuse the tests Brett initially added.

- There's a better data structure for MAPPING: rather than using

MAPPING = {module: [(new_module, [member, member, ..., member])]}

you should probably use

MAPPING = {module: {new_module: [member, member, ..., member]}}

The list-of-2-tuples was a bad idea on my part that didn't scale.

- The "cannot handle star imports" warning isn't strictly correct: star
imports for robotparser and urlparse can both be handled correctly,
since they're just being renamed.

- urlparse and robotparser don't seem to belong to this more specialized
fixer: they can go in fix_imports, since they aren't being broken across
multiple modules.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3335] subprocess lib - opening same command fails

[Justin Harper]

New submission from Justin Harper <[EMAIL PROTECTED]>:

When I make the same shell call a second time, a weird error occurs.  
It appears that the system is caching the call and then returning the 
same object the second time, which causes a problem because the stream 
is at EOF and there is no way to seek on this sort of file object.

Code:
fout = subprocess.Popen("owplaces -silent -multi", shell=True, 
stdout=subprocess.PIPE).stdout
self.output = fout.read()

if self.output != []:
for line in self.output:
print line

fout.close()

Error:
Traceback (most recent call last):
  File "./saveSettings.py", line 30, in next_page
func()
  File "./saveSettings.py", line 62, in save_startup
fout = subprocess.Popen("owplaces -silent -multi", shell=True, 
stdout=subprocess.PIPE).stdout
  File "/opt/app/g++lib6/python-2.4/lib/python2.4/warnings.py", line 
61, in warn
warn_explicit(message, category, filename, lineno, module, registry)
  File "/opt/app/g++lib6/python-2.4/lib/python2.4/warnings.py", line 
82, in warn_explicit
for item in filters:
TypeError: an integer is required


The first time the code works time.  The second (and subsequent times) 
the cryptic error msg is displayed.

Python 2.4.5 running on a Solaris machine.

--
components: Library (Lib)
messages: 69514
nosy: gtg944q
severity: normal
status: open
title: subprocess lib - opening same command fails
versions: Python 2.4

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3335] subprocess lib - opening same command fails

[Justin Harper]

Justin Harper <[EMAIL PROTECTED]> added the comment:

Correction:  line two should actually be:
self.output = fout.readlines()

The bug still exists with this change.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1673409] datetime module missing some important methods

[Erik Stephens]

Erik Stephens <[EMAIL PROTECTED]> added the comment:

I'm not sure this is still being considered, so I just wanted to add my
opinion.  This seems like such a simple request being made overly
complicated.  We just want seconds since epoch since that is used in
many other functions and libraries (i.e. the time module,
os.stat().st_mtime).  Why is there toordinal()?!?  If there is going to
be any toxxx() methods, there should definitely be a
tosecs()/totimestamp() method or an 'epoch/timestamp' attribute.  For
boundary cases, I would look to the std time module for guidance.

--
nosy: +erik.stephens

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3336] datetime weekday() function

[ryanboesch]

New submission from ryanboesch <[EMAIL PROTECTED]>:

Leap year ignored each century (2100, 2200, 2300, etc.) except 2000 for
the weekday() function. This code reproduces the error:

import datetime
datetime.date(2100,2,29).weekday()

Error message:
ValueError: day is out of range for the month

Also, this causes the weekday to be 1 day off from March 1st, 2100 to
February 28th 2200 and 2 days off...

--
messages: 69517
nosy: ryanboesch
severity: normal
status: open
title: datetime weekday() function
type: behavior
versions: Python 2.5

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3336] datetime weekday() function

[Tim Peters]

Tim Peters <[EMAIL PROTECTED]> added the comment:

The error message is correct.  In the Gregorian calendar, years
divisible by 100 are not leap years, unless they're also divisible by
400.  So 2000, 2400, 2800, ..., are leap years, but 2100, 2200, 2300,
2500, 2600, 2700, 2900, ... are not leap years.  Look it up (anywhere ;-)).

--
nosy: +tim_one

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3300] urllib.quote and unquote - Unicode issues

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

> Setting Version back to Python 3.0. Is there a reason it was set to
> Python 3.1? 

3.0b1 has been released, so no new features can be added to 3.0.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails

[Christopher Li]

Christopher Li <[EMAIL PROTECTED]> added the comment:

Hi,

After a closer look of your testing program. I believe that your testing
program is not correct. It might be the urllib way of doing things. But
that is not the urllib2 way of doing it. You should add a proxy_handler
rather than directly set_proxy on request objects.

The reason is that, you mess req directly. The urllib2 will not handle
correctly if the request needs rebuild and forward to other handlers.
One example is if the request needs redirect, I believe your test program
will not work.

So the right way of doing things, IMHO, is just adding a proxy handler
which contain the proxy you want. Then that proxy handler will just
automatically set_proxy() to every request it goes out. It even works
if the request needs to be rebuilt.

Then my patch should just work in that case. Try to make it work
for your test script will make things unnecessary complicated.
That defeats the benefit of the handler call chain in urllib2.

Does it make sense to you?

Thanks,

Chris

On Mon, Jun 30, 2008 at 1:49 AM, Nagy Ferenc László
<[EMAIL PROTECTED]> wrote:
> The test program was:
>
> import urllib2
>
> targeturl = 'https://www.paypal.com/'
> proxyhost = 'proxy..hu:3128'
>
> req = urllib2.Request(targeturl)
> req.set_proxy(proxyhost, 'https')
> response = urllib2.urlopen(req)
> print response.info()

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2275] urllib2 header capitalization

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

* The patch looks like it will break code that uses .header_items(),
which is not acceptable.

* The patch to the docs seems to muddy the waters even further (than the
current slightly murky state) about whether and why .headers is to be
preferred over the methods, or vice-versa.  I think .headers should
remain undocumented, for the reason stated by the doctest that failed
with Hans-Peter's original patch.  The best course of action is
debatable, but the patch is a regression in this respect, so should not
be committed as-is.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3008] Let bin/oct/hex show floats

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

Here's a slightly more polished version of the previous patch;  no
behaviour changes.

Let me know if there's anything I can do to help get this in before next 
week's beta.  Anybody want to trade patch reviews?

Added file: http://bugs.python.org/file10874/hex_float4.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3333] Need -3 warning for exec statement becoming a function

[Benjamin Peterson]

New submission from Benjamin Peterson <[EMAIL PROTECTED]>:

No, I don't think we do. This is something that 2to3 can handle well,
and also rather pointless because it would be impossible to get rid of
the warning in 2.x because exec isn't a function in 2.x.(short of
removing the exec completely!)

--
nosy: +benjamin.peterson

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2275] urllib2 header capitalization

[Facundo Batista]

Facundo Batista <[EMAIL PROTECTED]> added the comment:

John:

You say that it will break code because it changes the capitalization
policy, or because other reason? Do you think that there's a way to fix
this issue and not break the code? 

If you really think that this breaks code, please provide a test case.

Regarding .headers, having a public attribute not documented never is a
better solution than document it, with its benefits and its shortcomings. 

Thanks.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3316] Proposal for fix_urllib

[Brett Cannon]

Brett Cannon <[EMAIL PROTECTED]> added the comment:

What Collin said. =)

I will put robotparser and urlparse into fix_imports myself and continue
to update the docs in 2.x for urllib(2).

Thanks to the both of you for helping with this! It's going to be great
once this fixer is ready to go as it will put PEP 3108 REALLY close to
being finished!

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3337] Fixer for dbm is failing

[Brett Cannon]

New submission from Brett Cannon <[EMAIL PROTECTED]>:

The fixer for dbm to dbm.ndbm fails test_fixers.Test_imports .

--
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 69526
nosy: brett.cannon, collinwinter
priority: critical
severity: normal
status: open
title: Fixer for dbm is failing

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2775] Implement PEP 3108

[Brett Cannon]

Changes by Brett Cannon <[EMAIL PROTECTED]>:


--
dependencies: +Fixer for dbm is failing

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2775] Implement PEP 3108

[Brett Cannon]

Changes by Brett Cannon <[EMAIL PROTECTED]>:


--
dependencies: +fix_imports does not handle intra-package renames

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3337] Fixer for dbm is failing

[Brett Cannon]

Brett Cannon <[EMAIL PROTECTED]> added the comment:

The failure seems to be from anydbm being mapped directly to dbm:

import anydbm -> import dbm -> import dbm.ndbm

A separate pass might be needed to handle dbm properly so that an import
is not changed multiple times.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2275] urllib2 header capitalization

[Senthil]

Senthil <[EMAIL PROTECTED]> added the comment:

> John J Lee <[EMAIL PROTECTED]> added the comment:
> 
> * The patch looks like it will break code that uses .header_items(),
> which is not acceptable.

Nope, it does not break. If the concern was subclassing dict may have adverse
effect on .copy and .update methods, thats taken care because the subclass just 
passes it to the original dict method, which would behave the same way.

>>> r.header_items()
[('Spam-Eggs', 'blah')]
>>> r.add_header("Foo-Bar", "baz")
>>> items = r.header_items()
>>> items.sort()
>>> items
[('Foo-Bar', 'baz'), ('Spam-Eggs', 'blah')]

> * The patch to the docs seems to muddy the waters even further (than the
> current slightly murky state) about whether and why .headers is to be
> preferred over the methods, or vice-versa.  I think .headers should
> remain undocumented, for the reason stated by the doctest that failed
> with Hans-Peter's original patch.

IIRC, Hans-Peter's comment was on the reference to .headers undocumented 
interface mentioned in the test_urllib2.

>  The best course of action is
> debatable, but the patch is a regression in this respect, so should not
> be committed as-is.

My understanding in this case was to address 1) Title()-ize the headers and 2)
provide a case insensitive lookup.

Is this sufficient now to expose the headers method? If not, what else?
If headers method should not be exposed, then will the 2 cases addressed above
still do, as this issue request was opened for that?

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3159] glob.py improvements

[Facundo Batista]

Facundo Batista <[EMAIL PROTECTED]> added the comment:

If readability is enhanced is questionable, but is rejected on the basis
that cosmetic-only changes are not generally recommended: only
difficults following the code evolution in the repository.

The only change that I see regarding performance is the one involving
startswith, and it's actually wrong:

[EMAIL PROTECTED]:~$ timeit.py -s "s='qwerty'" "s[0]=='q';s[0]=='x'"
100 loops, best of 3: 0.338 usec per loop
[EMAIL PROTECTED]:~$ timeit.py -s "s='qwerty'"
"s.startswith('q');s.startswith('x')"
100 loops, best of 3: 0.854 usec per loop

Thanks anyway!

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

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2674] unittest.TestProgram uses sys.exit()

[Facundo Batista]

Facundo Batista <[EMAIL PROTECTED]> added the comment:

That class is normally used at the end of the testing suite, as is
recommended in the documentation.

In any case, I don't see that like a bug, so we shouldn't be changing
that behaviour, because of compatibility.

What do you think? Maybe the documentation should be more explicit about
this? Thanks!

--
nosy: +facundobatista

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3337] Fixer for dbm is failing

[Brett Cannon]

Brett Cannon <[EMAIL PROTECTED]> added the comment:

I have a potential solution brewing; running the full test suite to verify.

--
status: open -> pending

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3338] cPickle segfault with deep recursion

[Darryl Dixon]

New submission from Darryl Dixon <[EMAIL PROTECTED]>:

In at least Python 2.4, using cPickle.Pickler to try and pickle a nested
chain of objects more than about 2590 objects deep causes the Python
interpreter to segfault. This doesn't seem to happen when using the pure
Python pickle module.

It is not memory related (witness that the pure Python module can
achieve depths much greater than this just fine), and does not seem to
be directly related to system architecture (happens on both i386 and on
x86_64 (32bit and 64bit)).

Sample interpreter session to replicate:
>>> # Let's cause cPickle to segfault:
>>> from cPickle import Pickler as cPickler
>>> class rec:
...   child = None
...   def __init__(self, counter):
... if counter > 0:
...   self.child = rec(counter-1)
...
>>> import sys
>>> sys.setrecursionlimit(1)
>>> mychain = rec(2600)
>>> from cStringIO import StringIO
>>> stream = StringIO()
>>> p = cPickler(stream, 1)
>>> res = p.dump(mychain)
Segmentation fault

And now the same steps again using the pure Python Pickler:
>>> import sys
>>> from pickle import Pickler as pPickler
>>> from cStringIO import StringIO
>>> class rec:
...   child = None
...   def __init__(self, counter):
... if counter > 0:
...   self.child = rec(counter-1)
... 
>>> sys.setrecursionlimit(2)
>>> mychain = rec(2600)
>>> stream = StringIO()
>>> p = pPickler(stream, 1)
>>> p.dump(mychain)
>>> len(stream.getvalue())
48676
>>>

--
components: Library (Lib)
messages: 69532
nosy: esrever_otua
severity: normal
status: open
title: cPickle segfault with deep recursion
type: crash
versions: Python 2.4

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3337] Fixer for dbm is failing

[Brett Cannon]

Brett Cannon <[EMAIL PROTECTED]> added the comment:

r64870 has the fix through fix_imports2.

--
resolution:  -> fixed
status: pending -> closed

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3338] cPickle segfault with deep recursion

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

Can you try this for a newer version? For 2.4, such problems will not be
fixed anymore.

--
nosy: +loewis

___
Python tracker <[EMAIL PROTECTED]>

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