From vadimch@yahoo.com  Thu Sep  2 00:30:57 1999
From: vadimch@yahoo.com (vadimch@yahoo.com)
Date: Wed, 1 Sep 1999 19:30:57 -0400 (EDT)
Subject: [Python-bugs-list] struct module (PR#70)
Message-ID: <199909012330.TAA05242@python.org>

Full_Name: Vadim Chugunov
Version: 1.5.2
OS: NT
Submission from: tide72.microsoft.com (131.107.3.72)


Little endian and big endian tables in structmodule.c do not have entry for 'P'
format.  Native table is OK though

To repro:
>>> import struct
>>> struct.calcsize("P")
4
>>> struct.calcsize("=P")
Traceback (innermost last):
  File "<interactive input>", line 0, in ?
error: bad char in struct format




From tismer@appliedbiometrics.com  Thu Sep  2 01:14:05 1999
From: tismer@appliedbiometrics.com (Christian Tismer)
Date: Thu, 02 Sep 1999 02:14:05 +0200
Subject: [Python-bugs-list] pprint.pprint gives recursive message on my tuple :))
Message-ID: <37CDC14D.E79CFD8@appliedbiometrics.com>

This is a multi-part message in MIME format.
--------------8601ABB26C1251C93B66FE7B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Howdy,

today I found some strange behavior of pprint.pprint, but I can't
figure out what's wrong. The code looks quite right.

I just happened to create rather deeply nested structures of tuples,
where I made sure that every tuple with the same content was
created as one and only one tuple.
This means, whenever two tuples have the same value, they are the
same objects.

When you pretty print this, pprint claims that I have a recursion,
which cannot be with just tuples.

I failed to reproduce this by hand, but the tuple is pickleable
and restores correctly. So I attached the pickle here, if somebody
wants to try it himself.

funny - ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer@appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home
--------------8601ABB26C1251C93B66FE7B
Content-Type: text/plain; charset=us-ascii;
 name="look.dmp"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="look.dmp"

(lp1
(((S''
S'<'
t(S'praep'
p2
S' '
ttp3
((S'num'
p4
S'="'
p5
tp6
(S'0000'
S''
tp7
ttp8
a(((S'2'
S'-'
tp9
(S'1'
S'" '
p10
tp11
tp12
((S'fai'
g5
tp13
(S'N'
g10
ttp14
tp15
a(((S'kdat'
g5
tp16
(S'01'
p17
S'.'
tp18
tp19
((S'03'
p20
S'.'
tp21
(S'99'
p22
g10
tp23
tp24
tp25
a(((S'stp'
g5
tp26
(S'F'
g10
tp27
tp28
((S'hgl'
g5
tp29
(S'37'
p30
S'.'
tp31
tp32
tp33
a(((((S'1'
S'.'
tp34
(S'B'
S'.'
tp35
tp36
(g34
(S'1'
S'." '
p37
tp38
tp39
tp40
(((S'abs'
p41
g5
tp42
(S'Rp'
p43
g10
tp44
tp45
((S'pskl'
g5
tp46
(S'B'
S'"> <'
p47
tp48
tp49
tp50
tp51
(S'nam'
p52
S'>'
tp53
tp54
a(S'Bufedil'
p55
S'&'
tp56
a(S'reg'
p57
S'; / -'
tp58
aS'long'
p59
aS' / -'
p60
a((S'forte'
p61
S'</'
p62
tp63
(g52
S'> <'
p64
tp65
tp66
a((S'fkb'
p67
S'>'
tp68
(S'Abbott'
g62
tp69
tp70
a(((g67
g64
tp71
(S'darreich'
p72
S' '
tp73
tp74
((S'std'
g5
tp75
g27
tp76
tp77
a((((S'pbscod'
g5
tp78
(S'0247'
S''
tp79
tp80
((S'76'
p81
g47
tp82
(S'daf'
p83
S'>'
tp84
tp85
t(g56
(g57
S'; '
p86
tp87
tp88
tp89
a(((S'Injektionsl'
S'&'
tp90
(S'ouml'
p91
S';'
tp92
tp93
((S'sung'
p94
g62
tp95
(g83
g64
tp96
tp97
tp98
a((S'zln'
p99
S'>'
tp100
(S'229'
p101
S'.'
tp102
tp103
a((((S'00'
p104
S'.'
tp105
(g17
g62
tp106
tp107
((g99
g64
tp108
(S'aro'
p109
S'>'
tp110
tp111
tp112
(((S'0101'
S''
tp113
(S'1983'
p114
g62
tp115
tp116
((g109
g64
tp117
(S'packung'
p118
S' '
tp119
tp120
tp121
tp122
a((S'pzn'
p123
g5
tp124
(S'2419'
S''
tp125
tp126
a((S'401'
g47
tp127
(S'ppa'
p128
S'>'
tp129
tp130
a(((S'10'
p131
S' '
tp132
(S'Amp'
p133
S'. ('
p134
tp135
tp136
((S'N2'
p137
S')</'
p138
tp139
(g128
S'> </'
p140
tp141
tp142
tp143
a((((g118
g64
tp144
(S'zusammen'
p145
g64
tp146
tp147
((S'zus'
p148
S'>'
tp149
(S'1'
S' '
tp150
tp151
tp152
(((g133
S'.</'
p153
tp154
(g148
g64
tp155
tp156
((S'awbest'
p157
g64
tp158
(S'awb'
p159
S'>'
tp160
tp161
ttp162
a(((S'Buflomedil'
S'-'
t(S'HCl'
p163
g62
tp164
tp165
((g159
g64
tp166
(S'awbmng'
p167
S'>'
tp168
tp169
tp170
a(((S'50'
p171
S'&'
tp172
(S'nbsp'
p173
S';'
tp174
tp175
((S'mg'
p176
g62
tp177
(g167
g64
tp178
tp179
tp180
a((((S'awbcod'
p181
S'>'
tp182
g79
tp183
((g81
g62
tp184
(g181
g140
tp185
tp186
tp187
(g158
(S'hilfsst'
p188
g64
tp189
tp190
tp191
a((S'hst'
p192
S'>'
tp193
(S'D'
S'-'
tp194
tp195
a(((S'Mannitol'
p196
g62
tp197
(g192
g64
tp198
tp199
((S'hstcod'
p200
S'>'
tp201
(S'0717'
S''
tp202
tp203
tp204
a(((g171
g62
tp205
(g200
g140
tp206
tp207
(g189
g189
tp208
tp209
a((((g193
(S'Wasser'
p210
S' '
tp211
tp212
((S'f'
S'. '
p213
tp214
(S'Inj'
p215
S'.-'
p216
tp217
tp218
tp219
(((S'zwecke'
p220
g62
tp221
g198
tp222
(g201
(S'0160'
S''
tp223
tp224
tp225
tp226
((((S'15'
p227
g62
tp228
g206
tp229
((g188
g140
tp230
(g145
g140
tp231
tp232
tp233
(((g72
g64
tp234
g73
tp235
g76
tp236
tp237
tp238
ag89
a(((S'Filmtabletten'
p239
g62
tp240
g96
tp241
g103
tp242
a((g105
(g104
g62
tp243
tp244
((g111
g116
tp245
g120
tp246
tp247
ag126
a((S'387'
g47
tp248
g129
tp249
a(((g171
S' '
tp250
(S'Filmtbl'
p251
g134
tp252
tp253
(g142
(g144
g119
tp254
tp255
tp256
ag126
a(S'393'
p257
g47
tp258
a(g129
((((S'100'
p259
S' '
tp260
g252
tp261
((S'N3'
p262
g138
tp263
g141
tp264
tp265
g152
tp266
tp267
a((((g251
g153
tp268
g155
tp269
g161
tp270
g170
tp271
a(((S'150'
p272
S'&'
tp273
g174
tp274
g179
tp275
ag187
a((g190
(g193
(S'Saccharose'
p276
g62
tp277
tp278
tp279
((g198
g201
tp280
((S'1053'
S''
tp281
g205
tp282
tp283
tp284
a((((g206
g189
tp285
(g189
g193
tp286
tp287
(((S'mikrokri'
S''
tp288
(S'stalline'
S' '
tp289
tp290
((S'Cellulose'
g62
tp291
g198
tp292
tp293
tp294
((g201
(S'0293'
S''
tp295
tp296
((S'45'
p297
g62
tp298
g206
tp299
tp300
tp301
a((g208
(g193
(S'Ma'
S'&'
tp302
tp303
tp304
(((((S'shy'
p305
S';'
tp306
(S'gne'
S'&'
tp307
tp308
(g306
(S'si'
S'&'
tp309
tp310
tp311
((g306
(S'um'
p312
S'&'
tp313
tp314
(g306
(S'stea'
S'&'
tp315
tp316
tp317
tp318
(((g306
(S'rat'
p319
g62
tp320
tp321
g280
tp322
(((S'0708'
S''
tp323
(S'30'
p324
g62
tp325
tp326
g285
tp327
tp328
tp329
tp330
ag286
a((S'Macrogole'
g62
tp331
g198
tp332
a((g201
(S'0973'
S''
tp333
tp334
g207
tp335
a((g208
(g193
(S'Hypromellose'
g62
tp336
tp337
tp338
(g280
((S'2012'
S''
tp339
(S'65'
p340
g62
tp341
tp342
tp343
tp344
a(((g285
((S'ein'
p345
S'>'
tp346
(S'Farbstoff'
p347
g62
tp348
tp349
tp350
(((g345
g64
tp351
g189
tp352
(g193
(S'E'
S'&'
tp353
tp354
tp355
tp356
(((g174
(S'171'
p357
g62
tp358
tp359
g280
tp360
(((S'1171'
S''
tp361
g205
tp362
(g206
g230
tp363
tp364
tp365
tp366
a(((g231
g234
tp367
(g73
g75
tp368
tp369
(g27
g78
tp370
tp371
a((g79
g82
t((g84
g56
t(g87
(g61
S' '
tp372
tp373
ttp374
ag242
a((g18
g243
tp375
g111
tp376
a((g113
(S'1998'
p377
g62
tp378
tp379
g120
tp380
ag124
a(S'2743'
S''
tp381
a((g357
g47
tg129
tp382
ag253
a((g137
S') '
p383
tp384
g63
tp385
a((g141
g144
tp386
(g119
g124
tp387
tp388
ag381
a(S'188'
g47
tp389
a((g129
g260
tp390
(g252
(g262
g383
tp391
tp392
tp393
a((g63
g141
tp394
g152
tp395
ag271
a(((S'300'
p396
S'&'
tp397
g174
tp398
g179
tp399
ag187
a((g190
(g193
(S'Lactose'
p400
g62
tp401
tp402
tp403
(g280
((S'0668'
S''
tp404
g325
tp405
tp406
tp407
a((g287
(((S'Povidon'
p408
g62
tp409
g198
tp410
(g201
(S'0985'
S''
tp411
tp412
tp413
tp414
((((S'75'
p415
g62
tp416
g206
tp417
g208
tp418
((g193
(S'Magnesiu'
S''
tp419
tp420
((S'mstearat'
g62
tp421
g198
tp422
tp423
ttp424
a((g201
g323
tp425
(g325
g206
tp426
tp427
a(g208
g193
tp428
a(S'Celluloseace'
p429
S''
tp430
a(S'tatphthalat'
g62
tp431
a(g198
(g296
((g341
g206
tp432
g208
tp433
ttp434
a(((g193
(S'Propylenglycol'
p435
g62
tp436
tp437
g280
tp438
(((S'1003'
S''
tp439
g243
tp440
g285
tp441
tp442
ag286
a(S'Sorbitanoleat'
g62
tp443
a(g198
(g201
(S'1085'
S''
tp444
tp445
tp446
a((S'60'
p447
g62
tp448
g206
tp449
ag208
a(g193
(S'Rizinus'
S'&'
tp450
tp451
a(((g92
(S'l'
g62
tp452
tp453
g280
tp454
(((S'1044'
S''
tp455
g205
tp456
g285
ttp457
a(g286
((S'Macrogol'
p458
g62
tp459
g198
tp460
tp461
a(g335
(g232
g235
tp462
tp463
a(g76
g80
tp464
ag85
ag88
a(g59
S' '
tp465
a((S'Retardtabletten'
p466
g62
tp467
(g96
g100
tp468
tp469
ag102
ag105
a((g20
g62
tp470
g108
tp471
a(((g110
g113
tp472
((S'1986'
p473
g62
tp474
g117
tp475
tp476
g387
tp477
a(S'3173'
S''
tp478
a(S'155'
p479
g47
tp480
a(g129
(S'20'
p481
S' '
tp482
tp483
a((S'Retardtbl'
p484
g134
tp485
(S'N1'
p486
g383
tp487
tp488
a((g59
g62
tp489
g141
tp490
a(g254
g124
tp491
ag478
a((S'161'
p492
g47
tp493
g129
tp494
a(g250
g485
tp495
ag384
ag489
ag388
aS'8708'
aS''
aS'477'
p496
a(g47
(S'pre'
p497
S'>'
tp498
tp499
aS'143'
p500
aS','
ag184
a((g497
g64
tp501
g390
tp502
a(g485
g391
tp503
ag490
a(g152
(((g484
g153
tp504
g155
tp505
g161
tp506
tp507
ag170
a(((S'600'
p508
S'&'
tp509
g174
tp510
g179
tp511
ag191
a(g193
(S'Algins'
S'&'
tp512
tp513
a((S'auml'
p514
S';'
tp515
(S'ure'
p516
S' '
tp517
tp518
a(S'Natrium'
p519
S'-'
tp520
a(S'Calciumsalz'
g62
tp521
ag280
a(g113
g243
tp522
a(g414
(g418
(g337
g280
tp523
ttp524
a(g342
g285
tp525
a((g286
(g302
g306
tp526
tp527
((((g307
g306
tp528
(g309
g306
tp529
tp530
((g313
g306
tp531
(g315
g306
tp532
tp533
tp534
(((g320
g198
tp535
g425
tp536
(g426
g208
tp537
tp538
tp539
tp540
a(((g193
g331
tp541
g280
t((g333
g205
tp542
g285
tp543
tp544
a(g349
g352
tp545
a(g354
(g174
(S'124'
p546
g62
tp547
tp548
tp549
a((g280
((S'0385'
S''
tp550
g243
tp551
tp552
(g363
g367
tp553
tp554
a(g368
g370
tp555
ag374
a((S'Tropfen'
p556
g62
tp557
g96
tp558
ag103
a(g105
(S'02'
p559
g62
tp560
tp561
a(g111
(g113
(S'1988'
p562
g62
tp563
ttp564
a(g120
g124
tp565
a(S'3303'
S''
tp566
a((S'273'
p567
g47
tp568
g129
tp569
a(((g259
S'&'
tp570
g174
tp571
(((S'ml'
p572
S' ('
p573
tp574
g391
tp575
((S'Tr'
p576
g213
tp577
g63
tp578
ttp579
a(((g386
(g146
g149
tp580
tp581
(((S'1'
S'&'
tp582
g174
tp583
((g572
g62
tp584
g155
tp585
tp586
tp587
g161
tp588
ag165
a((g169
g274
tp589
g179
tp590
ag183
ag186
ag190
a(((g193
(S'Benzalkoni'
S''
tp591
tp592
((S'umchlorid'
p593
g62
tp594
g198
tp595
tp596
((g201
(S'0200'
S''
tp597
tp598
(g243
g206
tp599
tp600
tp601
a((g208
g437
tp602
(g280
g440
tp603
tp604
a((g287
(((S'Saccharin'
p605
S'-'
tp606
(g519
g62
tp607
tp608
g280
tp609
tp610
((((S'0206'
S''
tp611
g243
tp612
g285
tp613
g286
tp614
tp615
aS'Glycyrrhizins'
a((S'&'
g515
tp616
(g516
S', '
p617
tp618
tp619
aS'Monoammo'
aS''
aS'niumsalz'
a(g62
(g198
g201
tp620
tp621
a(S'0540'
S''
tp622
ag207
a((g208
(g193
(S'Aromastoff'
p623
g62
tp624
tp625
tp626
(g280
((S'9916'
S''
tp627
g205
tp628
tp629
tp630
a(g553
(S'anw'
p631
S'>'
tp632
tp633
a(S'Periphere'
p634
g617
tp635
a((S'arterielle'
S' '
tp636
(S'Durchblutungsst'
S'&'
tp637
tp638
a(g92
(S'rungen'
p639
g86
tp640
tp641
a((S'insbes'
p642
g213
tp643
(S'bei'
p644
S' '
tp645
tp646
a((S'Claudicatio'
S' '
tp647
(S'intermittens'
p648
S' '
tp649
tp650
a(S'mit'
p651
S' '
tp652
aS'erhaltener'
aS' '
a((S'Durchblutu'
S''
t(S'ngsreserve'
g153
ttp653
a(((g631
g64
tp654
(S'signatur'
g64
tp655
tp656
((S'gegenanz'
p657
g64
tp658
(S'gtx'
p659
S'>'
tp660
tp661
tp662
aS'Dekomp'
ag213
a(S'Herzinsuff'
p663
S'., '
p664
tp665
a(S'akuter'
S' '
tp666
a(S'Herzinfarkt'
p667
g617
tp668
ag636
a(S'Blutungen'
p669
g617
tp670
a(S'Zustand'
p671
S' '
tp672
a(S'unmittelbar'
S' '
tp673
a((S'nach'
p674
S' '
tp675
(S'd'
g213
tp676
tp677
a(S'Geburt'
p678
g617
tp679
a(S'sehr'
S' '
tp680
a((S'niedriger'
S' '
tp681
(S'Blutdruck'
p682
g617
tp683
tp684
a(S'frischer'
S' '
tp685
a((S'h'
S'&'
tp686
g515
tp687
a(S'morrhag'
g213
tp688
aS'Insult'
p689
ag213
a((S'Kdr'
p690
g153
tp691
((g659
g140
tp692
g658
tp693
tp694
a(((S'schwang'
p695
g64
tp696
(S'swtx'
p697
S'>&'
p698
tp699
tp700
((S'Lverweis'
S';'
tp701
(S'K'
S' &'
p702
tp703
tp704
tp705
a(((S'Sanf'
S';'
tp706
(S'Gr'
S'&'
tp707
tp708
(g174
(S'5'
S'&'
tp709
tp710
tp711
a(((S'Send'
p712
S';</'
p713
tp714
(g697
g140
tp715
tp716
(g696
(S'stillz'
p717
g64
tp718
tp719
tp720
a(((((S'sttx'
p721
g698
tp722
g701
tp723
(g703
g706
tp724
tp725
(((S'La'
S'&'
tp726
g174
tp727
(g582
g714
tp728
tp729
tp730
(((g721
g140
tp731
g718
tp732
((S'nebenw'
p733
g64
tp734
(S'ntx'
p735
S'>'
tp736
tp737
tp738
tp739
a(((S'H'
S'&'
tp740
g515
tp741
(S'ufig'
p742
S' '
tp743
tp744
a((S'Magen'
p745
S'-'
tp746
(S'Darm'
p747
S'-'
tp748
tp749
aS'Beschw'
p750
ag134
a(S'wie'
p751
g702
tp752
a((S'Uuml'
S';'
tp753
(S'belkeit'
p754
g617
tp755
tp756
a(S'Magendruck'
p757
g617
tp758
aS'Durchfall'
p759
aS'), '
p760
a(S'Kopfschmerzen'
p761
g213
tp762
a(S'Gelegentl'
p763
g213
tp764
a(S'Hautersch'
S''
tp765
a(S'einungen'
p766
g573
tp767
a(g751
S' '
tp768
a(S'Exantheme'
p769
g617
tp770
a((S'Hautr'
S'&'
tp771
(g92
(S'tungen'
p772
g617
tp773
tp774
tp775
aS'Juckreiz'
p776
a(g760
g645
tp777
a(S'hoh'
g213
tp778
a(S'Dosen'
p779
S' '
tp780
a(S'orthostat'
g213
tp781
a(S'Regulationsst'
S'&'
tp782
a(g92
(S'r'
g213
tp783
tp784
a((S'Bei'
p785
S' '
tp786
g680
tp787
a(g778
(S'Dos'
p788
g213
tp789
tp790
a(S'krampfartige'
S' '
tp791
a(S'Anf'
p792
S'&'
tp793
a(g515
(S'lle'
p794
S' '
tp795
tp796
a(((S'm'
S'&'
tp797
g92
tp798
(S'gl'
p799
g213
tp800
tp801
ag55
aS' '
a(g215
S'.: '
p802
tp803
aS'Venenwand'
p804
aS''
aS'reizungen'
a(g617
(S'allerg'
p805
g213
tp806
tp807
a(S'Reaktionen'
p808
g573
tp809
ag768
a(S'Hautausschlag'
p810
g617
tp811
a(S'Tachykardie'
p812
g617
tp813
a(S'Hypotension'
p814
g617
tp815
aS'Schock'
p816
a(S').</'
p817
(((g735
g140
tp818
g734
tp819
((S'wechselw'
p820
g64
tp821
(S'wtx'
p822
S'>'
tp823
tp824
tp825
tp826
a(((S'Verst'
p827
S'&'
tp828
g515
tp829
(S'rk'
p830
g213
tp831
tp832
a(S'der'
p833
S' '
tp834
a((S'blutdruck'
S''
tp835
(S'senkenden'
S' '
tp836
tp837
a((S'Wirkung'
p838
S' '
tp839
(S'von'
p840
S' '
tp841
tp842
aS'Vasodilatatoren'
p843
ag617
a(S'Calciumant'
S''
tp844
aS'agonisten'
p845
ag617
a((S'Antihype'
S''
tp846
(S'rtensiva'
p847
S' '
tp848
tp849
a(S'u'
g213
tp850
aS'Alkohol'
p851
a(g153
(g822
g140
tp852
tp853
a(g821
(S'toxi'
p854
g64
tp855
tp856
a(S'ttx'
p857
S'>'
tp858
a(g785
g702
tp859
a(g753
(S'berdos'
p860
g213
tp861
tp862
a(S'treten'
S' '
tp863
a(S'Blutdruckabfall'
p864
g617
tp865
ag813
a(S'Koma'
p866
g617
tp867
a(((S'Schl'
S'&'
tp868
g515
tp869
(S'frigkeit'
g617
tp870
tp871
a(S'Unruhe'
p872
g617
tp873
a((S'Erbrechen'
p874
S' '
tp875
g850
tp876
a((S'zerebrale'
S' '
tp877
(S'Krampfanf'
S'&'
tp878
tp879
ag796
a(S'auf'
p880
g213
tp881
a(S'Therapie'
p882
S': '
p883
tp884
a((S'Magensp'
S'&'
t(S'uuml'
p885
S';'
tp886
tp887
aS'lung'
p888
ag617
a((S'Gabe'
p889
S' '
tp890
g841
tp891
aS'Benzodiazepinen'
p892
a(g153
(((g857
g140
tp893
(g854
g140
tp894
tp895
(g655
(S'hinweise'
p896
g64
tp897
tp898
ttp899
a((S'dos'
p900
S'>'
tp901
(g133
g802
tp902
tp903
a(g9
(S'4'
S' '
tp904
tp905
a(g133
g213
tp906
a(S'tgl'
p907
g134
tp908
a((S'siehe'
S' '
tp909
(S'Gebrauchsi'
S''
tp910
tp911
aS'nformation'
p912
a(S').&'
p913
(S'para'
p914
g86
tp915
tp916
a(g251
g802
tp917
a(S'3'
S'-'
tp918
a(g904
(S'Tbl'
p919
g213
tp920
tp921
a(g907
g213
tp922
a((S'verteilt'
p923
S' '
tp924
((S'zu'
p925
S' '
tp926
(S'den'
p927
S' '
tp928
tp929
tp930
a((S'Mahlzeiten'
p931
S'.&'
p932
tp933
g915
tp934
a((g251
g213
tp935
(g61
g883
tp936
tp937
a((S'Morgens'
p938
S' '
tp939
g850
tp940
a(S'abends'
p941
S' '
tp942
a(S'jeweils'
S' '
tp943
a(g583
g935
tp944
a((g926
(g928
g933
ttg915
tp945
a(g484
g802
tp946
a((S'1mal'
p947
S' '
tp948
g150
tp949
a(g484
g213
tp950
a(g922
(S'unzerkaut'
p951
S' '
tp952
tp953
a(g926
(S'einer'
p954
S' '
tp955
tp956
aS'Mahlzeit'
p957
a(g932
g915
tp958
a(g556
g883
tp959
a(g918
(S'4'
S'&'
tp960
tp961
a(g174
(g572
S' '
tp962
tp963
a((g907
g153
tp964
(g900
g64
tp965
tp966
a((S'lag'
p967
S'>'
tp968
(S'Verfalldatum'
p969
S'! ('
p970
tp971
tp972
a(g133
S'.) '
p973
tp974
a(S'Lagerung'
S''
tp975
a(S'shinweis'
p976
g970
tp977
a(g133
g664
tp978
a(g576
S'.)</'
p979
tp980
a(g967
g64
tp981
a(((S'apa'
p982
S'>'
tp983
(g131
S'&'
tp984
tp985
((S'times'
p986
S';'
tp987
g482
tp988
tp989
ag950
ag59
a(g617
(g984
g987
tp990
tp991
a(g132
g978
tp992
a((S'Kombipack'
S' '
tp993
(S'z'
g213
tp994
tp995
a((S'i'
S'.'
tp996
(S'v'
g216
tp997
tp998
a(S'Inf'
p999
g213
tp1000
a((S'enth'
p1001
g802
tp1002
((g984
g174
tp1003
(g135
(g137
g760
ttttp1004
a((g709
g987
tp1005
g571
tp1006
a((g962
(S'NaCl'
p1007
S'-'
tp1008
tp1009
((S'Lsg'
p1010
g664
tp1011
g709
ttp1012
a((g174
(S'Infusions'
p1013
S'- '
p1014
tp1015
t(g850
g709
ttp1016
a((g174
(S'Perfusionsger'
S'&'
ttg515
tp1017
aS'te'
p1018
ag213
ag993
ag465
ag994
ag996
ag997
ag1000
a((g850
(S'oralen'
S' '
tp1019
t(g882
S' '
tp1020
tp1021
ag1004
ag1003
ag485
a(g486
g760
tp1022
ag1006
ag1012
ag1016
ag1017
a(g1018
g617
tp1023
a(g709
g174
tp1024
aS'Einmalspritzen'
p1025
ag617
a(g709
g174
tp1026
a(S'Kan'
S'&'
tp1027
ag886
a(S'len'
p1028
g153
tp1029
a(((g982
g140
tp1030
(g896
S'> \015\012<!-- '
p1031
tp1032
tp1033
(S'rs_oid'
S'='
tp1034
tp1035
aS'0xC4D92E'
aS''
aS'8C525'
aS''
a(S'0737'
S''
tp1036
aS'0435'
aS''
aS'45B9B2AL'
a(((S' -->\012</'
p1037
((g2
S'>'
tp1038
tp1039
tp1040
tp1041
tp1042
a.
--------------8601ABB26C1251C93B66FE7B--



From guido@CNRI.Reston.VA.US  Thu Sep  2 14:31:48 1999
From: guido@CNRI.Reston.VA.US (Guido van Rossum)
Date: Thu, 02 Sep 1999 09:31:48 -0400
Subject: [Python-bugs-list] pprint.pprint gives recursive message on my tuple :))
In-Reply-To: Your message of "Thu, 02 Sep 1999 02:14:05 +0200."
 <37CDC14D.E79CFD8@appliedbiometrics.com>
References: <37CDC14D.E79CFD8@appliedbiometrics.com>
Message-ID: <199909021331.JAA12506@eric.cnri.reston.va.us>

(You are using the python-bugs-list address wrongly.  This is a
distribution list used by the bug reporting system, see "python bugs
list" on the python homepage.)

There's a bug in your data: if a is the top-level list from your
pickle, t[-40] and t[-26] are the same object.

I would say there's also a bug in pprint, because there is no
recursion.  I'll ask Fred to look into it.

[Fred: the problem is exemplified by this:

>>> import pprint
>>> x = (('enth', '.: '), ((('10', '&'), ('nbsp', ';')), (('Amp', '. ('), ('N2', '), '))))
>>> y = x, x
>>> pprint.pprint(y)
((('enth', '.: '),
  ((('10', '&'), ('nbsp', ';')), (('Amp', '. ('), ('N2', '), ')))),
 <Recursion on tuple with id=1301816>)
>>> 

There is no actual recursion, just a repeated nested tuple.  I don't have
simpler cases that exhibit this behavior.

--Guido van Rossum (home page: http://www.python.org/~guido/)


From mz@pdm.pvt.net  Mon Sep  6 11:45:47 1999
From: mz@pdm.pvt.net (mz@pdm.pvt.net)
Date: Mon, 6 Sep 1999 06:45:47 -0400 (EDT)
Subject: [Python-bugs-list] Segmentation fault on range (PR#71)
Message-ID: <199909061045.GAA18798@python.org>

Full_Name: Milan Zamazal
Version: 1.5.2
OS: Debian GNU/Linux 2.1
Submission from: was.pvt.net (194.149.103.37)


When I start python and try to evaluate `range(1000000000)', I receive
segmentation fault:

  $ python
  Python 1.5.2 (#0, May  4 1999, 14:45:33)  [GCC 2.7.2.3] on linux2
  Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
  >>> range(1000000000)
  Segmentation fault

This can also be reproduced with Python 1.5.1 from the Debian 2.1 i386
distribution.




From jbley@cs.cmu.edu  Mon Sep  6 20:52:00 1999
From: jbley@cs.cmu.edu (jbley@cs.cmu.edu)
Date: Mon, 6 Sep 1999 15:52:00 -0400 (EDT)
Subject: [Python-bugs-list] Memory leak in audioop.c (PR#72)
Message-ID: <199909061952.PAA00592@python.org>

Full_Name: John Bley
Version: 1.5.2
OS: NT 4
Submission from: gs223.sp.cs.cmu.edu (128.2.242.27)


In audioop_ratecv (audioop.c), there is a memory leak.  The
memory allocated by these lines:
  prev_i = (int *) malloc(nchannels * sizeof(int));
  cur_i = (int *) malloc(nchannels * sizeof(int));

is never freed.



From jeremy@cnri.reston.va.us  Tue Sep  7 15:17:59 1999
From: jeremy@cnri.reston.va.us (jeremy@cnri.reston.va.us)
Date: Tue, 7 Sep 1999 10:17:59 -0400 (EDT)
Subject: [Python-bugs-list] exception during settrace line event dumps core (PR#73)
Message-ID: <199909071417.KAA28320@python.org>

Full_Name: Jeremy Hylton
Version: 1.5.2 (& current CVS)
OS: Linux & Solaris
Submission from: port1-16.jagunet.com (206.156.212.48)


If a trace function is installed via sys.settrace and the trace function
raises an exception while handling a line event, the interpreter gets stuck
in a loop where it raises line events recursively until it dumps core.

The problem only occurs with class based exceptions.  If you run python -X,
you get a traceback as expected.

The problem might by PyErr_NormalizeException, which appears a lot in the stack
trace below.

Here is a simple test program that demonstrates the problem:

import sys

class Tracer:
    def trace(self, frame, event, arg):
	if event == 'line':
	    print event
	    print frame.foo
	    print "oops"
	return self.trace

def test():
    x = 1

import test.pystone
t = Tracer()
sys.settrace(t.trace)
test()

#0  __pthread_mutex_unlock (mutex=0x40296858) at queue.h:57
#1  0x402410e0 in __libc_malloc (bytes=27) at malloc.c:2562
#2  0x8075772 in PyString_FromString (str=0x80fb954 "foo")
    at stringobject.c:145
#3  0x805bd48 in PyErr_SetString (exception=0x80d7778, string=0x80fb954 "foo")
    at errors.c:104
#4  0x8062f38 in PyMember_Get (addr=0x80eacc0 "\006", mlist=0x80b58e4, 
    name=0x80fb954 "foo") at structmember.c:158
#5  0x806e021 in frame_getattr (f=0x80eacc0, name=0x80fb954 "foo")
    at frameobject.c:66
#6  0x8074eaf in PyObject_GetAttrString (v=0x80eacc0, name=0x80fb954 "foo")
    at object.c:381
#7  0x8074fcd in PyObject_GetAttr (v=0x80eacc0, name=0x80fb940) at object.c:438
#8  0x8054bde in eval_code2 (co=0x80fb9c8, globals=0x80cefc8, locals=0x0, 
    args=0x80db6c4, argcount=4, kws=0x0, kwcount=0, defs=0x0, defcount=0, 
    owner=0x80f0b60) at ceval.c:1382
#9  0x80566a8 in call_function (func=0x80fbaf8, arg=0x80db6b8, kw=0x0)
    at ceval.c:2484
#10 0x805628a in PyEval_CallObjectWithKeywords (func=0x80efe48, arg=0x80dbe98, 
    kw=0x0) at ceval.c:2322
#11 0x8056027 in call_trace (p_trace=0x80eace0, p_newtrace=0x80eace0, 
    f=0x80eacc0, msg=0x80a6e6c "line", arg=0x80b6424) at ceval.c:2190
#12 0x805502b in eval_code2 (co=0x80d27c0, globals=0x80d5ca0, locals=0x0, 
    args=0x80d2df4, argcount=2, kws=0x0, kwcount=0, defs=0x0, defcount=0, 
    owner=0x80d5b00) at ceval.c:1543
#13 0x80566a8 in call_function (func=0x80d3e58, arg=0x80d2de8, kw=0x0)
    at ceval.c:2484
#14 0x805628a in PyEval_CallObjectWithKeywords (func=0x80ea540, arg=0x80d3df0, 
    kw=0x0) at ceval.c:2322
#15 0x8069312 in PyInstance_New (class=0x80d7778, arg=0x80d3df0, kw=0x0)
    at classobject.c:473
#16 0x8056393 in call_builtin (func=0x80d7778, arg=0x80d3df0, kw=0x0)
    at ceval.c:2362
#17 0x8056294 in PyEval_CallObjectWithKeywords (func=0x80d7778, arg=0x80d3df0, 
    kw=0x0) at ceval.c:2324
#18 0x805bebd in PyErr_NormalizeException (exc=0xbffff8f8, val=0xbffff8f4, 
    tb=0xbffff8f0) at errors.c:202
#19 0x805bf9a in PyErr_NormalizeException (exc=0xbffff8f8, val=0xbffff8f4, 
    tb=0xbffff8f0) at errors.c:227
#20 0x805bf9a in PyErr_NormalizeException (exc=0xbffff8f8, val=0xbffff8f4, 
    tb=0xbffff8f0) at errors.c:227
#21 0x805bf9a in PyErr_NormalizeException (exc=0xbffff8f8, val=0xbffff8f4, 
    tb=0xbffff8f0) at errors.c:227
#22 0x805bf9a in PyErr_NormalizeException (exc=0xbffff8f8, val=0xbffff8f4, 
    tb=0xbffff8f0) at errors.c:227
#23 0x805bf9a in PyErr_NormalizeException (exc=0xbffff8f8, val=0xbffff8f4, 
    tb=0xbffff8f0) at errors.c:227
[...]



From stockbridgen@cder.fda.gov  Fri Sep 10 12:34:14 1999
From: stockbridgen@cder.fda.gov (stockbridgen@cder.fda.gov)
Date: Fri, 10 Sep 1999 07:34:14 -0400 (EDT)
Subject: [Python-bugs-list] fpformat (PR#74)
Message-ID: <199909101134.HAA11342@python.org>

Full_Name: Norman Stockbridge
Version: 1.5.2
OS: Win95
Submission from: defender.fda.gov (198.77.181.2)


I'm new to Python, so maybe no one really uses fpformat, but I needed a
scientific notation formatted string. When fpformat.sci() is passed an arg
ALREADY in sci notation of the usual format, it produces either a correct
answer, an incorrect answer, or raises an exception, depending on the absolute
value of the exponent. The exponent is picked out and passed to eval(), but if
the exponent has a leading zero, eval() will attempt to interpret the exponent
as an octal number. Thus '1.23e005' and '1.23e-007' are interpreted correctly,
'1.23e010' and '1.23e-017' are interpreted incorrectly (as 1.23e8 and 1.23e-15),
and '1.23e-008' and '1.23e019' bomb.
My work-around is not to pass in anything already in scientific notation.



From guido@CNRI.Reston.VA.US  Fri Sep 10 15:34:13 1999
From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US)
Date: Fri, 10 Sep 1999 10:34:13 -0400 (EDT)
Subject: [Python-bugs-list] fpformat (PR#74)
Message-ID: <199909101434.KAA17050@python.org>

> I'm new to Python, so maybe no one really uses fpformat, but I
> needed a scientific notation formatted string. When fpformat.sci()
> is passed an arg ALREADY in sci notation of the usual format, it
> produces either a correct answer, an incorrect answer, or raises an
> exception, depending on the absolute value of the exponent. The
> exponent is picked out and passed to eval(), but if the exponent has
> a leading zero, eval() will attempt to interpret the exponent as an
> octal number. Thus '1.23e005' and '1.23e-007' are interpreted
> correctly, '1.23e010' and '1.23e-017' are interpreted incorrectly
> (as 1.23e8 and 1.23e-15), and '1.23e-008' and '1.23e019' bomb.

> My work-around is not to pass in anything already in scientific notation.

Thanks for reporting this!  There's a simple fix (which I'll check
into the CVS source tree momentarily) -- change the eval() call to
int().

I guess fpformat is mostly obsolete (the library docs for it say so)
because you can use things like "%10.6e" % x; the only use I see for
sci() is if you always want a 3-digit exponent.  Is this essential for 
you?

--Guido van Rossum (home page: http://www.python.org/~guido/)



From tim_one@email.msn.com  Sat Sep 11 02:46:56 1999
From: tim_one@email.msn.com (tim_one@email.msn.com)
Date: Fri, 10 Sep 1999 21:46:56 -0400 (EDT)
Subject: [Python-bugs-list] Very long lines fool tracebacks (PR#75)
Message-ID: <199909110146.VAA29819@python.org>

Full_Name: Tim Peters
Version: 1.5.2
OS: Win95
Submission from: 1cust239.tnt4.bos1.da.uu.net (63.21.45.239)


The traceback-printing mechanism calls fgets with a buffer of 1000 chars. 
Source lines larger than 1000 chars thus get treated as being more than one
line, causing the line actually printed to be off by a number of lines equal to
the number of times fgets gets fooled before reaching the target line number.

This popped up in c.l.py in what's likely the most unreasonable Python script
I've ever seen.  I don't have a lot of sympathy for that, but the off-by-3 here
then off-by-4 there (etc) tracebacks only made a miserable situation laughable
<wink>.

I'll look into cheap ways to fix this, and submit a patch if I find one.



From franzk@netal.com  Sat Sep 11 15:47:13 1999
From: franzk@netal.com (franzk@netal.com)
Date: Sat, 11 Sep 1999 10:47:13 -0400 (EDT)
Subject: [Python-bugs-list] Memory exception in python15.dll when calling IActiveScript::AddTypeLib (PR#76)
Message-ID: <199909111447.KAA14266@python.org>

Full_Name: Franz Krainer
Version: 1.5.2
OS: NT
Submission from: tk142052.telekabel.at (195.34.142.52)


A memory exception happens in python15.dll when an ActiveX Scripting Host
(Windows Scripting Host 2.0, for example) calls IActiveScript::AddTypeLib to add
a type library to the engine.

Use the following WSH 2.0 Beta 2 code to reproduce the problem:

--------------------Start of bugtest.ws----------------------------------
<job>
<reference object="Scripting.FileSystemObject" version="1.0"/>
<script language="Python">
# Testall - test core AX support.

# Test "Restricted Execution" (ie, IObjectSafety).
# This will fail if in a "restricted execution" environment, but
# will silenty do nothing of not restricted.  This same line in an MSIE
# script would cause an exception.
print "Importing win32api..."
import win32api
if 1==1:
	print "Hi"

WScript.Echo("Hello from WScript")

#fail
</script>
</job>
--------------------End of bugtest.ws------------------






From tim_one@email.msn.com  Sun Sep 12 04:05:55 1999
From: tim_one@email.msn.com (tim_one@email.msn.com)
Date: Sat, 11 Sep 1999 23:05:55 -0400 (EDT)
Subject: [Python-bugs-list] Rare bad tracebacks under -O (PR#77)
Message-ID: <199909120305.XAA24808@python.org>

Full_Name: Tim Peters
Version: 1.5.2
OS: Win95
Submission from: 1cust211.tnt2.bos1.da.uu.net (63.20.160.211)


For a long time I've seen absurd tracebacks under -O (e.g., negative line
numbers), but very rarely.  Since I was looking at tracebacks anyway, thought
I'd track it down.  Turns out to be Guido's only predictable blind spot <wink --
"char" is signed on some non-GvR systems>.  Patch follows.

*** Python/Old/compile.c	Thu Jan 28 09:08:08 1999
--- Python/New/compile.c	Sat Sep 11 22:53:26 1999
***************
*** 3451,3457 ****
  	int addrq;
  {
  	int size = PyString_Size(co->co_lnotab) / 2;
! 	char *p = PyString_AsString(co->co_lnotab);
  	int line = co->co_firstlineno;
  	int addr = 0;
  	while (--size >= 0) {
--- 3451,3457 ----
  	int addrq;
  {
  	int size = PyString_Size(co->co_lnotab) / 2;
! 	unsigned char *p = (unsigned char*)PyString_AsString(co->co_lnotab);
  	int line = co->co_firstlineno;
  	int addr = 0;
  	while (--size >= 0) {




From frido@nl.euro.net  Sun Sep 12 16:57:13 1999
From: frido@nl.euro.net (frido@nl.euro.net)
Date: Sun, 12 Sep 1999 11:57:13 -0400 (EDT)
Subject: [Python-bugs-list] stdin and arguments (PR#78)
Message-ID: <199909121557.LAA09946@python.org>

Hi,

When using python to pipe some source code like so:

cat test.py | python - foo bar

it doesn't give the arguments foo and bar too test.py but thinks
it is another source file, resulting in a file not found error.

What I would like to do is pipe it over a ssh connection + a pickled/base64 
obkject as an argument to do pseudo RPC stuf .


Thank you for your time,
                                   .
                                  *
 Frido Ferdinand                ***             EuroNet Internet BV
 Implementation Team         .*******'          Herengracht 208 - 214
 frido@nl.euro.net             ** **            1016 BS Amsterdam
                             .*     *.          T: +31 20 5355555





From tim_one@email.msn.com  Sun Sep 12 22:27:40 1999
From: tim_one@email.msn.com (Tim Peters)
Date: Sun, 12 Sep 1999 17:27:40 -0400
Subject: [Python-bugs-list] stdin and arguments (PR#78)
In-Reply-To: <199909121557.LAA09946@python.org>
Message-ID: <000001befd65$a51e4060$8a2d153f@tim>

[frido@nl.euro.net]
> When using python to pipe some source code like so:
>
> cat test.py | python - foo bar
>
> it doesn't give the arguments foo and bar too test.py but thinks
> it is another source file, resulting in a file not found error.

I agree this seems wrong.  For the short term, you can do:

    cat test.py | python -- - foo bar

test.py then sees:

    ['-', 'foo', 'bar']

in sys.argv, so just ignore sys.argv[0] when it's "-".




From tim_one@email.msn.com  Sun Sep 12 22:29:33 1999
From: tim_one@email.msn.com (tim_one@email.msn.com)
Date: Sun, 12 Sep 1999 17:29:33 -0400 (EDT)
Subject: [Python-bugs-list] stdin and arguments (PR#78)
Message-ID: <199909122129.RAA14149@python.org>

[frido@nl.euro.net]
> When using python to pipe some source code like so:
>
> cat test.py | python - foo bar
>
> it doesn't give the arguments foo and bar too test.py but thinks
> it is another source file, resulting in a file not found error.

I agree this seems wrong.  For the short term, you can do:

    cat test.py | python -- - foo bar

test.py then sees:

    ['-', 'foo', 'bar']

in sys.argv, so just ignore sys.argv[0] when it's "-".





From guido@CNRI.Reston.VA.US  Sun Sep 12 23:20:38 1999
From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US)
Date: Sun, 12 Sep 1999 18:20:38 -0400 (EDT)
Subject: [Python-bugs-list] stdin and arguments (PR#78)
Message-ID: <199909122220.SAA14712@python.org>

> When using python to pipe some source code like so:
> 
> cat test.py | python - foo bar
> 
> it doesn't give the arguments foo and bar too test.py but thinks
> it is another source file, resulting in a file not found error.

On what platform?  I can't reproduce this.  If my file test.py
contains "import sys; print sys.argv" it correctly prints ['-', 'foo',
'bar'].  This on Solaris.  I'm pretty sure the behavior is the same
across Unix.  On Windows, I indeed get the error you report -- but
your mention of ssh makes me doubt that you are on Windows.

> What I would like to do is pipe it over a ssh connection + a pickled/base64 
> obkject as an argument to do pseudo RPC stuf .

This should work.

(PS if you use the bug report form found via
python.org/search/search_bugs.html instead of mailing directly to
python-bugs-list, you would have been prompted for the platform and
Python version etc.  Please don't mail directly except in response to
a reply like this one.)

--Guido van Rossum (home page: http://www.python.org/~guido/)



From frido@nl.euro.net  Mon Sep 13 08:00:16 1999
From: frido@nl.euro.net (frido@nl.euro.net)
Date: Mon, 13 Sep 1999 03:00:16 -0400 (EDT)
Subject: [Python-bugs-list] stdin and arguments (PR#78)
Message-ID: <199909130700.DAA23775@python.org>

> > When using python to pipe some source code like so:
> > 
> > cat test.py | python - foo bar
> > 
> > it doesn't give the arguments foo and bar too test.py but thinks
> > it is another source file, resulting in a file not found error.
> 
> On what platform?  I can't reproduce this.  If my file test.py
> contains "import sys; print sys.argv" it correctly prints ['-', 'foo',
> 'bar'].  This on Solaris.  I'm pretty sure the behavior is the same
> across Unix.  On Windows, I indeed get the error you report -- but
> your mention of ssh makes me doubt that you are on Windows.

-=-=-=-
nightfall: ~ $ cat bla.py 
#!/usr/bin/python

import sys

print sys.argv
nightfall: ~ $ cat bla.py | python - test
python: can't open file 'test'
nightfall: ~ $ cat bla.py | python -- - test
['-', 'test']
nightfall: ~ $ uname -a
Linux nightfall.euronet.nl 2.2.6-15apmac #1 Mon May 31 03:54:09 EDT 1999 ppc unknown
-=-=-=-

Python 1.5.1 (#1, Apr 19 1999, 03:44:48)  [GCC egcs-2.91.66 19990314 
(e on linux-ppc)

Tested on Linux/intel and Linux/ppc (Redhat/LinuxPPC) :( , both produce the 
same error. Solaris seems to work. Don't know about freeBSD yet. 

Thanx, Frido
                                   .
                                  *
 Frido Ferdinand                ***             EuroNet Internet BV
 Implementation Team         .*******'          Herengracht 208 - 214
 frido@nl.euro.net             ** **            1016 BS Amsterdam
                             .*     *.          T: +31 20 5355555





From tim_one@email.msn.com  Mon Sep 13 09:37:39 1999
From: tim_one@email.msn.com (Tim Peters)
Date: Mon, 13 Sep 1999 04:37:39 -0400
Subject: [Python-bugs-list] stdin and arguments (PR#78)
In-Reply-To: <199909130700.DAA23775@python.org>
Message-ID: <000201befdc3$3da49980$7a2d153f@tim>

[frido@nl.euro.net]
> nightfall: ~ $ cat bla.py
> #!/usr/bin/python
>
> import sys
>
> print sys.argv
> nightfall: ~ $ cat bla.py | python - test
> python: can't open file 'test'
> nightfall: ~ $ cat bla.py | python -- - test
> ['-', 'test']
> nightfall: ~ $ uname -a
> Linux nightfall.euronet.nl 2.2.6-15apmac #1 Mon May 31 03:54:09
> EDT 1999 ppc unknown
> -=-=-=-
>
> Python 1.5.1 (#1, Apr 19 1999, 03:44:48)  [GCC egcs-2.91.66 19990314
> (e on linux-ppc)
>
> Tested on Linux/intel and Linux/ppc (Redhat/LinuxPPC) :( , both
> produce the same error. Solaris seems to work. Don't know about
> freeBSD yet.

I notice you're using Python 1.5.1.  It's hard to believe that it could
matter in this case, but you should think about upgrading to Python 1.5.2
(1.5.1 is no longer supported -- well over a year old).

In 1.5.2 (for sure, and probably also in 1.5.1), Python's behavior here will
be a direct result of what the platform getopt(3) function returns.  So the
above tells me that getopt varies across platforms when it sees a lone "-",
and that's all too easy to believe (looking at various getopt manpages on
the web showed that some authors were aware of this case, but others
apparently weren't).

Python has its own very simple version of getopt that it uses under Windows,
and that also displays this bug.  Last night I mailed a patch to Guido to
repair it, and I suppose Python should start to use that on every platform.

Luckily, the "python -- - test" form should work the same everywhere (the
intended meaning of "--" is clear to everyone), so stick to that for now.




From tim_one@email.msn.com  Mon Sep 13 09:39:27 1999
From: tim_one@email.msn.com (tim_one@email.msn.com)
Date: Mon, 13 Sep 1999 04:39:27 -0400 (EDT)
Subject: [Python-bugs-list] stdin and arguments (PR#78)
Message-ID: <199909130839.EAA29649@python.org>

[frido@nl.euro.net]
> nightfall: ~ $ cat bla.py
> #!/usr/bin/python
>
> import sys
>
> print sys.argv
> nightfall: ~ $ cat bla.py | python - test
> python: can't open file 'test'
> nightfall: ~ $ cat bla.py | python -- - test
> ['-', 'test']
> nightfall: ~ $ uname -a
> Linux nightfall.euronet.nl 2.2.6-15apmac #1 Mon May 31 03:54:09
> EDT 1999 ppc unknown
> -=-=-=-
>
> Python 1.5.1 (#1, Apr 19 1999, 03:44:48)  [GCC egcs-2.91.66 19990314
> (e on linux-ppc)
>
> Tested on Linux/intel and Linux/ppc (Redhat/LinuxPPC) :( , both
> produce the same error. Solaris seems to work. Don't know about
> freeBSD yet.

I notice you're using Python 1.5.1.  It's hard to believe that it could
matter in this case, but you should think about upgrading to Python 1.5.2
(1.5.1 is no longer supported -- well over a year old).

In 1.5.2 (for sure, and probably also in 1.5.1), Python's behavior here will
be a direct result of what the platform getopt(3) function returns.  So the
above tells me that getopt varies across platforms when it sees a lone "-",
and that's all too easy to believe (looking at various getopt manpages on
the web showed that some authors were aware of this case, but others
apparently weren't).

Python has its own very simple version of getopt that it uses under Windows,
and that also displays this bug.  Last night I mailed a patch to Guido to
repair it, and I suppose Python should start to use that on every platform.

Luckily, the "python -- - test" form should work the same everywhere (the
intended meaning of "--" is clear to everyone), so stick to that for now.





From ajung@sz-sb.de  Mon Sep 13 12:29:10 1999
From: ajung@sz-sb.de (ajung@sz-sb.de)
Date: Mon, 13 Sep 1999 07:29:10 -0400 (EDT)
Subject: [Python-bugs-list] Coredump in moduleobjectc.c:134 (PR#79)
Message-ID: <199909131129.HAA01720@python.org>

Full_Name: Andreas Jung
Version: 1.5.2
OS: Solaris 2.6/Sparc
Submission from: saarland.sz-sb.de (212.88.192.10)


(ojs@bonnie:~/PROD/lib/site-python/ojs) 73 : !gdb
gdb python core
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (sparc-sun-solaris2.4), Copyright 1996 Free Software Foundation,
Inc...
Core was generated by `python -v prod_descr.py'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libsocket.so.1...done.
Reading symbols from /usr/lib/libnsl.so.1...done.
Reading symbols from /usr/lib/libdl.so.1...done.
Reading symbols from /usr/lib/libm.so.1...done.
Reading symbols from /usr/lib/libc.so.1...done.
Reading symbols from /usr/lib/libmp.so.2...done.
Reading symbols from
/usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1...done.
Reading symbols from
/ojs/home/ojs/PROD/lib/python1.5/site-packages/DateTime/mxDateTime/mxDateTime.so...done.
#0  0x49220 in _PyModule_Clear (m=0xc76e4) at moduleobject.c:134
134                     if (value != Py_None && PyString_Check(key)) {
(gdb) bt
#0  0x49220 in _PyModule_Clear (m=0xc76e4) at moduleobject.c:134
#1  0x29fe4 in PyImport_Cleanup () at import.c:308
#2  0x30d18 in Py_Finalize () at pythonrun.c:206
#3  0x21c8c in Py_Main (argc=3, argv=0xeffff964) at main.c:298
#4  0x216e4 in main (argc=3, argv=0xeffff964) at python.c:12


I get the traceback above from a small module that
contains just 2 import statements. One module contains just
the declaration of 2 classes and the second module contains some
dicts,lists...nothing special. When I change the order of both import
statements in the main script no core dump occurs.

Any idea ?

Andreas 



From jeremy@cnri.reston.va.us  Mon Sep 13 23:41:44 1999
From: jeremy@cnri.reston.va.us (jeremy@cnri.reston.va.us)
Date: Mon, 13 Sep 1999 18:41:44 -0400 (EDT)
Subject: [Python-bugs-list] random.randint/randrange fails for large range (PR#80)
Message-ID: <199909132241.SAA06834@python.org>

Full_Name: Jeremy Hylton
Version: 1.5.2
OS: 
Submission from: bitdiddle.cnri.reston.va.us (132.151.1.41)


>>> x = 2**30
>>> y = -2**30
>>> random.randint(y, x)
Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python1.5/whrandom.py", line 92, in randint
    return self.randrange(a, b+1)
  File "/usr/local/lib/python1.5/whrandom.py", line 120, in randrange
    return istart + int(self.random() *
OverflowError: integer subtraction

I think the solution is to change line 120 so that it performs all
the calculations on longs and converts to int just before it returns.





From tim_one@email.msn.com  Tue Sep 14 02:32:13 1999
From: tim_one@email.msn.com (Tim Peters)
Date: Mon, 13 Sep 1999 21:32:13 -0400
Subject: [Python-bugs-list] random.randint/randrange fails for large range (PR#80)
In-Reply-To: <199909132241.SAA06834@python.org>
Message-ID: <000001befe50$f99ff0c0$e7a0143f@tim>

[Jeremy Hylton]
> >>> x = 2**30
> >>> y = -2**30
> >>> random.randint(y, x)
> Traceback (innermost last):
> ...
> OverflowError: integer subtraction
>
> I think the solution is to change line 120 so that it performs all
> the calculations on longs and converts to int just before it returns.

I consider this an obscure way of spelling the truth:  "this algorithm is
too weak to produce acceptable results for a range that large".  I
personally don't trust whrandom to choose from a range larger than about
2**15 elements (already a bit beyond the resolution of its underlying
generators).

The other consideration is sane-case speed, so if it's decided to go ahead
and produce bogus results <wink>, better to wrap the method body in
try/except_OverflowError and bite the expense of the int->long->int business
only when necessary.

Overall, if something *needs* to be done here, documentation may be the best
answer.  Note that on a C-long==64-bits machine, it's easy to feed randint a
non-overflowing range larger than the resolution of a double, and randint
has no chance at all of producing a reasonable approximation to randomness
then.

IOW, numerical algorithms have limits, and those need to be documented, or
(preferably, but sometimes just too expensive to do so) enforced, or (best
of all, but very expensive and difficult) removed via much more elaborate
algorithms.




From tim_one@email.msn.com  Tue Sep 14 02:34:13 1999
From: tim_one@email.msn.com (tim_one@email.msn.com)
Date: Mon, 13 Sep 1999 21:34:13 -0400 (EDT)
Subject: [Python-bugs-list] random.randint/randrange fails for large range (PR#80)
Message-ID: <199909140134.VAA23063@python.org>

[Jeremy Hylton]
> >>> x = 2**30
> >>> y = -2**30
> >>> random.randint(y, x)
> Traceback (innermost last):
> ...
> OverflowError: integer subtraction
>
> I think the solution is to change line 120 so that it performs all
> the calculations on longs and converts to int just before it returns.

I consider this an obscure way of spelling the truth:  "this algorithm is
too weak to produce acceptable results for a range that large".  I
personally don't trust whrandom to choose from a range larger than about
2**15 elements (already a bit beyond the resolution of its underlying
generators).

The other consideration is sane-case speed, so if it's decided to go ahead
and produce bogus results <wink>, better to wrap the method body in
try/except_OverflowError and bite the expense of the int->long->int business
only when necessary.

Overall, if something *needs* to be done here, documentation may be the best
answer.  Note that on a C-long==64-bits machine, it's easy to feed randint a
non-overflowing range larger than the resolution of a double, and randint
has no chance at all of producing a reasonable approximation to randomness
then.

IOW, numerical algorithms have limits, and those need to be documented, or
(preferably, but sometimes just too expensive to do so) enforced, or (best
of all, but very expensive and difficult) removed via much more elaborate
algorithms.





From jeremy@cnri.reston.va.us  Tue Sep 14 04:18:07 1999
From: jeremy@cnri.reston.va.us (Jeremy Hylton)
Date: Mon, 13 Sep 1999 23:18:07 -0400 (EDT)
Subject: [Python-bugs-list] random.randint/randrange fails for large range (PR#80)
In-Reply-To: <000001befe50$f99ff0c0$e7a0143f@tim>
References: <199909132241.SAA06834@python.org>
 <000001befe50$f99ff0c0$e7a0143f@tim>
Message-ID: <14301.48751.668225.690303@bitdiddle.cnri.reston.va.us>

The documentation for the random/whrandom modules certainly needs to
be improved.  It has confusing links between random and whrandom. The
randint function, which is deprecated according to a comment in code,
is included in the docs, but randrange, it's replacement, is not.

I was looking at a different algorithm this afternooon, an MLCG by
Pierre L'Ecuyer, that describes itself as a 32-bit random number
generator.  I would guess that it could generate a random number over
a 32-bit range; of course, I don't understnad the issue well enough so 
I'll have to read a little more.

Jeremy


From jeremy@cnri.reston.va.us  Tue Sep 14 04:18:18 1999
From: jeremy@cnri.reston.va.us (jeremy@cnri.reston.va.us)
Date: Mon, 13 Sep 1999 23:18:18 -0400 (EDT)
Subject: [Python-bugs-list] random.randint/randrange fails for large range (PR#80)
Message-ID: <199909140318.XAA11368@python.org>

The documentation for the random/whrandom modules certainly needs to
be improved.  It has confusing links between random and whrandom. The
randint function, which is deprecated according to a comment in code,
is included in the docs, but randrange, it's replacement, is not.

I was looking at a different algorithm this afternooon, an MLCG by
Pierre L'Ecuyer, that describes itself as a 32-bit random number
generator.  I would guess that it could generate a random number over
a 32-bit range; of course, I don't understnad the issue well enough so 
I'll have to read a little more.

Jeremy



From tim_one@email.msn.com  Wed Sep 15 06:19:44 1999
From: tim_one@email.msn.com (Tim Peters)
Date: Wed, 15 Sep 1999 01:19:44 -0400
Subject: [Python-bugs-list] random.randint/randrange fails for large range (PR#80)
In-Reply-To: <14301.48751.668225.690303@bitdiddle.cnri.reston.va.us>
Message-ID: <000201beff39$ec5a1d20$612d153f@tim>

[Jeremy Hylton]
> The documentation for the random/whrandom modules certainly needs to
> be improved.  It has confusing links between random and whrandom. The
> randint function, which is deprecated according to a comment in code,
> is included in the docs, but randrange, it's replacement, is not.

May I introduce you to Fred Drake <wink>?

> I was looking at a different algorithm this afternooon, an MLCG by
> Pierre L'Ecuyer, that describes itself as a 32-bit random number
> generator.  I would guess that it could generate a random number over
> a 32-bit range; of course, I don't understnad the issue well enough so
> I'll have to read a little more.

L'Ecuyer is indeed one of the few trustworthy names in the field.  Ivan
Frohne has implemented the best algorithms known (including L'Ecuyer's) for
Python already.  I don't think you can replace Python's WH, though:  it's
the fastest, has no obvious patterns to trip newbies up, and old code may
very well rely on tucked-away WH seed values.  People wanting more than that
can get the very best from Ivan.  The docs for the builtin stuff should
emphasize that it's just a basic facility for casual use, and indeed takes
dubious shortcuts in the interest of speed and simplicity (e.g., it's not
even thread-safe!  nor, I think, should it be -- multiplexing WH across
threads is a *bad* way to generate random #s in a multithreaded app anyway).




From tim_one@email.msn.com  Wed Sep 15 06:21:43 1999
From: tim_one@email.msn.com (tim_one@email.msn.com)
Date: Wed, 15 Sep 1999 01:21:43 -0400 (EDT)
Subject: [Python-bugs-list] random.randint/randrange fails for large range (PR#80)
Message-ID: <199909150521.BAA09348@python.org>

[Jeremy Hylton]
> The documentation for the random/whrandom modules certainly needs to
> be improved.  It has confusing links between random and whrandom. The
> randint function, which is deprecated according to a comment in code,
> is included in the docs, but randrange, it's replacement, is not.

May I introduce you to Fred Drake <wink>?

> I was looking at a different algorithm this afternooon, an MLCG by
> Pierre L'Ecuyer, that describes itself as a 32-bit random number
> generator.  I would guess that it could generate a random number over
> a 32-bit range; of course, I don't understnad the issue well enough so
> I'll have to read a little more.

L'Ecuyer is indeed one of the few trustworthy names in the field.  Ivan
Frohne has implemented the best algorithms known (including L'Ecuyer's) for
Python already.  I don't think you can replace Python's WH, though:  it's
the fastest, has no obvious patterns to trip newbies up, and old code may
very well rely on tucked-away WH seed values.  People wanting more than that
can get the very best from Ivan.  The docs for the builtin stuff should
emphasize that it's just a basic facility for casual use, and indeed takes
dubious shortcuts in the interest of speed and simplicity (e.g., it's not
even thread-safe!  nor, I think, should it be -- multiplexing WH across
threads is a *bad* way to generate random #s in a multithreaded app anyway).





From skip@mojam.com  Wed Sep 15 22:54:39 1999
From: skip@mojam.com (skip@mojam.com)
Date: Wed, 15 Sep 1999 17:54:39 -0400 (EDT)
Subject: [Python-bugs-list] Byte code compiler missed duplicate keyword args (PR#81)
Message-ID: <199909152154.RAA08345@python.org>

Full_Name: Skip Montanaro
Version: 1.5.2
OS: Linux
Submission from: uwire5.uwire.nunet.net (199.249.165.174)


Python 1.5.2 silently allows multiple keyword arguments in function definitions
as demonstrated by the following code snippet:

Python 1.5.2+ (#35, Aug 26 1999, 10:08:41)  [GCC 2.7.2.3] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> def f(a=0,a=0):
...   print a
... 
>>> f(3)
0

This was reported on the comp.lang.python by François Pinard.  I haven't seen
it fly by the bugs list so wanted to make sure it got recorded.

Skip




From guido@CNRI.Reston.VA.US  Wed Sep 15 22:58:10 1999
From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US)
Date: Wed, 15 Sep 1999 17:58:10 -0400 (EDT)
Subject: [Python-bugs-list] Byte code compiler missed duplicate keyword args (PR#81)
Message-ID: <199909152158.RAA08502@python.org>

> Python 1.5.2 silently allows multiple keyword arguments in function definitions
> as demonstrated by the following code snippet:
> 
> Python 1.5.2+ (#35, Aug 26 1999, 10:08:41)  [GCC 2.7.2.3] on linux2
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> >>> def f(a=0,a=0):
> ...   print a
> ... 

Oops, you're right.  It's not restricted to arguments with defaults
either:

>>> def f(a,a): print a

>>> f(1,2)
2

--Guido van Rossum (home page: http://www.python.org/~guido/)



From mhammond@skippinet.com.au  Wed Sep 15 23:48:50 1999
From: mhammond@skippinet.com.au (mhammond@skippinet.com.au)
Date: Wed, 15 Sep 1999 18:48:50 -0400 (EDT)
Subject: franzk@netal.com: [Python-bugs-list] Memory exception in python15.dll when calling IActi  veScript::AddTypeLib (PR#76)
Message-ID: <199909152248.SAA09992@python.org>

This was only just reported to me!  It is definately a bug in the
Active Scripting implementation, so I guess it doesnt belong in the
bugs list.  If you did decide to make a seperate category for the
Windows extensions I would be happy to word it appropriately, but Im
not sure it makes sense for my bugs to go there...

Mark.

> Do you have any insights here?  I'm not sure how to file this in the
> bugs list...
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>
>
> ------- Forwarded Message
>
> Date:    Sat, 11 Sep 1999 10:47:13 -0400
> From:    franzk@netal.com
> To:      python-bugs-list@python.org
> cc:      bugs-py@python.org
> Subject: [Python-bugs-list] Memory exception in python15.dll
> when calling IActi
> 	  veScript::AddTypeLib (PR#76)
>
> Full_Name: Franz Krainer
> Version: 1.5.2
> OS: NT
> Submission from: tk142052.telekabel.at (195.34.142.52)
>
>
> A memory exception happens in python15.dll when an ActiveX
> Scripting Host
> (Windows Scripting Host 2.0, for example) calls
> IActiveScript::AddTypeLib to ad
> d
> a type library to the engine.
>
> Use the following WSH 2.0 Beta 2 code to reproduce the problem:
>
> - --------------------Start of
> bugtest.ws----------------------------------
> <job>
> <reference object="Scripting.FileSystemObject" version="1.0"/>
> <script language="Python">
> # Testall - test core AX support.
>
> # Test "Restricted Execution" (ie, IObjectSafety).
> # This will fail if in a "restricted execution" environment, but
> # will silenty do nothing of not restricted.  This same line
> in an MSIE
> # script would cause an exception.
> print "Importing win32api..."
> import win32api
> if 1==1:
> 	print "Hi"
>
> WScript.Echo("Hello from WScript")
>
> #fail
> </script>
> </job>
> - --------------------End of bugtest.ws------------------
>
>
>
>
>
> _______________________________________________
> Python-bugs-list maillist  -  Python-bugs-list@python.org
> http://www.python.org/mailman/listinfo/python-bugs-list
>
> ------- End of Forwarded Message
>




From guido@cnri.reston.va.us  Thu Sep 16 05:13:26 1999
From: guido@cnri.reston.va.us (guido@cnri.reston.va.us)
Date: Thu, 16 Sep 1999 00:13:26 -0400 (EDT)
Subject: [Python-bugs-list] [comp.lang.python] Bug in Tkinter.ScrolledText (and fix). (PR#82)
Message-ID: <199909160413.AAA15433@python.org>

(From the newsgroup:)

Message-ID: <199909151925.MAA02285@wartch.sapros.com>
To: python-list@python.org
Subject: Bug in Tkinter.ScrolledText (and fix).
Date: Wed, 15 Sep 1999 12:25:01 -0700
From: Peter Haight <peterh@sapros.com>
Newsgroups: comp.lang.python


If you create multiple ScrolledText widgets it uses the same name for all
of them. This is because the line cnf['name'] = 'text' clobbers the default
value for cnf which was created inside class scope. This means the next time
__init__ is called with no cnf argument, cnf now has the default value of {
'name' : 'text' } instead of {}.

I'm including some sample code and a patch.

----------- PATCH ----------------
--- ScrolledText.py.orig	Wed Sep 15 12:09:54 1999
+++ ScrolledText.py	Wed Sep 15 12:15:22 1999
@@ -14,7 +14,9 @@
 from Tkinter import _cnfmerge
 
 class ScrolledText(Text):
-	def __init__(self, master=None, cnf={}, **kw):
+	def __init__(self, master=None, cnf=None, **kw):
+		if cnf is None:
+			cnf = {}
 		if kw:
 			cnf = _cnfmerge((cnf, kw))
 		fcnf = {}
-----------------------------------

-------- SAMPLE CODE --------------

#!/usr/bin/env python

from Tkinter import *
import ScrolledText

class App(Frame):
	def __init__(self, master=None):
		Frame.__init__(self, master)
		self.pack(expand=1, fill=BOTH)
		self.texts = []
		self._create_widgets()

	def _create_widgets(self):
		self.entry = Entry(self)
		self.entry.pack(side=TOP, expand=0, fill=X)
		self.entry.bind('<Return>', self.change)
		self.entry.focus_set()

		self.pane = Frame(self)
		self.pane.pack(side=TOP)
		for i in range(6):
			t = ScrolledText.ScrolledText(self)
			#t = Text(self)
			print 'Created text:', t
			t.insert('end', 'Screen %i' % i)
			self.texts.append(t)

		self.curscreen = 0
		self.texts[0].pack(side=TOP, expand=1, fill=BOTH)
	
	def change(self, event):
		try:
			num = int(self.entry.get())
		except ValueError:
			return
		if num == self.curscreen: return
		if num >= 6: return
		self.texts[self.curscreen].forget()
		self.texts[num].pack(side=TOP, expand=1, fill=BOTH)
		self.curscreen = num

def main():
	a = App()
	a.mainloop()

if __name__ == '__main__':
	main()
-----------------------------------



From guido@CNRI.Reston.VA.US  Thu Sep 16 15:04:59 1999
From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US)
Date: Thu, 16 Sep 1999 10:04:59 -0400 (EDT)
Subject: [Python-bugs-list] Coredump in moduleobjectc.c:134 (PR#79)
Message-ID: <199909161404.KAA00475@python.org>

> I was able to get more information. The problem might occur with the following code:
> 
> * module.py*
> 
> from prod_support import read_current_prodids
> 
> PRODIDS = read_current_prodids()
> 
> 
> * main.py *
> 
> import module.py
> 
> 
> When I run python on main.py I get the bus error. When I switch module.py to:
> 
> import prod_support
> PRODIDS = prod_support.read_current_prodids()
> 
> everything is ok. The function read_current_prodids() uses DCOracle (Digicool/Zope).
> I'm not sure if this causes the problem - I'll try to figure it out.

Probably something in the prod_support module causes the problem.  I'm 
quite sure the problem is not in Python itself, so the Python bugs
list is not the place to report the bug.

--Guido van Rossum (home page: http://www.python.org/~guido/)



From gry@ll.mit.edu  Fri Sep 17 19:56:50 1999
From: gry@ll.mit.edu (gry@ll.mit.edu)
Date: Fri, 17 Sep 1999 14:56:50 -0400 (EDT)
Subject: [Python-bugs-list] segfault in PyInt_FromLong (PR#83)
Message-ID: <199909171856.OAA05097@python.org>

Full_Name: george young
Version: 1.5.2b2
OS: linux(suse 6.1)
Submission from: llproxy.ll.mit.edu (129.55.200.20)


gcc version 2.95.1 19990816, Python-1.5.2b2, linux(SuSE 6.1)
unpack tar file; ./configure --prefix=/opt/python; make
./python
crashes immediately with sigsegv.
gdb shows:
#0  PyInt_FromLong (ival=17105586) at intobject.c:152
#1  0x805e6ea in _PySys_Init () at sysmodule.c:404
#2  0x805c6c7 in Py_Initialize () at pythonrun.c:146
#3  0x804fe6a in Py_Main (argc=1, argv=0xbffff754) at main.c:245
#4  0x804fa82 in main (argc=1, argv=0xbffff754) at python.c:12
 print free_list
$1 = (PyIntObject *) 0x1




From guido@CNRI.Reston.VA.US  Fri Sep 17 20:15:00 1999
From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US)
Date: Fri, 17 Sep 1999 15:15:00 -0400 (EDT)
Subject: [Python-bugs-list] segfault in PyInt_FromLong (PR#83)
Message-ID: <199909171915.PAA05836@python.org>

> Full_Name: george young
> Version: 1.5.2b2
> OS: linux(suse 6.1)
> Submission from: llproxy.ll.mit.edu (129.55.200.20)
> 
> gcc version 2.95.1 19990816, Python-1.5.2b2, linux(SuSE 6.1)
> unpack tar file; ./configure --prefix=/opt/python; make
> ./python
> crashes immediately with sigsegv.
> gdb shows:
> #0  PyInt_FromLong (ival=17105586) at intobject.c:152
> #1  0x805e6ea in _PySys_Init () at sysmodule.c:404
> #2  0x805c6c7 in Py_Initialize () at pythonrun.c:146
> #3  0x804fe6a in Py_Main (argc=1, argv=0xbffff754) at main.c:245
> #4  0x804fa82 in main (argc=1, argv=0xbffff754) at python.c:12
>  print free_list
> $1 = (PyIntObject *) 0x1

I notice you're still using Python 1.5.2b2.  Why not upgrade to Python 
1.5.2 final?

Also, I'm sure I cannot reproduce this.  (Many people have
successfully built Python, including 1.5.2b2, on various Linux
platforms.)

Could it be that you have a buggy libc or a buggy gcc?

--Guido van Rossum (home page: http://www.python.org/~guido/)




From gry@ll.mit.edu  Fri Sep 17 21:53:24 1999
From: gry@ll.mit.edu (gry@ll.mit.edu)
Date: Fri, 17 Sep 1999 16:53:24 -0400 (EDT)
Subject: [Python-bugs-list] segfault in PyInt_FromLong (PR#83)
Message-ID: <199909172053.QAA08100@python.org>

On Fri, Sep 17, 1999 at 03:14:46PM -0400, Guido van Rossum wrote:
> > Full_Name: george young
> > Version: 1.5.2b2
> > OS: linux(suse 6.1)
> > Submission from: llproxy.ll.mit.edu (129.55.200.20)
> > 
> > gcc version 2.95.1 19990816, Python-1.5.2b2, linux(SuSE 6.1)
> > unpack tar file; ./configure --prefix=/opt/python; make
> > ./python
> > crashes immediately with sigsegv.
> > gdb shows:
> > #0  PyInt_FromLong (ival=17105586) at intobject.c:152
> > #1  0x805e6ea in _PySys_Init () at sysmodule.c:404
> > #2  0x805c6c7 in Py_Initialize () at pythonrun.c:146
> > #3  0x804fe6a in Py_Main (argc=1, argv=0xbffff754) at main.c:245
> > #4  0x804fa82 in main (argc=1, argv=0xbffff754) at python.c:12
> >  print free_list
> > $1 = (PyIntObject *) 0x1
> 
> I notice you're still using Python 1.5.2b2.  Why not upgrade to Python 
> 1.5.2 final?
> 
> Also, I'm sure I cannot reproduce this.  (Many people have
> successfully built Python, including 1.5.2b2, on various Linux
> platforms.)
> 
> Could it be that you have a buggy libc or a buggy gcc?

1.5.2 final fixed it. 

The problem correlated with the gcc -fstrict-aliasing
flag, just for your info; i.e. appending -fno-strict-aliasing to the OPT
value made it go away.

Thanks much,

	George

-- 
George Young,  Rm. L-204		gry@ll.mit.edu
MIT Lincoln Laboratory
244 Wood St.
Lexington, Massachusetts  02420-9108	(781) 981-2756



From CashCow@idirect.com  Sun Sep 19 14:11:04 1999
From: CashCow@idirect.com (CashCow@idirect.com)
Date: Sun, 19 Sep 1999 09:11:04 -0400 (EDT)
Subject: [Python-bugs-list] Buy An Internet Business (PR#84)
Message-ID: <199909191311.JAA21521@python.org>

This is a one time message, if it reached you by mistake please accept 
my apologies, disregard and delete. Thank you.

Dear Entrepreneur:

Please take the time to read this. It can start you on the road to an 
easier life as an internet businessman/woman.
Thank you.



EBIZ = 1,2,3...4 CASH!

1.	READ THIS ALL THE WAY THROUGH!
2.	FOLLOW THE INSTRUCTIONS!
3.	GO BUY A BIG BAG...
4. 	ALL THE CASH!



THE PROGRAM
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

INCREDIBLE $0 to $50,000 in 90 days!!!

Dear Friend,

You can earn $50,000 or more in next the 90 days sending e-mail. Seem 
impossible? Read on for details.

"AS SEEN ON NATIONAL TV"
Thank you for your time and interest. This is the letter you've been 
reading about in the news lately.  Due to the popularity of this letter 
on the Internet, a major nightly news program recently devoted an entire 
show to the investigation of the program described below to see if it 
really can make people money.
The show also investigated whether or not the program was legal.  Their 
findings proved once and for all that there are absolutely no laws 
prohibiting the participation in the program. This has helped to show 
people that this is a simple, harmless and fun way to make some extra 
money at home.
The results of this show have been truly remarkable. So many people are 
participating that those involved are doing much better than ever 
before.  Since everyone makes more as more people try it out, it's been 
very exciting to be a part of it lately. You will understand once you 
experience it.

HERE IT IS BELOW:

*** Print This Now For Future Reference ***
The following income opportunity is one you may be interested in taking 
a look at. It can be started with VERY LITTLE investment and the income 
return is TREMENDOUS!!!

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
If you would like to make at least $50,000 in less than 90 days !
Please read the enclosed program...THEN READ IT AGAIN!!!
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

THIS IS A LEGITIMATE, LEGAL, MONEY MAKING OPPORTUNITY. It does not 
require you to come into contact with people, do any hard work, and best 
of all, you never have to leave the house except to get the mail. If you 
believe that someday you'll get that big break that you've been waiting 
for, THIS IS IT!  Simply follow the instructions, and your dreams will 
come true. This multi-level e-mail order marketing program works 
perfectly...100% EVERY TIME.
E-mail is the sales tool of the future. Take advantage of this 
non-commercialized method of advertising NOW!!! The longer you wait, the 
more people will be doing business using e-mail. Get your piece of this 
action!!!
MULTI-LEVEL MARKETING (MLM) has finally gained respectability.  It is 
being taught in the Harvard Business School, and both Stanford Research 
and the Wall Street Journal have stated that between 50% and 65% of all 
goods and services will be sold through multi-level methods by the mid 
to late 1990's.  This is a Multi-Billion Dollar industry and of the 
500,000 millionaires in the U.S., 20% (100,000) made their fortune in 
the last several years in MLM.  Moreover, statistics show 45 people 
become millionaires everyday through Multi-Level Marketing.
You may have heard this story before, but over the summer Donald Trump 
made an appearance on the David Letterman show. Dave asked him what he 
would do if he lost everything and had to start over from scratch. 
Without hesitating, Trump said he would find a good network marketing 
company and get to work. The audience started to hoot and boo him. He 
looked out at the audience and dead-panned his response:
"That's why I'm sitting up here and you are all sitting out there!"
The enclosed information is something I almost let slip through my 
fingers. Fortunately, sometime later I re-read everything and gave some 
thought and study to it. My name is Johnathon Rourke. Two years ago, the 
corporation I worked at for the past twelve years down-sized and my 
position was eliminated. After unproductive job interviews, I decided to 
open my own business. Over the past year, I incurred many unforeseen 
financial problems.  I owed my family, friends and creditors over 
$35,000.
The economy was taking a toll on my business and I just couldn't seem to 
make ends meet. I had to refinance and borrow against my home to support 
my family and struggling business. AT THAT MOMENT something significant 
happened in my life and I am writing to share the experience in hopes 
that this will change your life FOREVER FINANCIALLY!!!
In mid December, I received this program via e-mail. Six month's prior 
to receiving this program I had been sending away for information on 
various business opportunities. All of the programs I received, in my 
opinion, were not cost effective. They were either too difficult for me 
to comprehend or the initial investment was too much for me to risk to 
see if they would work or not. One claimed that I would make a million 
dollars in one year...it didn't tell me I'd have to write a book to make 
it!
But like I was saying, in December of 1997 I received this program. I 
didn't send for it, or ask for it, they just got my name off a mailing 
list. THANK GOODNESS FOR THAT!!! After reading it several times, to make 
sure I was reading it correctly, I couldn't believe my eyes. Here was a 
MONEY MAKING PHENOMENON. I could invest as much as I wanted to start, 
without putting me further into debt. After I got a pencil and paper and 
figured it out, I would at least get my money back. But like most of you 
I was still a little sceptical and a little worried about the legal 
aspects of it all. So I checked it out with the U.S. Post Office 
(1-800-725-2161 24-hrs) and they confirmed that it is indeed legal! 
After determining the program was LEGAL and NOT A CHAIN LETTER, I 
decided "WHY NOT."
Initially I sent out 10,000 e-mails. It cost me about $15 for my time 
on-line. The great thing about e-mail is that I don't need any money for 
printing to send out the program, and because all of my orders are 
fulfilled via e-mail, my only expense is my time. I am telling you like 
it is I hope it doesn't turn you off, but I promised myself that I would 
not "rip-off" anyone, no matter how much money it made me.
In less than one week, I was starting to receive orders for REPORT #1 By 
January 13, I had received 26 orders for REPORT #1. Your goal is to 
"RECEIVE at least 20 ORDERS FOR REPORT #1 WITHIN 2 WEEKS. IF YOU DON'T, 
SEND OUT MORE PROGRAMS UNTIL YOU DO!" My first step in making $50,000 in 
90 days was done.  By January 30, I had received 196 orders for REPORT 
#2. Your goal is to "RECEIVE AT LEAST 100+ ORDERS FOR REPORT #2 WITHIN 2 
WEEKS. IF NOT, SEND OUT MORE PROGRAMS UNTIL YOU DO. ONCE YOU HAVE 100 
ORDERS, THE REST IS EASY, RELAX, YOU WILL MAKE YOUR $50,000 GOAL." Well, 
I had 196 orders for REPORT #2, 96 more than I needed. So I sat back and 
relaxed. By March 1, of my e-mailing of 10,000, I received $58,000 with 
more coming in every day.
I paid off ALL my debts and bought a much needed new car. Please take 
time to read the attached program, IT WILL CHANGE YOUR LIFE FOREVER!!  ! 
Remember, it won't work if you don't try it. This program does work , 
but you must follow it EXACTLY! Especially the rules of not trying to 
place your name in a different place. It won't work and you'll lose out 
on a lot of money!
In order for this program to work, you must meet your goal of 20+ orders 
for REPORT #1, and 100+ orders for REPORT #2 and you will make $50,000 
or more in 90 days. I AM LIVING PROOF THAT IT WORKS!!!
If you choose not to participate in this program, I am sorry. It really 
is a great opportunity with little cost or risk to you. If you choose to 
participate, follow the program and you will be on your way to financial 
security. If you are a fellow business owner and are in financial 
trouble like I was, or you want to start your own business, consider 
this a sign. I DID!
Sincerely,
Johnathon Rourke



A PERSONAL NOTE FROM THE ORIGINATOR OF THIS PROGRAM:
By the time you have read the enclosed program and reports, you should 
have concluded that such a program, and one that is legal, could not 
have been created by an amateur.
Let me tell you a little about myself. I had a profitable business for 
10 years. Then in 1979 my business began falling off. I was doing the 
same things that were previously successful for me, but it wasn't 
working. Finally, I figured it out. It wasn't me, it was the economy.  
Inflation and recession had replaced the stable economy that had been 
with us since 1945.I don't have to tell you what happened to the 
unemployment rate... because many of you know from first hand 
experience. There were more failures and bankruptcies than ever before.
The middle class was vanishing. Those who knew what they were doing 
invested wisely and moved up. Those who did not, including those who 
never had anything to save or invest, were moving down into the ranks of 
the poor. As the saying goes, "THE RICH GET RICHER AND THE POOR GET 
POORER." The traditional methods of making money will never allow you to 
"move up" or "get rich", inflation will see to that.
You have just received information that can give you financial freedom 
for the rest of your life, with "NO RISK" and "JUST A LITTLE BIT OF 
EFFORT." You can make more money in the next few months than you have 
ever imagined. I should also point out that I will not see a penny of 
this money, nor anyone else who has provided a testimonial for this 
program. I have already made over 4 MILLION DOLLARS!I have retired from 
the program after sending thousands and thousands of programs.
Follow the program EXACTLY AS INSTRUCTED. Do not change it in any way . 
It works exceedingly well as it is now. Remember to e-mail a copy of 
this exciting report to everyone you can think of. One of the people you 
send this to may send out 50,000...and your name will be on everyone of 
them!
Remember though, the more you send out the more potential customers you 
will reach.
So my friend, I have given you the ideas, information, materials and 
opportunity to become financially independent. IT IS UP TO YOU NOW!
"THINK ABOUT IT"
Before you delete this program from your mailbox, as I almost did, take 
a little time to read it and REALLY THINK ABOUT IT. Get a pencil and 
figure out what could happen when YOU participate. Figure out the worst 
possible response and no matter how you calculate it, you will still 
make a lot of money! You will definitely get back what you invested. Any 
doubts you have will vanish when your first orders come in. IT WORKS!
Jody Jacobs, Richmond, VA
HERE'S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF DOLLAR$
INSTRUCTIONS:
This method of raising capital REALLY WORKS 100% EVERY TIME.  I am sure 
that you could use up to $50,000 or more in the next 90 days. Before you 
say "BULL... ", please read this program carefully.
This is not a chain letter, but a perfectly legal money making 
opportunity. Basically, this is what you do: As with all multi-level 
businesses, we build our business by recruiting new partners and selling 
our products. Every state in the USA allows you to recruit new 
multi-level business partners, and we offer a product for EVERY dollar 
sent. YOUR ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, so you are not 
involved in personal selling. You do it privately in your own home, 
store or office. This is the GREATEST Multi-Level Mail Order Marketing 
anywhere.
This is what you MUST do:
1. Order all 4 reports shown on the list below (you can't sell them if 
you don't order them).
* For each report, send $5.00 CASH, the NAME & NUMBER OF THE REPORT YOU 
ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR NAME & RETURN ADDRESS (in 
case of a problem) to the person whose name appears on the list next to 
the report.  MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE IN CASE 
OF ANY MAIL PROBLEMS!
* When you place your order, make sure you order each of the four 
reports. You will need all four reports so that you can save them on 
your computer and resell them.
* Within a few days you will receive, via e-mail, each of the four 
reports. Save them on your computer so they will be accessible for you 
to send to the 1,000's of people who will order them from you.

2. IMPORTANT DO NOT alter the names of the people who are listed next to 
each report, or their sequence on the list, in any way other than is 
instructed below in steps "a" through "f" or you will lose out on the 
majority of your profits. Once you understand the way this works, you'll 
also see how it doesn't work if you change it. Remember, this method has 
been tested, and if you alter it, it will not work.
a. Look below for the listing of available reports.
b. After you've ordered the four reports, take this advertisement and 
remove the name and address under REPORT #4. This person has made it 
through the cycle and is no doubt counting their $50,000!  c. Move the 
name and address under REPORT #3 down to REPORT #4.  d. Move the name 
and address under REPORT #2 down to REPORT #3.  e. Move the name and 
address under REPORT #1 down to REPORT #2.  f.  Insert your name/address 
in the REPORT #1 position.
Please make sure you COPY ALL INFORMATION, every name and address, 
ACCURATELY!
3. Take this entire letter, including the modified list of names, and 
save it to your computer. Make NO changes to the instruction portion of 
this letter.
Your cost to participate in this is practically nothing (surely you can 
afford $20). You obviously already have an Internet connection and 
e-mail is FREE!


There are two primary methods of building your downline:
METHOD #1: SENDING BULK E-MAIL
Let's say that you decide to start small, just to see how it goes, and 
we'll assume you and all those involved send out only 2,000 programs 
each. Let's also assume that the mailing receives a 0.5% response. Using 
a good list the response could be much better. Also, many people will 
send out hundreds of thousands of programs instead of 2,000. But 
continuing with this example, you send out only 2,000 programs. With a 
0.5% response, that is only 10 orders for REPORT #1. Those 10 people 
respond by sending out 2,000 programs each for a total of 20,000. Out of 
those 0.5%, 100 people respond and order REPORT #2. Those 100 mail out 
2,000 programs each for a total of 200,000.
The 0.5% response to that is 1,000 orders for REPORT #3. Those 1,000 
send out 2,000 programs each for a 2,000,000 total. The 0.5% response to 
that is 10,000 orders for REPORT #4. That's 10,000 $5 bills for you. 
CASH!!! Your total income in this example is $50 + $500 + $5,000 + 
$50,000 for a total of $55,550!!! REMEMBER FRIEND, THIS IS ASSUMING 
1,990 OUT OF THE 2,000 PEOPLE YOU MAIL TO WILL DO ABSOLUTELY NOTHING AND 
TRASH THIS PROGRAM! DARE TO THINK FOR A MOMENT WHAT WOULD HAPPEN IF 
EVERYONE, OR HALF SENT OUT 100,000 PROGRAMS INSTEAD OF 2,000.  Believe 
me, many people will do just that, and more! By the way, your cost to 
participate in this is practically nothing.  You obviously already have 
an Internet connection and e-mail is FREE!!! REPORT #2 will show you the 
best methods for bulk e-mailing, tell you where to obtain free bulk 
e-mail software and where to obtain e-mail lists.


METHOD #2 - PLACING FREE ADS ON THE INTERNET
Advertising on the internet is very, very inexpensive, and there are 
HUNDREDS of FREE places to advertise. Let's say you decide to start 
small just to see how well it works. Assume your goal is to get ONLY 10 
people to participate on your first level. (Placing a lot of FREE ads on 
the Internet will EASILY get a larger response.) Also assume that 
everyone else in YOUR ORGANIZATION gets ONLY 10 downline members.
Follow this example to achieve the STAGGERING results below:
1st level-your 10 members with 
$5.......................................$50
2nd level--10 members from those 10 ($5 x 100)..................$500
3rd level--10 members from those 100 ($5 x 1,000)...........$5,000
4th level--10 members from those 1,000 ($5 x 10,000).....$50,000
THIS TOTALS ---------->$55,550
Remember friends, this assumes that the people who participate only 
recruit 10 people each. Think for a moment what would happen if they got 
20 people to participate! Most people get 100's of participants!  THINK 
ABOUT IT! For every $5.00 you receive, all you must do is e-mail them 
the report they ordered. THAT'S IT! ALWAYS PROVIDE SAME-DAY SERVICE ON 
ALL ORDERS! This will guarantee that the e-mail THEY send out with YOUR 
name and address on it will be prompt because they can't advertise until 
they receive the report!
AVAILABLE REPORTS
*** Order Each REPORT by NUMBER and NAME ***
Notes:
* ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH REPORT. CHECKS NOT 
ACCEPTED.
* ALWAYS SEND YOUR ORDER VIA FIRST CLASS MAIL.
* Make sure the cash is concealed by wrapping it in at least two sheets 
of paper. On one of those sheets of paper, include:
(a) the number & name of the report you are ordering, (b) your e-mail 
address, and (c) your name & postal address.
PLACE YOUR ORDER FOR THESE REPORTS NOW:

REPORT #1   "The Insider's Guide to Advertising for Free on the 
Internet'
ORDER REPORT #1 FROM
EBIZ 
PH2-45 Grenoble Drive
Toronto, Ontario
Canada   M3C 1C5

REPORT #2  "The Insider's Guide to sending Bulk E-Mail on the Internet.
ORDER REPORT #2 FROM:
C. Alexander
2315 Lava Dr.
San Jose, CA 95133


REPORT #3  "The secrets of Multilevel Marketing on the Internet.
ORDER REPORT #3 FROM:
P.G. Webb
16 Huntley Crescent
St. Catharines, Ontario
Canada, L2M 6E7


REPORT #4  "How to become a Millionaire Utilizing the Power of 
Multilevel Marketing on the Internet"
ORDER REPORT #4 FROM:
F.D. Hardy
22306 128th. ST. E.
Sumner, Wa. 98390-7634


About 50,000 new people get online every month!
******* TIPS FOR SUCCESS *******
* TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the 
directions accurately.
* Send for the four reports IMMEDIATELY so you will have them when the 
orders start coming in because: When you receive a $5 order, you MUST 
send out the requested product/report.
* ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE.
* Be patient and persistent with this program. If you follow the 
instructions exactly, your results WILL BE SUCCESSFUL!
* ABOVE ALL, HAVE FAITH IN YOURSELF AND KNOW YOU WILL SUCCEED!

******* YOUR SUCCESS GUIDELINES ******* Follow these guidelines to 
guarantee your success:
If you don't receive 20 orders for REPORT #1 within two weeks, Continue 
advertising or sending e-mails until you do. Then, a couple of weeks 
later you should receive at least 100 orders for REPORT#2. If you don 
't, continue advertising or sending e-mails until you do. Once you have 
received 100 or more orders for REPORT #2, YOU CAN RELAX, because the 
system is already working for you, and the cash will continue to roll 
in!
THIS IS IMPORTANT TO REMEMBER:
Every time your name is moved down on the list, you are placed in front 
of a DIFFERENT report. You can KEEP TRACK of your PROGRESS by watching 
which report people are ordering from you. If you want to generate more 
income, send another batch of e-mails or continue placing ads and start 
the whole process again! There is no limit to the income you will 
generate from this business!
Before you make your decision as to whether or not you participate in 
this program. Please answer one question. DO YOU WANT TO CHANGE YOUR 
LIFE? If the answer is yes, please look at the following facts about 
this program:

1. You are selling a product which does not Cost anything to PRODUCE, 
SHIP OR ADVERTISE.
2. All of your customers pay you in CASH!
3. E-mail is without question the most powerful method of distributing 
information on earth. This program combines the distribution power of 
e-mail together with the revenue generating power of multi-level 
marketing.
4. Your only expense-other than your initial $20 investment-is your 
time!
5. Virtually all of the income you generate from this program is PURE 
PROFIT!
6. This program will change your LIFE FOREVER.

ACT NOW! Take your first step toward achieving financial independence.  
Order the reports and follow the program outlined above-SUCCESS will be 
your reward.
Thank you for your time and consideration.


PLEASE NOTE: If you need help with starting a business, registering a 
business name, learning how income tax is handled, etc., contact your 
local office of the Small Business Administration (a Federal Agency) 
1-800-827-5722 for free help and answers to questions. Also, the 
Internal Revenue Service offers free help via telephone and free 
seminars about business tax requirements. Your earnings are highly 
dependent on your activities and advertising. The information contained 
on this site and in the report constitutes no guarantees stated nor 
implied. In the event that it is determined that this site or report 
constitutes a guarantee of any kind, that guarantee is now void. The 
earnings amounts listed on this site and in the report are estimates 
only. If you have any questions of the legality of this program, contact 
the Office of Associate Director for Marketing Practices, Federal Trade 
Commission, Bureau of Consumer Protection in Washington, DC.
 
 
 
 
 
 
 
 



From sdunn@digitalanvil.com  Fri Sep 24 04:03:51 1999
From: sdunn@digitalanvil.com (sdunn@digitalanvil.com)
Date: Thu, 23 Sep 1999 23:03:51 -0400 (EDT)
Subject: [Python-bugs-list] apply(): throws MemoryError when sending an {} as the keyword list (PR#85)
Message-ID: <199909240303.XAA23129@python.org>

Full_Name: Sean Dunn
Version: 1.5.2
OS: Irix 6.5
Submission from: da111.digitalanvil.com (208.10.150.111)


Description: 
	The builtin function apply() seems to barf on empty dictionaries
	when passed as the keyword list.  See the following output:

###
Python 1.5.2 (#33, Sep 23 1999, 21:46:26) [C] on irix6
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> def func(a):
...     return a
... 
>>> print func
<function func at 1018aa68>
>>> func(1)
1
>>> apply(func, (1,))
1
>>> apply(func, (1,), {})
Traceback (innermost last):
  File "<stdin>", line 1, in ?
MemoryError
>>> 
###


I first found this problem when trying to simply import the 'threading' module:

###
Python 1.5.2 (#33, Sep 23 1999, 21:46:26) [C] on irix6
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import threading
Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "./Lib/threading.py", line 545, in ?
    _MainThread()
  File "./Lib/threading.py", line 460, in __init__
    Thread.__init__(self, name="MainThread")
  File "./Lib/threading.py", line 332, in __init__
    self.__block = Condition(Lock())
  File "./Lib/threading.py", line 136, in Condition
    return apply(_Condition, args, kwargs)
MemoryError
>>> 
###


The variable 'kwargs' in this case is {}.  The actual exception is thrown
at line 2467 of Python/ceval.c:

	if (kw != NULL) {
		int pos, i;
		nk = PyDict_Size(kw);

/* 2467 */	k = PyMem_NEW(PyObject *, 2*nk);
/* nk, the PyDict_Size (the size of ma_used) is 0 */

		if (k == NULL) {
			PyErr_NoMemory();
			Py_DECREF(arg);
			return NULL;
		}
		pos = i = 0;
		while (PyDict_Next(kw, &pos, &k[i], &k[i+1]))
			i += 2;
		nk = i/2;
		/* XXX This is broken if the caller deletes dict items! */
	}



Currently, I am making the following change to threading to catch {} kwargs:

###
def Condition(*args, **kwargs):
    if kwargs=={}:
	return apply(_Condition, args)
    else:
	return apply(_Condition, args, kwargs)
###    





From skip@mojam.com (Skip Montanaro)  Fri Sep 24 14:04:24 1999
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Fri, 24 Sep 1999 08:04:24 -0500 (CDT)
Subject: [Python-bugs-list] apply(): throws MemoryError when sending an {} as the keyword list (PR#85)
In-Reply-To: <181204906@toto.iv>
Message-ID: <14315.30424.560216.5198@dolphin.mojam.com>

    Sean> Full_Name: Sean Dunn
    Sean> Version: 1.5.2
    Sean> OS: Irix 6.5
    Sean> Submission from: da111.digitalanvil.com (208.10.150.111)

    Sean> Description: 
    Sean> 	The builtin function apply() seems to barf on empty
    Sean> 	dictionaries when passed as the keyword list.  See the
    Sean> 	following output: 

I think Something else besides a MemoryError is going on.  The example you
gave works for me on my Linux system (close to the latest CVS source).  This
happened when you typed this in to a fresh interpreter?  I'd be real
surprised if it actually failed because it was out of memory unless
something else was going on on your system that made memory extremely tight.

Skip Montanaro | http://www.mojam.com/
skip@mojam.com | http://www.musi-cal.com/
847-971-7098   | Python: Programming the way Guido indented...


From guido@CNRI.Reston.VA.US  Fri Sep 24 15:46:01 1999
From: guido@CNRI.Reston.VA.US (Guido van Rossum)
Date: Fri, 24 Sep 1999 10:46:01 -0400
Subject: [Python-bugs-list] apply(): throws MemoryError when sending an {} as the keyword list (PR#85)
In-Reply-To: Your message of "Thu, 23 Sep 1999 23:03:51 EDT."
 <199909240303.XAA23129@python.org>
References: <199909240303.XAA23129@python.org>
Message-ID: <199909241446.KAA20422@eric.cnri.reston.va.us>

> 	The builtin function apply() seems to barf on empty dictionaries
> 	when passed as the keyword list.  See the following output:

> >>> apply(func, (1,), {})
> Traceback (innermost last):
>   File "<stdin>", line 1, in ?
> MemoryError
> >>> 

> The variable 'kwargs' in this case is {}.  The actual exception is thrown
> at line 2467 of Python/ceval.c:
> 
> 	if (kw != NULL) {
> 		int pos, i;
> 		nk = PyDict_Size(kw);
> 
> /* 2467 */	k = PyMem_NEW(PyObject *, 2*nk);
> /* nk, the PyDict_Size (the size of ma_used) is 0 */
> 
> 		if (k == NULL) {
> 			PyErr_NoMemory();
> 			Py_DECREF(arg);
> 			return NULL;
> 		}
> 		pos = i = 0;
> 		while (PyDict_Next(kw, &pos, &k[i], &k[i+1]))
> 			i += 2;
> 		nk = i/2;
> 		/* XXX This is broken if the caller deletes dict items! */
> 	}

Thanks very much for your detailed analysis!  The cause is probably
that somehow the configure script doesn't compute the correct value
for MALLOC_ZERO_RETURNS_NULL.  I don't know why; the test seems simple
enough.  (Maybe you inherited a config.cache file from a previous Irix 
version?)  To work around this in the build, if "make clobber" and
rerunning configure don't do the trick, add

    #define MALLOC_ZERO_RETURNS_NULL 1

to the top of Include/mymalloc.h.

Please let me know if rerunning configure makes the bug go away; this
will decides the classification of your bug report.

--Guido van Rossum (home page: http://www.python.org/~guido/)


From guido@CNRI.Reston.VA.US  Fri Sep 24 15:46:04 1999
From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US)
Date: Fri, 24 Sep 1999 10:46:04 -0400 (EDT)
Subject: [Python-bugs-list] apply(): throws MemoryError when sending an {} as the keyword list (PR#85)
Message-ID: <199909241446.KAA13703@python.org>

> 	The builtin function apply() seems to barf on empty dictionaries
> 	when passed as the keyword list.  See the following output:

> >>> apply(func, (1,), {})
> Traceback (innermost last):
>   File "<stdin>", line 1, in ?
> MemoryError
> >>> 

> The variable 'kwargs' in this case is {}.  The actual exception is thrown
> at line 2467 of Python/ceval.c:
> 
> 	if (kw != NULL) {
> 		int pos, i;
> 		nk = PyDict_Size(kw);
> 
> /* 2467 */	k = PyMem_NEW(PyObject *, 2*nk);
> /* nk, the PyDict_Size (the size of ma_used) is 0 */
> 
> 		if (k == NULL) {
> 			PyErr_NoMemory();
> 			Py_DECREF(arg);
> 			return NULL;
> 		}
> 		pos = i = 0;
> 		while (PyDict_Next(kw, &pos, &k[i], &k[i+1]))
> 			i += 2;
> 		nk = i/2;
> 		/* XXX This is broken if the caller deletes dict items! */
> 	}

Thanks very much for your detailed analysis!  The cause is probably
that somehow the configure script doesn't compute the correct value
for MALLOC_ZERO_RETURNS_NULL.  I don't know why; the test seems simple
enough.  (Maybe you inherited a config.cache file from a previous Irix 
version?)  To work around this in the build, if "make clobber" and
rerunning configure don't do the trick, add

    #define MALLOC_ZERO_RETURNS_NULL 1

to the top of Include/mymalloc.h.

Please let me know if rerunning configure makes the bug go away; this
will decides the classification of your bug report.

--Guido van Rossum (home page: http://www.python.org/~guido/)



From sdunn@digitalanvil.com  Fri Sep 24 20:47:56 1999
From: sdunn@digitalanvil.com (sdunn@digitalanvil.com)
Date: Fri, 24 Sep 1999 15:47:56 -0400 (EDT)
Subject: [Python-bugs-list] apply(): throws MemoryError when sending an {} as (PR#86)
Message-ID: <199909241947.PAA20976@python.org>

The use of

    #define MALLOC_ZERO_RETURNS_NULL 1

at the top of mymalloc.h worked fine...
By curiousity.. I just tried compiling the following:

/*testmalloc.c*/
#include <stdio.h>
main()
{
    int *fp;
    int *sp;

    fp = (int*)malloc(0);
    sp = (int*)malloc(sizeof(int));
    printf("fp: %x\nsp: %x\n", fp, sp);
}
/**/

First, I just compiled normally:

> cc -o testmalloc testmalloc.c
> ./testmalloc
fp: 10015010
sp: 10015020

Then I compiled with the -lmalloc flag (libmalloc is the SGI high performance
memory library - which seems to be the default used after running the
configure script)

> cc -o testmalloc testmalloc.c
> ./testmalloc
fp: 0
sp: 10015048

So...  It looks like without libmalloc, we're actually getting memory when we
"shouldn't" - but from reading your source code it seems like that's the way
it is usually made to work (weird).  When compiling with libmalloc, the
returned 0 is triggering the MemError flag.

At ceval.c:2467, should it even get to this point if the passed in kwargs ==
{}?  It does a PyDict_Size of it, which returns 0 (which seems correct) but kw
isn't NULL.  It seems like at this point that it should be..

Sean


Guido van Rossum wrote:

> >       The builtin function apply() seems to barf on empty dictionaries
> >       when passed as the keyword list.  See the following output:
>
> > >>> apply(func, (1,), {})
> > Traceback (innermost last):
> >   File "<stdin>", line 1, in ?
> > MemoryError
> > >>>
>
> > The variable 'kwargs' in this case is {}.  The actual exception is thrown
> > at line 2467 of Python/ceval.c:
> >
> >       if (kw != NULL) {
> >               int pos, i;
> >               nk = PyDict_Size(kw);
> >
> > /* 2467 */    k = PyMem_NEW(PyObject *, 2*nk);
> > /* nk, the PyDict_Size (the size of ma_used) is 0 */
> >
> >               if (k == NULL) {
> >                       PyErr_NoMemory();
> >                       Py_DECREF(arg);
> >                       return NULL;
> >               }
> >               pos = i = 0;
> >               while (PyDict_Next(kw, &pos, &k[i], &k[i+1]))
> >                       i += 2;
> >               nk = i/2;
> >               /* XXX This is broken if the caller deletes dict items! */
> >       }
>
> Thanks very much for your detailed analysis!  The cause is probably
> that somehow the configure script doesn't compute the correct value
> for MALLOC_ZERO_RETURNS_NULL.  I don't know why; the test seems simple
> enough.  (Maybe you inherited a config.cache file from a previous Irix
> version?)  To work around this in the build, if "make clobber" and
> rerunning configure don't do the trick, add
>
>     #define MALLOC_ZERO_RETURNS_NULL 1
>
> to the top of Include/mymalloc.h.
>
> Please let me know if rerunning configure makes the bug go away; this
> will decides the classification of your bug report.
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)






From sdunn@digitalanvil.com  Fri Sep 24 20:44:22 1999
From: sdunn@digitalanvil.com (Sean Dunn)
Date: Fri, 24 Sep 1999 14:44:22 -0500
Subject: [Python-bugs-list] apply(): throws MemoryError when sending an {} as
 the keyword list (PR#85)
References: <199909240303.XAA23129@python.org> <199909241446.KAA20422@eric.cnri.reston.va.us>
Message-ID: <37EBD496.1451B714@digitalanvil.com>

The use of

    #define MALLOC_ZERO_RETURNS_NULL 1

at the top of mymalloc.h worked fine...
By curiousity.. I just tried compiling the following:

/*testmalloc.c*/
#include <stdio.h>
main()
{
    int *fp;
    int *sp;

    fp = (int*)malloc(0);
    sp = (int*)malloc(sizeof(int));
    printf("fp: %x\nsp: %x\n", fp, sp);
}
/**/

First, I just compiled normally:

> cc -o testmalloc testmalloc.c
> ./testmalloc
fp: 10015010
sp: 10015020

Then I compiled with the -lmalloc flag (libmalloc is the SGI high performance
memory library - which seems to be the default used after running the
configure script)

> cc -o testmalloc testmalloc.c
> ./testmalloc
fp: 0
sp: 10015048

So...  It looks like without libmalloc, we're actually getting memory when we
"shouldn't" - but from reading your source code it seems like that's the way
it is usually made to work (weird).  When compiling with libmalloc, the
returned 0 is triggering the MemError flag.

At ceval.c:2467, should it even get to this point if the passed in kwargs ==
{}?  It does a PyDict_Size of it, which returns 0 (which seems correct) but kw
isn't NULL.  It seems like at this point that it should be..

Sean


Guido van Rossum wrote:

> >       The builtin function apply() seems to barf on empty dictionaries
> >       when passed as the keyword list.  See the following output:
>
> > >>> apply(func, (1,), {})
> > Traceback (innermost last):
> >   File "<stdin>", line 1, in ?
> > MemoryError
> > >>>
>
> > The variable 'kwargs' in this case is {}.  The actual exception is thrown
> > at line 2467 of Python/ceval.c:
> >
> >       if (kw != NULL) {
> >               int pos, i;
> >               nk = PyDict_Size(kw);
> >
> > /* 2467 */    k = PyMem_NEW(PyObject *, 2*nk);
> > /* nk, the PyDict_Size (the size of ma_used) is 0 */
> >
> >               if (k == NULL) {
> >                       PyErr_NoMemory();
> >                       Py_DECREF(arg);
> >                       return NULL;
> >               }
> >               pos = i = 0;
> >               while (PyDict_Next(kw, &pos, &k[i], &k[i+1]))
> >                       i += 2;
> >               nk = i/2;
> >               /* XXX This is broken if the caller deletes dict items! */
> >       }
>
> Thanks very much for your detailed analysis!  The cause is probably
> that somehow the configure script doesn't compute the correct value
> for MALLOC_ZERO_RETURNS_NULL.  I don't know why; the test seems simple
> enough.  (Maybe you inherited a config.cache file from a previous Irix
> version?)  To work around this in the build, if "make clobber" and
> rerunning configure don't do the trick, add
>
>     #define MALLOC_ZERO_RETURNS_NULL 1
>
> to the top of Include/mymalloc.h.
>
> Please let me know if rerunning configure makes the bug go away; this
> will decides the classification of your bug report.
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)





From guido@CNRI.Reston.VA.US  Fri Sep 24 21:11:13 1999
From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US)
Date: Fri, 24 Sep 1999 16:11:13 -0400 (EDT)
Subject: [Python-bugs-list] apply(): throws MemoryError when sending an {} as the keyword list (PR#85)
Message-ID: <199909242011.QAA21617@python.org>

> The use of
> 
>     #define MALLOC_ZERO_RETURNS_NULL 1
> 
> at the top of mymalloc.h worked fine...
> By curiousity.. I just tried compiling the following:
> 
> /*testmalloc.c*/
> #include <stdio.h>
> main()
> {
>     int *fp;
>     int *sp;
> 
>     fp = (int*)malloc(0);
>     sp = (int*)malloc(sizeof(int));
>     printf("fp: %x\nsp: %x\n", fp, sp);
> }
> /**/
> 
> First, I just compiled normally:
> 
> > cc -o testmalloc testmalloc.c
> > ./testmalloc
> fp: 10015010
> sp: 10015020
> 
> Then I compiled with the -lmalloc flag (libmalloc is the SGI high performance
> memory library - which seems to be the default used after running the
> configure script)
> 
> > cc -o testmalloc testmalloc.c
> > ./testmalloc
> fp: 0
> sp: 10015048
> 
> So...  It looks like without libmalloc, we're actually getting memory when we
> "shouldn't" - but from reading your source code it seems like that's the way
> it is usually made to work (weird).  When compiling with libmalloc, the
> returned 0 is triggering the MemError flag.

There are two schools of thought here -- one says that malloc(0)
should return a non-NULL pointer because it doesn't "fail": it
correctly allocates an array of 0 bytes; the other of course says that 
malloc(0) is nonsensical and should return an error.  ANSI C allows
both (as long as consistent) so Python supports either.

Could it be that the configure script was run without -lmalloc but
later for some reason you rebuilt with -lmalloc?  (I think that
enabling threading might cause this.)

> At ceval.c:2467, should it even get to this point if the passed in kwargs ==
> {}?  It does a PyDict_Size of it, which returns 0 (which seems correct) but kw
> isn't NULL.  It seems like at this point that it should be..

{} is an object so it is not NULL.  Given a correct malloc, the code
will work with {} or NULL.

--Guido van Rossum (home page: http://www.python.org/~guido/)



From guido@CNRI.Reston.VA.US  Fri Sep 24 21:11:11 1999
From: guido@CNRI.Reston.VA.US (Guido van Rossum)
Date: Fri, 24 Sep 1999 16:11:11 -0400
Subject: [Python-bugs-list] apply(): throws MemoryError when sending an {} as the keyword list (PR#85)
In-Reply-To: Your message of "Fri, 24 Sep 1999 14:44:22 CDT."
 <37EBD496.1451B714@digitalanvil.com>
References: <199909240303.XAA23129@python.org> <199909241446.KAA20422@eric.cnri.reston.va.us>
 <37EBD496.1451B714@digitalanvil.com>
Message-ID: <199909242011.QAA23031@eric.cnri.reston.va.us>

> The use of
> 
>     #define MALLOC_ZERO_RETURNS_NULL 1
> 
> at the top of mymalloc.h worked fine...
> By curiousity.. I just tried compiling the following:
> 
> /*testmalloc.c*/
> #include <stdio.h>
> main()
> {
>     int *fp;
>     int *sp;
> 
>     fp = (int*)malloc(0);
>     sp = (int*)malloc(sizeof(int));
>     printf("fp: %x\nsp: %x\n", fp, sp);
> }
> /**/
> 
> First, I just compiled normally:
> 
> > cc -o testmalloc testmalloc.c
> > ./testmalloc
> fp: 10015010
> sp: 10015020
> 
> Then I compiled with the -lmalloc flag (libmalloc is the SGI high performance
> memory library - which seems to be the default used after running the
> configure script)
> 
> > cc -o testmalloc testmalloc.c
> > ./testmalloc
> fp: 0
> sp: 10015048
> 
> So...  It looks like without libmalloc, we're actually getting memory when we
> "shouldn't" - but from reading your source code it seems like that's the way
> it is usually made to work (weird).  When compiling with libmalloc, the
> returned 0 is triggering the MemError flag.

There are two schools of thought here -- one says that malloc(0)
should return a non-NULL pointer because it doesn't "fail": it
correctly allocates an array of 0 bytes; the other of course says that 
malloc(0) is nonsensical and should return an error.  ANSI C allows
both (as long as consistent) so Python supports either.

Could it be that the configure script was run without -lmalloc but
later for some reason you rebuilt with -lmalloc?  (I think that
enabling threading might cause this.)

> At ceval.c:2467, should it even get to this point if the passed in kwargs ==
> {}?  It does a PyDict_Size of it, which returns 0 (which seems correct) but kw
> isn't NULL.  It seems like at this point that it should be..

{} is an object so it is not NULL.  Given a correct malloc, the code
will work with {} or NULL.

--Guido van Rossum (home page: http://www.python.org/~guido/)


From npirzkal@eso.org  Sun Sep 26 12:37:05 1999
From: npirzkal@eso.org (npirzkal@eso.org)
Date: Sun, 26 Sep 1999 07:37:05 -0400 (EDT)
Subject: [Python-bugs-list] C API/PyFloat_AsDouble() w/ RH6.x (PR#87)
Message-ID: <199909261137.HAA02886@python.org>

Full_Name: Norbert Pirzkal
Version: 1.5.2
OS: Linux RH 6.0
Submission from: eso-wall-ext.hq.eso.org (134.171.69.199)


The values returned by PyFloat_AsDouble() are no longer correct when I compile
my Python C extended function under RH 6.0.
I have had the same C code compiled and running flawlessly under RH5.2 , Solaris
2.6,
and OpenStep 4.2.
I could not find any information as to what could cause these functions to stop
working
with the new RH distributions (PyInt_AsLong() also fails, PyString_AsString()
still works).
Any information would be very much appreciated...

	Cheers,
	Nor



From guido@CNRI.Reston.VA.US  Sun Sep 26 15:06:32 1999
From: guido@CNRI.Reston.VA.US (Guido van Rossum)
Date: Sun, 26 Sep 1999 10:06:32 -0400
Subject: [Python-bugs-list] C API/PyFloat_AsDouble() w/ RH6.x (PR#87)
In-Reply-To: Your message of "Sun, 26 Sep 1999 07:37:05 EDT."
 <199909261137.HAA02886@python.org>
References: <199909261137.HAA02886@python.org>
Message-ID: <199909261406.KAA24167@eric.cnri.reston.va.us>

> The values returned by PyFloat_AsDouble() are no longer correct when
> I compile my Python C extended function under RH 6.0.

> I have had the same C code compiled and running flawlessly under
> RH5.2 , Solaris 2.6, and OpenStep 4.2.

> I could not find any information as to what could cause these
> functions to stop working with the new RH distributions
> (PyInt_AsLong() also fails, PyString_AsString() still works).

I'm certain that the problem is not Python itself but a configuration
problem.  Without access to your system, this is almost impossible to
fix.

My guess is that you are using a different compiler or linker or
(perhaps most likely) a different glibc version than the installed
Python on your platform.  It's also possible that the installed Python 
is not the same Python version, which could explain all this.

If you don't get any further with investigating these possibilities,
can you mail us a *small* but *complete* example of code that fails
under RH 6.0 but succeeds on other platforms?  (If you mail us the
1000-line extension you wrote, it'll likely be impossible for us to
determine what's wrong.  If you reproduce the same problem in a
100-line extension that defines one function which makes one call to
PyFloat_AsDouble(), we might have a chance.)

Good luck,

--Guido van Rossum (home page: http://www.python.org/~guido/)


From tim_one@email.msn.com  Sun Sep 26 17:29:58 1999
From: tim_one@email.msn.com (tim_one@email.msn.com)
Date: Sun, 26 Sep 1999 12:29:58 -0400 (EDT)
Subject: [Python-bugs-list] Integer division can crash under Windows (PR#88)
Message-ID: <199909261629.MAA08666@python.org>

Full_Name: Tim Peters
Version: 1.5.2
OS: Win95
Submission from: 1cust9.tnt4.bos1.da.uu.net (63.21.45.9)


i_divmod doesn't catch overflow when dividing
-sys.maxint-1 by -1.  Under Win95, this has two symptoms:

1. Under the debug build, -sys.maxint-1 is returned.

2. Under the release(!) build, Windows kills the
   interpreter with a system division exception.

The difference is due to different division sequences generated by
the compiler (#2 is triggered by the hardware).

The patch below raises OverflowError in this case.

I confirm that, to the best of my knowledge and belief, this
contribution is free of any claims of third parties under
copyright, patent or other rights or interests ("claims").  To
the extent that I have any such claims, I hereby grant to CNRI a
nonexclusive, irrevocable, royalty-free, worldwide license to
reproduce, distribute, perform and/or display publicly, prepare
derivative versions, and otherwise use this contribution as part
of the Python software and its related documentation, or any
derivative versions thereof, at no cost to CNRI or its licensed
users, and to authorize others to do so.

I acknowledge that CNRI may, at its sole discretion, decide
whether or not to incorporate this contribution in the Python
software and its related documentation.  I further grant CNRI
permission to use my name and other identifying information
provided to CNRI by me for use in connection with the Python
software and its related documentation.

*** Objects/Old/intobject.c	Fri Mar 19 14:30:38 1999
--- Objects/New/intobject.c	Sun Sep 26 11:55:10 1999
***************
*** 434,441 ****
  		return -1;
  	}
  	if (yi < 0) {
! 		if (xi < 0)
  			xdivy = -xi / -yi;
  		else
  			xdivy = - (xi / -yi);
  	}
--- 434,447 ----
  		return -1;
  	}
  	if (yi < 0) {
! 		if (xi < 0) {
! 			if (yi == -1 && -xi < 0) {
! 				/* most negative / -1 */
! 				err_ovf("integer division");
! 				return -1;
! 			}
  			xdivy = -xi / -yi;
+ 		}
  		else
  			xdivy = - (xi / -yi);
  	}





From tim_one@email.msn.com  Mon Sep 27 07:03:08 1999
From: tim_one@email.msn.com (tim_one@email.msn.com)
Date: Mon, 27 Sep 1999 02:03:08 -0400 (EDT)
Subject: [Python-bugs-list] long(+/- infinity) returns nonsense (PR#89)
Message-ID: <199909270603.CAA20585@python.org>

Full_Name: Tim Peters
Version: 1.5.2
OS: Win95
Submission from: 1cust47.tnt4.bos1.da.uu.net (63.21.45.47)


I've been meaning to fix this for years:  PyLong_FromDouble returns
platform-specific gibberish if given an infinity as input.  On Windows,
it returns 0(!):

>>> i = 1e200**2
>>> i
1.#INF
>>> long(i)
0L
>>>

That's because the Windows frexp returns an exponent of 0 given an
infinity.  frexp was defined before IEEE-754 came into vogue, so
there's no portable behavior you can count on here.  This one is
particularly nasty because converting an extremely large long
(like 1L << 5000) to float returns an infinity, then converting
that back to 0 is the most surprising result imaginable.

Anyway, the attached patch uses a cheap platform-independent test
to weed out infinities before frexp is called.  It may cause the
hardware underflow flag to get set, but so it goes; until C9X,
there are no "neutral" platform-independent ways to test for an
infinity either.

After the patch:

>>> i = 1e200**2
>>> i
1.#INF
>>> long(i)
Traceback (innermost last):
  File "<stdin>", line 1, in ?
OverflowError: cannot convert float infinity to long
>>>

I confirm that, to the best of my knowledge and belief, this
contribution is free of any claims of third parties under
copyright, patent or other rights or interests ("claims").  To
the extent that I have any such claims, I hereby grant to CNRI a
nonexclusive, irrevocable, royalty-free, worldwide license to
reproduce, distribute, perform and/or display publicly, prepare
derivative versions, and otherwise use this contribution as part
of the Python software and its related documentation, or any
derivative versions thereof, at no cost to CNRI or its licensed
users, and to authorize others to do so.

I acknowledge that CNRI may, at its sole discretion, decide
whether or not to incorporate this contribution in the Python
software and its related documentation.  I further grant CNRI
permission to use my name and other identifying information
provided to CNRI by me for use in connection with the Python
software and its related documentation.

*** Objects/Old/longobject.c	Wed Jan 27 11:48:26 1999
--- Objects/New/longobject.c	Mon Sep 27 01:33:06 1999
***************
*** 145,150 ****
--- 145,155 ----
  	double frac;
  	int i, ndig, expo, neg;
  	neg = 0;
+ 	if (dval && dval * 0.5 == dval) {
+ 		PyErr_SetString(PyExc_OverflowError,
+ 			"cannot convert float infinity to long");
+ 		return NULL;
+ 	}
  	if (dval < 0.0) {
  		neg = 1;
  		dval = -dval;





From dgrisby@uk.research.att.com  Wed Sep 29 16:22:09 1999
From: dgrisby@uk.research.att.com (dgrisby@uk.research.att.com)
Date: Wed, 29 Sep 1999 11:22:09 -0400 (EDT)
Subject: [Python-bugs-list] Minor bug in threading.py (PR#90)
Message-ID: <199909291522.LAA23954@python.org>

Full_Name: Duncan Grisby
Version: 1.5.2
OS: All
Submission from: pineapple.cam-orl.co.uk (158.124.64.81)


The definition of the _DummyThread class in threading.py says:

class _DummyThread(Thread):
    
    def __init__(self):
        Thread.__init__(self, name=_newname("Dummy-%d"))
        self.__Thread_started = 1
...

It should actually say
        ...
        self._Thread__started = 1

The bug means that dummy threads reply 0 to isAlive() when they should return
1.




From guido@CNRI.Reston.VA.US  Wed Sep 29 16:28:16 1999
From: guido@CNRI.Reston.VA.US (Guido van Rossum)
Date: Wed, 29 Sep 1999 11:28:16 -0400
Subject: [Python-bugs-list] Minor bug in threading.py (PR#90)
In-Reply-To: Your message of "Wed, 29 Sep 1999 11:22:09 EDT."
 <199909291522.LAA23954@python.org>
References: <199909291522.LAA23954@python.org>
Message-ID: <199909291528.LAA07565@eric.cnri.reston.va.us>

Thanks -- your fix has been applied to the CVS archives.

--Guido van Rossum (home page: http://www.python.org/~guido/)