date:20140501

On Thursday, May 1, 2014 10:30:43 AM UTC+5:30, Steven D'Aprano wrote:
 On Tue, 29 Apr 2014 21:53:22 -0700, Rustom Mody wrote:

  On Tuesday, April 29, 2014 11:29:23 PM UTC+5:30, Tim Chase wrote:
  While I dislike feeding the troll, what I see here is:
  Since its Unicode-troll time, here's my contribution
  http://blog.languager.org/2014/04/unicode-and-unix-assumption.html

 Also your link to Joel On Software mistakenly links to me instead of Joel.
 There's a missing apostrophe in Ive [sic] in Acknowledgment #2.

Done, Done.

 I didn't notice any other typos.

Thank you sir!

 I point out that out of the two most widespread flavours of OS today, 
 Linux/Unix and Windows, it is *Windows* and not Unix which still 
 regularly uses legacy encodings.

Not sure what you are suggesting... 
That (I am suggesting that) 8859 is legacy and 1252 is not?

 I disagree with much of your characterisation of the Unix assumption,

I'd be interested to know the details -- Contents? Details? Tone? Tenor? 
Blaspheming the sacred scripture?
(if you are so inclined of course)


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Convert numpy array to single number

2014-05-01 Thread Papp Győző

Maybe something like this?
 to_num = lambda array: np.sum(array * 2**np.arange(len(array)-1, -1,
-1))
 to_num(np.array([1,0,1,0]))
10




2014-04-29 17:42 GMT+02:00 Tom P werot...@freent.dd:

 On 28.04.2014 15:04, mboyd02...@gmail.com wrote:

 I have a numpy array consisting of 1s and zeros for representing binary
 numbers:

 e.g.

binary
   array([ 1.,  0.,  1.,  0.])

 I wish the array to be in the form 1010, so it can be manipulated.

 I do not want to use built in binary converters as I am trying to build
 my own.


 Do you mean that each element in the array represents a power of two?
 So array([ 1.,  0.,  1.,  0.]) represents 2^3 + 2 = 6 decimal?

 --
 https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Significant digits in a float?

2014-05-01 Thread William Ray Wing

On May 1, 2014, at 12:16 AM, Mark H Harris harrismh...@gmail.com wrote:

 On 4/30/14 10:56 PM, Paul Rubin wrote:
 
 There is a nice Javascript simulation of the N4-ES here:
 
 http://www.antiquark.com/sliderule/sim/n4es/virtual-n4es.html
 
 
 Thank you!
 
 The N4-ES and the N4-T (mine) are essentially the same rule. The N4-ES on the 
 site is yellow (mine is white) and the site rule indicates Picket  Eckel 
 Inc. (that's where the E comes from)  Also the the ES states Chicage Ill USA 
 where the T states Made in USA.
 

I’ve resisted - but finally have to jump into this discussion...

Picket used to talk a lot about their yellow background being optimized for the 
color the human eye was most sensitive to and therefore produced the sharpest 
focus and allowed the most precise reading of the scales.  Nice theory, but at 
least on MY Picket rule the scales were printed not engraved and the result 
negated any possible advantage the color might have given.

I’m surprised no one has jumped in to defend/tout the Dietzgen slide rules 
(which I always thought were the ultimate).  Mine (their Vector Log Log) is one 
of their Microglide series that had teflon rails inserted in the body and is 
still totally stick-free after nearly 50 years.

Taking it one step further, I _ALSO_ have a Curta Type II calculator 
http://en.wikipedia.org/wiki/Curta_calculator - which still operates as 
smoothly as it did the day I bought it.

-Bill

 The only technical difference is the T scale (which is folded-expanded on 
 both). On the ES the T scale is listed only once in the margin.  On the N4-T 
 the T scale is listed 'twice'!--  once for each part of the fold.  Well, that 
 gives (2) scales instead of one --for T...  increasing the number of scales 
 on the rule from 34 to 35... if I'm counting right.  Which makes the N4-T 
 more valuable... supposedly.  I don't plan are parting with it... till I 
 croak, then my son (who is studying engineering this fall) will inherit it... 
  heh   he won't have a clue what to do with it !
 
 The simulated rule on the site above is fabulous... especially if viewed from 
 a large wide LED.  ... simply fabulouso/:)
 
 
 
 marcus
 -- 
 https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Slightly OT - using PyUIC from Eclipse

2014-05-01 Thread Steve Simmons


On 01/05/2014 02:50, Steven D'Aprano wrote:

On Thu, 01 May 2014 01:49:25 +0100, Steve Simmons wrote:


html
   head
 meta content=text/html; charset=UTF-8 http-equiv=Content-Type
   /head
   body bgcolor=#FF text=#00
 br
 div class=moz-cite-prefixOn 30/04/2014 23:49, Fabio Zadrozny
   wrote:br
 /div
 blockquote
cite=mid:CANXBEFrqndqCeT-9Hgqz7jRCZcmp8nz4VE+ebf-BKsYr54qQqQ
@mail.gmail.com
   type=cite

And that's about where I stopped reading.

I'm sorry Steve, but you're writing to a programmer's forum here, and you
should be sending in plain text, not so-called rich text (actually HTML
code, as you can see). At the very least, if you absolutely must send
HTML code, you should instruct your mail program to also send plain text.

People are reading this via Usenet and email and possibly using other
ways as well. Depending on how they are receiving your post, sending HTML
may be considered rude and a breach of etiquette (e.g. text-based news
groups typically ban binary attachments, including HTML), or their client
may not support HTML, or they may simply choose not to receive or read
such posts. (Pure HTML is one of the most reliable signs of spam email.)

So I'm afraid that I have no idea what you were trying to say in your
post. Manually deciphering the message from the markup was too painful.
I'm not likely to be the only one. If you would care to try again using
plain text, you may get a better response rate.




Mea Culpa.

Ironic really, the post was to thank Fabio for resolving my problem 
(posted correctly in plain text) and saying that I was too tired to make 
the required fix.  Obviously too tired to hit 'plain text' instead of 
'RTF' in my mail format drop-down too.


Anyways, a plain text Thank you to Fabio for fixing my issue; a Thank 
you to Mark Harris for putting my encoded text through the 
transmogrifier and an apology to the rest of the list members.


Steve
--
https://mail.python.org/mailman/listinfo/python-list

zipimport limited to 65536 files?

2014-05-01 Thread Tom Graves

Hello,

I am trying to use python (2.6.6) to read a jar file that contains python 
files.  I'm simply setting PYTHONPATH= 
spark-assembly-1.0.0-SNAPSHOT-hadoop2.4.0.jar.   Unfortunately it fails to read 
the python files from the jar file and if run in verbose mode just shows:

import zipimport # builtin
# installed zipimport hook
# zipimport: found 0 names in spark-assembly-1.0.0-SNAPSHOT-hadoop2.4.0.jar

I was messing around and noticed that if I reduce the number of files and 
directories in the jar to below 65536 then it works:

import zipimport # builtin
# installed zipimport hook
# zipimport: found 65452 names in pyspark.jar

Is this a known limitation or is this perhaps fixed in newer version or is 
there a work around?

Note, I'm not subscribed to the mailing list so please copy me in response if 
possible.

Thanks,
Tom
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Significant digits in a float?

2014-05-01 Thread Larry Hudson

On 05/01/2014 05:56 AM, Roy Smith wrote:

In article ljsghc$65b$1...@speranza.aioe.org,
Mark H Harris harrismh...@gmail.com wrote:

Absolutely, snort. I still have my KE (Keuffel Esser Co. N.Y.);
made of wood... (when ships were wood, and men were steel, and sheep ran
scared) ... to get to the S L T scales I have to pull the slide out
(turn it over) and reinsert it. You're right, the CF and DF scales are
missing, but the A B scales have the Ï€ symbol where it should be (more
or less). Mine is the 4058 C model, and you're right... has maths
equivalents and conversions printed on the back...

For those who have no idea what we're talking about, take a look at
http://www.ted.com/talks/clifford_stoll_on_everything. If you just want
to see what you do with a slide rule, fast forward to 14:20, but you
really owe it to yourself to invest the 18 minutes to watch the whole
thing.

Anyone (besides me) ever seen a cylindrical slide rule? I have one -- unfortunately misplaced
at the moment. :-(

The scales were helical around a cylinder giving (it was claimed) to be the equivalent of a
five-foot rule. But that still only gave one additional significant digit. Only two scales,
however, which limited its use to multiply/divide and logs. But interesting.

I just did a quick google search and found a picture of one on e-bay, asking price of $175.
This price rather surprised me because when I bought mine new (probably 45 or so years ago) I'm
sure I didn't pay more than around $25-$30 for it. And mine is in far better condition than the
one in the e-bay photo. I recently ran across mine, but promptly misplaced it again (long story
-- don't ask...). I'll have to look for it again. (And no, mine is not for sale when/if I find
it again.)

-=- Larry -=-

--
https://mail.python.org/mailman/listinfo/python-list

Re: Off-topic circumnavigating the earth in a mile or less

On 2014-05-01, Terry Reedy wrote:

 On 4/30/2014 7:46 PM, Ian Kelly wrote:

 It also works if your starting point is (precisely) the north pole.  I
 believe that's the canonical answer to the riddle, since there are no
 bears in Antarctica.

 For the most part, there are no bears within a mile of the North Pole 
 either. they are rare north of 88° (ie, 140 miles from pole).
 https://en.wikipedia.org/wiki/Polar_bears
 They mostly hunt in or near open water, near the coastlines.

 I find it amusing that someone noticed and posted an alternate, 
 non-canonical  solution. How might a bear be near the south pole? As 
 long as we are being creative, suppose some jokester mounts a near 
 life-size stuffed black bear, made of cold-tolerant artificial 
 materials, near but not at the South Pole. The intent is to give fright 
 to naive newcomers. Someone walking in a radius 1/2pi circle about the 
 pole might easily see it.

OK, change bear to bird  the question to What kind of bird is it?


-- 
There's no money in poetry, but there's no poetry in
money either.  --- Robert Graves
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Significant digits in a float?

On 2014-05-01, Dennis Lee Bieber wrote:

 On Tue, 29 Apr 2014 20:42:33 -0400, Roy Smith r...@panix.com declaimed the
 following:

In article mailman.9594.1398818045.18130.python-l...@python.org,
 Dennis Lee Bieber wlfr...@ix.netcom.com wrote:

 (one reason slide-rules were acceptable for so long -- and even my high
 school trig course only required slide-rule significance even though half
 the class had scientific calculators [costing $100, when a Sterling
 slide-rule could still be had for $10]) G

Sterling?  Snort.  KE was the way to go.

   Math teacher was selling them in my 10th grade... Actually I already
 owned a Faber-Castell 57/22 Business ruler (which did NOT have the CF/DF
 scales set for *PI) and a Pickett N-1010-ES Trig rule.

What does a business slide-rule do?  Depreciation?


-- 
Mrs CJ and I avoid clichés like the plague.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Off-topic circumnavigating the earth in a mile or less

On 2014-04-30, Ethan Furman wrote:

 Wow.  It's amazing how writing something down, wrongly (I originally had 
 north and south reversed), correcting it, 
 letting some time pass (enough to post the message so one can be properly 
 embarrassed ;), and then rereading it later 
 can make something so much clearer!

It's amazing how big a subthread appeared in response to a gag that I
think I got from a Car Talk puzzler.


-- 
A recent study conducted by Harvard University found that the average
American walks about 900 miles a year. Another study by the AMA found
that Americans drink, on average, 22 gallons of alcohol a year. This
means, on average, Americans get about 41 miles to the gallon.
 http://www.cartalk.com/content/average-americans-mpg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Significant digits in a float?

On 2014-05-01, Larry Hudson wrote:

 On 05/01/2014 05:56 AM, Roy Smith wrote:

 For those who have no idea what we're talking about, take a look at
 http://www.ted.com/talks/clifford_stoll_on_everything.  If you just want
 to see what you do with a slide rule, fast forward to 14:20, but you
 really owe it to yourself to invest the 18 minutes to watch the whole
 thing.


 Anyone (besides me) ever seen a cylindrical slide rule?  I have one -- 
 unfortunately misplaced 
 at the moment.  :-(

 The scales were helical around a cylinder giving (it was claimed) to be the 
 equivalent of a 
 five-foot rule.  But that still only gave one additional significant digit.  
 Only two scales, 
 however, which limited its use to multiply/divide and logs.  But interesting.

I have a circular (really spiral) slide rule that I inherited from
my grandfather.

http://www.ducksburg.com/atlas_slide_rule/

One of my uncles told me that he took it (or a similar model) to
university (ca. 1960, I guess)  got an F on a calculus test because
his answers were too accurate  precise to be honest.  He went to the
professor's office, showed him the circular slide rule,  got an A.


-- 
To live without killing is a thought which could electrify the world,
if men were only capable of staying awake long enough to let the idea
soak in. --- Henry Miller
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Off-topic circumnavigating the earth in a mile or less

2014-05-01 Thread Mark Lawrence


On 01/05/2014 21:57, Adam Funk wrote:

On 2014-05-01, Terry Reedy wrote:


On 4/30/2014 7:46 PM, Ian Kelly wrote:


It also works if your starting point is (precisely) the north pole.  I
believe that's the canonical answer to the riddle, since there are no
bears in Antarctica.


For the most part, there are no bears within a mile of the North Pole
either. they are rare north of 88° (ie, 140 miles from pole).
https://en.wikipedia.org/wiki/Polar_bears
They mostly hunt in or near open water, near the coastlines.

I find it amusing that someone noticed and posted an alternate,
non-canonical  solution. How might a bear be near the south pole? As
long as we are being creative, suppose some jokester mounts a near
life-size stuffed black bear, made of cold-tolerant artificial
materials, near but not at the South Pole. The intent is to give fright
to naive newcomers. Someone walking in a radius 1/2pi circle about the
pole might easily see it.


OK, change bear to bird  the question to What kind of bird is it?



A buffalo with an aqualung possibly?

--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


--
https://mail.python.org/mailman/listinfo/python-list

Re: Unicode 7


On 5/1/2014 2:04 PM, Rustom Mody wrote:


Since its Unicode-troll time, here's my contribution
http://blog.languager.org/2014/04/unicode-and-unix-assumption.html


I will not comment on the Unix-assumption part, but I think you go wrong 
with this:  Unicode is a Headache. The major headache is that unicode 
and its very few encodings are not universally used. The headache is all 
the non-unicode legacy encodings still being used. So you better title 
this section 'Non-Unicode is a Headache'.


The first sentence is this misleading tautology: With ASCII, data is 
ASCII whether its file, core, terminal, or network; ie ABC is 
65,66,67. Let me translate: If all text is ASCII encoded, then text 
data is ASCII, whether ... But it was never the case that all text was 
ASCII encoded. IBM used 6-bit BCDIC and then 8-bit EBCDIC and I believe 
still uses the latter. Other mainframe makers used other encodings of 
A-Z + 0-9 + symbols + control codes. The all-ASCII paradise was never 
universal. You could have just as well said With EBCDIC, data is 
EBCDIC, whether ...


https://en.wikipedia.org/wiki/Ascii
https://en.wikipedia.org/wiki/EBCDIC

A crucial step in the spread of Ascii was its use for microcomputers, 
including the IBM PC. The latter was considered a toy by the mainframe 
guys. If they had known that PCs would partly take over the computing 
world, they might have suggested or insisted that the it use EBCDIC.


With unicode there are:
encodings
where 'encodings' is linked to
https://en.wikipedia.org/wiki/Character_encodings_in_HTML

If html 'always' used utf-8 (like xml), as has become common but not 
universal, all of the problems with *non-unicode* character sets and 
encodings would disappear. The pre-unicode declarations could then 
disappear. More truthful: without unicode there are 100s of encodings 
and with unicode only 3 that we should worry about.


in-memory formats

These are not the concern of the using programmer as long as they do not 
introduce bugs or limitations (as do all the languages stuck on UCS-2 
and many using UTF-16, including old Python narrow builds). Using what 
should generally be the universal transmission format, UFT-8, as the 
internal format means either losing indexing and slicing, having those 
operations slow from O(1) to O(len(string)), or adding an index table 
that is not part of the unicode standard. Using UTF-32 avoids the above 
but usually wasted space -- up to 75%.


strange beasties like python's FSR

Have you really let yourself be poisoned by JMF's bizarre rants? The FSR 
is an *internal optimization* that benefits most unicode operations that 
people actually perform. It uses UTF-32 by default but adapts to the 
strings users create by compressing the internal format. The compression 
is trivial -- simple dropping leading null bytes common to all 
characters -- so each character is still readable as is. The string 
headers records how many bytes are left.  Is the idea of algorithms that 
adapt to inputs really strange to you?


Like good adaptive algorthms, the FSR is invisible to the user except 
for reducing space or time or maybe both. Unicode operations are 
otherwise the same as with previous wide builds. People who used to use 
narrow-builds also benefit from bug elimination. The only 'headaches' 
involved might have been those of the developers who optimized previous 
wide builds.


CPython has many other functions with special-case optimizations and 
'fast paths' for common, simple cases. For instance, (some? all?) number 
operations are optimized for pairs of integers.  Do you call these 
'strange beasties'?


PyPy is faster than CPython, when it is, because it is even more 
adaptable to particular computations by creating new fast paths. The 
mechanism to create these 'strange beasties' might have been a headache 
for the writers, but when it works, which it now seems to, it is not for 
the users.


--
Terry Jan Reedy


--
https://mail.python.org/mailman/listinfo/python-list

Re: zipimport limited to 65536 files?


On 5/1/2014 3:49 PM, Tom Graves wrote:

Hello,

I am trying to use python (2.6.6) to read a jar file that contains
python files.  I'm simply setting
PYTHONPATH=spark-assembly-1.0.0-SNAPSHOT-hadoop2.4.0.jar.
   Unfortunately it fails to read the python files from the jar file and
if run in verbose mode just shows:

import zipimport # builtin
# installed zipimport hook
# zipimport: found 0 names in spark-assembly-1.0.0-SNAPSHOT-hadoop2.4.0.jar

I was messing around and noticed that if I reduce the number of files
and directories in the jar to below 65536 then it works:

import zipimport # builtin
# installed zipimport hook
# zipimport: found 65452 names in pyspark.jar

Is this a known limitation


It is definitely not documented, which it should be if intentional.

 or is this perhaps fixed in newer version or

Install 3.4 and try. Or go to http://bugs.python.org,
click search, enter 'zipimport' in the title box, change 'open' in the 
status box to 'dont care', and look at 44 titles returned (I did not see 
anything that looked relevant).


All I know is that in the discussion about a ziplib issue, someone 
mentioned using zips with 10s of files. But zipimport could have an 
additional limitation.



is there a work around?


Multiple archives?


Note, I'm not subscribed to the mailing list so please copy me in
response if possible.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Unicode 7

2014-05-01 Thread MRAB


On 2014-05-01 23:38, Terry Reedy wrote:

On 5/1/2014 2:04 PM, Rustom Mody wrote:


Since its Unicode-troll time, here's my contribution
http://blog.languager.org/2014/04/unicode-and-unix-assumption.html


I will not comment on the Unix-assumption part, but I think you go wrong
with this:  Unicode is a Headache. The major headache is that unicode
and its very few encodings are not universally used. The headache is all
the non-unicode legacy encodings still being used. So you better title
this section 'Non-Unicode is a Headache'.


[snip]
I think he's right when he says Unicode is a headache, but only
because it's being used to handle languages which are, themselves, a
headache: left-to-right versus right-to-left, sometimes on the same
line; diacritics, possibly several on a glyph; etc.
--
https://mail.python.org/mailman/listinfo/python-list

optimized compile with egg files

2014-05-01 Thread Matyas

Our project is using setuptools to compile. I noticed that by default

python setup.py build

will create .pyc files which I assume are archived into the egg file. I do not 
know yet how to verify what is in the egg file.

I tried using

python setup.py build_py -O1
python setup.py install --user -O1

in my attempt to compile to .pyo files. Indeed the output indicates that .pyo 
files are created (I can see them in build/lib.macos-10.9-x86_64-2.7/...)

However I still see the some files being bytecompiled to .pyc files as well. I 
am not sure where these end up, I cannot find them.

Well I guess I hope for some direction on how to compile optimized using 
setuptools.

Then how to run the optimized version of the modules? Often we use nosetests to 
run and nosetests does not take a -O parm like python. Also ipython does not 
like -O either.

Thanks!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Unicode 7

On Friday, May 2, 2014 5:03:21 AM UTC+5:30, MRAB wrote:
 On 2014-05-01 23:38, Terry Reedy wrote:
  On 5/1/2014 2:04 PM, Rustom Mody wrote:
  Since its Unicode-troll time, here's my contribution
  http://blog.languager.org/2014/04/unicode-and-unix-assumption.html
  I will not comment on the Unix-assumption part, but I think you go wrong
  with this:  Unicode is a Headache. The major headache is that unicode
  and its very few encodings are not universally used. The headache is all
  the non-unicode legacy encodings still being used. So you better title
  this section 'Non-Unicode is a Headache'.
 [snip]
 I think he's right when he says Unicode is a headache, but only
 because it's being used to handle languages which are, themselves, a
 headache: left-to-right versus right-to-left, sometimes on the same
 line; diacritics, possibly several on a glyph; etc.

Yes, the headaches go a little further back than Unicode.
There is a certain large old book...
In which is described the building of a 'tower that reached up to heaven'...

At which point 'it was decided'¶ to do something to prevent that.

And our headaches started.

I dont know how one causally connects the 'headaches' but Ive seen
- mojibake
- unicode 'number-boxes' (what are these called?)
- Worst of all what we *dont* see -- how many others dont see what we see?

I never knew of any of this in the good ol days of ASCII

¶ Passive voice is often the best choice in the interests of political 
correctness

It would be a pleasant surprise if everyone sees a pilcrow at start of line 
above
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Unicode 7

On Friday, May 2, 2014 4:08:35 AM UTC+5:30, Terry Reedy wrote:
 On 5/1/2014 2:04 PM, Rustom Mody wrote:

  Since its Unicode-troll time, here's my contribution
  http://blog.languager.org/2014/04/unicode-and-unix-assumption.html

 I will not comment on the Unix-assumption part, but I think you go wrong 
 with this:  Unicode is a Headache. The major headache is that unicode 
 and its very few encodings are not universally used. The headache is all 
 the non-unicode legacy encodings still being used. So you better title 
 this section 'Non-Unicode is a Headache'.

 The first sentence is this misleading tautology: With ASCII, data is 
 ASCII whether its file, core, terminal, or network; ie ABC is 
 65,66,67. Let me translate: If all text is ASCII encoded, then text 
 data is ASCII, whether ... But it was never the case that all text was 
 ASCII encoded. IBM used 6-bit BCDIC and then 8-bit EBCDIC and I believe 
 still uses the latter. Other mainframe makers used other encodings of 
 A-Z + 0-9 + symbols + control codes. The all-ASCII paradise was never 
 universal. You could have just as well said With EBCDIC, data is 
 EBCDIC, whether ...

 https://en.wikipedia.org/wiki/Ascii
 https://en.wikipedia.org/wiki/EBCDIC

 A crucial step in the spread of Ascii was its use for microcomputers, 
 including the IBM PC. The latter was considered a toy by the mainframe 
 guys. If they had known that PCs would partly take over the computing 
 world, they might have suggested or insisted that the it use EBCDIC.

 With unicode there are:
  encodings
 where 'encodings' is linked to
 https://en.wikipedia.org/wiki/Character_encodings_in_HTML

 If html 'always' used utf-8 (like xml), as has become common but not 
 universal, all of the problems with *non-unicode* character sets and 
 encodings would disappear. The pre-unicode declarations could then 
 disappear. More truthful: without unicode there are 100s of encodings 
 and with unicode only 3 that we should worry about.

 in-memory formats

 These are not the concern of the using programmer as long as they do not 
 introduce bugs or limitations (as do all the languages stuck on UCS-2 
 and many using UTF-16, including old Python narrow builds). Using what 
 should generally be the universal transmission format, UFT-8, as the 
 internal format means either losing indexing and slicing, having those 
 operations slow from O(1) to O(len(string)), or adding an index table 
 that is not part of the unicode standard. Using UTF-32 avoids the above 
 but usually wasted space -- up to 75%.

 strange beasties like python's FSR

 Have you really let yourself be poisoned by JMF's bizarre rants? The FSR 
 is an *internal optimization* that benefits most unicode operations that 
 people actually perform. It uses UTF-32 by default but adapts to the 
 strings users create by compressing the internal format. The compression 
 is trivial -- simple dropping leading null bytes common to all 
 characters -- so each character is still readable as is. The string 
 headers records how many bytes are left.  Is the idea of algorithms that 
 adapt to inputs really strange to you?

 Like good adaptive algorthms, the FSR is invisible to the user except 
 for reducing space or time or maybe both. Unicode operations are 
 otherwise the same as with previous wide builds. People who used to use 
 narrow-builds also benefit from bug elimination. The only 'headaches' 
 involved might have been those of the developers who optimized previous 
 wide builds.

 CPython has many other functions with special-case optimizations and 
 'fast paths' for common, simple cases. For instance, (some? all?) number 
 operations are optimized for pairs of integers.  Do you call these 
 'strange beasties'?

Here is an instance of someone who would like a certain optimization to be
dis-able-able

https://mail.python.org/pipermail/python-list/2014-February/667169.html

To the best of my knowledge its nothing to do with unicode or with jmf.

Why if optimizations are always desirable do C compilers have:
-O0 O1 O2 O3 and zillions of more specific flags?

JFTR I have no issue with FSR.  What we have to hand to jmf - willingly
or otherwise - is that many more people have heard of FSR thanks to him. [I am 
one of them]

I dont even know whether jmf has a real
technical (as he calls it 'mathematical') issue or its entirely political:

Why should I pay more for a EURO sign than a $ sign?

Well perhaps that is more related to the exchange rate than to python!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Unicode 7

2014-05-01 Thread Ben Finney

Rustom Mody rustompm...@gmail.com writes:

 Yes, the headaches go a little further back than Unicode.

Okay, so can you change your article to reflect the fact that the
headaches both pre-date Unicode, and are made much easier by Unicode?

 There is a certain large old book...

Ah yes, the neo-Sumerian story “Enmerkar_and_the_Lord_of_Aratta”
URL:https://en.wikipedia.org/wiki/Enmerkar_and_the_Lord_of_Aratta.
Probably inspired by stories older than that, of course.

 In which is described the building of a 'tower that reached up to heaven'...
 At which point 'it was decided'¶ to do something to prevent that.
 And our headaches started.

And other myths with fantastic reasons for the diversity of language
URL:https://en.wikipedia.org/wiki/Mythical_origins_of_language.

 I never knew of any of this in the good ol days of ASCII

Yes, by ignoring all other writing systems except one's own – and
thereby excluding most of the world's people – the system can be made
simpler.

Hopefully the proportion of programmers who still feel they can make
such a parochial choice is rapidly shrinking.

-- 
 \ “Why doesn't Python warn that it's not 100% perfect? Are people |
  `\ just supposed to “know” this, magically?” —Mitya Sirenef, |
_o__) comp.lang.python, 2012-12-27 |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Unicode 7

On Friday, May 2, 2014 7:59:55 AM UTC+5:30, Rustom Mody wrote:
 Why should I pay more for a EURO sign than a $ sign?

A unicode 'headache' there:
I typed the Euro sign (trying again € ) not EURO

Somebody -- I guess its GG in overhelpful mode -- converted it
And made my post: 
Content-Type: text/plain; charset=ISO-8859-1

Will some devanagarari vowels help it stop being helpful?
अ आ इ ई उ ऊ ए ऐ
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Unicode 7

On Friday, May 2, 2014 8:09:44 AM UTC+5:30, Ben Finney wrote:
 Rustom Mody  writes:

  Yes, the headaches go a little further back than Unicode.

 Okay, so can you change your article to reflect the fact that the
 headaches both pre-date Unicode, and are made much easier by Unicode?

Predate: Yes
Made easier: No

  There is a certain large old book...

 Ah yes, the neo-Sumerian story Enmerkar_and_the_Lord_of_Aratta
 URL:https://en.wikipedia.org/wiki/Enmerkar_and_the_Lord_of_Aratta.
 Probably inspired by stories older than that, of course.

Thanks for that link

  In which is described the building of a 'tower that reached up to heaven'...
  At which point 'it was decided'¶ to do something to prevent that.
  And our headaches started.

 And other myths with fantastic reasons for the diversity of language
 URL:https://en.wikipedia.org/wiki/Mythical_origins_of_language.

This one takes the cake - see 1st para
http://hilgart.org/enformy/BronsonRekindling.pdf


  I never knew of any of this in the good ol days of ASCII

 Yes, by ignoring all other writing systems except one's own - and
 thereby excluding most of the world's people - the system can be made
 simpler.

 Hopefully the proportion of programmers who still feel they can make
 such a parochial choice is rapidly shrinking.

See link above: Ethnic differences and chauvinism are invariably linked
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Unicode 7

2014-05-01 Thread Chris Angelico

On Fri, May 2, 2014 at 12:29 PM, Rustom Mody rustompm...@gmail.com wrote:
 Here is an instance of someone who would like a certain optimization to be
 dis-able-able

 https://mail.python.org/pipermail/python-list/2014-February/667169.html

 To the best of my knowledge its nothing to do with unicode or with jmf.

It doesn't, and it has only to do with testing. I've had similar
issues at times; for instance, trying to benchmark one language or
language construct against another often means fighting against an
optimizer. (How, for instance, do you figure out what loop overhead
is, when an empty loop is completely optimized out?) This is nothing
whatsoever to do with Unicode, nor to do with the optimization that
Python and Pike (and maybe other languages) do with the storage of
Unicode strings.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Unicode 7

2014-05-01 Thread Steven D'Aprano

On Thu, 01 May 2014 18:38:35 -0400, Terry Reedy wrote:

 strange beasties like python's FSR
 
 Have you really let yourself be poisoned by JMF's bizarre rants? The FSR
 is an *internal optimization* that benefits most unicode operations that
 people actually perform. It uses UTF-32 by default but adapts to the
 strings users create by compressing the internal format. The compression
 is trivial -- simple dropping leading null bytes common to all
 characters -- so each character is still readable as is.

For anyone who, like me, wasn't convinced that Unicode worked that way, 
you can see for yourself that it does. You don't need Python 3.3, any 
version of 3.x will work. In Python 2.7, it should work if you just 
change the calls from chr() to unichr():

py for i in range(256):
... c = chr(i)
... u = c.encode('utf-32-be')
... assert u[:3] == b'\0\0\0'
... assert u[3:] == c.encode('latin-1')
...
py for i in range(256, 0x+1):
... c = chr(i)
... u = c.encode('utf-32-be')
... assert u[:2] == b'\0\0'
... assert u[2:] == c.encode('utf-16-be')
...
py 


So Terry is correct: dropping leading zeroes, and treating the remainder 
as either Latin-1 or UTF-16, works fine, and potentially saves a lot of 
memory.


-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Unicode 7

On Friday, May 2, 2014 8:31:56 AM UTC+5:30, Chris Angelico wrote:
 On Fri, May 2, 2014 at 12:29 PM, Rustom Mody wrote:
  Here is an instance of someone who would like a certain optimization to be
  dis-able-able
  https://mail.python.org/pipermail/python-list/2014-February/667169.html
  To the best of my knowledge its nothing to do with unicode or with jmf.

 It doesn't, and it has only to do with testing. I've had similar
 issues at times; for instance, trying to benchmark one language or
 language construct against another often means fighting against an
 optimizer. (How, for instance, do you figure out what loop overhead
 is, when an empty loop is completely optimized out?) This is nothing
 whatsoever to do with Unicode, nor to do with the optimization that
 Python and Pike (and maybe other languages) do with the storage of
 Unicode strings.

This was said in response to Terry's

 CPython has many other functions with special-case optimizations and
 'fast paths' for common, simple cases. For instance, (some? all?) number
 operations are optimized for pairs of integers.  Do you call these
 'strange beasties'?

which evidently vanished -- optimized out :D -- in multiple levels of quoting 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Unicode in Python

2014-05-01 Thread Michael Torrie

Can't help but feed the troll... forgive me.

On 04/28/2014 02:57 AM, wxjmfa...@gmail.com wrote:
 Python 2.7 + cp1252:
 - Solid and coherent system (nothing to do with the Euro).

Except that cp1252 is not unicode.  Perhaps some subset of unicode can
be encoded into bytes using cp1252.  But if it works for you keep using
it, and stop spreading nonsense about FSR.

 Python 3:
 - Flexible String Representation (a problem per se),
 a mathematical absurditiy which does the opposite of
 the coding schemes endorsed by Unicord.org (sheet of
 paper and pencil!)
 - Very deeply buggy (quadrature of the circle problem).

Maybe it's the language barrier, but whatever it is you are talking
about, I certainly can't make out.

You've been ranting about FSR for years without being able to clearly
say what's wrong with it.  Please quote unicode specifications that you
feel Python does not implement.  What unicode characters cannot be
represented?  Does Python choke on certain unicode strings or expose
entities it should not (like Javascript does)?

Why would you think that the unicode consortium's list of byte encodings
are the only possible valid ways of encoding unicode to a byte stream?

If you're going to continue to write this sort of stuff, please have the
decency to answer these questions at least.

 Positive side:
 - A very nice tool to teach the coding of characters
 and unicode.

Indeed.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Unicode 7


On 5/1/2014 7:33 PM, MRAB wrote:

On 2014-05-01 23:38, Terry Reedy wrote:

On 5/1/2014 2:04 PM, Rustom Mody wrote:


Since its Unicode-troll time, here's my contribution
http://blog.languager.org/2014/04/unicode-and-unix-assumption.html


I will not comment on the Unix-assumption part, but I think you go wrong
with this:  Unicode is a Headache. The major headache is that unicode
and its very few encodings are not universally used. The headache is all
the non-unicode legacy encodings still being used. So you better title
this section 'Non-Unicode is a Headache'.


[snip]
I think he's right when he says Unicode is a headache, but only
because it's being used to handle languages which are, themselves, a
headache: left-to-right versus right-to-left, sometimes on the same
line;


Handling that without unicode is even worse.


diacritics, possibly several on a glyph; etc.


Ditto.

--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Unicode 7

On Friday, May 2, 2014 9:46:36 AM UTC+5:30, Terry Reedy wrote:
 On 5/1/2014 7:33 PM, MRAB wrote:
  On 2014-05-01 23:38, Terry Reedy wrote:
  On 5/1/2014 2:04 PM, Rustom Mody wrote:
  Since its Unicode-troll time, here's my contribution
  http://blog.languager.org/2014/04/unicode-and-unix-assumption.html
  I will not comment on the Unix-assumption part, but I think you go wrong
  with this:  Unicode is a Headache. The major headache is that unicode
  and its very few encodings are not universally used. The headache is all
  the non-unicode legacy encodings still being used. So you better title
  this section 'Non-Unicode is a Headache'.
  [snip]
  I think he's right when he says Unicode is a headache, but only
  because it's being used to handle languages which are, themselves, a
  headache: left-to-right versus right-to-left, sometimes on the same
  line;

 Handling that without unicode is even worse.

  diacritics, possibly several on a glyph; etc.

 Ditto.

Whats the best cure for headache?

Cut off the head

Whats the best cure for Unicode?

Ascii

Saying however that there is no headache in unicode does not make the headache
go away:

http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/

No I am not saying that the contents/style/tone are right.
However people are evidently suffering the transition.
Denying it is not a help.

And unicode consortium's ways are not exactly helpful to its own cause:
Imagine the C standard committee deciding that adding mandatory garbage 
collection
to C is a neat idea

Unicode consortium's going from old BMP to current (6.0) SMPs to who-knows-what
in the future is similar.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Unicode 7

2014-05-01 Thread Chris Angelico

On Fri, May 2, 2014 at 2:42 PM, Rustom Mody rustompm...@gmail.com wrote:
 Unicode consortium's going from old BMP to current (6.0) SMPs to 
 who-knows-what
 in the future is similar.

Unicode 1.0: Let's make a single universal character set that can
represent all the world's scripts. We'll define 65536 codepoints to do
that with.

Unicode 2.0: Oh. That's not enough. Okay, let's define some more.

It's not a fundamental change, nor is it unhelpful to Unicode's cause.
It's simply an acknowledgement that 64K codepoints aren't enough. Yes,
that gave us the mess of UTF-16 being called Unicode (if it hadn't
been for Unicode 1.0, I doubt we'd now have so many languages using
and exposing UTF-16 - it'd be a simple judgment call, pick
UTF-8/UTF-16/UTF-32 based on what you expect your users to want to
use), but it doesn't change Unicode's goal, and it also doesn't
indicate that there's likely to be any more such changes in the
future. (Just look at how little of the Unicode space is allocated so
far.)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Unicode 7


On 5/1/2014 10:29 PM, Rustom Mody wrote:


Here is an instance of someone who would like a certain optimization to be
dis-able-able

https://mail.python.org/pipermail/python-list/2014-February/667169.html

To the best of my knowledge its nothing to do with unicode or with jmf.


Right. Ned has an actual technical reason to complain, even though the 
developers do not consider it strong enough to act.



Why if optimizations are always desirable do C compilers have:
-O0 O1 O2 O3 and zillions of more specific flags?


One reason is that many optimizations sometimes introduce bugs, or to 
put it another way, they are based on assumptions that are not true for 
all code. For instance, some people have suggested that CPython should 
have an optional optimization based on the assumption that builtin names 
are never rebound. That is true for perhaps many code files, but 
definitely not all. Guido does not seem to like such conditional 
optimizations.


I can think of three reasons for not adding to the numerous options 
CPython already has.
1. We do not have the developers resources to handle the added 
complications of multiple optimization options.
2. Zillions of options and flags confuse users. As it is, most options 
are seldom used.
3. Optimization options are easily misused, possibly leading to silently 
buggy results, or mysterious failures. For instance, people sometimes 
rebind builtins without realizing what they have done, such as using 
'id' as a parameter name. Being in the habit of routinely using the 
'assume no rebinding option' would lead to problems.


I am rather sure that the string (unicode) test suite was reviewed and 
the performance of 3.2 wide builds recorded before the new 
implementation was committed.


The tracker currently has 37 behavior (bug) issues marked for the 
unicode component. In a quick review, I do not see that any have 
anything to do with using standard UTF-32 versus adaptive UTF-32. 
Indeed, I believe a majority of the 37 were filed before 3.3 or are 2.7 
specific. Problems with FSR itself have been fixed as discovered.



JFTR I have no issue with FSR.  What we have to hand to jmf - willingly
or otherwise - is that many more people have heard of FSR thanks to him. [I am 
one of them]


Somewhat ironically, I suppose your are right.


I dont even know whether jmf has a real
technical (as he calls it 'mathematical') issue or its entirely political:


I would call his view personal or philosophical. I only object to 
endless repetition and the deception of claiming that personal views are 
mathematical facts.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

[issue21403] cElementTree's Element creation handles attrib argument different from ET


Stefan Behnel added the comment:

Works for me in 3.2 and 3.4, fails in 2.7, as reported.

I'll leave it to Eli to decide if this should get fixed in 2.7. In Py2, ET and 
cET were different modules, so this could also be considered a missing feature 
in cET. Given that it leads to a serialisation failure, though, it shouldn't 
hurt to change the behaviour.

(changing title to something more specific)

--
nosy: +scoder
title: cElementTree creation of nodes with attributes is bugged - 
cElementTree's Element creation handles attrib argument different from ET

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

[issue21403] cElementTree's Element creation handles attrib argument different from ET


Stefan Behnel added the comment:

Ah, sorry, actually, it does not work in Py3.2:

 import xml.etree.cElementTree as cET
 root = cET.Element('root', attrib={'Name':'Root'})
 child = cET.SubElement(root, 'child', attrib={'Name':'Child'})
 cET.tostring(root)
b'root attrib={\'Name\': \'Root\'}child attrib={\'Name\': \'Child\'} 
//root'

That's even worse than in 2.7 as it doesn't raise an exception.

--

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

[issue21403] cElementTree's Element creation handles attrib argument different from ET


Stefan Behnel added the comment:

According to issue 1572710, this is not a bug. The attrib argument is 
supposed to be a positional argument, not a keyword argument. This makes sense, 
given that arbitrary keyword arguments are accepted for additional XML 
attributes.

--

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

[issue21405] Allow using symbols from Unicode block Superscripts and Subscripts in identifiers

2014-05-01 Thread Roman Inflianskas


New submission from Roman Inflianskas:

It's really useful that python 3 allows me to use some Unicode symbols (as 
specified in 
https://docs.python.org/3.4/reference/lexical_analysis.html#identifiers), 
especially Greek symbols for mathematical programs. But when I write 
mathematical program with lots of indices I would like to use symbols from 
block Superscripts and Subscripts (as id_continue), for example: 

⁴₂₍₎

I don't see any problems with allowing yet another subset of Unicode symbols. 
In Julia, for example, I can use them without problems.

--
components: Unicode
messages: 217681
nosy: ezio.melotti, haypo, rominf
priority: normal
severity: normal
status: open
title: Allow using symbols from Unicode block Superscripts and Subscripts in 
identifiers
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

[issue21351] refcounts not respected at process exit

2014-05-01 Thread STINNER Victor


STINNER Victor added the comment:

Never rely on the GC. Avoid cycles by using the weakref module.

--

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

[issue21332] subprocess bufsize=1 docs are misleading

2014-05-01 Thread akira


akira added the comment:

I've changed test_newlines to work also with Python io implementation.

I've updated the patch.

Note: tests use 10 seconds timeouts: I don't know how long it should take to 
read back a line from a subprocess so that the timeout would indicate a 
deadlock.

--
Added file: 
http://bugs.python.org/file35124/subprocess-line-buffering-issue21332-ps2.patch

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

[issue21396] Python io implementation doesn't flush with write_through=True unlike C implementation

2014-05-01 Thread akira


akira added the comment:

I've uploaded the patch that makes C implementation behave according
to the docs like Python implementation with the corresponding tests.

Issue #21332 is a dependency for this issue: subprocess' 
test_universal_newlines needs to be updated to work with Python version.


For Reference
-

issue #12591 introduces `write_through` to support subprocess' stdin
pipe in text mode with bufsize=0 i.e., TextIOWrapper.buffer is
unbuffered (raw) and Python and C implementation behave the same in
this particular case.

C implementation (pseudo-code)::

  if self.write_through:
  flush_text_buffer()
  buffer.flush() # -- undocumented

Python implementation::

   if self.write_through:
   pass # _pyio.TextIOWrapper.write() calls buffer.write() directly

behaves according to the current documentation [1]:

   If *write_through* is ``True``, calls to :meth:`write` are guaranteed
   not to be buffered: any data written on the :class:`TextIOWrapper`
   object is immediately handled to its underlying binary *buffer*
  
[1]: hg.python.org/cpython/file/2a56d3896d50/Doc/library/io.rst

For reference, here's how subprocess.py uses write_through [2]::

  self.stdin = io.open(pipe, 'wb', bufsize)
  if universal_newlines=True:
  self.stdin = io.TextIOWrapper(self.stdin,
  write_through=True,
  line_buffering=(bufsize == 1)) # -- issue #21332

http://hg.python.org/cpython/rev/9ce8fa0a0899/ - introduce io.TextIOWrapper in 
subprocess
http://hg.python.org/cpython/rev/5cc536fbd7c1  - introduce write_through

[2]: http://hg.python.org/cpython/file/2a56d3896d50/Lib/subprocess.py#l849

--
keywords: +patch
Added file: 
http://bugs.python.org/file35125/io-write_through-c-vs-python-issue21396.patch

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

[issue2159] dbmmodule inquiry function is performance prohibitive

2014-05-01 Thread Jesús Cea Avión


Jesús Cea Avión added the comment:

OK, you did your homework.

I checked PyObject_Is_True() function and I agree. This actually looks like a 
leak when True/False were added to Python. Python3 is inheriting it :-).

OK.

I see three issues in the code:

a) You are getting a key from the database, and you are not freeing it. So, 
this code leaks memory.

b) You should check database errors too. Documentation says When the end of 
the database is reached, the dptr member of the key is a null pointer. If an 
error is detected, the dptr member of the key shall be a null pointer and the 
error condition of the database shall be set.. Raise an exception with the 
proper error. Would be nice to test that too, but it is probably nos possible.

c) Please, use NULL instead of 0.

Thanks for your effort, Eric.

--
assignee:  - jcea

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

[issue21391] PATCH: using the abspath shortcut in Lib/shutil

2014-05-01 Thread Yinon Ehrlich


Yinon Ehrlich added the comment:

Use the 'abspath' shortcut instead of 'os.path.abspath'
See the attached patch (sorry, forgot to attach before)

--
keywords: +patch
Added file: http://bugs.python.org/file35126/shutil.patch

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

[issue21405] Allow using symbols from Unicode block Superscripts and Subscripts in identifiers

2014-05-01 Thread Steven D'Aprano


Steven D'Aprano added the comment:

3.1, 3.2, 3.3 and 3.4 are all in feature-freeze, so this is only an option for 
3.5.

A very tentative +1 on this feature. But I fear it may need to be discussed on 
python-ideas first.

--
nosy: +steven.daprano
type:  - enhancement
versions:  -Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

[issue21391] PATCH: using the abspath shortcut in Lib/shutil

2014-05-01 Thread Eric V. Smith


Eric V. Smith added the comment:

Wouldn't it be better to switch uses of abspath to be os.path.abspath? os.path 
is used elsewhere in the file, after all.

Brett added from os.path import abspath in 
http://hg.python.org/cpython/rev/686e5d38be42 but I think that import should be 
deleted and os.path.abspath used directly.

--

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

[issue21391] PATCH: using the abspath shortcut in Lib/shutil

2014-05-01 Thread Eric V. Smith


Changes by Eric V. Smith e...@trueblade.com:


--
stage:  - patch review
type:  - behavior

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

[issue20951] SSLSocket.send() returns 0 for non-blocking socket


Antoine Pitrou added the comment:

Actually, the test hangs after one of the threads crashes:

test__all__ (test.test_poplib.TestPOP3_SSLClass) ... Exception in thread 
Thread-23:
Traceback (most recent call last):
  File /home/antoine/cpython/default/Lib/threading.py, line 920, in 
_bootstrap_inner
self.run()
  File /home/antoine/cpython/default/Lib/test/test_poplib.py, line 218, in run
asyncore.loop(timeout=0.1, count=1)
  File /home/antoine/cpython/default/Lib/asyncore.py, line 212, in loop
poll_fun(timeout, map)
  File /home/antoine/cpython/default/Lib/asyncore.py, line 153, in poll
read(obj)
  File /home/antoine/cpython/default/Lib/asyncore.py, line 87, in read
obj.handle_error()
  File /home/antoine/cpython/default/Lib/asyncore.py, line 83, in read
obj.handle_read_event()
  File /home/antoine/cpython/default/Lib/asyncore.py, line 422, in 
handle_read_event
self.handle_accept()
  File /home/antoine/cpython/default/Lib/asyncore.py, line 499, in 
handle_accept
self.handle_accepted(*pair)
  File /home/antoine/cpython/default/Lib/test/test_poplib.py, line 228, in 
handle_accepted
self.handler_instance = self.handler(conn)
  File /home/antoine/cpython/default/Lib/test/test_poplib.py, line 368, in 
__init__
self.push('+OK dummy pop3 server ready. timestamp')
  File /home/antoine/cpython/default/Lib/test/test_poplib.py, line 82, in push
asynchat.async_chat.push(self, data.encode(ISO-8859-1) + b'\r\n')
  File /home/antoine/cpython/default/Lib/asynchat.py, line 190, in push
self.initiate_send()
  File /home/antoine/cpython/default/Lib/asynchat.py, line 243, in 
initiate_send
self.handle_error()
  File /home/antoine/cpython/default/Lib/asynchat.py, line 241, in 
initiate_send
num_sent = self.send(data)
  File /home/antoine/cpython/default/Lib/asyncore.py, line 366, in send
result = self.socket.send(data)
  File /home/antoine/cpython/default/Lib/ssl.py, line 667, in send
return self._sslobj.write(data)
ssl.SSLWantReadError: The operation did not complete (read) (_ssl.c:1636)


This was due to a simplistic handling of asyncore SSL connections in 
test_poplib, which I've fixed by reusing the code from test_ftplib.

--

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

[issue21109] tarfile: Traversal attack vulnerability

2014-05-01 Thread Lars Gustäbel


Lars Gustäbel added the comment:

Let me present for discussion a proposal (and a patch with documentation) with 
an approach that is a little different, but in my opinion the most effective. I 
hope that it will appeal to all involved.

My proposal consists of a new class SafeTarFile, that is a subclass and drop-in 
replacement for the TarFile class and can be employed whenever the user feels 
the necessity.  It can be used the same way as TarFile, with the difference 
that SafeTarFile is equipped with a wide range of tests and as soon as it 
detects anything bad it interrupts the current operation with a SecurityError 
exception. This way damage is effectively averted, and it is up to the 
developer to decide whether he rejects the archive altogether (which is the 
obvious and recommended measure) or he wants to continue to process it in a 
subsequent step (on his own responsibility).

To simplify a few common operations, SafeTarFile has three more methods: 
analyze(), filter() and is_safe(). These methods will allow access to the 
archive without SecurityError exceptions being raised. The analyze() method is 
a kind of low-level iterator that produces each TarInfo object together with a 
list of warnings (if the member is bad) as a tuple. This gives a developer 
access to all the information he needs to implement his own more differentiated 
way of handling bad archives. The filter() method is a convenience method that 
provides an iterator over all the good members of an archive leaving out all 
the bad ones. It can be used as an argument to SafeTarFile.extractall() for 
example. is_safe() is a high-level shortcut method that reduces the result of 
the analysis to a simple True or False.

SafeTarFile has a variety of checks that test e.g. for bad pathnames, bad 
permissions and duplicate files. Also, to prevent denial-of-service scenarios, 
it enforces user-defined limits upon the archive, such as a maximum number of 
files or a maxmimum size of unpacked data.

The main advantage of this approach is the higher degree of security. The 
practice of rewriting paths (e.g. like in Daniel.Garcia's patch) is 
error-prone, has side-effects and is hard to maintain because of its tendency 
towards regression. It just adds another layer of complexity to an already 
complex and delicate problem.

SafeTarFile (or whatever it will be called) is backward compatible and easy to 
maintain, because it is an isolated addition to the tarfile module. It is 
easily subclassable to add more tests. It can be used as a standalone tool to 
check for bad archives and possible denial-of-service scenarios. Its analyze() 
method tells the user exactly what's wrong with the archive instead of keeping 
it away from him. Instead of silently extracting files to locations they 
weren't expected to be stored (i.e. after fixing their pathnames), 
SafeTarFile simply refuses to extract them at all. This way it is far more 
transparent and understandable to the user what happens.

Feedback is welcome.

--
assignee:  - lars.gustaebel
priority: release blocker - normal
versions:  -Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file35127/safetarfile-1.diff

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

[issue21406] Some socket constants are not enums


New submission from Antoine Pitrou:

Many constants in the socket module, are not int enums. Examples are 
socket.CAN_BCM, socket.BTPROTO_RFCOMM, etc.

For example when creating a bluetooth socket, you may get the following repr():

 socket.socket(socket.AF_BLUETOOTH, socket.SOCK_STREAM, 
 socket.BTPROTO_RFCOMM)
socket.socket fd=3, family=AddressFamily.AF_BLUETOOTH, 
type=SocketType.SOCK_STREAM, proto=3, laddr=('00:00:00:00:00:00', 0), 
raddr=('00:00:00:00:00:00', 0)

(notice the integer proto)

--
messages: 217691
nosy: barry, eli.bendersky, ethan.furman, neologix, pitrou
priority: low
severity: normal
status: open
title: Some socket constants are not enums
type: enhancement
versions: Python 3.5

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

[issue21405] Allow using symbols from Unicode block Superscripts and Subscripts in identifiers


Antoine Pitrou added the comment:

I think python-dev or python-ideas should indeed be consulted before.

--
nosy: +pitrou

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

[issue21404] Compression level for tarfile/zipfile

2014-05-01 Thread Lars Gustäbel


Lars Gustäbel added the comment:

tarfile.open() actually supports a compress_level argument for gzip and bzip2 
and a preset argument for lzma compression.

--
nosy: +lars.gustaebel

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

[issue21377] PyBytes_Concat could try to concat in-place


Antoine Pitrou added the comment:

Thanks! The latest patch looks fine to me.

--

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

[issue21377] PyBytes_Concat could try to concat in-place

2014-05-01 Thread Roundup Robot


Roundup Robot added the comment:

New changeset 4ed1b6c7e2f3 by Antoine Pitrou in branch 'default':
Issue #21377: PyBytes_Concat() now tries to concatenate in-place when the first 
argument has a reference count of 1.
http://hg.python.org/cpython/rev/4ed1b6c7e2f3

--
nosy: +python-dev

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

[issue21377] PyBytes_Concat could try to concat in-place


Changes by Antoine Pitrou pit...@free.fr:


--
resolution:  - fixed
stage:  - resolved
status: open - closed

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

[issue21405] Allow using symbols from Unicode block Superscripts and Subscripts in identifiers

2014-05-01 Thread Roman Inflianskas


Roman Inflianskas added the comment:

I'm sorry, I didn't now that bugtracker is not for features discussing. I'll 
wrote the letter to the python-ideas: 
https://groups.google.com/forum/#!topic/python-ideas/yjR7j9TSFeE

--

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

[issue21407] Add function signatures to _decimal


Changes by Stefan Krah stefan-use...@bytereef.org:


--
assignee: skrah
components: Extension Modules
nosy: skrah
priority: normal
severity: normal
status: open
title: Add function signatures to _decimal
type: enhancement
versions: Python 3.5

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

[issue21407] Add function signatures to _decimal

2014-05-01 Thread Roundup Robot


New submission from Roundup Robot:

New changeset 40b06a75d1c6 by Stefan Krah in branch 'default':
Issue #21407: _decimal now supports function signatures.
http://hg.python.org/cpython/rev/40b06a75d1c6

--
nosy: +python-dev

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

[issue21399] inspect and class methods


Stefan Krah added the comment:

Okay, thanks.  I've used $cls for Decimal.from_float in 40b06a75d1c6,
and it appears to work already.


Feel free to close the issue (I don't know whether AC emits $cls or
if it should).

--

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

[issue21407] Add function signatures to _decimal


Changes by Stefan Krah stefan-use...@bytereef.org:


--
resolution:  - fixed
stage:  - resolved
status: open - closed

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

[issue21408] delegation of `!=` to the right-hand side argument is not always done

2014-05-01 Thread Jean-Paul Calderone


New submission from Jean-Paul Calderone:

$ ~/Projects/cpython/3.4/python -c '
class Foo(object):
def __ne__(self, other):
return yup
def __eq__(self, other):
return nope

class Bar(object):
pass

print(object() != Foo(), object() == Foo())
print(Bar() != Foo(), Bar() == Foo())
'
yup nope
False nope
$

The output I would expect from this is

yup nope
yup nope

That is, even when the type of the left-hand argument is not a base class of 
the type of the right-hand argument, delegation to the right-hand argument is 
sensible if the left-hand argument does not implement the comparison.

Note that the output also demonstrates that this is already the behavior for 
`==`.  Only `!=` seems to suffer from this issue.

--
components: Interpreter Core
messages: 217699
nosy: exarkun
priority: normal
severity: normal
status: open
title: delegation of `!=` to the right-hand side argument is not always done
type: behavior
versions: Python 3.3, Python 3.4

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

[issue21408] delegation of `!=` to the right-hand side argument is not always done

2014-05-01 Thread Benjamin Peterson


Benjamin Peterson added the comment:

That's because the implicit default __ne__ on Bar returns the opposite of 
__eq__.

--
nosy: +benjamin.peterson

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

[issue21400] Code coverage documentation is out-of-date.

2014-05-01 Thread Brett Cannon


Changes by Brett Cannon br...@python.org:


--
nosy: +brett.cannon

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

[issue21401] python2 -3 does not warn about str/unicode to bytes conversions and comparisons

2014-05-01 Thread Brett Cannon


Brett Cannon added the comment:

Unfortunately it's impossible to warn against this in Python 2 since the bytes 
type is just another name for the str type:

 str == bytes
True
 type(b'1')
type 'str'

What we could potentially do, though, is change things such that -3 does what 
you are after when comparing bytes/str to unicode in Python 2. Unfortunately in 
that instance it's still a murky question as to whether that will help things 
more than hurt them as some people explicitly leave strings as-is in both 
Python 2 and Python 3 for either speed or code simplicity reasons.

--
nosy: +brett.cannon
title: python2 -3 does not warn about str to bytes conversions and comparisons 
- python2 -3 does not warn about str/unicode to bytes conversions and 
comparisons

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

[issue21404] Compression level for tarfile/zipfile

2014-05-01 Thread Sworddragon


Sworddragon added the comment:

Could it be that compress_level is not documented?

--

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

[issue21404] Compression level for tarfile/zipfile

2014-05-01 Thread Lars Gustäbel


Lars Gustäbel added the comment:

That's right. But it is there.

--

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

[issue21404] Compression level for tarfile/zipfile

2014-05-01 Thread Sworddragon


Sworddragon added the comment:

Then this one is easy: The documentation needs just an update. But then there 
is still zipfile that doesn't provide (or at least document) a compression 
level.

--

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

[issue21401] python2 -3 does not warn about str/unicode to bytes conversions and comparisons

2014-05-01 Thread Joshua J Cogliati


Joshua J Cogliati added the comment:

Hm.  That is a good point.  Possibly it could only be done when 
from __future__ import unicode_literals
has been used.  For example:

python2 -3
Python 2.7.5 snip
Type help, copyright, credits or license for more information.
 type(ba) == type(a)
True
 from __future__ import unicode_literals
 type(ba) == type(a)
False
 ba == a
True
 ba + a
u'aa'
 


After unicode_literals is used, then ba and a have a different type and the 
same code would be an issue in python3:
 python3
Python 3.3.2 snip
 type(ba) == type(a)
False
 ba == a
False
 ba + a
Traceback (most recent call last):
  File stdin, line 1, in module
TypeError: can't concat bytes to str


--

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

[issue21403] cElementTree's Element creation handles attrib argument different from ET

2014-05-01 Thread Santoso Wijaya


Santoso Wijaya added the comment:

There is still a matter of inconsistency between the two implementations and 
between 2.7 and 3.x. IMO, the Python-based ElementTree implementation is more 
graceful at handling the attrib argument.

The signature of the factory function Element (and SubElement) in the doc is 
thus:

class xml.etree.ElementTree.Element(tag, attrib={}, **extra)


which is fair game for the user to use attrib as a keyword argument.

Further, this serialization (in 3.x) does not really make sense, anyway:

 cET.tostring(root)
b'root attrib={\'Name\': \'Root\'}child attrib={\'Name\': \'Child\'} 
//root'

--
components: +XML

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

[issue21403] cElementTree's Element creation handles attrib argument different from ET

2014-05-01 Thread Santoso Wijaya


Santoso Wijaya added the comment:

Quoting dabrahams in issue 1572710:

On second thought, I see what effbot is trying to say... but it's still a bug. 
Given the way the interface is declared and the behavior of regular python 
functions:

  Element(tag, attrib={}, **extra)

indicates that I can pass attrib (or tag, for that matter) as a keyword 
argument.  Nothing in the documentation gives the C implementation permission 
to behave differently.

--

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

[issue21403] cElementTree's Element creation handles attrib argument different from ET


Stefan Behnel added the comment:

Note that this has been fixed in Py3 already (Py3.3, I guess). The only 
question is whether the behaviour will be changed in Py2.7.

--
components:  -XML

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

[issue21403] cElementTree's Element creation handles attrib argument different from ET

2014-05-01 Thread Eli Bendersky


Eli Bendersky added the comment:

 Note that this has been fixed in Py3 already (Py3.3, I guess). The only
 question is whether the behaviour will be changed in Py2.7.


I don't think this issue is acute enough to warrant fixes in 2.7; however,
a documentation patch would be welcome.

--

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

[issue21400] Code coverage documentation is out-of-date.


Changes by Antoine Pitrou pit...@free.fr:


--
components: +Devguide
nosy: +ezio.melotti

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

[issue21406] Some socket constants are not enums


Charles-François Natali added the comment:

Enum are for, well, enumerated values, so for values within a finite
and known range (like days, cards, etc).
OTOH, I'm not sure all socket constants could be categorized like this.
It makes sense for address families, especially since they're used so
much, but when it comes to e.g. SO_REUSEADDR or BTPROTO_RFCOMM, I'm
not sure how we could categorize them.
Unless would declare them all in a SocketConstant Enum?

--

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

[issue1599254] mailbox: other programs' messages can vanish without trace

2014-05-01 Thread David Watson


David Watson added the comment:

On Mon 28 Apr 2014, Jim Jewett wrote:
 pinging David Watson:  What is the status?  If I understand correctly, (and I 
 may well not), you have already opened other issues for parts of this, and 
 (only) the final patch is ready for patch (and hopefully) commit review.  Is 
 this correct?

No, I haven't opened any separate issues (I would be perfectly
happy with fixing the original renaming-vs-copying problem and
then leaving this issue open to deal with the rest).  The patches
mailbox-copy-back-2.7.diff and
mailbox-tests-2.7-part1-for-copy-back.diff are what I suggest
applying for the renaming-vs-copying problem.

I haven't looked at the other patches in much detail, but for
what it's worth, the tests in mailbox-tests-2.7-part2.diff do
pass with mailbox-update-toc-again.diff applied.

--

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

[issue21406] Some socket constants are not enums

2014-05-01 Thread R. David Murray


R. David Murray added the comment:

This is why we should have had named constants and not Enums :)

But no, nothing in the python Enum implementation restricts it to a value 
*range*.  It is really a collection of named constants.

--
nosy: +r.david.murray

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

[issue21406] Some socket constants are not enums


Charles-François Natali added the comment:

 But no, nothing in the python Enum implementation restricts it to a value 
 *range*.  It is really a collection of named constants.

I didn't say in the implementation, I said in spirit.
Would you describe all possible Unix PIDs are a Enum?

Also, the problem is that many such constant can have identical values
(because they can be passed at different syscalls/argument offset),
and in this case the IntEnum equality isn't wanted:
cf@neobox:~/python/hg/default$ cat /tmp/test.py
from enum import IntEnum

class Const(IntEnum):

AF_INET = 1
SO_REUSEADDR = 1

print(Const.AF_INET == Const.SO_REUSEADDR)
cf@neobox:~/python/hg/default$ ./python /tmp/test.py
True

Really?

--

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

[issue21406] Some socket constants are not enums


Antoine Pitrou added the comment:

 It makes sense for address families, especially since they're used so
 much, but when it comes to e.g. SO_REUSEADDR or BTPROTO_RFCOMM,

Hmm, I was thinking mostly about protocol numbers. All the BTPROTO_* constants 
should be part of a given enum (BlueToothProtocol?), the CAN_* constants part 
of another one.

--

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

[issue21406] Some socket constants are not enums


Charles-François Natali added the comment:

To put it slightly differently:
AF_XXX constant actually whome belong to the same namespace, the
socket address family namespace.
So we put them all in AddressFamily Enum.

Now, for many constants defined in system header files, it's not so
clear, e.g. BTPROTO_RFCOMM, TIPC_ADDR_ID, SCM_CREDENTIALS: in which
Enum would you declare them?

I'm not saying it's a bad idea: it actually probably makes sense for
e.g. socket-level options (SO_REUSEADDR  Co), but it don't see any
generic classification scheme that would make sense for all of them.

--

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

[issue21406] Some socket constants are not enums


Antoine Pitrou added the comment:

Ah, I missed the fact that the family and type properties are re-computed 
on the fly; I thought the enum values where stored on the socket object.

Then it makes it harder to do the same for proto, since there are 
family-specific namespaces with colliding values, indeed.

 socket.IPPROTO_ICMP
1
 socket.BTPROTO_HCI
1

--

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

[issue21409] setup.py check - should fail and retrun a non 0 exit code

2014-05-01 Thread Jeff Hinrichs


New submission from Jeff Hinrichs:

python setup.py check 
python setup.py check --restructuredtext

both incorrectly warn and don't Fail for things that will cause a failure 
when uploading to pypi.  This is wrong.

Additionally, they should return a non 0 exit code so they can be used as part 
of an CI such as drone.io / travis so the build will show as failing.  
Currently they do not, and if there are errors that will cause a pypi failure 
(like an unreadable long description) bad things happen.

--
components: Distutils
messages: 217719
nosy: dstufft, dundeemt, eric.araujo
priority: normal
severity: normal
status: open
title: setup.py check - should fail and retrun a non 0 exit code
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

[issue21409] setup.py check - should fail and retrun a non 0 exit code

2014-05-01 Thread Jeff Hinrichs


Jeff Hinrichs added the comment:

example:

(dhp)jlh@jlh-d520:~/Projects/dhp/src$ python setup.py check
running check
(dhp)jlh@jlh-d520:~/Projects/dhp/src$ python setup.py check --restructuredtext
running check
warning: check: Title underline too short. (line 2)

warning: check: Could not finish the parsing.

--

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

[issue21410] setup.py check --restructuredtext -- appears to pass if docutils not installed

2014-05-01 Thread Jeff Hinrichs


New submission from Jeff Hinrichs:

if you run
  setup.py check --restructuredtext
without docutils installed, it will appear to pass

if you add the -s flag, it will error and inform you that docutils is not 
installed.   

So nothing is reported and return results are the same as a passing check.

$ python setup.py check --restructuredtext
running check

$ python setup.py check --restructuredtext -s
running check
error: The docutils package is needed.


The not strict version is a little too loose to be of any good.

--
components: Distutils
messages: 217721
nosy: dstufft, dundeemt, eric.araujo
priority: normal
severity: normal
status: open
title: setup.py check --restructuredtext  -- appears to pass if docutils not 
installed
versions: Python 2.7

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

[issue21411] Enable Treat Warning as Error on 32-bit Windows

2014-05-01 Thread Zachary Ware


New submission from Zachary Ware:

Python 3.4 and 3.5 both compile without warnings on 32-bit Windows, so we 
should turn on Treat Warning as Error (/WX option to cl.exe).  Setting that 
property in pyproject.props sets it for all projects, and the setting does not 
affect Makefile projects so warnings from OpenSSL, Tcl, Tk, or Tix will not 
kill the build.  It will need to be explicitly disabled on 64-bit Windows; 
setting it in x64.props does the trick.

One small issue is that /WX does pick up the no profile information warning 
in the PGUpdate build.  I'm unsure whether we should turn off /WX in 
pgupdate.props, or just force PGUpdate builders to have run something for each 
PGI'd project.

--
components: Build, Windows
messages: 217722
nosy: loewis, tim.golden, zach.ware
priority: low
severity: normal
status: open
title: Enable Treat Warning as Error on 32-bit Windows
type: enhancement
versions: Python 3.4, Python 3.5

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

[issue21412] core dump in PyThreadState_Get when built --with-pymalloc

2014-05-01 Thread John Beck


New submission from John Beck:

I am porting Python 3.4.0 to Solaris 12.  The Makefile I inherited from my 
predecessor had --without-pymalloc as an option to be passed to configure.  
Curious why, I removed this line, only to find that after python was built, it 
core dumped:

LD_LIBRARY_PATH=/builds/jbeck/ul-python-3/components/python/python34/build/sparcv9
 ./python -E -S -m sysconfig --generate-posix-vars
Fatal Python error: PyThreadState_Get: no current thread
make[3]: *** [pybuilddir.txt] Abort (core dumped)

But if I add the --without-pymalloc line back to my Makefile, everything works 
fine.
 
Note that although this example was on sparc, the exact same thing occurred on 
x86.

I searched for a similar bug but did not find out; please feel free to close 
this as a duplicate if there is one that I missed.  I also suspect I have not 
provided enough information, out of a desire not to trigger information 
overload.  But I would be happy to provide whatever specifics might be 
requested.

--
components: Interpreter Core
messages: 217723
nosy: jbeck
priority: normal
severity: normal
status: open
title: core dump in PyThreadState_Get when built --with-pymalloc
type: crash
versions: Python 3.4

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

[issue21412] core dump in PyThreadState_Get when built --with-pymalloc


Stefan Krah added the comment:

On SPARC/suncc the flags in http://bugs.python.org/issue15963#msg170661
appear to work.

Also, we have several Solaris build slaves that don't core dump.
Some are offline, but you can click through to the ./configure
steps of past builds to see the build flags.

http://buildbot.python.org/all/waterfall?category=3.x.stablecategory=3.x.unstable

--
nosy: +skrah

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

[issue21037] add an AddressSanitizer build option


Stefan Krah added the comment:

 Hmm... perhaps Stefan would like to set something up?

Being a correctness tool hipster, of course I already have the latest toy. :)  
The patch works on Debian 64-bit + clang.

I can set up a VM.  We may have to react quickly to some of the issues.
Then again, anyone can run the tool, so there's no real secrecy anyway.

--

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

[issue21399] inspect and class methods

2014-05-01 Thread Yury Selivanov


Yury Selivanov added the comment:

Yeah, I'm closing this issue.

--
resolution:  - not a bug
status: open - closed

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

[issue21408] delegation of `!=` to the right-hand side argument is not always done

2014-05-01 Thread Josh Rosenberg


Josh Rosenberg added the comment:

Why would an subclass of object that doesn't redefine either __eq__ or __ne__ 
have a different behavior for inequality than object itself? Bar never defined 
__eq__, so it shouldn't have an implicit __ne__ any more than object itself 
does...

Saying that Bar has an implicit __ne__ that object doesn't is answering how 
this happens, but it's not a why; is there a reason why this should be the 
case, or is this a bug (either in spec or in code) that should be fixed?

--
nosy: +josh.rosenberg

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

[issue21037] add an AddressSanitizer build option