[issue3264] Use -lcrypto instead of -lcrypt on Solaris 2.6 when available

[Martin Mokrejs]

Martin Mokrejs <[EMAIL PROTECTED]> added the comment:

Could it be the name clashing problem between -lcrypt and -lcrypto?

bash-3.00# ar x /usr/lib/libcrypt.a;nm -g des_crypt.o
 U ___errno
033c T _des_crypt
0274 T _des_encrypt
 U _des_encrypt1
01b0 T _des_setkey
 U _mutex_lock
 U _mutex_unlock
 U _thr_getspecific
 U _thr_keycreate
 U _thr_setspecific
033c W des_crypt
0274 W des_encrypt
01b0 W des_setkey
 U free
 U malloc
bash-3.00# ar x /usr/local/lib/libcrypto.a;nm -g des_crypt.o
 U ___errno
033c T _des_crypt
0274 T _des_encrypt
 U _des_encrypt1
01b0 T _des_setkey
 U _mutex_lock
 U _mutex_unlock
 U _thr_getspecific
 U _thr_keycreate
 U _thr_setspecific
033c W des_crypt
0274 W des_encrypt
01b0 W des_setkey
 U free
 U malloc
bash-3.00#

There used to be name clashes between -lcrypt from KTH-KRB/HEIMDAL
with those from openssl -lcrypto in the past. I think that was
"fixed" around/in openssl-2.7 and heimdal-1.0. The clashes caused
openssh dying when compiled with kerberos4 support because the
functions of same names expected in some way different data.
I am sure you would Goggle it out.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3264] Use -lcrypto instead of -lcrypt on Solaris 2.6 when available

[Martin v. Löwis]

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

No. We are not linking with libcrypto at all, so there can't be clashes.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3264] Use -lcrypto instead of -lcrypt on Solaris 2.6 when available

[Martin Mokrejs]

Martin Mokrejs <[EMAIL PROTECTED]> added the comment:

You say "did always work"?

http://mail.python.org/pipermail/python-list/2002-December/177479.html

Maybe the reason why in ruby they forced to -shared flag
because it was possible to link only with the shared library?
I do not know from which package to get the shared version. :(
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-list/33517

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3088] test_multiprocessing hangs on OS X 10.5.3

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

The two tracebacks provided by Mark seem to correspond to the following
python stack (innermost last):

Lib/test/test_multiprocessing.py, line 1005, in _test_map_unordered
self.assertEqual(sorted(it), map(sqr, range(1000)))
Lib/multiprocessing/pool.py, line 500, in IMapIterator.next()
self._cond.acquire()
Lib/threading.py, line 123, in _RLock.acquire():
rc = self.__block.acquire(blocking)

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3088] test_multiprocessing hangs on OS X 10.5.3

[Ismail Donmez]

Ismail Donmez <[EMAIL PROTECTED]> added the comment:

The test hanged for me at first try but worked fine on the second test,
weird.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3264] Use -lcrypto instead of -lcrypt on Solaris 2.6 when available

[Martin v. Löwis]

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

Ah, ok. I completely missed the point of the error message (i.e.
"relocations remain"), and misinterpreted it as missing symbols.

So I still recommend doing what I recommended back then: Uncomment the
line in Modules/Setup to build the crypt module on Solaris 2.6. That
should still work as it always did.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3264] Use -lcrypto instead of -lcrypt on Solaris 2.6 when available

[Martin Mokrejs]

Martin Mokrejs <[EMAIL PROTECTED]> added the comment:

Confirming the enabling line 216 like below helped. Thanks. Maybe change
"Resolution"?

204 # Socket module helper for SSL support; you must comment out the
other
205 # socket line above, and possibly edit the SSL variable:
206 #SSL=/usr/local/ssl
207 #_ssl _ssl.c \
208 #   -DUSE_SSL -I$(SSL)/include -I$(SSL)/include/openssl \
209 #   -L$(SSL)/lib -lssl -lcrypto
210 
211 # The crypt module is now disabled by default because it breaks
builds
212 # on many systems (where -lcrypt is needed), e.g. Linux (I believe).
213 #
214 # First, look at Setup.config; configure may have set this for you.
215 
216 crypt cryptmodule.c # -lcrypt   # crypt(3); needs -lcrypt on
some systems

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3088] test_multiprocessing hangs on OS X 10.5.3

[Paul Melis]

Paul Melis <[EMAIL PROTECTED]> added the comment:

On a Linux system (FC4) with r64686 of the Py3k branch I also still get
occassional hangs (with ./python -E -bb ./Lib/test/regrtest.py -v
test_multiprocessing). Mostly this seems to occur with the very first
test executed, i.e. before any of the "test_... " lines have been generated.

The following may or may not be related. Some time ago I decided to give
valgrind a try to see if it could detect anything strange going on with
the multiprocessing tests, specifically using the 'helgrind'
thread-debugging tool that comes with it. 

Valgrind reports as its first error:

==9719== Thread #1: Bug in libpthread: sem_wait succeeded on semaphore
without prior sem_post
==9719==at 0x4007FFF: sem_wait_WRK (hg_intercepts.c:1057)
==9719==by 0x4008094: [EMAIL PROTECTED] (hg_intercepts.c:1073)
==9719==by 0x46A0087: semlock_acquire (semaphore.c:310)
==9719==by 0x808C121: PyEval_EvalFrameEx (ceval.c:3371)
==9719==by 0x808D0FE: PyEval_EvalCodeEx (ceval.c:2808)
==9719==by 0x808B9D0: PyEval_EvalFrameEx (ceval.c:3469)
==9719==by 0x808D0FE: PyEval_EvalCodeEx (ceval.c:2808)
==9719==by 0x80F4B65: function_call (funcobject.c:628)
==9719==by 0x80D1207: PyObject_Call (abstract.c:2178)
==9719==by 0x80890EC: PyEval_EvalFrameEx (ceval.c:3672)
==9719==by 0x808C1A9: PyEval_EvalFrameEx (ceval.c:3459)
==9719==by 0x808C1A9: PyEval_EvalFrameEx (ceval.c:3459)
==9716== Thread #1 is the program's root thread

I've been hesitant to report this as the claim that libpthread is broken
is pretty bold. I contacted the valgrind devs about this, see [1]. 
More recently, someone on the valgrind list reported problems that do
seem to indicate there are broken libpthreads out there (see [2]), as
this individual reports a semaphore wait not blocking where it should.

Could it be that the multiprocessing tests are exposing one or more bugs
in libpthread?

[1] http://thread.gmane.org/gmane.comp.debugging.valgrind/8345
[2] http://thread.gmane.org/gmane.comp.debugging.valgrind/8384

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1322] platform.dist() has unpredictable result under Linux

[Marc-Andre Lemburg]

Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:

Please see the top of platform.py:

#This module is maintained by Marc-Andre Lemburg <[EMAIL PROTECTED]>.
#If you find problems, please submit bug reports/patches via the
#Python SourceForge Project Page and assign them to "lemburg".
#
#Note: Please keep this module compatible to Python 1.5.2.

I wonder why the ticket wasn't assigned to me.

Regarding the patch: 

 * the dist() function has been superseded by linux_distribution().

 * the supported_dists argument is a documented feature of
linux_distributions(), so should not be removed

 * the Windows name normalization should not be removed (it fixes a bug
in Vista)

 * the change from using string functions to using string methods breaks
1.5.2 compatibility (*)

 * the _ETC_DIR global just makes things harder to read and there's no
apparent need for it

(*) It's probably time to drop 1.5.2 compatibility and only keep the
module compatible to Python 2.1, so this is not much of an issue.

Overall, I think it's better to define a fixed search order for the
release files than to try to figure out and parse random release files
that happen to match the release file RE.

For that to work, it would help a lot if you could provide the file name
and contents of various platform release files.

--
assignee: christian.heimes -> lemburg
nosy: +lemburg

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1322] platform.dist() has unpredictable result under Linux

[Marc-Andre Lemburg]

Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:

Also note that linux_distribution() will use the parsed distro name from
the release file per default (full_distribution_name=1), so the problem
described in the original ticket description should no longer be
relevant: all release files point to the same lsb-release file in the end.

I don't have access to Mandriva. Could you please let me know whether
the current SVN version of platform.py still exhibits the mentioned
problem ?

Thanks.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3088] test_multiprocessing hangs on OS X 10.5.3

[Mark Dickinson]

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

> Are you sure that's right?  That traceback has no mention of
> PyObject_Malloc or obmalloc.c.

So now I think that the traceback was right.  There was no mention of 
PyObject_Malloc or obmalloc.c because the traceback only showed 1 of the 9 
threads, and the failed assert occurred in a different thread.

I've attached another traceback, showing all the threads, and applying 'tb 
full' to the relevant thread.  (This was from a different run, but with 
the same failed assertion at line 746 of Objects/obmalloc.c.)

Added file: http://bugs.python.org/file10800/multithread_traceback.txt

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3249] bug adding datetime.timedelta to datetime.date

[Chris Withers]

Chris Withers <[EMAIL PROTECTED]> added the comment:

This may be "as documented" but it's *extremely* counter intuitive and
seems to go against the grain of where python is headed.

(remember that whole struggle to get 3/2 = 1.5 rather 3/2=1? ;-) )

I've changed the "type" to "feature request", what's the best mailing
list to kick off discussion about this?

--
type:  -> feature request

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2235] __eq__ / __hash__ check doesn't take inheritance into account

[Nick Coghlan]

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

As far as deque goes, the following behaviour on the trunk is the
problem I am trying to fix:

Python 2.6b1+ (trunk:64655, Jul  2 2008, 22:48:24)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from collections import deque, Hashable
>>> isinstance(deque(), Hashable)
True

All of the container types that my patch touches were already unhashable
in 2.5 - my patch just ensures that they all correctly return false for
isinstance(obj, collections.Hashable) even after we make object.__hash__
inherited by default again. This is also the reason why simply reverting
the trunk hash implementation to the 2.5 behaviour (which is what I
first tried) is inadequate.

Since collections.Hashable is new in 2.6, I can live with it returning
the wrong answer for types which define __hash__ to always raise an
error (that's a known limitation of the ABC system, even in Py3k).
However, we should at least make sure it returns the correct answer for
all of the types in the standard library.

--
assignee:  -> ncoghlan

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3249] bug adding datetime.timedelta to datetime.date

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

To be valid, your analogy between dates and numbers suggests that a date
should be convertible to the datetime with the same date, at midnight.
And both objects compare equal, just like 42==42.0

But today this is not the case: it's hard to convert a date into a
datetime, and types cannot be ordered:
>>> datetime.date.today() < datetime.datetime.now()
TypeError: can't compare datetime.datetime to datetime.date

--
nosy: +amaury.forgeotdarc

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3269] strptime() makes an error concerning second in arg

[Neven Goršić]

New submission from Neven Goršić <[EMAIL PROTECTED]>:

strptime() allows 60 and 61 sec, but not 62 sec in arg. string 

>>> s='02/28/2000 12:33:61 AM'
>>> time.strptime(s,'%m/%d/%Y %I:%M:%S %p')
(2000, 2, 28, 0, 33, 61, 0, 59, -1)

>>> s='02/28/2000 12:33:62 AM'
>>> time.strptime(s,'%m/%d/%Y %I:%M:%S %p')

Traceback (most recent call last):
  File "", line 1, in 
time.strptime(s,'%m/%d/%Y %I:%M:%S %p')
  File "C:\Python25\lib\_strptime.py", line 330, in strptime
(data_string, format))
ValueError: time data did not match format:  data=02/28/2000 12:33:62 AM
 fmt=%m/%d/%Y %I:%M:%S %p

--
components: None
messages: 69192
nosy: nevgor
severity: normal
status: open
title: strptime() makes an error concerning second in arg
type: compile error
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

[issue1622] zipfile hangs on certain zip files

[Martin v. Löwis]

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

Thanks for the patch. This is now committed as r64688

--
resolution:  -> accepted
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

[issue1526] DeprecationWarning in zipfile.py while zipping 113000 files

[Martin v. Löwis]

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

The patch for issue1622 was committed as r64688; closing this patch as
outdated.

--
nosy: +loewis
resolution:  -> out of date
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

[issue3267] yield in list comprehensions possibly broken in 3.0

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

This is because list comprehensions are implemented as functions in 3.0
so their scope is not leaked out to the rest of the function.

Here is the bytecode for 2.6:
>>> dis.dis(f)
  2   0 BUILD_LIST   0
  3 DUP_TOP 
  4 STORE_FAST   0 (_[1])
  7 LOAD_CONST   5 ((1, 2, 3))
 10 GET_ITER
>>   11 FOR_ITER14 (to 28)
 14 STORE_FAST   1 (x)
 17 LOAD_FAST0 (_[1])
 20 LOAD_FAST1 (x)
 23 YIELD_VALUE 
 24 LIST_APPEND 
 25 JUMP_ABSOLUTE   11
>>   28 DELETE_FAST  0 (_[1])
 31 STORE_FAST   1 (x)

  3  34 LOAD_CONST   4 (5)
 37 YIELD_VALUE 
 38 POP_TOP 

  4  39 LOAD_FAST1 (x)
 42 YIELD_VALUE 
 43 POP_TOP 
 44 LOAD_CONST   0 (None)
 47 RETURN_VALUE

and here it is for 3.0:
>>> dis.dis(f)
  2   0 LOAD_CONST   1 ( at
0x740770, file "", line 2>) 
  3 MAKE_FUNCTION0 
  6 LOAD_CONST   6 ((1, 2, 3)) 
  9 GET_ITER 
 10 CALL_FUNCTION1 
 13 STORE_FAST   0 (x) 

  3  16 LOAD_CONST   5 (5) 
 19 YIELD_VALUE  
 20 POP_TOP  

  4  21 LOAD_FAST0 (x) 
 24 YIELD_VALUE  
 25 POP_TOP  
 26 LOAD_CONST   0 (None) 
 29 RETURN_VALUE

--
nosy: +benjamin.peterson
type:  -> behavior

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1746] ZIP files with archive comments longer than 4k not recognized as valid by zipfile module

[Martin v. Löwis]

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

The patch in #1622 was committed as r64688.

--
nosy: +loewis
resolution: duplicate -> fixed

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3270] test_multiprocessing: test_listener_client flakiness

[Jesse Noller]

New submission from Jesse Noller <[EMAIL PROTECTED]>:

Per mail thread:
http://mail.python.org/pipermail/python-dev/2008-June/080497.html

Attached is the patch to connection.py to drop the fqdn call.

Final suggestion from Trent:

> This is a common problem.  Binding to '127.0.0.1' will bind to *only*
> that address;

Indeed.

> binding to "" will bind to *all* addresses the machine
> is known by.

Agreed again.  I believe what we're dealing with here though is a lack 
of clarity regarding what role the 'address' attribute exposed by 
multiprocess.connection.Listener should play.  The way 
test_listener_client() is written, it effectively treats 'address' as an 
end-point that can be connected to directly (irrespective of the 
underlying family (i.e. AF_INET, AF_UNIX, AF_PIPE)).

I believe the problems we've run into stem from the fact that the API 
doesn't provide any guarantees as to what 'address' represents.  The 
test suite assumes it always reflects a connectable end-point, which I 
think is more than reasonable.  Unfortunately, nothing stops us from 
breaking this invariant by constructing the object as 
Listener(family='AF_INET', address=('0.0.0.0', 0)).

How do I connect to an AF_INET Listener (i.e. SocketListener) instance 
whose 'address' attribute reports '0.0.0.0' as the host?  I can't.

So, for now, I think we should enforce this invariant by raising an 
exception in Listener.__init__() if self._socket.getsockbyname()[0] 
returns '0.0.0.0'.  In effect, tightening up the API such that we can 
guarantee  Listener.address will always represent a connectable end-
point.  We can look at how to service 'listen on all available 
interfaces' semantics at a later date -- that adds far less value IMO 
than being able to depend on the said guarantee.

--
assignee: jnoller
components: Library (Lib)
files: connection.patch
keywords: patch
messages: 69197
nosy: jnoller, roudkerk
priority: high
severity: normal
status: open
title: test_multiprocessing: test_listener_client flakiness
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10801/connection.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3269] strptime() makes an error concerning second in arg

[Facundo Batista]

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

Minutes with 61 (0..60) and 62 (0..61) seconds are used to adjust the
theoretical calendar because of small differences with real world
rotation... 

Are you aware of any case where a minute with 63 seconds (0..62) should
be used?

--
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

[issue3122] sys.getsizeof() gives an AttributeError for _sre objects.

[Robert Schuppenies]

Robert Schuppenies <[EMAIL PROTECTED]> added the comment:

Amaury,
I was testing your patch and it turns out, that it will ignore
any __sizeof__ attribute which may be available through getattr. I
adapted it a bit, so now getsizeof will try to call the method on the
passed object first, and if it fails or the object is a type, the code
proposed by you will be executed. This also deals with old-style class
instances. The match_sizeof function in the patch is just to showcase
the example. What do you think?

Added file: http://bugs.python.org/file10802/sizeof2.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3258] ctypes assertion failure in trunk

[Kevin Watters]

Changes by Kevin Watters <[EMAIL PROTECTED]>:


--
nosy: +kevinwatters

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3269] strptime() makes an error concerning second in arg

[Neven Goršić]

Neven Goršić <[EMAIL PROTECTED]> added the comment:

Thank you for your reply, although is not helpful for me.

I use strptime() for datedate transformation and datatime boundaries
checking
and therefore I am not conserned in Reltivity theory.

When someone in datetime table enter 02:61:38 it is sign for me to
rise a warning and not to supposed that the gay is astrophysicist :)

-

On Thu, Jul 3, 2008 at 3:19 PM, Facundo Batista <[EMAIL PROTECTED]>
wrote:

>
> Facundo Batista <[EMAIL PROTECTED]> added the comment:
>
> Minutes with 61 (0..60) and 62 (0..61) seconds are used to adjust the
> theoretical calendar because of small differences with real world
> rotation...
>
> Are you aware of any case where a minute with 63 seconds (0..62) should
> be used?
>
> --
> nosy: +facundobatista
>
> ___
> Python tracker <[EMAIL PROTECTED]>
> 
> ___
>

Added file: http://bugs.python.org/file10803/unnamed

___
Python tracker <[EMAIL PROTECTED]>

___Thank you for your reply, although is not helpful for me.I use 
strptime() for datedate transformation and datatime boundaries checkingand 
therefore I am not conserned in Reltivity theory.When someone in 
datetime table enter 02:61:38 it is sign for me to
rise a warning and not to supposed that the gay is astrophysicist 
:)-On Thu, Jul 
3, 2008 at 3:19 PM, Facundo Batista [EMAIL PROTECTED]> wrote:

Facundo Batista [EMAIL 
PROTECTED]> added the comment:

Minutes with 61 (0..60) and 62 (0..61) seconds are used to adjust the
theoretical calendar because of small differences with real world
rotation...

Are you aware of any case where a minute with 63 seconds (0..62) should
be used?

--
nosy: +facundobatista

___
Python tracker [EMAIL 
PROTECTED]>
http://bugs.python.org/issue3269>
___

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

[issue3269] strptime() makes an error concerning second in arg

[Facundo Batista]

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

Closing as invalid, two reasons:

- Your original issue was that time.strptime() didn't allow 62 seconds,
not that it allowed 60 or 61.

- If you use it to validate input... how do you actually know that
03/25/2012 17:13:61 AM' is an invalid date?

I suggest to bring this issue in the python list if you have further doubts.

Thank you!!

--
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

[issue3269] strptime() makes an error concerning second in arg

[Neven Goršić]

Neven Goršić <[EMAIL PROTECTED]> added the comment:

- My original issue was that time.strptime() makes difference between 61 and
62 seconds
- 17h AM, 78 s, 128min everyone can easly transform correctly, I just wanted
to use function for
  boundarie checking: rising error for 62 sec and not for 61 is confusing!
- I just wanted to point out that Python should be consistent: to provide
the same behaviour for 60,61 and 62 sec.

The conclusion is over as far as I am concerned.
I got the picture (you standpoint), and I hope, you too.

Thank you, once again,

Regards

 Neven

--

On Thu, Jul 3, 2008 at 3:49 PM, Facundo Batista <[EMAIL PROTECTED]>
wrote:

>
> Facundo Batista <[EMAIL PROTECTED]> added the comment:
>
> Closing as invalid, two reasons:
>
> - Your original issue was that time.strptime() didn't allow 62 seconds,
> not that it allowed 60 or 61.
>
> - If you use it to validate input... how do you actually know that
> 03/25/2012 17:13:61 AM' is an invalid date?
>
> I suggest to bring this issue in the python list if you have further
> doubts.
>
> Thank you!!
>
> --
> resolution:  -> invalid
> status: open -> closed
>
> ___
> Python tracker <[EMAIL PROTECTED]>
> 
> ___
>

Added file: http://bugs.python.org/file10804/unnamed

___
Python tracker <[EMAIL PROTECTED]>

___- My original issue was that time.strptime() makes difference between 61 and 62 
seconds- 17h AM, 78 s, 128min everyone can easly transform correctly, I 
just wanted to use function for  boundarie checking: rising error for 
62 sec and not for 61 is confusing!
- I just wanted to point out that Python should be consistent: to provide the 
same behaviour for 60,61 and 62 sec.The conclusion is over as far as I 
am concerned.I got the picture (you standpoint), and I hope, you too.
Thank you, once again,Regards 
Neven--On Thu, Jul 
3, 2008 at 3:49 PM, Facundo Batista [EMAIL PROTECTED]> wrote:

Facundo Batista [EMAIL 
PROTECTED]> added the comment:

Closing as invalid, two reasons:

- Your original issue was that time.strptime() didn't allow 62 seconds,
not that it allowed 60 or 61.

- If you use it to validate input... how do you actually know that
03/25/2012 17:13:61 AM' is an invalid date?

I suggest to bring this issue in the python list if you have further doubts.

Thank you!!

--
resolution:  -> invalid
status: open -> closed

___
Python tracker [EMAIL 
PROTECTED]>
http://bugs.python.org/issue3269>
___

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

[issue1555570] email parser incorrectly breaks headers with a CRLF at 8192

[chris.eveleigh]

Changes by chris.eveleigh <[EMAIL PROTECTED]>:


--
nosy: +chris.eveleigh

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1690840] xmlrpclib methods submit call on __str__, __repr__

[Ralf Schmitt]

Ralf Schmitt <[EMAIL PROTECTED]> added the comment:

I think __str__ should also be implemented.
I'm attaching a patch with unittests against current trunk.

--
keywords: +patch
Added file: http://bugs.python.org/file10805/xmlrpc_repr.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1690840] xmlrpclib methods submit call on __str__, __repr__

[Ralf Schmitt]

Ralf Schmitt <[EMAIL PROTECTED]> added the comment:

this is how it looks:

~/pydev/trunk/ python  
[EMAIL PROTECTED] ok
Python 2.6b1+ (trunk, Jul  3 2008, 12:43:37) 
[GCC 4.3.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from xmlrpclib import Server
>>> Server("http://localhost:8000";).doit
>>

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3271] iter.next() or iter.__next__() ?

[vizcayno]

New submission from vizcayno <[EMAIL PROTECTED]>:

For Win XP SP3 I do next in py30.b1:

a=[9,8,1,2]
it=iter(a)
it.next()
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'list_iterator' object has no attribute 'next'

but doing:
it.__next__()
9
it.__next__()
8

it is ok.

However, manual of Py3.0 indicates iter.next() as valid.

Python 25 does not accept "it.__next__()" but "it.next()"
Regards.

--
assignee: georg.brandl
components: Documentation
messages: 69205
nosy: georg.brandl, vizcayno
severity: normal
status: open
title: iter.next() or iter.__next__() ?
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

[issue1641] asyncore delayed calls feature

[Josiah Carlson]

Josiah Carlson <[EMAIL PROTECTED]> added the comment:

Generally speaking, delayed calls, and/or a practical scheduling
algorithm are useful for async servers.  Since 2.6 and 3.0 are on
feature freeze right now, this is going to have to wait for 2.7 and 3.1
.  I'll make sure to get something like this into 2.7 / 3.1 .

--
assignee: akuchling -> josiahcarlson

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3272] Multiprocessing hangs when multiprocessing.Pool methods are called

[Andrii V. Mishkovskyi]

New submission from Andrii V. Mishkovskyi <[EMAIL PROTECTED]>:

`multiprocessing` hangs, when `multiprocessing.Pool` methods `map`,
`imap`, `imap_unordered`, `apply`, `apply_async`, `map_async` are called.
Here is an example:

Python 3.0b1+ (py3k:64686M, Jul  3 2008, 13:06:13)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from multiprocessing import Pool
>>> Pool(processes=4).imap(lambda x: x, range(10))

>>> Pool(processes=4).map(lambda x: x, range(10))
Exception in thread Thread-13:
Traceback (most recent call last):
  File "/usr/local/lib/python3.0/threading.py", line 492, in
_bootstrap_inner
self.run()
  File "/usr/local/lib/python3.0/threading.py", line 447, in run
self._target(*self._args, **self._kwargs)
  File "/usr/local/lib/python3.0/multiprocessing/pool.py", line 225, in
_handle_tasks
put(task)
  File "/usr/local/lib/python3.0/pickle.py", line 1319, in dumps
Pickler(f, protocol).dump(obj)
  File "/usr/local/lib/python3.0/multiprocessing/util.py", line 311, in
_reduce_method
if m.__self__ is None:
AttributeError: 'function' object has no attribute '__self__'

Process PoolWorker-28:
Traceback (most recent call last):
  File "/usr/local/lib/python3.0/multiprocessing/process.py", line 232,
in _bootstrap
self.run()
  File "/usr/local/lib/python3.0/multiprocessing/process.py", line 88,
in run
self._target(*self._args, **self._kwargs)
  File "/usr/local/lib/python3.0/multiprocessing/pool.py", line 57, in
worker
task = get()
  File "/usr/local/lib/python3.0/multiprocessing/queues.py", line 337,
in get
Process PoolWorker-27:
Traceback (most recent call last):
  File "/usr/local/lib/python3.0/multiprocessing/process.py", line 232,
in _bootstrap
self.run()
  File "/usr/local/lib/python3.0/multiprocessing/process.py", line 88,
in run
self._target(*self._args, **self._kwargs)
  File "/usr/local/lib/python3.0/multiprocessing/pool.py", line 57, in
worker
task = get()
  File "/usr/local/lib/python3.0/multiprocessing/queues.py", line 337,
in get
Process PoolWorker-26:
Traceback (most recent call last):
  File "/usr/local/lib/python3.0/multiprocessing/process.py", line 232,
in _bootstrap
Process PoolWorker-25:
Traceback (most recent call last):
  File "/usr/local/lib/python3.0/multiprocessing/process.py", line 232,
in _bootstrap
self.run()
  File "/usr/local/lib/python3.0/multiprocessing/process.py", line 88,
in run
self._target(*self._args, **self._kwargs)
  File "/usr/local/lib/python3.0/multiprocessing/pool.py", line 57, in
worker
task = get()
  File "/usr/local/lib/python3.0/multiprocessing/queues.py", line 337,
in get
self.run()
  File "/usr/local/lib/python3.0/multiprocessing/process.py", line 88,
in run
self._target(*self._args, **self._kwargs)
  File "/usr/local/lib/python3.0/multiprocessing/pool.py", line 57, in
worker
task = get()
  File "/usr/local/lib/python3.0/multiprocessing/queues.py", line 339,
in get
return recv()
KeyboardInterrupt
racquire()
KeyboardInterrupt
racquire()
KeyboardInterrupt
racquire()
KeyboardInterrupt
Terminated

The same happens on latest trunk of Python 2.6.
Note, `map` and `apply` methods hang Python interpreter completely, so I
have to use `kill` utility to exit Python.

--
components: Library (Lib)
messages: 69207
nosy: jnoller, mishok13, roudkerk
severity: normal
status: open
title: Multiprocessing hangs when multiprocessing.Pool methods are called
type: crash
versions: 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

[issue3273] multiprocessing and meaningful errors

[Andrii V. Mishkovskyi]

New submission from Andrii V. Mishkovskyi <[EMAIL PROTECTED]>:

multiprocessing uses a lot of `assert` statements all over the code. I
propose to change this way to a more readable and understandable. For
example:
Lib/multiprocessing/managers.py, line 136:
assert isinstance(authkey, bytes)
>From my point of view, raising an AssertionError is not enough in this
case. I propose changing this one to more intuitive:
if not isinstance(authkey, bytes):
   raise TypeError("'authkey' argument should be an instance of 'bytes'")
(Well, maybe message could be more descriptive. :) )

And this goes for all of the multiprocessing code base.
Should I consider writing a patch for this?

--
components: Library (Lib)
messages: 69208
nosy: jnoller, mishok13, roudkerk
severity: normal
status: open
title: multiprocessing and meaningful errors
type: feature request
versions: 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

[issue1675455] Use getaddrinfo() in urllib2.py for IPv6 support

[Facundo Batista]

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

What I don't understand here is... if gethostbyname() lacks of IPv6
support, instead of creating a new function why not to add the
functionality to that same function?

Right now gethostbyname() is implemented in C, which would be the
drawback of making it a Python function?

--
assignee:  -> facundobatista
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

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

[Facundo Batista]

Changes by Facundo Batista <[EMAIL PROTECTED]>:


___
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

[Facundo Batista]

Changes by Facundo Batista <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file10632/unnamed

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3267] yield in list comprehensions possibly broken in 3.0

[Brett Cannon]

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

Yes, this change in semantics is expected. Closing as "won't fix".

--
nosy: +brett.cannon
resolution:  -> wont fix
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

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

[Facundo Batista]

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

I see that you're working on a final solution, this is great!

What we would need also to incorporate this to the trunk is a patch for
the test suite. Senthil, could you handle this?

--
assignee:  -> facundobatista
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

[issue2916] urlgrabber.grabber calls setdefaulttimeout

[Facundo Batista]

Changes by Facundo Batista <[EMAIL PROTECTED]>:


--
assignee:  -> facundobatista
nosy: +facundobatista, orsenthil

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2756] urllib2 add_header fails with existing unredirected_header

[Facundo Batista]

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

BitTorment, what would increase the possibility of accepting this is a
patch also for the test suite (test_urllib2.py), checking this
behaviour, for us to be sure that does not break again in the future.

Could you please submit also this?

--
assignee:  -> facundobatista
nosy: +facundobatista, orsenthil

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2776] urllib2.urlopen() gets confused with path with // in it

[Facundo Batista]

Changes by Facundo Batista <[EMAIL PROTECTED]>:


--
assignee:  -> facundobatista
nosy: +facundobatista, orsenthil

___
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]

New submission from Daniel Stutzbach <[EMAIL PROTECTED]>:

I'm writing a C extension module and discovered that Py_CLEAR() causes a
crash if the programmer happened to name their variable "tmp".  The
Py_CLEAR() macro internally uses the name "tmp" in a new scope, hiding
the callers "tmp", and calling Py_DECREF() on an essentially random bit
of memory.

I suggest changing Py_CLEAR() to use something a little less common than
"tmp".  Perhaps "_py_tmp".

For easy reference, here's how Py_CLEAR() is defined now:

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

--
components: Interpreter Core
messages: 69213
nosy: stutzbach
severity: normal
status: open
title: Py_CLEAR(tmp) seg faults
type: crash
versions: Python 2.5, 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

[issue1063924] asyncore should handle ECONNRESET in send

[Josiah Carlson]

Josiah Carlson <[EMAIL PROTECTED]> added the comment:

We are actually closing the socket before returning in the latest
version of asyncore.  Closing as fixed.

--
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

[issue760475] asyncore.py and "handle_error"

[Josiah Carlson]

Josiah Carlson <[EMAIL PROTECTED]> added the comment:

I forgot to fix this in my most recent commits, but I'll fix it this
weekend for 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

[issue1736101] asyncore should handle also ECONNABORTED in recv

[Josiah Carlson]

Josiah Carlson <[EMAIL PROTECTED]> added the comment:

Fixed in trunk, will be fixed in 3.0 this weekend.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue889153] asyncore.dispactcher: incorrect connect

[Josiah Carlson]

Josiah Carlson <[EMAIL PROTECTED]> added the comment:

Fixed in trunk, will be fixed in 3.0 this weekend.

--
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

[issue1740572] asynchat should call "handle_close"

[Josiah Carlson]

Josiah Carlson <[EMAIL PROTECTED]> added the comment:

Fixed in trunk, will be fixed in 3.0 this weekend.

--
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

[issue3232] Wrong str->bytes conversion in Lib/encodings/idna.py

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

Martin, you seem to be the author of that module.

--
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

[issue3139] bytearrays are not thread safe

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

Wow...
Isn't this kind of code supposed to ask for a buffer on the bytearray
object, together with an optional lock on it (or something like that)?

--
nosy: +pitrou

___
Python tracker <[EMAIL PROTECTED]>

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

[issue909005] asyncore fixes and improvements

[Josiah Carlson]

Josiah Carlson <[EMAIL PROTECTED]> added the comment:

I have applied my variant patch to trunk, which will be in 3.0 this weekend.

--
resolution:  -> out of date
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

[issue1025525] asyncore.file_dispatcher should not take fd as argument

[Josiah Carlson]

Josiah Carlson <[EMAIL PROTECTED]> added the comment:

Fixed in trunk, will be fixed in 3.0 this weekend.

--
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

[issue1736190] asyncore/asynchat patches

[Josiah Carlson]

Josiah Carlson <[EMAIL PROTECTED]> added the comment:

Committed to trunk a bit ago, will be in 3.0 this weekend.

--
resolution:  -> accepted
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

[issue2464] urllib2 can't handle http://www.wikispaces.com

[Facundo Batista]

Changes by Facundo Batista <[EMAIL PROTECTED]>:


--
assignee:  -> facundobatista
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

[issue3250] datetime.time does not support arithmetic

[George Boutsioukis]

George Boutsioukis <[EMAIL PROTECTED]> added the comment:

I have also come across this in the past. Although I sense that some
obscure reason might prevent time arithmetic from being included, here's
a patch to add time/timedelta addition and subtraction. It closely
follows the datetime arithmetic functions. To handle overflows, I
figured it should wrap around a 24-hour limit. The timezone stuff is
copied verbatim from the datetime functions, some finger-crossing applied.

--
keywords: +patch
nosy: +gboutsioukis
Added file: http://bugs.python.org/file10806/datetime.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2808] asynchat forgets packets when push is called from a thread

[Josiah Carlson]

Changes by Josiah Carlson <[EMAIL PROTECTED]>:


--
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

[issue2275] urllib2 header capitalization

[Facundo Batista]

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

Senthil: We would need some tests to assure this will keep working ok in
the future

Also as this is (somehow) a new functionality, we'd need to modify the
NEWS file and maybe even the docs (a comment about this case insensitivity?

Could you please send a patch for these? Thank you!

--
assignee:  -> facundobatista
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

[issue3271] iter.next() or iter.__next__() ?

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

Where in the 3.0 docs do you see it.next() used? It should be changed.

--
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

[issue1462525] URI parsing library

[Facundo Batista]

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

Senthil, we should incorporate the tests from RFC 3986 to the test
suite, what do you think?

Coul we integrate the effort from Paul Jimenez and the current urlparse
and achieve a RFC compliant library? Should we handle this compliance in
this bug?

--
assignee:  -> facundobatista
nosy: +facundobatista, orsenthil

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3271] iter.next() or iter.__next__() ?

[vizcayno]

vizcayno <[EMAIL PROTECTED]> added the comment:

Please, go to python 3.0 -> python manuals and search with word: iter
then select first line of found titles, i.e. Functional Programming 
HOWTO. Into this title you will find some samples.
Regards,

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3271] iter.next() or iter.__next__() ?

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

fixed in r64696.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3271] iter.next() or iter.__next__() ?

[Benjamin Peterson]

Changes by Benjamin Peterson <[EMAIL PROTECTED]>:


--
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

[issue3275] Control flow not optimized

[Daniel Colascione]

New submission from Daniel Colascione <[EMAIL PROTECTED]>:

Consider:

import dis
def foo():
  if 0 and 1: return "hi"

dis.dis(foo)

What I get is 

  2   0 LOAD_CONST   1 (0)
  3 JUMP_IF_FALSE   15 (to 21)
  6 POP_TOP 
  7 LOAD_CONST   2 (1)
 10 JUMP_IF_FALSE8 (to 21)
 13 POP_TOP 
 14 LOAD_CONST   3 ('hi')
 17 RETURN_VALUE
 18 JUMP_FORWARD 1 (to 22)
>>   21 POP_TOP 
>>   22 LOAD_CONST   0 (None)
 25 RETURN_VALUE

What I'd expect to see is:

  1   0 LOAD_CONST   0 (None)
  3 RETURN_VALUE

--
components: Interpreter Core
messages: 69230
nosy: quotemstr
severity: normal
status: open
title: Control flow not optimized
type: performance
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

[issue3275] Control flow not optimized

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

A patch for this was just recently rejected. See #1394.

--
nosy: +benjamin.peterson
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

[issue1580] Use shorter float repr when possible

[Guido van Rossum]

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

I'd like to reopen this. I'm still in favor of something like to this
algorithm:

def float_repr(x):
  s = "%.16g" % x
  if float(s) != x:
s = "%.17g" % x
  s1 = s
  if s1.startswith('-'):
s1 = s[1:]
  if s1.isdigit():
s += '.0'  # Flag it as a float
  # XXX special case inf and nan, see floatobject.c::format_double
  return s

combined with explicitly using %.17g or the new hex notation (see issue
3008) in places where cross-platform correctness matters, like pickle
and marshal.

This will ensure float(repr(x)) == x on all platforms, but not cross
platforms -- and I don't care.

I'm fine with only doing this in 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

[issue3008] Let bin/oct/hex show floats

[Guido van Rossum]

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

Raymond, Mark?  Is a new patch with tests and docs forthcoming?  Have
you decided on the API yet?  I'm willing to approve this for beta 2,
which will be around July 15.

--
assignee: gvanrossum -> rhettinger

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3276] httplib.HTTPConnection._send_request should not blindly assume dicts for headers

[toxik]

New submission from toxik <[EMAIL PROTECTED]>:

Presently it's impossible to use httplib.HTTPConnection.request and send 
the several headers with the same name. This is because _send_request 
assumes a dict is passed in, or a dict-like interface. Obviously one could 
make a list subclass or some such and give it an iteritems that returns 
itself, but IMHO the solution is to fix httplib.

Attached patch changes the current behavior to using iteritems only if it 
exists, otherwise iterate directly (which would fit with sequences of two-
tuples).

--
components: Library (Lib)
files: httplib.py.diff
keywords: patch
messages: 69234
nosy: ludvig.ericson
severity: normal
status: open
title: httplib.HTTPConnection._send_request should not blindly assume dicts for 
headers
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/file10807/httplib.py.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1580] Use shorter float repr when possible

[Tim Peters]

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

If you think using 16 (when possible) will stop complaints, think again
;-)  For example,

>>> for x in 0.07, 0.56:
... putatively_improved_repr = "%.16g" % x
... assert float(putatively_improved_repr) == x
... print putatively_improved_repr
0.07001
0.5601

(those aren't the only "2-digit" examples, but I expect those specific
examples work the same under Linux and Windows).

IOW, 16 doesn't eliminate base-conversion surprises, except at the 8
"single-digit surprises" (i/10.0 for i in range(1, 5) + range(6, 10)).

To eliminate "2-digit surprises" (like 0.07 and 0.56 above), and higher,
 in this way, you need to add a loop and keeping trying smaller
conversion widths so long as they convert back to the original input.

Keep it up, and you can make repr(float) so slow it would be faster to
do perfect rounding in Python ;-)

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3277] socket's OOB data management is broken on FreeBSD

[Giampaolo Rodola']

New submission from Giampaolo Rodola' <[EMAIL PROTECTED]>:

I've tried to run the code below on Windows XP and Linux Ubuntu and it
works as expected. Here is the output:

expt -> o
read -> fo

On FreeBSD 7.0 it raises the following exception:

expt -> o
read -> fo 
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/local/lib/python2.5/threading.py", line 460, in __bootstrap
self.run()
  File "/usr/local/lib/python2.5/threading.py", line 440, in run
self.__target(*self.__args, **self.__kwargs)
  File "_test2.py", line 13, in server
data = conn.recv(1024, socket.MSG_OOB)
error: (22, 'Invalid argument')





--- code ---

import socket, select, threading, time, os

def server():
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
s.bind(('', 1024))
s.listen(1)
conn, addr = s.accept()
conn.setblocking(0)
while 1:
r, w, e = select.select([conn], [conn], [conn], 0.01)
if e:
data = conn.recv(1024, socket.MSG_OOB)
print "expt -> " + data
if r:
data = conn.recv(1024)
print "read -> " + data


threading.Thread(target=server).start()
time.sleep(0.1)
s = socket.socket()
s.connect(('127.0.0.1', 1024))
s.sendall('foo', socket.MSG_OOB)

--- /code ---

--
messages: 69236
nosy: giampaolo.rodola
severity: normal
status: open
title: socket's OOB data management is broken on FreeBSD
versions: Python 2.5, 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

[issue3277] socket's OOB data management is broken on FreeBSD

[Giampaolo Rodola']

Changes by Giampaolo Rodola' <[EMAIL PROTECTED]>:


--
components: +Library (Lib)
type:  -> behavior

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3278] socket's SO_REUSEADDR option does not work on FreeBSD

[Giampaolo Rodola']

New submission from Giampaolo Rodola' <[EMAIL PROTECTED]>:

When the SO_OOBINLINE option is used against a socket, out-of-band data
should be placed in the normal data input stream as it is received.
In fact this is what happens on Windows and Linux by using the script below.
On FreeBSD this does not happen. select instead of returning a
"readable" file descriptor returns an "exceptional" file descriptor. 
Later, when we try to read some data from the socket, the following
exception is raised:


Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/local/lib/python2.5/threading.py", line 460, in __bootstrap
self.run()
  File "/usr/local/lib/python2.5/threading.py", line 440, in run
self.__target(*self.__args, **self.__kwargs)
  File "_test2.py", line 14, in server
data = conn.recv(1024, socket.MSG_OOB)
error: (22, 'Invalid argument')





--- code ---

import socket, select, threading, time, os

def server():
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
s.bind(('', 1024))
s.listen(1)
conn, addr = s.accept()
conn.setblocking(0)
conn.setsockopt(socket.SOL_SOCKET, socket.SO_OOBINLINE, 1)
while 1:
r, w, e = select.select([conn], [conn], [conn], 0.01)
if r:
# the socket is supposed to be in the "readable" list
data = conn.recv(1024)
print "read -> " + data
if e:
# ...but not in the "exception" list
data = conn.recv(1024, socket.MSG_OOB)
print "expt -> " + data


threading.Thread(target=server).start()
time.sleep(0.1)
s = socket.socket()
s.connect(('127.0.0.1', 1024))
s.sendall('x', socket.MSG_OOB)

--- /code ---

--
components: Library (Lib)
messages: 69237
nosy: giampaolo.rodola
severity: normal
status: open
title: socket's SO_REUSEADDR option does not work on FreeBSD
type: behavior
versions: Python 2.5, 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

[issue3278] socket's SO_REUSEADDR option does not work on FreeBSD

[Giampaolo Rodola']

Giampaolo Rodola' <[EMAIL PROTECTED]> added the comment:

This bug should be strictly related with issue 3277:
http://bugs.python.org/issue3277

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3277] socket's OOB data management is broken on FreeBSD

[Giampaolo Rodola']

Giampaolo Rodola' <[EMAIL PROTECTED]> added the comment:

This bug should be strictly related with issue 3278:
http://bugs.python.org/issue3278

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3279] import of site.py fails on startup

[Roger Upole]

New submission from Roger Upole <[EMAIL PROTECTED]>:

In pythonrun.c, initstdio injects 'open' into builtins.  However,
initsite is called before initstdio and site.py uses open.
Running with -v, this traceback is printed:

Traceback (most recent call last):
  File "j:\python30\lib\site.py", line 518, in 
main()
  File "j:\python30\lib\site.py", line 501, in main
known_paths = addsitepackages(known_paths)
  File "j:\python30\lib\site.py", line 281, in addsitepackages
addsitedir(sitedir, known_paths)
  File "j:\python30\lib\site.py", line 178, in addsitedir
addpackage(sitedir, name, known_paths)
  File "j:\python30\lib\site.py", line 141, in addpackage
f = open(fullname, "rU")
NameError: global name 'open' is not defined

--
messages: 69240
nosy: rupole
severity: normal
status: open
title: import of site.py fails on startup
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

[issue3008] Let bin/oct/hex show floats

[Raymond Hettinger]

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

Mark, I'm tied-up with EuroPython until the 14th.  Do you have time to 
take a crack at this?

--
assignee: rhettinger -> marketdickinson

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1580] Use shorter float repr when possible

[Guido van Rossum]

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

Here's a rough-and-tumble implementation of that idea, for Py3k.

Added file: http://bugs.python.org/file10808/float.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1580] Use shorter float repr when possible

[Guido van Rossum]

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

That is truly maddening! :-(

I guess Noam's proposal to return str(x) if float(str(x)) == x makes
more sense then.  I don't really care as much about 1.234567890123 vs.
1.234567890122 as I care about 1.2345 vs. 1.2344.

(This comment is supposed to *precede* the patch.)

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3277] socket's OOB data management is broken on FreeBSD

[Martin v. Löwis]

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

Why do you think this is a bug in Python, and not in FreeBSD?

--
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

[issue3139] bytearrays are not thread safe

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

Probably, but this affects all PyArg_ParseTuple("s#") calls that release
the GIL afterwards. How many of them are there?

___
Python tracker <[EMAIL PROTECTED]>

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