[issue1740] use unittest for test_logging

[Thomas Herve]

Thomas Herve added the comment:

I have just one comment: I have recently modified the initialization of
LogRecordSocketReceiver to not use a stupid loop to get a free port, but
instead use port 0 and get the port number once bound. I think this
modification should stay.

--
nosy: +therve

__
Tracker <[EMAIL PROTECTED]>

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

[issue1152248] Enhance file.readlines by making line separator selectable

[Raymond Hettinger]

Raymond Hettinger added the comment:

For the record, I thought it was a reasonable request.

AWK has a similar feature.  The AWK book shows a number of example 
uses.  Google's codesearch shows that the feature does get used in the 
field:  http://www.google.com/codesearch?q=lang%3Aawk+RS&hl=en

I think this request should probably be kept open.

--
resolution: rejected -> 
status: closed -> open

_
Tracker <[EMAIL PROTECTED]>

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

[issue1152248] Enhance file.readlines by making line separator selectable

[Facundo Batista]

Facundo Batista added the comment:

Sorry, I misunderstood you. I assign this to myself to give it a try.

--
assignee:  -> facundobatista

_
Tracker <[EMAIL PROTECTED]>

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

[issue1170] shlex have problems with parsing unicode

[Matej Cepl]

Changes by Matej Cepl:


--
nosy: +mcepl

__
Tracker <[EMAIL PROTECTED]>

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

[issue1740] use unittest for test_logging

[Christian Heimes]

Christian Heimes added the comment:

Thomas Herve wrote:
> I have just one comment: I have recently modified the initialization of
> LogRecordSocketReceiver to not use a stupid loop to get a free port, but
> instead use port 0 and get the port number once bound. I think this
> modification should stay.

Most likely the student, who submitted the patch during the GHOP
contest, didn't know about the feature. ;) But yeah, the mod should stay
indeed.

Christian

__
Tracker <[EMAIL PROTECTED]>

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

[issue2195] urlparse() does not handle URLs with port numbers properly

[Χρήστος Γεωργίου (Christos Georgiou)]

Χρήστος Γεωργίου (Christos Georgiou) added the comment:

RFC1808 §2.1 suggests a generic RL syntax that specifies '://' as the
separator, so Gawain's suggestion makes practical sense. However, also
as Gawain says, the RFC specifies that '//' is considered as the first
part of a "net_path" and is not necessarily included (example:
"mailto:[EMAIL PROTECTED]" (and yes, I actually welcome spammers :) ).

I believe that urlparse should stay as-is when not called with a
default_scheme argument, and fixed as-suggested when called with a
default_scheme argument (that's the point for providing default_scheme).

--
nosy: +tzot

__
Tracker <[EMAIL PROTECTED]>

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

[issue2197] Further simplify dict literal bytecode

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

I did not think of the insertion after creation change of semantics.  Do 
I understand that this is important when keys have custom 
comparison/hash methods with side-effects.  If it is important for the 
language to guarantee the create/insert order in building dict literals, 
it would be unfortunate if that order were specified differently for 
dict and set literals.

I will think some more about the stack issue.  There is a valid argument 
that large dict literals will be more common than large set literals, so 
the stack issue is more important for dicts.

BTW, what is the status of making set literal a frozen set proposal?

__
Tracker <[EMAIL PROTECTED]>

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

[issue2195] urlparse() does not handle URLs with port numbers properly

[Senthil]

Senthil added the comment:

I don't think this is a valid issue. If you browse through the RFC 1808
you will find that.
1) For net_loc information it refers to a broad section 1738 and we wont
specifically find any information on port number in that.
2) But, have a look at the BNF Representation of the net_loc

net_loc =  *( pchar | ";" | "?" )
pchar   = uchar | ":" | "@" | "&" | "="

There it dismisses this issue.

The port number is a property of the scheme in the absolute URL
notation. so, urlparse.urlparse('foo.bar.com',8088).scheme would give
you the port.

If someone can validate my reasoning, then we can close this issue.

--
nosy: +orsenthil

__
Tracker <[EMAIL PROTECTED]>

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

[issue2181] optimize out local variables at end of function

[Armin Rigo]

Armin Rigo added the comment:

I suppose you are aware that performing this optimization in general
would break a lot of existing code that uses inspect.getstack() or
sys._getframe() to peek at the caller's local variables.  I know this
because it's one thing that Psyco doesn't do correctly, and one of the
most common causes I'm aware of for a random existing program to break
under Psyco.

--
nosy: +arigo

__
Tracker <[EMAIL PROTECTED]>

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

[issue2181] optimize out local variables at end of function

[Neal Norwitz]

Neal Norwitz added the comment:

>  I suppose you are aware that performing this optimization in general
>  would break a lot of existing code that uses inspect.getstack() or
>  sys._getframe() to peek at the caller's local variables.  I know this

Yes, with this optimization the variable might never be set or when
the function exits, the value would be set to the previous value.

Note that the current optimization only works just before a return and
only for local variables.  It doesn't generally optimize out
variables, although that would be a good next step.

>  because it's one thing that Psyco doesn't do correctly, and one of the
>  most common causes I'm aware of for a random existing program to break
>  under Psyco.

How often does this cause problems?  Do you view this as psyco's
problem or broken user code?

I don't view this any different that a C compiler optimizing out
variables.  It can make debugging harder since the symbols no longer
exist.  In this case the variable name is not removed from the
co_varnames even if it is the only reference.  That would also be
nice, but left for another patch.  Since this will only be used with
-O and is currently limited, this seems reasonable to me.  But I would
like to know if others disagree.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2193] Cookie Colon Name Bug

[Jerry Seutter]

Jerry Seutter added the comment:

Heh, I think I should not have gotten involved in this bug. :)  I have a
few comments:

In response to 2.: David M. Kristol in that article is referring to the
original Netscape cookie implementation which is somewhat different from
what is set out in the RFC's.   Now I understand where the difference is.

In response to 6: Yes, I was referring to the NAME part of NAME=VALUE...


So it looks to me like the Python code implements the specification as
set out in the RFC.  I agree with you that there are multiple
implementations (Java and Perl) in wide use that allow behavior not set
out in the RFC.  The question is, do we want to stick the bahavior in
the RFC, or accomodate existing implementations?  My opinion:  I agree
with you.

Can some Python regulars comment on Python's policy in situations like this?

I can throw together a patch if this change would likely be accepted.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2193] Cookie Colon Name Bug

[Jerry Seutter]

Changes by Jerry Seutter:


--
type:  -> behavior

__
Tracker <[EMAIL PROTECTED]>

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

[issue2157] sqlite numeric type conversion problems

[Gerhard Häring]

Gerhard Häring added the comment:

The same question came up in the external pysqlite project once. My
answer is the same here: this won't be fixed because of backwards
compatibility reasons. The current behaviour is well documented.

I acknowledge that it would be nice to be able to use declaratos like
number(x,y) used with other databases and reuse them with SQLite and
pysqlite. But we can't implement your feature request with 100 %
backwards compatibility.

--
assignee:  -> ghaering
keywords: +patch
nosy: +ghaering
resolution:  -> wont fix
status: open -> closed
type:  -> feature request

__
Tracker <[EMAIL PROTECTED]>

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

[issue1546263] Segfaults with concurrent sqlite db access and schema change

[Gerhard Häring]

Gerhard Häring added the comment:

See http://initd.org/tracker/pysqlite/ticket/170 and
http://initd.org/tracker/pysqlite/changeset/301

_
Tracker <[EMAIL PROTECTED]>

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

[issue2127] sqlite3 docs should mention utf8 requirement

[Gerhard Häring]

Changes by Gerhard Häring:


--
nosy: +ghaering

__
Tracker <[EMAIL PROTECTED]>

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

[issue2127] sqlite3 docs should mention utf8 requirement

[Gerhard Häring]

Gerhard Häring added the comment:

I'll assign this one to me. The "sqlite3" module cannot be just
"refreshed" with the externally maintained pysqlite, I'll have to do
merging anyway. Don't worry here ;-)

--
assignee:  -> ghaering
keywords: +easy
priority:  -> low
severity: normal -> minor
type:  -> feature request

__
Tracker <[EMAIL PROTECTED]>

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

[issue2152] make sqlite.Row hashable correctly

[Gerhard Häring]

Changes by Gerhard Häring:


--
assignee:  -> ghaering
nosy: +ghaering
priority:  -> normal

__
Tracker <[EMAIL PROTECTED]>

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

[issue2157] sqlite numeric type conversion problems

[wrobell]

wrobell added the comment:

fair enough, but...

1. i really do not see that behaviour documented, i.e.

   http://docs.python.org/lib/node347.html

   says nothing about types being broken on space character.

2. i am bit missing the point about backward compability.
   when looking on internet for a reason why types like
   "numeric(10, 2)" are not being converted (please note
   that "numeric (10, 2)" works, the difference is just one
   space), then i found no explanation of such behaviour,
   no single line of code trying to register conversion
   of "numeric(10,)" or similar.

   even more. if somebody has declaration like

  register_converter("numeric(10,", Decimal)

   then i can bet that he has also

  register_converter("numeric", Decimal)

   i doubt that my patch is breaking anybody's code, as no one
   is going to register "numeric(10," without registering "numeric".

__
Tracker <[EMAIL PROTECTED]>

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

[issue2157] sqlite numeric type conversion problems

[Gerhard Häring]

Gerhard Häring added the comment:

It's mentioned here: http://docs.python.org/lib/sqlite3-Module-Contents.html

__
Tracker <[EMAIL PROTECTED]>

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

[issue2157] sqlite numeric type conversion problems

[Gerhard Häring]

Gerhard Häring added the comment:

Yes, I acknowledge the backwards incompatibility is rather a one in a
billion case than a one in a million case.

I'll reopen this one and integrate your patch or something similar for
Python 2.6 and 3.0.

--
resolution: wont fix -> 
status: closed -> open

__
Tracker <[EMAIL PROTECTED]>

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

[issue2183] optimize list comprehensions

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

The patch looks reasonable to me. Bytecode docs need to be changed.  At 
minimum like this:
===
--- Doc/library/dis.rst (revision 61097)
+++ Doc/library/dis.rst (working copy)
@@ -463,9 +463,9 @@
address to jump to (which should be a ``FOR_ITER`` instruction).
 
 
-.. opcode:: LIST_APPEND ()
+.. opcode:: LIST_APPEND (i)
 
-   Calls ``list.append(TOS1, TOS)``.  Used to implement list 
comprehensions.
+   Calls ``list.append(TOS[-i], TOS)``.  Used to implement list 
comprehensions.
 
 
 .. opcode:: LOAD_LOCALS ()


More explanation on TOS being removed while TOS[-i] (obviously) not may 
be in order.

For py3k similar optimization should be available for dict and set 
comprehensions.

More unit tests will be helpful, particularly for nested iterations such 
as [(x,y,z) for x in s for y in s for z in s].

--
nosy: +belopolsky

__
Tracker <[EMAIL PROTECTED]>

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

[issue2198] code_hash() can be the same for different code objects

[Stephan R.A. Deibel]

New submission from Stephan R.A. Deibel:

The algorithm in code_hash() in codeobject.c can return the same hash
value for different code objects.  

Presumably distinct code objects should be very unlikely to have the
same hash value.  This bug affected our debugger before we worked around
it, and it could affect other things like profilers.

Adding the co_filename to the hash would be one way to fix this but I'm
not sure if that was purposely avoided in this code?

--
components: Interpreter Core
files: code_hash_bug.tgz
messages: 63083
nosy: sdeibel
severity: normal
status: open
title: code_hash() can be the same for different code objects
type: behavior
versions: Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, 
Python 2.2.3, Python 2.3, Python 2.4, Python 2.5
Added file: http://bugs.python.org/file9565/code_hash_bug.tgz

__
Tracker <[EMAIL PROTECTED]>

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

[issue2198] code_hash() can be the same for different code objects

[Stephan R.A. Deibel]

Stephan R.A. Deibel added the comment:

I should have noted that adding co_firstlineno as well to the hash would
be necessary to distinguish like code objects within the same file.  The
example has them on the same lines in different files but changing the
first line of the defs doesn't matter.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2185] code objects should conserve memory

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

Since names and varnames are known to be tuples of interned strings, 
they can be compared without calling abstract API. Just compare sizes 
and then compare item pointers in a loop.

What are the cases when co_names == co_varnames?  How often is this the 
case in the wild?

--
nosy: +belopolsky

__
Tracker <[EMAIL PROTECTED]>

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

[issue2193] Cookie Colon Name Bug

[BM]

BM added the comment:

Well, as D.M.Kristol says: there are no any standard for this particular 
topic. And RFC is not any standard but a request for comments...

Personally I've been added a colon in Cookie.py for let Trac and other 
Python-based software stop crashing, because such sort of cookies are quite 
often appears. For some reason people treat a colon as a namespace separator, 
like in XML. Thus there are plenty of cookies like "section:key=value" you 
can meet quite often. But this is not a fix, but just quick local fix.

You also can find a lots of cookies that consists "[" and "]", slash, 
even a space that has been quoted as "%20", which means a "%" inside the
token -- just look what godaddy.com gives to you. :-)

So I see another problem here: there is not just a colon thing, but
implementation should be slightly different. Currently Python code
lists allowed chars. I am not sure it is correct way to implement.
Rather I would list disallowed chars (see example in Java).

Here is also an example how Ruby does the thing 
(see lib/webrick/cookie.rb):
--
def self.parse(str)
  if str
ret = []
cookie = nil
ver = 0
str.split(/[;,]\s+/).each{|x|  # <--- Here you go.
  key, val = x.split(/=/,2)
  val = val ? HTTPUtils::dequote(val) : ""
  case key
  when "$Version"; ver = val.to_i
  when "$Path";cookie.path = val
  when "$Domain";  cookie.domain = val
  when "$Port";cookie.port = val
  else
ret << cookie if cookie
cookie = self.new(key, val)
cookie.version = ver
  end
}
ret << cookie if cookie
ret
  end
end
--

I still have doubts that Cookie NAME is the same token, because
specs still disallows only comma, semi-colon and a space. Well, 
I don't know, but we can either stick to Request For Comments or 
we can behave as the rest of the world, avoiding future interference.

Would be nice to hear some comments on policies... Tim?

--
nosy: +tim_one

__
Tracker <[EMAIL PROTECTED]>

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

[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.

[Mark Dickinson]

Mark Dickinson added the comment:

I'm wondering what there is left to do here.  Are we close to being able 
to close this issue?  Some thoughts:

(1) I think the docs could use a little work (just expanding, and giving 
a few examples).  But it doesn't seem urgent that this gets done before 
the next round of alphas.

(2) Looking at it, I'm really not sure that implementing 
Rational.__format__ is worthwhile;  it's not obvious that we need a way
to format a Rational as a float.  So I'm -0 on this.  If others think 
Rational should have a __format__ method I'm still happy to implement 
it.

Is there much else that needs to be done here?

__
Tracker <[EMAIL PROTECTED]>

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

[issue1762] Inheriting from ABCs makes classes slower.

[Jeffrey Yasskin]

Jeffrey Yasskin added the comment:

Since there were no comments, I submitted the patch as r61098. I think
we're done here. :)

--
resolution:  -> fixed
status: open -> closed
type:  -> behavior
versions: +Python 2.6

__
Tracker <[EMAIL PROTECTED]>

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

[issue2184] Speed up Thread.start()

[Jeffrey Yasskin]

Jeffrey Yasskin added the comment:

Submitted as r61100.

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

__
Tracker <[EMAIL PROTECTED]>

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