[issue6829] Frendly error message when inheriting from function

[anatoly techtonik]

New submission from anatoly techtonik :

It is an error to try to inherit from function and the error message in 
this case is:
{{{
Traceback (most recent call last):
  File "", line 1, in 
  File "m:\p\pb.py", line 4, in 
class PostgreSQLConnection(DatabaseConnection):
TypeError: Error when calling the metaclass bases
function() argument 1 must be code, not str
}}}

Something like 'Impossible to inherit from function' will clear 
confusion state from users unfamiliar with metaclasses.
{{{
def DatabaseConnection(object):
pass

class PostgreSQLConnection(DatabaseConnection):
pass
}}}

--
components: Interpreter Core
messages: 92191
nosy: techtonik
severity: normal
status: open
title: Frendly error message when inheriting from function
type: behavior
versions: Python 2.6

___
Python tracker 

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

[issue6828] wrongly highlighted blocks in the Tutorial

[Georg Brandl]

Georg Brandl  added the comment:

Thanks, fixed in r74632.

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

___
Python tracker 

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

[issue6830] Some uniformness in defaultdict

[Toshihiro Kamiya]

New submission from Toshihiro Kamiya :

I found the syntax of collections.defaultdict is confusing, at least to 
me.

When I need a defaultdict of int, that is, a defaultdict which contains 
int objects, I can write simply:
a = defaultdict(int)

However, when I want a defaultdict of defaultdict of something, I can't 
write:
d = defaultdict(defaultdict(int))

This raises TypeError.

I understand the argument of defaultdict is not a type (or class), but 
a factory by definition. So I should to write:
d = defaultdict(lambda: defaultdict(int))

But this syntax is somehow confusing to me.
Am I missing some important feature of defaultdict?

The workaround that I've found is:

import collections
class __Helper(object):
  def __getitem__(self, ctor):
return lambda: collections.defaultdict(lambda: ctor())
genericdefaultdict = __Helper()

This helper introduce some generics flavor in defaultdict.
The above cases can be spelt out:

a = genericdefaultdict[int]()
d = genericdefaultdict[genericdefaultdict[int]]()

--
components: Library (Lib)
files: ddh.py
messages: 92193
nosy: t-kamiya
severity: normal
status: open
title: Some uniformness in defaultdict
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file14824/ddh.py

___
Python tracker 

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

[issue6831] 2to3 assignment division conversion

[Jonas Byström]

New submission from Jonas Byström :

Code from 2.x containing __idiv__ does not translate into

def __floordiv__(self, x): self.__truediv__(x)
def __truediv__(self, x): ...

--
components: 2to3 (2.x to 3.0 conversion tool)
messages: 92194
nosy: highfestiva
severity: normal
status: open
title: 2to3 assignment division conversion
type: behavior
versions: Python 3.1

___
Python tracker 

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

[issue1766304] improve xrange.__contains__

[Mark Dickinson]

Mark Dickinson  added the comment:

The py3k patch no longer works:  it makes use of PyObject_Cmp, which no
longer exists.

--

___
Python tracker 

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

[issue6832] Outputting unicode crushes when printing to file on Linux

[Jerzy]

New submission from Jerzy :

Hi

When I am outputting unicode strings to terminal my script works OK, but
when I redirect it to file I get a crash:

$ python mailing/message_sender.py -l Bia
Białystok

$ python mailing/message_sender.py -l Bia > ~/tmp/aaa.txt 
Traceback (most recent call last):
  File "mailing/message_sender.py", line 71, in 
list_groups(unicode(args[0],'utf-8'))
  File "mailing/message_sender.py", line 53, in list_groups
print group[1].name
UnicodeEncodeError: 'ascii' codec can't encode character u'\u0142' in
position 3: ordinal not in range(128)

--
components: Unicode
messages: 92196
nosy: Orlowski
severity: normal
status: open
title: Outputting unicode crushes when printing to file on Linux
type: crash
versions: Python 2.6

___
Python tracker 

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

[issue1766304] improve xrange.__contains__

[Mark Dickinson]

Mark Dickinson  added the comment:

The trunk patch is also unacceptable in its current form:

 1. there are no docs or tests
 2. keyval, start, step and end should have type long, not type int
(as Antoine already mentioned)
 3. the expression ((keyval - start) % step) can overflow, leading to
undefined behaviour (e.g., wrong results, segfaults, strange
effects from gcc optimizations that assume no overflow).  For
example, with the patch, on Linux/x86-64, I get:

  >>> x = xrange(-20, 20, 5)
  >>> 10 in x
  False

This should be relatively easy to fix:  e.g., if you already
know that step > 0 and start <= keyval and keyval < stop, then
'(unsigned long)keyval - (unsigned long)start'  is safe from
overflow.

 4. the containment check only works for ints:  with the patch, I get:

  >>> x = xrange(10)
  >>> 4 in x
  True
  >>> 4L in x
  False
  >>> 4.0 in x
  False

but without the patch applied, all these return True.  It's possible
that it's worth special-casing integer inputs for the sake of
speed, but I don't think the behaviour should change like this for
other types.

--

___
Python tracker 

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

[issue1766304] improve xrange.__contains__

[Mark Dickinson]

Mark Dickinson  added the comment:

[Joseph Thomson]
> Also, as I said in my closed duplicate issue, 'if value in range(lower,
> upper)' to me looks far more Pythonic than 'if value >= lower and value
> < upper'.

Note that the Pythonic spelling would be:  'if lower <= value < upper'.
 (Though that's not quite the same thing if value is not an integer.)

--

___
Python tracker 

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

[issue6833] incorrect: failed local variable referenced before assignment

[Paul van der Linden]

New submission from Paul van der Linden :

The attached python file will give the following output, which is 
incorrect behavior as far as I know:
"
this will fail
failed local variable 'in_std' referenced before assignment

this won't fail
Not failed
this won't fail either
Not failed
"

This is tested on windows with python2.6(standard msi) and on centos 
5.3 with python2.6 (custom rpm), python2.4 (system rpm), freebsd with 
python2.5 (system package), python2.6 ("hand" compiled) and python3.0 
("hand" compiled).

The attached code is stripped down to the bare minimum and therefore 
won't do anything usefull.

--
components: None
files: bug.py
messages: 92199
nosy: paultjuhatwork
severity: normal
status: open
title: incorrect: failed local variable referenced before assignment
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file14825/bug.py

___
Python tracker 

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

[issue6827] deepcopy erroneously doesn't call __setstate__ if __getstate__ returns empty dict

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

This is precisely documented here:
http://docs.python.org/library/pickle.html#object.__setstate__
"Note: For new-style classes, if __getstate__() returns a false value,
the __setstate__() method will not be called."

If you want some default value even when the state is empty, you could
set it in the __new__ method:
[__new__ is always called, but __init__ is skipped by the copy protocol]

class A(object):
def __new__(cls):
self = super(cls, A).__new__(cls)
self.a = 1
return self
def __setstate__(self, d):
self.__dict__.update(d)
def __getstate__(self):
d = self.__dict__.copy()
d.pop('a')
return d

The __setstate__ is even not necessary here, since it implements the
default behaviour.

--
nosy: +amaury.forgeotdarc
resolution:  -> works for me
status: open -> pending

___
Python tracker 

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

[issue6833] incorrect: failed local variable referenced before assignment

[Mark Dickinson]

Mark Dickinson  added the comment:

This is not a bug.  The behaviour you're seeing is described here:

http://docs.python.org/reference/executionmodel.html#naming-and-binding

"If a name binding operation occurs anywhere within a code block, all
uses of the name within the block are treated as references to the
current block. This can lead to errors when a name is used within a
block before it is bound. This rule is subtle. Python lacks declarations
and allows name binding operations to occur anywhere within a code
block. The local variables of a code block can be determined by scanning
the entire text of the block for name binding operations."

In the failing example, the registerdecorator function contains an
assignment to in_std, so by the rules above in_std is local to the
function.  The 'if in_std' line therefore tries to lookup 'in_std' in
the local namespace;  it doesn't exist (yet), so an UnboundLocalError
exception occurs.

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

___
Python tracker 

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

[issue6832] Outputting unicode crushes when printing to file on Linux

[Benjamin Peterson]

Benjamin Peterson  added the comment:

You have to use an encoding that's not ascii then.

--
nosy: +benjamin.peterson
resolution:  -> works for me
status: open -> closed

___
Python tracker 

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

[issue6832] Outputting unicode crushes when printing to file on Linux

[Jerzy]

Jerzy  added the comment:

I know how to make it work. The question is why outputting to file makes 
it crush when outputting to terminal does not.

I have never seen "$program > file" behaving in a different way than 
"$program" in any other language

Jerzy Orlowski

Benjamin Peterson wrote:
> Benjamin Peterson  added the comment:
>
> You have to use an encoding that's not ascii then.
>
> --
> nosy: +benjamin.peterson
> resolution:  -> works for me
> status: open -> closed
>
> ___
> Python tracker 
> 
> ___
>
>
>
>

--

___
Python tracker 

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

[issue6832] Outputting unicode crushes when printing to file on Linux

[Georg Brandl]

Georg Brandl  added the comment:

When output goes to a terminal, Python can determine its encoding. For a
file, it cannot, therefore it refuses to guess.

Also, many programs behave differently when used with redirection;
namely, all those that use `isatty()` to determine if stdout is a terminal.

--
nosy: +georg.brandl

___
Python tracker 

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

[issue6823] time.strftime does unnecessary range check

[Georg Brandl]

Georg Brandl  added the comment:

Assigning to Brett who added this check in r35368.

--
assignee:  -> brett.cannon
nosy: +brett.cannon, georg.brandl

___
Python tracker 

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

[issue6830] Some uniformness in defaultdict

[Georg Brandl]

Georg Brandl  added the comment:

This won't change -- the argument of defaultdict is simply a callable
that is called with no arguments and returns the default value.

It works with `int` because `int()` can be called without arguments and
yields 0; however, `defaultdict` cannot.  Therefore, the lambda
expression you wrote is one of the correct ways to spell this.

--
nosy: +georg.brandl
resolution:  -> wont fix
status: open -> closed

___
Python tracker 

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

[issue6832] Outputting unicode crushes when printing to file on Linux

[Jerzy]

Jerzy  added the comment:

Well, I would suggest using the terminal encoding as default one when 
redirecting. In my opinion sys.stdin and sys.stdout should always have 
the terminal encoding

Alternatively you could make the function sys.setdefaultencoding() 
visible to change it in a reasonable way

Jerzy

Georg Brandl wrote:
> Georg Brandl  added the comment:
>
> When output goes to a terminal, Python can determine its encoding. For a
> file, it cannot, therefore it refuses to guess.
>
> Also, many programs behave differently when used with redirection;
> namely, all those that use `isatty()` to determine if stdout is a terminal.
>
> --
> nosy: +georg.brandl
>
> ___
> Python tracker 
> 
> ___
>
>
>
>

--

___
Python tracker 

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

[issue6757] Marshal's documentation incomplete (Bools)

[Georg Brandl]

Georg Brandl  added the comment:

Thanks, fixed in r74633.

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

___
Python tracker 

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

[issue6820] Redefinition of HAVE_STRFTIME can cause compiler errors.

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Those HAVE_XXX symbols should be defined like autoconf does:
#define HAVE_STRFTIME 1
This is what happens on Unix platforms, and AFAIK this plays well with
other libraries which define the same symbols.

--
nosy: +amaury.forgeotdarc

___
Python tracker 

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

[issue6802] build fails on Snow Leopard

[fideli]

Changes by fideli :


--
nosy: +fideli

___
Python tracker 

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

[issue6802] build fails on Snow Leopard

[Ronald Oussoren]

Ronald Oussoren  added the comment:

My current plan is to fix this issue, and the issue of 64-bit universal 
builds on SL in the weekend. 

BTW. I'm not planning to fix this for 2.5 and 2.4, AFAIK both are no 
maintained beyond critical security patches.

--

___
Python tracker 

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

[issue6834] use different mechanism for pythonw on osx

[Ronald Oussoren]

New submission from Ronald Oussoren :

Note: this is mostly a reminder for myself to clean up the pythonw stub 
executable

The current implementation of pythonw on OSX uses exec to start an 
executable inside the framework, this is needed to be able to use GUI 
functionality from the command-line without resorting to undocumented 
and unsupported system APIs. To deal with selection between 32-bit and 
64-bit the framework contains a number of python executables.

Using "posix_spawnattr_setbinpref_np", "posix_spawnattr_setflags" and 
"posix_spawn" it is possible to do away with the additional executables, 
leaving a simpler situation. 

Nice to have features:
* python(1) on SnowLeopard has a system preference to select between 32-
bit and 64-bit:

   $ defaults read com.apple.versioner.python  
   {
"Prefer-32-Bit" = 1;
   }

(The "versioner" appears to be a private Apple library/tool, 
reimplementing the functionality would be fairly trivial)

* It would be nice to have a command-line switch as well

* It would be nice if the stub executable could be reused by tools like 
virtualenv without recompilation

--
assignee: ronaldoussoren
components: Macintosh
keywords: easy
messages: 92210
nosy: ronaldoussoren
severity: normal
stage: needs patch
status: open
title: use different mechanism for pythonw on osx
type: feature request
versions: Python 2.7, Python 3.2

___
Python tracker 

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

[issue6835] doctest problem with decorated function when decorator is defined in separate file

[Goetz Pfeiffer]

New submission from Goetz Pfeiffer :

As described in bug 1108, doctest skips tests on 
functions that have been decorated with a decorator that 
is defined in a separate file.

As described in bug 1108, the problem lies in 
file "doctest.py", there in class "DocTestFinder",
there in method "_from_module"

There at about line 857 the following code makes problems:

elif inspect.isfunction(object):
return module.__dict__ is object.func_globals

The "func_globals" property of the function is used to find out if
the function was defined in the current module. This is not true
for a decorated function where the decorator is defined in another
module. Maybe _from_module() should use inspect.getmodulename() or
the "__module__" property of the function instead. "__module__"
is set correctly when the decorator uses functools.wraps().

The func_globals property is read-only, so there is no chance fix this
at the decorator definition.

--
components: Library (Lib)
files: mytest.sh
messages: 92212
nosy: goetzpf
severity: normal
status: open
title: doctest problem with decorated function when decorator is defined in 
separate file
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14826/mytest.sh

___
Python tracker 

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

[issue6802] build fails on Snow Leopard

[Brett Cannon]

Brett Cannon  added the comment:

On Thu, Sep 3, 2009 at 07:28, Ronald Oussoren wrote:
>
> Ronald Oussoren  added the comment:
>
> My current plan is to fix this issue, and the issue of 64-bit universal
> builds on SL in the weekend.
>
> BTW. I'm not planning to fix this for 2.5 and 2.4, AFAIK both are no
> maintained beyond critical security patches.

That's correct.

--

___
Python tracker 

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

[issue6832] Outputting unicode crushes when printing to file on Linux

[Martin v . Löwis]

Martin v. Löwis  added the comment:

Using the terminal encoding for sys.stdout does not work in the general
case, as a (background) process may not *have* a controlling terminal
(such as a CGI script, a cron job, or a Windows service). That Python
recognizes the terminal encoding is primarily a convenience feature for
the interactive mode.

Exposing sys.setdefaultencoding is not implementable in a reasonable way.

--
nosy: +loewis

___
Python tracker 

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

[issue6834] use different mechanism for pythonw on osx

[Martin v . Löwis]

Martin v. Löwis  added the comment:

Can you kindly report how architecture selection works? Is there a
separate binary which execs? Some other magic?

Asking primarily out of curiosity, but if it's a launcher, then
(sym)linking it into a virtualenv might be sufficient.

--
nosy: +loewis

___
Python tracker 

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

[issue6832] Outputting unicode crushes when printing to file on Linux

[Jerzy]

Jerzy  added the comment:

OK, I give up.

The problem is that one might test a program on terminal and think that 
everything is running OK and then spend a reasonable amount of time 
trying to find the problem later

Another approach: couldn't utf8 be set as default encoding for all 
inputs and outputs?

I know that some of my questions are caused by the fact that I do not 
understand how python works. But You have to bear in mind that most of 
the people don't. Such behaviour of Python (see also 
http://bugs.python.org/issue5092) is illogical in the "common sense" for 
standard poeple. If interpreter does something illogical for me, I am 
more eager to switch to another language.

Jerzy

Martin v. Löwis wrote:
> Martin v. Löwis  added the comment:
>
> Using the terminal encoding for sys.stdout does not work in the general
> case, as a (background) process may not *have* a controlling terminal
> (such as a CGI script, a cron job, or a Windows service). That Python
> recognizes the terminal encoding is primarily a convenience feature for
> the interactive mode.
>
> Exposing sys.setdefaultencoding is not implementable in a reasonable way.
>
> --
> nosy: +loewis
>
> ___
> Python tracker 
> 
> ___
>
>
>
>

--

___
Python tracker 

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

[issue6832] Outputting unicode crushes when printing to file on Linux

[Martin v . Löwis]

Martin v. Löwis  added the comment:

If you want to switch to a different language, consider switching to
Python 3. There, all strings are Unicode strings, and files opened in
text mode always use the locale encoding.

--

___
Python tracker 

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

[issue6582] test_telnetlib doesn't test Telnet.write

[Jack Diederich]

Jack Diederich  added the comment:

applied in r74638
and I've added you to Misc/ACKS
Thanks again for the patch!

--
resolution:  -> accepted
status: open -> closed

___
Python tracker 

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

[issue6748] test test_telnetlib failed

[Jack Diederich]

Jack Diederich  added the comment:

I think this is fixed by r74638 but it never triggered on my box (Ubuntu
9.x) so I can't be sure.  What distro are you using?

--
assignee:  -> jackdied
nosy: +jackdied

___
Python tracker 

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

[issue6582] test_telnetlib doesn't test Telnet.write

[Rodrigo Steinmuller Wanderley]

Rodrigo Steinmuller Wanderley  added the comment:

On Thu, 03 Sep 2009 20:38:49 +
Jack Diederich  wrote:

> 
> Jack Diederich  added the comment:
> 
> applied in r74638
> and I've added you to Misc/ACKS
> Thanks again for the patch!

No problem,

Anything I can do to improve telnetlib further?

I'm currently with plenty of time available and would appreciate the
opportunity to learn more Python.

Rodrigo

> --
> resolution:  -> accepted
> status: open -> closed
> 
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

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

[issue6806] test_platform fails under Snow Leopard

[Brett Cannon]

Brett Cannon  added the comment:

Got a fix, about to start applying it.

--

___
Python tracker 

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

[issue6748] test test_telnetlib failed

[Thomas Kowaliczek]

Thomas Kowaliczek  added the comment:

Fedora 11 64 Bit

--

___
Python tracker 

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

[issue6806] test_platform fails under Snow Leopard

[Brett Cannon]

Brett Cannon  added the comment:

2.7: 74640
3.2: 74641
3.1: 74642

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

___
Python tracker 

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

[issue6823] time.strftime does unnecessary range check

[Brett Cannon]

Brett Cannon  added the comment:

Ugh, damn platforms and having to be different. =)

Normalization is the best solution as Python's docs says the expected 
value for the tm_dst field is -1, 0, or 1 (which is why I added the 
check).

--
keywords: +easy
priority:  -> low
stage:  -> test needed

___
Python tracker 

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

[issue2649] poss. patch for fnmatch.py to add {.htm, html} style globbing

[Tim Hatch]

Tim Hatch  added the comment:

More discussion has gone on in issue #4573 on this topic.  Can this bug
be marked as a duplicate?

--
nosy: +thatch

___
Python tracker 

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

[issue6824] help for a module should list supported platforms

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

I'm not sure to understand. The web page says the module "works on all 
supported platforms." Many python features works equally well on all 
platforms, and I don't feel necessary to repeat this everywhere.
The differences between platforms are more interesting IMO.

--
nosy: +amaury.forgeotdarc

___
Python tracker 

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

[issue5329] os.popen2 and os.popen3 in python 2.6 incompatible with os.popen* in python 2.5

[Philip Jenvey]

Philip Jenvey  added the comment:

The subprocess docs (in Doc/library/subprocess.rst and the module itself) 
need to also reflect this change

--
nosy: +pjenvey

___
Python tracker 

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

[issue5329] os.popen2 and os.popen3 in python 2.6 incompatible with os.popen* in python 2.5

[Jean-Paul Calderone]

Jean-Paul Calderone  added the comment:

Hey Philip,

I'm not sure I follow.  The patch only changes the os module, not the
subprocess module.  What subprocess documentation do you think needs to
be updated?

--

___
Python tracker 

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

[issue5329] os.popen2 and os.popen3 in python 2.6 incompatible with os.popen* in python 2.5

[Philip Jenvey]

Philip Jenvey  added the comment:

Sorry, I meant the docs describing how to convert os.popen* calls to 
subprocess calls. They assume the shell arg is always True regardless of 
the cmd arg type. Those docs are probably the original source of this bug

--

___
Python tracker 

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

[issue6832] Outputting unicode crushes when printing to file on Linux

[Jerzy]

Jerzy  added the comment:

good point!

I will give it a try

Jerzy

Martin v. Löwis wrote:
> Martin v. Löwis  added the comment:
>
> If you want to switch to a different language, consider switching to
> Python 3. There, all strings are Unicode strings, and files opened in
> text mode always use the locale encoding.
>
> --
>
> ___
> Python tracker 
> 
> ___
>
>
>
>

--

___
Python tracker 

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

[issue6824] help for a module should list supported platforms

[Ritesh Raj Sarraf]

Ritesh Raj Sarraf  added the comment:

Take "help os" or "help os.fork" for example.

WIth the help output that they provide, how am I supposed to know that
os.fork is only supported on Unix.

We can also go with the assumption that the modules shipped are
cross-platform. But then, for those that aren't, I don't think we mention
that in the help file documentation.

--

___
Python tracker 

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

[issue6834] use different mechanism for pythonw on osx

[Ronald Oussoren]

Ronald Oussoren  added the comment:

Let me first explain in more detail why pythonw is needed in the first 
place: MacOSX only allows access to a large number of GUI-related APIs 
from application bundles (the symbols are of course always available, 
but the APIs fail when you are calling them from an executable that is 
not in an application bundle)

This is why we introduced pythonw in framework builds of Python. Pythonw 
is a small executable that does nothing else but execv the real python 
interpreter that is in and .app bundle inside the Python framework 
(Python.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/Pytho
n). The full path to the execv-ed interpreter is hardcoded into the 
pythonw executable.

To be able to switch between 32-bit and 64-bit versions of Python a 4-
way universal build of Python creates 3 variations of the Python 
executable inside the .app bundle: Python-32, Python-64 and Python (the 
latter being 4-way universal).  There are also 3 variations of the 
pythonw executable (such as pythonw-32) that execv the proper version of 
the interpreter.

Using posix_spawn and the other API's I mention it should be fairly easy 
to create a simpler situation where we need only one copy of Python in 
the .app bundle, with the pythonw wrapper selecting the required 
architecture(s) before executing the real interpreter.

Making pythonw fully reusable by virtualenv requires some more work, and 
requires more support code in virtualenv itself as well. One fairly easy 
way to accomplish easy reusability without requiring a C compiler is to 
use a large buffer for storing the path to the real interpreter, 
virtualenv could then patch the executable. 

Another option is to link the pythonw executable to Python.framework and 
then use dyld APIs to find the path to the Python framework and from 
that the executable.

As an aside, virtualenv copies the shared library in Python.framework 
into virtual environments, this is needed because the framework build 
uses the location of that shared library to determine sys.prefix.

--

___
Python tracker 

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

[issue2649] poss. patch for fnmatch.py to add {.htm, html} style globbing

[Georg Brandl]

Georg Brandl  added the comment:

Yes, I think that's fine.

--
nosy: +georg.brandl
resolution:  -> duplicate
status: open -> closed
superseder:  -> zsh-style subpattern matching for fnmatch/glob

___
Python tracker 

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

[issue2666] webbrowser.py doesn't properly handle BROWSER env var

[Georg Brandl]

Georg Brandl  added the comment:

Thanks, applied in r74643.

--
nosy: +georg.brandl
resolution:  -> accepted
status: open -> closed

___
Python tracker 

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

[issue5639] Support TLS SNI extension in ssl module

[Daniel Black]

Daniel Black  added the comment:

Hey Phil,
> (Sorry for dropping this, lost available time)
know the feeling :-(

> use of SNI needs to be something that can be disabled
maybe. See small rational below:

> and people need to be able to connect to host A while supplying host B
This seems to be a fringe case for usage and I seem to thing adding this
would overly complicate the API. When testing hosts you would have all
the names in DNS I'd assume.

> Unless s.connect() gains a keep_original_hostname=False option (?),
this is hard to do.
Is this starting to look too complicated?

Options for client side SNI:
1. wrapssl() - defaults to SNI enabled on SSL2/TLS1 connections (compile
time/module level/object variable disable if really needed?)
2. wrapssl(server_hostname=True/False) - enable SNI using the connect
hostname (if domainname and not IP/socket)
3. wrapssl(server_hostname=True/False/String) - True - enable SNI as
above, False/None- don't use SNI or use hostname if a String.
4. wrapssl(server-hostname=String)
5. connect() should an override_server_hostname=False
more?

> Then there's the principle of least surprise -- while it would be nice
to get SNI working automatically for everyone, it's still plausible that
amongst the various TLS servers out there are some which break horribly
for SNI and upgrading Python shouldn't break the tools in use.

Small rational to enable SNI by default:
1. SNI probably won't break too much stuff.
It was only in July 2009 that Apache-2.2.12 got officially released with
proper SNI support. Patches existed before then however deployment was
limited. mod_gnutls did implemented this earlier however I never thought
this was widely used.
Vista IE7 got SNI support in ~2005
(http://blogs.msdn.com/ie/archive/2005/10/22/483795.aspx)
FF got SNI support in the 2.0 release (October 24, 2006, wikipedia) 
(https://bugzilla.mozilla.org/show_bug.cgi?id=116169#c26)
The OpenSSL server side API for SNI required the registration of a
callback to receive the SNI name. It is possible that there are some
faulty implementations in this part of the server code. The default case
that a TLS server doesn't account for SNI is very safe as it won't ever
get a callback for it.
The existence of wide spread client side support with limited server
support hasn't broken the web.

> So I tend towards favouring "make use of the newer, less well tested, 
protocol feature something that has to be explicitly enabled", even if 
it adds a line to boilerplate -- if SNI ever takes over the world (as 
Host: headers in HTTP have) then it can be defaulted on in future 
perhaps?

2. I think with p3k there is an opportunity to put something in that may
break stuff. The release noted didn't guarantee stuff would work compatibly.

3. supporting SNI clients by default may actually break less stuff that
not supporting SNI client. e.g. Webhosting companies may embrace the SNI
features of Apache for maximum IP utilization breaking the non-SNI aware
clients (which won't be the majority of web browsers).

> With checking for an IP address?
To be RFC compliant IP addresses shouldn't be used in SNI. Apart from
socket family checking (AF_INET/AF_INET6) and doing a regex on the name
I couldn't see an easy way to do this even looking at the low level
socketmodule.c file. Maybe I need to look deeper. I could cheat and look
at the Firefox crypto (NSS) code though.

just my current thoughts

--

___
Python tracker 

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