Re: Any comment on using ctypesgen package?

[Chris Angelico]

On Sat, Mar 5, 2016 at 4:35 PM,   wrote:
> After taking Chris's suggestion, the installation is pushing forward a little 
> and then bump into another error:
> --
> File "D:\Patch\ctypesgen-master\ctypesgencore\parser\pplexer.py", line 123, in
> punctuator_regex
> punctuator_regexes.sort(lambda a, b: -cmp(len(a), len(b)))
> TypeError: must use keyword argument for key function
> --
> This error has been mentioned in "Sorting HOW TO" section in 3.4 document,
> "In Py3.0, the cmp parameter was removed entirely"
> "To convert to a key function, just wrap the old comparison function:"
> "In Python 3.2, the functools.cmp_to_key() function was added to the 
> functools module in the standard library."
>
> Oh, goodness! do I have to dive into 2.x?
>
> Based on the assumptions below:
> 1. It might be not easy to upgrade it to 3.x (at least not just run 2To3), or 
> else its author will not drop it.
> 2. I have to go back into 2.x jungle to study all these difference.
> 3. Even "Python setup.py install" passed, it's still not sure if the output 
> will be correct.
>
> I think it's better to drop it too. Thanks for your advice, Chris and Peter.

Your conclusion may well be correct. However, the exact issue you're
looking at here might be easily enough fixed; it looks like it's
trying to sort things by length, so you can simply use "key=len" (and
maybe "reverse=True").

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

Re: Any comment on using ctypesgen package?

[jfong]

Peter Otten 2016/3/4  UTC+8 8:36:02PM worte:
> """
> The 2to3 route is not likely to apply since ctypesgen actually writes Python 
> code and the 2to3 utility will probably miss a good portion of that logic.
> """
> 
> But as someone else seems to have done the work already
> 
> https://github.com/davidjamesca/ctypesgen/issues/51
> 
> I'd try his version first.

Following this link, it says "Make output python3-compatible". So it still run 
under 2.x but generate codes for 3.x:-(

After taking Chris's suggestion, the installation is pushing forward a little 
and then bump into another error:
--
File "D:\Patch\ctypesgen-master\ctypesgencore\parser\pplexer.py", line 123, in  
punctuator_regex
punctuator_regexes.sort(lambda a, b: -cmp(len(a), len(b)))
TypeError: must use keyword argument for key function
--
This error has been mentioned in "Sorting HOW TO" section in 3.4 document,
"In Py3.0, the cmp parameter was removed entirely"
"To convert to a key function, just wrap the old comparison function:"
"In Python 3.2, the functools.cmp_to_key() function was added to the 
functools module in the standard library."

Oh, goodness! do I have to dive into 2.x?

Based on the assumptions below:
1. It might be not easy to upgrade it to 3.x (at least not just run 2To3), or 
else its author will not drop it.
2. I have to go back into 2.x jungle to study all these difference.
3. Even "Python setup.py install" passed, it's still not sure if the output 
will be correct.

I think it's better to drop it too. Thanks for your advice, Chris and Peter.

--Jach

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

Re: Continuing indentation

[Ben Finney]

srinivas devaki  writes:

> thought i should add this here so that people will get to this after
> someone decides a standard way to do this :P

No, you've wasted that effort. If you want a request to be acted on by
those who maintain the official Python source, submit it to the official
Python bug tracker. Here, it will simply be ignored.

-- 
 \ “We live in capitalism. Its power seems inescapable. So did the |
  `\   divine right of kings.” —Ursula K. LeGuin, National Book Awards |
_o__)acceptance speech, 2014-11-19 |
Ben Finney

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

Re: Continuing indentation

[srinivas devaki]

thought i should add this here so that people will get to this after
someone decides a standard way to do this :P

look for second if condition in the source code of
subprocess.Popen(*args, **kwargs).communicate

def communicate(self, input=None, timeout=None):
"""Interact with process: Send data to stdin.  Read data from
stdout and stderr, until end-of-file is reached.  Wait for
process to terminate.

The optional "input" argument should be data to be sent to the
child process (if self.universal_newlines is True, this should
be a string; if it is False, "input" should be bytes), or
None, if no data should be sent to the child.

communicate() returns a tuple (stdout, stderr).  These will be
bytes or, if self.universal_newlines was True, a string.
"""

if self._communication_started and input:
raise ValueError("Cannot send input after starting communication")

# Optimization: If we are not worried about timeouts, we haven't
# started communicating, and we have one or zero pipes, using select()
# or threads is unnecessary.
if (timeout is None and not self._communication_started and
[self.stdin, self.stdout, self.stderr].count(None) >= 2):
stdout = None
stderr = None
if self.stdin:
self._stdin_write(input)
elif self.stdout:
stdout = self.stdout.read()
self.stdout.close()
elif self.stderr:
stderr = self.stderr.read()
[. extra code snapped]

ps: Python3.5.1


On Sat, Mar 5, 2016 at 8:19 AM, Tim Chase  wrote:
> On 2016-03-04 17:17, sohcahto...@gmail.com wrote:
>> x \
>> = \
>> 5
>> if \
>> y \
>> == \
>> z:
>> print \
>> 'this is terrible'
>> print \
>> 'but still not incorrect
>>
>> It would be terrible, still but not incorrect.
>
> And has the sociopathic benefit that the diffs make it quite clear
> what changed.  None of this
> looking-deep-into-lines-to-see-what-changed.
>
>   x \
>   = \
>   5
>   if \
>   y \
> - != \
> + == \
>   z:
>   print \
>   'this is terrible'
>   print \
>   'but still not incorrect
>
> Still terrible.  But not quite as useless as a knee-jerk reaction
> might suggest.
>
> I actually hacked together a binary-diff something like this,
> emitting every hex-formatted byte of each file on its own line, then
> diffing the two results.  I could see doing something similar to diff
> Python ASTs.
>
> -tkc
>
>
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list



-- 
Regards
Srinivas Devaki
Junior (3rd yr) student at Indian School of Mines,(IIT Dhanbad)
Computer Science and Engineering Department
ph: +91 9491 383 249
telegram_id: @eightnoteight
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: creating zipfile with symlinks

[Michael Torrie]

On 03/04/2016 05:18 AM, Larry Martell wrote:
> Unfortunately very slow - around 8 minutes to zip a 7GB dir using the
> command line zip vs. 13 seconds with the python zipfile module.

And likely Python's zipfile is just giving up and storing the file
without compression.  What does unzip -v say about the compression on
the zip file you made with zipfile.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Lookahead while doing: for line in fh.readlines():

[Veek. M]

MRAB wrote:

> On 2016-03-04 13:04, Veek. M wrote:
>> Terry Reedy wrote:
>>
>>> On 2/27/2016 4:39 AM, Veek. M wrote:
 I want to do something like:

 #!/usr/bin/env python3

 fh = open('/etc/motd')
 for line in fh.readlines():
  print(fh.tell())

 why doesn't this work as expected.. fh.readlines() should return a
 generator object and fh.tell() ought to start at 0 first.
>>>
>>> Not after you have already read some data.  Readlines() reads the
>>> entire
>>> file and splits it into lines.  readline reads at least a single
>>> block.
>>>   Reading a single byte or character at a time looking for /n would
>>>   be
>>> too slow, so even after readline, the file pointer will be somewhere
>>> past the end of the last line returned.
>>>
 Instead i get the final count repeated for the number of lines.

 What i'm trying to do is lookahead:
 #!whatever

 fh = open(whatever)
 for line in fh.readlines():
  x = fh.tell()
  temp = fh.readline()
  fh.seek(x)

>>>
>>>
>>
>> I get that readlines() would slurp the whole file for efficiency
>> reasons. Why doesn't fh.seek() work though. Object 'fh' is a data
>> structure for the OS file descriptor similar to FILE in C.
>> 
>>
>  > So if seek works in C, how come it doesn't work in python wrt
>  > readlines() which is just a method. What obviates the functioning
>  > of seek wrt readlines()?
>  >
>  > fh.tell() works at the line level.. and fh.readline() works with
>  > fh.seek(0)
>  >
> 
> fh.readlines() reads the entire file.
> 
> At this point, it's at the end of the file.
> 
> The 'body' of the 'for' loop is then executed.
> 
> fh.tell() returns the the position of the end of the file because it's
> at the end of the file.
> 
> fh.readline() returns an empty string because it's at the end of the
> file.
> 
> fh.seek(x) seeks to the end of the file, which is where it already is.
> 
> Is that clearer?
Ah, right - got it - sorry for being thick. readlines() slurps the whole 
darn thing so the file pointer is at the EOF and within the loop body, 
i'm just saving that EOF position and restoring it back every time.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Still off-top] Physics [was Requests author discusses MentalHealthError exception]

[Chris Angelico]

On Sat, Mar 5, 2016 at 1:51 PM, Gregory Ewing
 wrote:
> Conservation of energy would be one reason. If you
> put two particles together and got more energy out than
> went in, where did the extra energy come from?

You borrowed it from the bank, of course. You have to make loan
payments periodically, or they'll foreclose on your particles. If
everyone borrows energy all at once, and then can't make their
payments, the universe crashes in a "heat death".

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

Re: [Still off-top] Physics [was Requests author discusses MentalHealthError exception]

[Gregory Ewing]

Oscar Benjamin wrote:

If we want to be precise then
it's pointless to even refer to the "rest mass" of something that is
never at rest.


Which just shows that the term "rest mass" is a bit silly.
It came from some confused thinking very early in the
development of relativity. The physicists soon sorted that
out, but unfortunately the textbooks didn't catch up, and
we've ended up with several generations of confused
students as a result. :-(

 The masslessness of photons comes from an extrapolation

that leads to a divide by infinity: strictly speaking it's just
undefined.


No, it's not. The total energy of a particle is given by

   E**2 == c**2 * p**2 + m**2 * c**4

where p is the particle's momentum and m is its mass.
For a photon, m == 0. No division by zero involved.

For a massive particle at rest, p == 0 and the above
reduces to the well-known

   E == m * c**2


Something I don't know is if there's some theoretical reason why the
binding energy could never exceed the sum of the energies of the
constituent particles (resulting in an overall negative mass).


Conservation of energy would be one reason. If you
put two particles together and got more energy out than
went in, where did the extra energy come from?

If you find a way to make that trick work, watch out --
the secret cartel of energy companies that's suppressing
all the free-energy inventions will want to disappear
you...

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

Re: Continuing indentation

[Tim Chase]

On 2016-03-04 17:17, sohcahto...@gmail.com wrote:
> x \
> = \
> 5
> if \
> y \
> == \
> z:
> print \
> 'this is terrible'
> print \
> 'but still not incorrect
> 
> It would be terrible, still but not incorrect.

And has the sociopathic benefit that the diffs make it quite clear
what changed.  None of this
looking-deep-into-lines-to-see-what-changed.

  x \
  = \
  5
  if \
  y \
- != \
+ == \
  z:
  print \
  'this is terrible'
  print \
  'but still not incorrect

Still terrible.  But not quite as useless as a knee-jerk reaction
might suggest.

I actually hacked together a binary-diff something like this,
emitting every hex-formatted byte of each file on its own line, then
diffing the two results.  I could see doing something similar to diff
Python ASTs.

-tkc




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

Re: Continuing indentation

[Ben Finney]

sohcahto...@gmail.com writes:

> Arguing whether or not a style guide is "incorrect" is as silly as
> arguing over whether lima beans are delicious. I think they're
> disgusting, but you can't make a statement of fact about the topic.

Yet there *are* many relevant facts that bear on the choice of one style
over another.

Objective facts about human capacity to comprehend program text.
Objective facts about the intended semantics of a syntactic structure.
Objective facts about how commonly one style is used in deployed code.

Many objective facts exist that are relevant to the choices in a style
guide. Those facts may be infeasible to *measure* with our limited
access to code bases, and limited resources available for such research.
That doesn't take away from the objective nature of what is actually
factual for a criterion.

So it isn't a pure matter of taste and preference, as some assert.

Yet, when facts are too difficult to ascertain, or when in fact several
styles are equally “good” by whatever objective criteria we might choose
— then deciding that specific matter based on some person's preference
can be quite reasonable, in pursuit of *some* single style which will
allow consistency across a code base.

> Style guides are just guides. They're a suggestion. You can agree with
> them or disagree with them.

Right. The power of such a guide comes from whether, and how, it is
enforced within a particular community.

Don't make the mistake of thinking there are *no* relevant objective
facts to discuss, though.

> I just can't understand why so many people get their panties all up in
> a bunch over how other people choose to format their code.

One factor is that we know (objectively!) that there are many relevant
objective facts to be known; paired with a paucity of actual verifiable
research into those facts available for us to apply to these discussions.

People's personal prejudices start to weigh heavily in those
circumstances.

Yet we can neither say “just do whatever you like” (because too much
inconsistency is a huge cost that is what leads us to write style guides
in the first place), nor can we say “it's all subjective, pick one and
stop arguing” (because that's just not true, there are plenty of
relevant facts that bear on the matter of choosing a style).


What we do need is the wisdom to recognise – when several styles have
good arguments supporting them and no objective facts can help decide
between them – *at what point* should we stop arguing that specific
issue, and just pick a style and stick with it.

Choosing too soon risks dismissing relevant facts that can demonstrate
one style is substantially better than the chosen style.

Choosing too late can allow a community to become weary of ever
discussing style issues again, or of arguing past the point of reason,
or of subverting cohesion by violating the style guide, or resenting it.

All of which loses the unified approach which was the whole point of
working on a style guide in the first place. Wisdom is needed to avoid
that.

I don't have a good general answer.

-- 
 \  “Faith is generally nothing more than the permission religious |
  `\ people give to one another to believe things strongly without |
_o__)  evidence.” —Sam Harris, _Letter to a Christian Nation_ 2006 |
Ben Finney

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

[issue25907] Documentation i18n: Added trans tags in sphinx templates

[Berker Peksag]

Changes by Berker Peksag :


--
resolution:  -> fixed
stage:  -> resolved

___
Python tracker 

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

Re: creating zipfile with symlinks

[Wildman via Python-list]

On Fri, 04 Mar 2016 13:31:52 -0700, Ian Kelly wrote:

> On Fri, Mar 4, 2016 at 11:50 AM, crankypuss  wrote:
>> I don't know about that, but you've certainly shown that what I was told
>> about this group being helpful and non-combative is bullshit.
> 
> Look in a mirror much?

You/We should thank $DIETY he is gone.  Take a look in
alt.os.linux or a.o.l.mint or a.o.l.ubuntu sometime.
His nym describes his personality to a tee.

-- 
 GNU/Linux user #557453
May the Source be with you.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Ethan Furman]

On 03/04/2016 05:17 PM, sohcahto...@gmail.com wrote:


I just can't understand why so many people get their panties all up in a bunch 
over how other people choose to format their code.


s/panties/undies/g

;)

--
~Ethan~

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

Re: Continuing indentation

[Erik]

Hi Ben,

On 05/03/16 01:05, Ben Finney wrote:

Certainly you are allowed. You should not expect that suggestion to be
compelling unless it is accompanied by *factual*, rather than emotive,
argument.


I thought I had done that. I pointed out that LHS (whitespace) is 
significant when it comes to code structure but RHS seems significant 
when it comes to a condition structure (according to this PEP's 
recommendation). That inconsistency was my argument in the message you 
responded to.



That may be enough to rule
out the option you are suggesting, because we're not starting from a
blank slate of no existing code.


And that's fair enough. I certainly have no desire to argue this until 
everyone agrees with me (which is what some people are accusing me of) - 
I'm just replying to those who keep saying "because PEP8".


I'm done with this thread.

BR,
E.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[sohcahtoa82]

On Friday, March 4, 2016 at 4:43:57 PM UTC-8, Simon Ward wrote:
> On 4 March 2016 23:31:43 GMT+00:00, Erik  wrote:
> >On 04/03/16 21:14, sohcahto...@gmail.com wrote:
> >> You guys are spending way too much time fighting over something that
> >is clearly subjective.  Nobody is "correct" here.  There's no right and
> >wrong, just simple preference.
> >
> >I will take that as a vote +1 that PEP8 is wrong (*). ;)
> >
> >E.
> >
> >(*) PEP8 defines a specific format and you are stating that no specific
> >
> >format can be considered correct.
> 
> Style guides are always going to be considered incorrect by some people, but 
> they should aim more for consistency (the hobgoblin that may be), which is 
> what makes code easier to grok. Stop arguing, start thinking about others who 
> will have to read your code. What is better in your subjective opinion means 
> very little. Having commonly understandable style is what matters, and what 
> style guides help (including PEP8).
> 
> Simon
> -- 
> Sent from Kaiten Mail. Please excuse my brevity.

Arguing whether or not a style guide is "incorrect" is as silly as arguing over 
whether lima beans are delicious.  I think they're disgusting, but you can't 
make a statement of fact about the topic.

Style guides are just guides.  They're a suggestion.  You can agree with them 
or disagree with them.  If I write a guide that dictates that every line of 
code should only include necessary indentation, a single token, and then a line 
continuation backslash if necessary, so code looks like this:

x \
= \
5
if \
y \
== \
z:
print \
'this is terrible'
print \
'but still not incorrect

It would be terrible, still but not incorrect.

This argument about whether binary operators should go on the end of one line 
or the beginning of the next is the C/C++/C#/Java/etc. fight about braces all 
over again.  It is entirely subjective, and I find it absolutely ridiculous 
that so many people are willing to argue until they're blue in the face about 
it.

If you're doing your own project, do it however you like it and ignore anyone 
that tells you that you're doing it "wrong".  Not formatting your code to match 
PEP 8 doesn't make your code formatted wrong, it just means you're choosing not 
to follow PEP 8 to a T.  Personally, I hate underscores in variable names that 
aren't constants.  I much prefer myVariableName over my_variable_name.  I think 
using underscores creates a sort of white space that makes it harder to read.  
Do I think that people that use underscores are wrong?  No.  They just have a 
different opinion.

I just can't understand why so many people get their panties all up in a bunch 
over how other people choose to format their code.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Ben Finney]

Erik  writes:

> On 05/03/16 00:23, Simon Ward wrote:
> > Style guides are always going to be considered incorrect by some
> > people, but they should aim more for consistency (the hobgoblin that
> > may be), which is what makes code easier to grok.
>
> So you're saying that it doesn't matter if something is good or bad,
> as long as it's consistently so?

That's not my reading of the above. “X more than Y” does not dismiss the
importance of Y.

> Am I not allowed to suggest that the style guide is wrong in what it
> suggests?

Certainly you are allowed. You should not expect that suggestion to be
compelling unless it is accompanied by *factual*, rather than emotive,
argument.

If the advantage is small, you need to accept that the small advantage
will be weighed against the high cost of a long period of inconsistency
with existing, currently-conformant, code. That may be enough to rule
out the option you are suggesting, because we're not starting from a
blank slate of no existing code.

You also need to accept that many choices in a good style guide *will*
be on the basis of choosing among many good options, and thereby exclude
a number of good options from that guide.

It doesn't make those options un-good, it just means that conforming to
the style guide excludes those options.

-- 
 \ “For a sentimentalist is simply one who desires to have the |
  `\luxury of an emotion without paying for it.” —Oscar Wilde, _De |
_o__) Profundis_, 1897 |
Ben Finney

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

Re: Continuing indentation

[Ethan Furman]

On 03/04/2016 04:30 PM, Ben Finney wrote:> sohcahto...@gmail.com writes:
>> On Friday, March 4, 2016 at 3:41:29 PM UTC-8, Ben Finney wrote:

>>> We can't put the binary operator in multiple places,
>>
>> 
>>
>> Who are you, the binary operator police?  Watch me!
>>
>> if x == y and \
>>  x == z and \
>>  a > b \
>>  or b > c \
>>  and (d is not \
>>  None \
>>  ):
>>  pass
>
> Each one of those binary operators is in exactly one place.
>
>> You're not the boss of me!
>
> Nor am I your father.

What was that disturbance?  The Force whimpering away...

--
~Ethan~


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

Re: Continuing indentation

[Erik]

On 05/03/16 00:23, Simon Ward wrote:

Style guides are always going to be considered incorrect by some
people, but they should aim more for consistency (the hobgoblin that
may be), which is what makes code easier to grok.


So you're saying that it doesn't matter if something is good or bad, as 
long as it's consistently so? I don't agree. Am I not allowed to suggest 
that the style guide is wrong in what it suggests?


FWIW, my issue here is that the language defines that the structure of 
the code is strictly defined by the indentation on the LHS (which is a 
feature I like). This PEP recommends that the structure of the condition 
should be determined by the keywords appearing on the RHS. That, to me, 
is inconsistency. I would prefer it if the PEP suggested that the LHS is 
significant in this case also.


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

[issue25702] Link Time Optimizations support for GCC and CLANG

[Gregory P. Smith]

Gregory P. Smith added the comment:

Piping up from the peanut gallery here:

If your use case is not doing release builds for production use, i.e. "casual 
use", don't bother with either PGO or LTO.  It won't matter.

Your final build that you Q ship should absolutely use those. (nobody's going 
to disagree with that :)

While I would not reject changes that allow --with-lto to work in the absence 
of PGO, but I don't think it should be anyone's priority.

--

___
Python tracker 

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

Re: Continuing indentation

[Simon Ward]

On 4 March 2016 23:31:43 GMT+00:00, Erik  wrote:
>On 04/03/16 21:14, sohcahto...@gmail.com wrote:
>> You guys are spending way too much time fighting over something that
>is clearly subjective.  Nobody is "correct" here.  There's no right and
>wrong, just simple preference.
>
>I will take that as a vote +1 that PEP8 is wrong (*). ;)
>
>E.
>
>(*) PEP8 defines a specific format and you are stating that no specific
>
>format can be considered correct.

Style guides are always going to be considered incorrect by some people, but 
they should aim more for consistency (the hobgoblin that may be), which is what 
makes code easier to grok. Stop arguing, start thinking about others who will 
have to read your code. What is better in your subjective opinion means very 
little. Having commonly understandable style is what matters, and what style 
guides help (including PEP8).

Simon
-- 
Sent from Kaiten Mail. Please excuse my brevity.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue26484] Broken table in /2.7/library/sets.html#set-objects

[Gregory P. Smith]

Gregory P. Smith added the comment:

thanks for reporting this!

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

___
Python tracker 

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

[issue26484] Broken table in /2.7/library/sets.html#set-objects

[Roundup Robot]

Roundup Robot added the comment:

New changeset f7a2f81a190c by Gregory P. Smith in branch '2.7':
issue26484 - fix the broken table in the doc about len().
https://hg.python.org/cpython/rev/f7a2f81a190c

--
nosy: +python-dev

___
Python tracker 

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

Re: Continuing indentation

[Ben Finney]

sohcahto...@gmail.com writes:

> On Friday, March 4, 2016 at 3:41:29 PM UTC-8, Ben Finney wrote:
> > We can't put the binary operator in multiple places,
>
> 
>
> Who are you, the binary operator police?  Watch me!
>
> if x == y and \
> x == z and \
> a > b \
> or b > c \
> and (d is not \
> None \
> ):
> pass

Each one of those binary operators is in exactly one place.

> You're not the boss of me!

Nor am I your father.

-- 
 \   “… correct code is great, code that crashes could use |
  `\   improvement, but incorrect code that doesn’t crash is a |
_o__)horrible nightmare.” —Chris Smith, 2008-08-22 |
Ben Finney

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

[issue25702] Link Time Optimizations support for GCC and CLANG

[INADA Naoki]

INADA Naoki added the comment:

> For sure you are not the only user that has active workloads on the physical 
> machine while you do benchmarks :)

I think largest machine type I chosen (32core) can avoid sharing physical 
machine with other users.

> On the other hand, the path you are going with just LTO is nice for 
> experiments, but for real-world usages is not feasible. Using it in 
> conjunction with PGO is the way to have the best Python interpreter, and I 
> strongly recommend for you to use the v04 versions of the patches.

I agree PGO+LTE is the best.  But I want "only LTO" because:

1) It is a pitfall that `./configure --with-lto && make` doesn't use LTO.
2) PGO makes build too slow.  For casual usecase, I can wait LTO but not PGO.

--

___
Python tracker 

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

[issue25907] Documentation i18n: Added trans tags in sphinx templates

[Julien]

Changes by Julien :


--
status: open -> closed

___
Python tracker 

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

[issue26485] Missing newline, raising a warning, in /Doc/license.rst

[Julien]

New submission from Julien:

o/

While fixing sphinx-doc warnings, I found this missing newline.

Yet the documentation is still correctly rendered.

--
assignee: docs@python
components: Documentation
files: missing_newline_in_licence.rst
messages: 261204
nosy: docs@python, sizeof
priority: normal
severity: normal
status: open
title: Missing newline, raising a warning, in /Doc/license.rst
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file42070/missing_newline_in_licence.rst

___
Python tracker 

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

[issue26446] Mention in the devguide that core dev stuff falls under the PSF CoC

[Brett Cannon]

Brett Cannon added the comment:

The PSF board passed a resolution in January 2014 that all web-related stuff 
falls under the CoC: 
https://www.python.org/psf/records/board/minutes/2014-01-06/#management-of-the-psfs-web-properties.
 I'm still pushing to get the CoC mentioned in the devguide but I've given up 
on pushing to explicitly state it for python-dev, bugs.python.org, or anywhere 
else.

--

___
Python tracker 

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

Re: Continuing indentation

[sohcahtoa82]

On Friday, March 4, 2016 at 3:41:29 PM UTC-8, Ben Finney wrote:
> alister  writes:
> 
> > On Fri, 04 Mar 2016 10:23:37 +0900, INADA Naoki wrote:
> >
> > > Because PEP8 says:
> > > 
> > >> The preferred place to break around a binary operator is after the
> > >> operator, not before it. http://pep8.org/#maximum-line-length
> >
> > and that is to make it obvious that there is more to come.
> 
> That's a good way to express it.
> 
> I think there are competing models here:
> 
> * When breaking an expression between two lines, put the binary operator
>   at the end of the earlier line.
> 
>   This makes it obvious what's going on when reading the earlier line.
> 
> * When breaking an expression between two lines, put the binary operator
>   at the beginning of the later line.
> 
>   This makes it obvious what's going on when reading the continuation
>   line.
> 
> Both have merit. Both models make an almost-identical appeal to
> readability.
> 
> We can't put the binary operator in multiple places,



Who are you, the binary operator police?  Watch me!

if x == y and \
x == z and \
a > b \
or b > c \
and (d is not \
None \
):
pass

You're not the boss of me!

And that code hurt to write...
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue26484] Broken table in /2.7/library/sets.html#set-objects

[Julien]

New submission from Julien:

Hi,

Since: 
https://github.com/python/cpython/commit/5fdcdab5794d18adc4c66abdce8639440433ed24#diff-c191394dee92fb4800d40d9a8ba431ee

the table is broken (...Doc/library/sets.rst:76: ERROR: Malformed table.

   ) so it is no longer displayed here: 
https://docs.python.org/2.7/library/sets.html#set-objects

Bests

--
assignee: docs@python
components: Documentation
messages: 261202
nosy: docs@python, gregory.p.smith, sizeof
priority: normal
severity: normal
status: open
title: Broken table in /2.7/library/sets.html#set-objects
type: enhancement
versions: Python 2.7

___
Python tracker 

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

Re: Continuing indentation

[Ethan Furman]

On 03/04/2016 03:45 PM, Mark Lawrence wrote:

> PEP8 is not a standard that must be adhered to under all
> cicumstances, it is only a style guide [...]

Not only that, it's a style guide for code /in the stdlib/.

Make your own style guide for your own projects.  ;)

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

Re: Continuing indentation

[Mark Lawrence]

On 04/03/2016 23:31, Erik wrote:

On 04/03/16 21:14, sohcahto...@gmail.com wrote:

You guys are spending way too much time fighting over something that
is clearly subjective.  Nobody is "correct" here.  There's no right
and wrong, just simple preference.


I will take that as a vote +1 that PEP8 is wrong (*). ;)

E.

(*) PEP8 defines a specific format and you are stating that no specific
format can be considered correct.



PEP8 is not a standard that must be adhered to under all cicumstances, 
it is only a style guide, hence:-



A style guide is about consistency. Consistency with this style guide is 
important. Consistency within a project is more important. Consistency 
within one module or function is the most important.


However, know when to be inconsistent -- sometimes style guide 
recommendations just aren't applicable. When in doubt, use your best 
judgment. Look at other examples and decide what looks best. And don't 
hesitate to ask!



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

Mark Lawrence

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

Re: Continuing indentation

[Ben Finney]

alister  writes:

> On Fri, 04 Mar 2016 10:23:37 +0900, INADA Naoki wrote:
>
> > Because PEP8 says:
> > 
> >> The preferred place to break around a binary operator is after the
> >> operator, not before it. http://pep8.org/#maximum-line-length
>
> and that is to make it obvious that there is more to come.

That's a good way to express it.

I think there are competing models here:

* When breaking an expression between two lines, put the binary operator
  at the end of the earlier line.

  This makes it obvious what's going on when reading the earlier line.

* When breaking an expression between two lines, put the binary operator
  at the beginning of the later line.

  This makes it obvious what's going on when reading the continuation
  line.

Both have merit. Both models make an almost-identical appeal to
readability.

We can't put the binary operator in multiple places, so have to make a
choice. And, for consistency, we are motivated to set one style and
disallow the other.

Our mistake, I think, is to draw the inference that, because one style
has been chosen, it means the excluded styles do not have merit.

That inference is IMO unfounded. It may be that there are multiple
styles which could be justifiably chosen, and no option clearly superior
to all others.

I think this case – where to put the binary operator when breaking
an expression over a line break – is one where the style guide should
not be taken as advocating on the basis of superiority, but only having
chosen one for consistency.

-- 
 \   “Working out the social politics of who you can trust and why |
  `\  is, quite literally, what a very large part of our brain has |
_o__)   evolved to do.” —Douglas Adams |
Ben Finney

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

Re: Continuing indentation

[Erik]

On 04/03/16 21:14, sohcahto...@gmail.com wrote:

You guys are spending way too much time fighting over something that is clearly 
subjective.  Nobody is "correct" here.  There's no right and wrong, just simple 
preference.


I will take that as a vote +1 that PEP8 is wrong (*). ;)

E.

(*) PEP8 defines a specific format and you are stating that no specific 
format can be considered correct.


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

Re: creating zipfile with symlinks

[Peter Otten]

Larry Martell wrote:

> On Fri, Mar 4, 2016 at 9:22 AM, Gene Heskett  wrote:
>> On Friday 04 March 2016 07:18:57 Larry Martell wrote:
>>
>>> On Thu, Mar 3, 2016 at 10:32 PM, Larry Martell
>>  wrote:
>>> > On Thu, Mar 3, 2016 at 4:58 PM, Chris Angelico 
>> wrote:
>>> >> On Fri, Mar 4, 2016 at 8:38 AM, MRAB 
>> wrote:
>>> >>> Is it even possible to zip a link?
>>> >>>
>>> >>> A quick search came up with this:
>>> >>>
>>> >>> Are hard links possible within a zip archive?
>>> >>> http://stackoverflow.com/questions/8859616/are-hard-links-possible
>>> >>>-within-a-zip-archive
>>> >>
>>> >> Hard links are different. Symlinks are files containing the target
>>> >> filename, with a special mode bit set. I'm not sure if it's a
>>> >> standard feature of all zip archivers, but on my Debian system, I
>>> >> can use "zip --symlinks" to create such a zip. How that will unzip
>>> >> on a system that doesn't understand symlinks, I don't know.
>>> >>
>>> >> rosuav@sikorsky:~/tmp$ ls -l
>>> >> total 4
>>> >> -rw-r--r-- 1 rosuav rosuav 162 Mar  4 08:48 aaa.zip
>>> >> lrwxrwxrwx 1 rosuav rosuav   4 Mar  4 08:49 qwer -> asdf
>>> >> rosuav@sikorsky:~/tmp$ unzip -l aaa.zip
>>> >> Archive:  aaa.zip
>>> >>   Length  DateTimeName
>>> >> -  -- -   
>>> >> 4  2016-03-04 08:45   qwer
>>> >> - ---
>>> >> 4 1 file
>>> >>
>>> >>
>>> >> That's a broken symlink (there is no "asdf" in the directory), and
>>> >> zip and unzip are both fine with that.
>>> >>
>>> >> Now, how the Python zipfile module handles this, I don't know. The
>>> >> ZipInfo shows a file mode of 'lrwxrwxrwx', but when I call
>>> >> extract(), it comes out as a regular file. You might have to do
>>> >> some work manually, or else just drop to an external command with
>>> >> --symlinks.
>>> >
>>> > Thanks. That's what I ended up doing.
>>>
>>> Unfortunately very slow - around 8 minutes to zip a 7GB dir using the
>>> command line zip vs. 13 seconds with the python zipfile module.
>>
>> Obviously the python version is not doing very much, or has enough python
>> magic in it to be truely called magic. In any case Larry, the operative
>> phrase for any of the various compression methods is TANSTAAFL.
>>
>> To generate a compressed archive of 7GB of data, is going to take time,
>> and I don't care what size that compressors dictionary block is. 13
>> seconds is simply not a believeable figure.
>>
>> I also note carefully that no one has allowed as to what exactly this
>> python version does do.  Thats scary...
> 
> I clearly did not have enough coffee when I wrote that (it was 7am -
> if I had written it at 7pm I would have said I clearly had had too
> much gin ;-).
> 
> Anyway, I checked again and it was 2 minutes. But still much faster
> then the command line zip.

It is still unlikely that the Python library performs that much better. If 
you have double-checked that both strategies are applied to the same set of 
files you can 

(1) verify that both scripts use the same compression algorithm
(2) run both scripts in reverse order to rule out OS-level caching.  

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

[issue24909] Windows: subprocess.Popen: race condition for leaking inheritable handles

[Jack O'Connor]

Changes by Jack O'Connor :


--
nosy: +oconnor663

___
Python tracker 

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

Re: exit from Tkinter mainloop Python 2.7

[Peter Otten]

kevind0...@gmail.com wrote:

> 
> 
> Christian & Others:
> 
> Thanks for your attention to this matter.
> My code now look like this:
> 
> from Tkinter import *
> 
> 
> def butContinue():
> dbUser = entryName.get()

Here you set the local variable dbUser (every name you rebind inside a 
function is local to that function by default)

> pWord =  entryPWord.get()
> print dbUser

and here you print it.

> print pWord
> root1.quit()
> 
> 
> dbUser = ""

Here you set the global variable dbUser

> pWord  = ""
> root1 = Tk()
> ##root1.geometry("500x250")
> 
> 
> lblTop = Label(root1, text= '  Enter Values Below', font="Helvetica
> 14").grid(row=0, column=0, columnspan=2 , pady=5)
> ##lblTop.pack(side = TOP)
> 
> lblDB = Label(root1,text= 'Weight').grid(row=1, column=0 )
> lblPWord = Label(root1, text= 'Height').grid(row=2,column=0)
> entryName = Entry(root1)
> entryName.grid(row=1, column=1, pady=5)
> 
> entryPWord = Entry(root1)
> entryPWord.grid(row=2, column=1, pady = 5)
> 
> butGo  =  Button(root1, text="   Continue "  , command=butContinue
> ).grid(row=3, column=1, sticky=W, pady=10)
> 
> 
> root1.mainloop()
> 
> print "After the MainLoop"
> print dbUser

and here you print that global variable.

> print pWord
> 
> After I type in the text Weight and Height
> No error are reported and output looks like this:
> 
> Weight
> Height
> After the MainLoop
> 
> 
> Question:
> Why did this code not cause Weight and Height to print again.
> 
> print "After the MainLoop"
> print dbUser
> print pWord
> 
> Thanks in advance.

If you want

> def butContinue():
> dbUser = entryName.get()
> pWord =  entryPWord.get()

to change the global dbUser and pWord you need to declare them as global 
explicitly:

> def butContinue():
  global dbUser, pWord
> dbUser = entryName.get()
> pWord =  entryPWord.get()


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

Re: creating zipfile with symlinks

[Larry Martell]

On Fri, Mar 4, 2016 at 9:22 AM, Gene Heskett  wrote:
> On Friday 04 March 2016 07:18:57 Larry Martell wrote:
>
>> On Thu, Mar 3, 2016 at 10:32 PM, Larry Martell
>  wrote:
>> > On Thu, Mar 3, 2016 at 4:58 PM, Chris Angelico 
> wrote:
>> >> On Fri, Mar 4, 2016 at 8:38 AM, MRAB 
> wrote:
>> >>> Is it even possible to zip a link?
>> >>>
>> >>> A quick search came up with this:
>> >>>
>> >>> Are hard links possible within a zip archive?
>> >>> http://stackoverflow.com/questions/8859616/are-hard-links-possible
>> >>>-within-a-zip-archive
>> >>
>> >> Hard links are different. Symlinks are files containing the target
>> >> filename, with a special mode bit set. I'm not sure if it's a
>> >> standard feature of all zip archivers, but on my Debian system, I
>> >> can use "zip --symlinks" to create such a zip. How that will unzip
>> >> on a system that doesn't understand symlinks, I don't know.
>> >>
>> >> rosuav@sikorsky:~/tmp$ ls -l
>> >> total 4
>> >> -rw-r--r-- 1 rosuav rosuav 162 Mar  4 08:48 aaa.zip
>> >> lrwxrwxrwx 1 rosuav rosuav   4 Mar  4 08:49 qwer -> asdf
>> >> rosuav@sikorsky:~/tmp$ unzip -l aaa.zip
>> >> Archive:  aaa.zip
>> >>   Length  DateTimeName
>> >> -  -- -   
>> >> 4  2016-03-04 08:45   qwer
>> >> - ---
>> >> 4 1 file
>> >>
>> >>
>> >> That's a broken symlink (there is no "asdf" in the directory), and
>> >> zip and unzip are both fine with that.
>> >>
>> >> Now, how the Python zipfile module handles this, I don't know. The
>> >> ZipInfo shows a file mode of 'lrwxrwxrwx', but when I call
>> >> extract(), it comes out as a regular file. You might have to do
>> >> some work manually, or else just drop to an external command with
>> >> --symlinks.
>> >
>> > Thanks. That's what I ended up doing.
>>
>> Unfortunately very slow - around 8 minutes to zip a 7GB dir using the
>> command line zip vs. 13 seconds with the python zipfile module.
>
> Obviously the python version is not doing very much, or has enough python
> magic in it to be truely called magic. In any case Larry, the operative
> phrase for any of the various compression methods is TANSTAAFL.
>
> To generate a compressed archive of 7GB of data, is going to take time,
> and I don't care what size that compressors dictionary block is. 13
> seconds is simply not a believeable figure.
>
> I also note carefully that no one has allowed as to what exactly this
> python version does do.  Thats scary...

I clearly did not have enough coffee when I wrote that (it was 7am -
if I had written it at 7pm I would have said I clearly had had too
much gin ;-).

Anyway, I checked again and it was 2 minutes. But still much faster
then the command line zip.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue25973] Segmentation fault with nonlocal and two underscores

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Only security fixes are accepted for 3.4.

--

___
Python tracker 

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

Re: exit from Tkinter mainloop Python 2.7

[kevind0718]

Christian & Others:

Thanks for your attention to this matter.
My code now look like this:

from Tkinter import *


def butContinue():
dbUser = entryName.get()
pWord =  entryPWord.get()
print dbUser
print pWord
root1.quit()


dbUser = ""
pWord  = ""
root1 = Tk()
##root1.geometry("500x250")


lblTop = Label(root1, text= '  Enter Values Below', font="Helvetica 
14").grid(row=0, column=0, columnspan=2 , pady=5)
##lblTop.pack(side = TOP)

lblDB = Label(root1,text= 'Weight').grid(row=1, column=0 )
lblPWord = Label(root1, text= 'Height').grid(row=2,column=0)
entryName = Entry(root1)
entryName.grid(row=1, column=1, pady=5)

entryPWord = Entry(root1)
entryPWord.grid(row=2, column=1, pady = 5)

butGo  =  Button(root1, text="   Continue "  , command=butContinue 
).grid(row=3, column=1, sticky=W, pady=10)


root1.mainloop()

print "After the MainLoop"
print dbUser
print pWord

After I type in the text Weight and Height
No error are reported and output looks like this:

Weight
Height
After the MainLoop


Question:  
Why did this code not cause Weight and Height to print again.

print "After the MainLoop"
print dbUser
print pWord

Thanks in advance.


KBD


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

[issue25973] Segmentation fault with nonlocal and two underscores

[Antti Haapala]

Antti Haapala added the comment:

So no fix for 3.4 for an obvious SIGSEGV?

% python3  
Python 3.4.3 (default, Mar 26 2015, 22:03:40) 
[GCC 4.9.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> class A:
... def f(self):
... nonlocal __x
... 
[4]19173 segmentation fault (core dumped)  python3

--
nosy: +ztane

___
Python tracker 

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

Re: Continuing indentation

[Mark Lawrence]

On 04/03/2016 21:14, sohcahto...@gmail.com wrote:

On Friday, March 4, 2016 at 6:03:48 AM UTC-8, alister wrote:

On Fri, 04 Mar 2016 10:12:58 +, cl wrote:


Steven D'Aprano  wrote:

On Fri, 4 Mar 2016 12:23 pm, INADA Naoki wrote:




Indeed. I don't understand why, when splitting a condition such as
this,
people tend to put the operator at the end of each line.



Because PEP8 says:


The preferred place to break around a binary operator is after the

operator, not before it. http://pep8.org/#maximum-line-length


PEP 8 is wrong :-)


Yes, I agree.  In my mind the logic is:-

 IF xxx
 AND yyy AND zzz OR aaa
 THEN do something

The PEP8 correct(er):-

 IF xxx AND
  yyy AND zzz OR aaa
 THEN do something

... just seems all wrong and difficult to understand.


not at all
the split after the operator shows that their is more to that line
splitting before & the reader could believe that the condition ends there

PEP 8 is mos definitely correct on this one



--
According to all the latest reports, there was no truth in any of the
earlier reports.


I wouldn't call PEP 8 "correct".  I would say that you just simply agree with 
PEP 8's suggestion.

You guys are spending way too much time fighting over something that is clearly 
subjective.  Nobody is "correct" here.  There's no right and wrong, just simple 
preference.



+1

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

Mark Lawrence

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

Re: Help

[Mark Lawrence]

On 04/03/2016 21:06, Tom P wrote:

On 02/29/2016 01:53 PM, tomwilliamson...@gmail.com wrote:

Thanks. If a word appears more than once how would I bring back both
locations?



for i, str in enumerate(l): . . . .


When replying would everybody please quote some context.  All of the 
above is completely meaningless, standing all alone.


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

Mark Lawrence

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

Re: Continuing indentation

[sohcahtoa82]

On Friday, March 4, 2016 at 6:03:48 AM UTC-8, alister wrote:
> On Fri, 04 Mar 2016 10:12:58 +, cl wrote:
> 
> > Steven D'Aprano  wrote:
> >> On Fri, 4 Mar 2016 12:23 pm, INADA Naoki wrote:
> >> 
> >> 
> >> >>
> >> >> Indeed. I don't understand why, when splitting a condition such as
> >> >> this,
> >> >> people tend to put the operator at the end of each line.
> >> >>
> >> >>
> >> > Because PEP8 says:
> >> > 
> >> >> The preferred place to break around a binary operator is after the
> >> > operator, not before it. http://pep8.org/#maximum-line-length
> >> 
> >> PEP 8 is wrong :-)
> >> 
> > Yes, I agree.  In my mind the logic is:-
> > 
> > IF xxx
> > AND yyy AND zzz OR aaa
> > THEN do something
> > 
> > The PEP8 correct(er):-
> > 
> > IF xxx AND
> >  yyy AND zzz OR aaa
> > THEN do something
> > 
> > ... just seems all wrong and difficult to understand.
> 
> not at all
> the split after the operator shows that their is more to that line
> splitting before & the reader could believe that the condition ends there
> 
> PEP 8 is mos definitely correct on this one
> 
> 
> 
> -- 
> According to all the latest reports, there was no truth in any of the
> earlier reports.

I wouldn't call PEP 8 "correct".  I would say that you just simply agree with 
PEP 8's suggestion.

You guys are spending way too much time fighting over something that is clearly 
subjective.  Nobody is "correct" here.  There's no right and wrong, just simple 
preference.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Help

[Tom P]

On 02/29/2016 01:53 PM, tomwilliamson...@gmail.com wrote:

Thanks. If a word appears more than once how would I bring back both locations?



for i, str in enumerate(l): . . . .
--
https://mail.python.org/mailman/listinfo/python-list

[issue26483] docs unclear on difference between str.isdigit() and str.isdecimal()

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Yes. For details you need to read The Unicode Standard.

And every decimal character is accepted by the int() constructor, but 
non-decimal digits are not.

>>> for d in decimals: x = int(d)
... 
>>> for d in set(digits) - set(decimals):
... try:
... int(d)
... except ValueError:
... pass
... else:
... raise AssertionError
...

--

___
Python tracker 

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

[issue26483] docs unclear on difference between str.isdigit() and str.isdecimal()

[Ethan Furman]

Ethan Furman added the comment:

I like those code snippets!  Thanks, Serhiy!

Just to make sure I have understood correctly:  every decimal char is also a 
digit char, but some digit chars are not decimal chars.

--

___
Python tracker 

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

Re: creating zipfile with symlinks

[Ian Kelly]

On Fri, Mar 4, 2016 at 11:50 AM, crankypuss  wrote:
> I don't know about that, but you've certainly shown that what I was told
> about this group being helpful and non-combative is bullshit.

Look in a mirror much?
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue26483] docs unclear on difference between str.isdigit() and str.isdecimal()

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

>>> chars = ''.join(map(chr, range(sys.maxunicode+1)))
>>> digits = ''.join(filter(str.isdigit, chars))
>>> digits
'0123456789²³¹٠١٢٣٤٥٦٧٨٩۰۱۲۳۴۵۶۷۸۹߀߁߂߃߄߅߆߇߈߉०१२३४५६७८९০১২৩৪৫৬৭৮৯੦੧੨੩੪੫੬੭੮੯૦૧૨૩૪૫૬૭૮૯୦୧୨୩୪୫୬୭୮୯௦௧௨௩௪௫௬௭௮௯౦౧౨౩౪౫౬౭౮౯೦೧೨೩೪೫೬೭೮೯൦൧൨൩൪൫൬൭൮൯෦෧෨෩෪෫෬෭෮෯๐๑๒๓๔๕๖๗๘๙໐໑໒໓໔໕໖໗໘໙༠༡༢༣༤༥༦༧༨༩၀၁၂၃၄၅၆၇၈၉႐႑႒႓႔႕႖႗႘႙፩፪፫፬፭፮፯፰፱០១២៣៤៥៦៧៨៩᠐᠑᠒᠓᠔᠕᠖᠗᠘᠙᥆᥇᥈᥉᥊᥋᥌᥍᥎᥏᧐᧑᧒᧓᧔᧕᧖᧗᧘᧙᧚᪀᪁᪂᪃᪄᪅᪆᪇᪈᪉᪐᪑᪒᪓᪔᪕᪖᪗᪘᪙᭐᭑᭒᭓᭔᭕᭖᭗᭘᭙᮰᮱᮲᮳᮴᮵᮶᮷᮸᮹᱀᱁᱂᱃᱄᱅᱆᱇᱈᱉᱐᱑᱒᱓᱔᱕᱖᱗᱘᱙⁰⁴⁵⁶⁷⁸⁹₀₁₂₃₄₅₆₇₈₉①②③④⑤⑥⑦⑧⑨⑴⑵⑶⑷⑸⑹⑺⑻⑼⒈⒉⒊⒋⒌⒍⒎⒏⒐⓪⓵⓶⓷⓸⓹⓺⓻⓼⓽⓿❶❷❸❹❺❻❼❽❾➀➁➂➃➄➅➆➇➈➊➋➌➍➎➏➐➑➒꘠꘡꘢꘣꘤꘥꘦꘧꘨꘩꣐꣑꣒꣓꣔꣕꣖꣗꣘꣙꤀꤁꤂꤃꤄꤅꤆꤇꤈꤉꧐꧑꧒꧓꧔꧕꧖꧗꧘꧙꧰꧱꧲꧳꧴꧵꧶꧷꧸꧹꩐꩑꩒꩓꩔꩕꩖꩗꩘꩙꯰꯱꯲꯳꯴꯵꯶꯷꯸꯹０１２３４５６７８９ҠҡҢңҤҥҦҧҨҩੀੁੂ੃๠๡๢๣๤๥๦๧๨ၒၓၔၕၖၗၘၙၚၦၧၨၩၪၫၬၭၮၯჰჱჲჳჴჵჶჷჸჹᄶᄷᄸᄹᄺᄻᄼᄽᄾᄿᇐᇑᇒᇓᇔᇕᇖᇗᇘᇙደዱዲዳዴድዶዷዸዹᓐᓑᓒᓓᓔᓕᓖᓗᓘᓙᙐᙑᙒᙓᙔᙕᙖᙗᙘᙙᛀᛁᛂᛃᛄᛅᛆᛇᛈᛉᜰᜱᜲᜳ᜴᜵᜶᜷᜸᜹ᣠᣡᣢᣣᣤᣥᣦᣧᣨᣩ橠橡橢橣橤橥橦橧橨橩歐歑歒歓歔歕歖歗歘歙ퟎퟏퟐퟑퟒퟓퟔퟕퟖퟗퟘퟙퟚퟛퟜퟝퟞퟟퟠퟡퟢퟣퟤퟥퟦퟧퟨퟩퟪퟫퟬퟭퟮퟯퟰퟱퟲퟳퟴퟵퟶퟷퟸퟹퟺퟻ퟼퟽퟾퟿'
>>> decimals = ''.join(filter(str.isdecimal, chars))
>>> decimals
'0123456789٠١٢٣٤٥٦٧٨٩۰۱۲۳۴۵۶۷۸۹߀߁߂߃߄߅߆߇߈߉०१२३४५६७८९০১২৩৪৫৬৭৮৯੦੧੨੩੪੫੬੭੮੯૦૧૨૩૪૫૬૭૮૯୦୧୨୩୪୫୬୭୮୯௦௧௨௩௪௫௬௭௮௯౦౧౨౩౪౫౬౭౮౯೦೧೨೩೪೫೬೭೮೯൦൧൨൩൪൫൬൭൮൯෦෧෨෩෪෫෬෭෮෯๐๑๒๓๔๕๖๗๘๙໐໑໒໓໔໕໖໗໘໙༠༡༢༣༤༥༦༧༨༩၀၁၂၃၄၅၆၇၈၉႐႑႒႓႔႕႖႗႘႙០១២៣៤៥៦៧៨៩᠐᠑᠒᠓᠔᠕᠖᠗᠘᠙᥆᥇᥈᥉᥊᥋᥌᥍᥎᥏᧐᧑᧒᧓᧔᧕᧖᧗᧘᧙᪀᪁᪂᪃᪄᪅᪆᪇᪈᪉᪐᪑᪒᪓᪔᪕᪖᪗᪘᪙᭐᭑᭒᭓᭔᭕᭖᭗᭘᭙᮰᮱᮲᮳᮴᮵᮶᮷᮸᮹᱀᱁᱂᱃᱄᱅᱆᱇᱈᱉᱐᱑᱒᱓᱔᱕᱖᱗᱘᱙꘠꘡꘢꘣꘤꘥꘦꘧꘨꘩꣐꣑꣒꣓꣔꣕꣖꣗꣘꣙꤀꤁꤂꤃꤄꤅꤆꤇꤈꤉꧐꧑꧒꧓꧔꧕꧖꧗꧘꧙꧰꧱꧲꧳꧴꧵꧶꧷꧸꧹꩐꩑꩒꩓꩔꩕꩖꩗꩘꩙꯰꯱꯲꯳꯴꯵꯶꯷꯸꯹０１２３４５６７８９ҠҡҢңҤҥҦҧҨҩၦၧၨၩၪၫၬၭၮၯჰჱჲჳჴჵჶჷჸჹᄶᄷᄸᄹᄺᄻᄼᄽᄾᄿᇐᇑᇒᇓᇔᇕᇖᇗᇘᇙደዱዲዳዴድዶዷዸዹᓐᓑᓒᓓᓔᓕᓖᓗᓘᓙᙐᙑᙒᙓᙔᙕᙖᙗᙘᙙᛀᛁᛂᛃᛄᛅᛆᛇᛈᛉᜰᜱᜲᜳ᜴᜵᜶᜷᜸᜹ᣠᣡᣢᣣᣤᣥᣦᣧᣨᣩ橠橡橢橣橤橥橦橧橨橩歐歑歒歓歔歕歖歗歘歙ퟎퟏퟐퟑퟒퟓퟔퟕퟖퟗퟘퟙퟚퟛퟜퟝퟞퟟퟠퟡퟢퟣퟤퟥퟦퟧퟨퟩퟪퟫퟬퟭퟮퟯퟰퟱퟲퟳퟴퟵퟶퟷퟸퟹퟺퟻ퟼퟽퟾퟿'
>>> ''.join(sorted(set(decimals) - set(digits)))
''
>>> ''.join(sorted(set(digits) - set(decimals)))
'²³¹፩፪፫፬፭፮፯፰፱᧚⁰⁴⁵⁶⁷⁸⁹₀₁₂₃₄₅₆₇₈₉①②③④⑤⑥⑦⑧⑨⑴⑵⑶⑷⑸⑹⑺⑻⑼⒈⒉⒊⒋⒌⒍⒎⒏⒐⓪⓵⓶⓷⓸⓹⓺⓻⓼⓽⓿❶❷❸❹❺❻❼❽❾➀➁➂➃➄➅➆➇➈➊➋➌➍➎➏➐➑➒ੀੁੂ੃๠๡๢๣๤๥๦๧๨ၒၓၔၕၖၗၘၙၚ'

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue26483] docs unclear on difference between str.isdigit() and str.isdecimal()

[Ezio Melotti]

Changes by Ezio Melotti :


--
assignee:  -> docs@python
components: +Documentation, Unicode
nosy: +docs@python, ezio.melotti, haypo
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.6

___
Python tracker 

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

[issue26483] docs unclear on difference between str.isdigit() and str.isdecimal()

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
title: docs unclear on difference between isdigt() and isdecimal() -> docs 
unclear on difference between str.isdigit() and str.isdecimal()

___
Python tracker 

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

[issue26459] Windows build instructions are very inaccurate

[Terry J. Reedy]

Terry J. Reedy added the comment:

I built 2.7.11 on Win10 last Jan 16 with MCS v.1500 32 bit.  I believe that is 
VS2008.  Besides TortoiseHG, which I think is great, I downloaded SlikSVN 
minimal client only.  I somewhat arbitrarily picked it from some svn list.  
http://www.sliksvn.com/en/download.  A suggestion, with note that minimal 
client is enough, would not help.  Tested install with 'svn help'. With that 
installed, pcbuild + appropriate args downloads all external dependencies 
needed.  F7 in VS GUI builds Python binary, no Perl needed.  The docs, 
including readme.TXT, are much better than 3 or 4 years ago.  (At the time, 
there was an undocumented requirement, to run tkinter, to move/copy some tcl/tk 
files.  Zack fixed the build script to make manual step unneeded.)  Obviously 
still needs improvement.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue26483] docs unclear on difference between isdigt() and isdecimal()

[Ethan Furman]

New submission from Ethan Furman:

The docs use different explanations for what constitutes a decimal verses a 
digit character; consequently I can't tell if they are the same or different, 
and if different what the differences are.

---

https://docs.python.org/3/library/stdtypes.html?#str.isdecimal

Return true if all characters in the string are decimal characters and there is 
at least one character, false otherwise. Decimal characters are those from 
general category “Nd”. This category includes digit characters, and all 
characters that can be used to form decimal-radix numbers, e.g. U+0660, 
ARABIC-INDIC DIGIT ZERO.

---

https://docs.python.org/3/library/stdtypes.html?#str.isdigit

Return true if all characters in the string are digits and there is at least 
one character, false otherwise. Digits include decimal characters and digits 
that need special handling, such as the compatibility superscript digits. 
Formally, a digit is a character that has the property value Numeric_Type=Digit 
or Numeric_Type=Decimal.

--
messages: 261195
nosy: ethan.furman
priority: normal
severity: normal
status: open
title: docs unclear on difference between isdigt() and isdecimal()
versions: Python 3.4, Python 3.5

___
Python tracker 

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

Re: [Still off-top] Physics [was Requests author discusses MentalHealthError exception]

[André Roberge]

This discussion about energy and masses of particles has nothing to do with 
Python, and I am hoping that it will be dropped.  That being said, I feel 
compelled to correct what are completely wrong statements.

On Friday, 4 March 2016 13:36:11 UTC-4, Oscar Benjamin  wrote:
> On 4 March 2016 at 10:38, Marko Rauhamaa  wrote:
> > Oscar Benjamin :
> >
...
> 
> That's just a casual use of terminology. If we want to be precise then
> it's pointless to even refer to the "rest mass" of something that is
> never at rest. The masslessness of photons comes from an extrapolation
> that leads to a divide by infinity: strictly speaking it's just
> undefined.

This is simply wrong.  In Quantum Field Theory, particles can have "bare" mass 
term included in the Lagrangian and the measured mass either includes the bare 
mass + quantum corrections OR is a purely dynamically generated term.

In the Standard Model, there is no bare mass term for the photon, nor is there 
any dynamically generated mass.  In fact, to preserve gauge invariance 
symmetry, the mass of the photon MUST be identically equal to zero.

(Of course, the Standard Model could be incorrect but all meausurements done so 
far are completely consistent with a massless photon; see 
http://pdg.lbl.gov/2015/listings/rpp2015-list-photon.pdf for current 
experimental limits.)


> 
> > As for the existence of a negative mass, it is interesting to note that
> > the (rest) mass of an alpha particle is less than the sum of the (rest)
> > masses of its constituents. About 1% of the mass is "missing."
> 
> Since the binding is associated with negative energy it has a negative
> contribution to the energy/mass of the particle as a whole. This is
> true of any bound state.
> 
> Something I don't know is if there's some theoretical reason why the
> binding energy could never exceed the sum of the energies of the
> constituent particles (resulting in an overall negative mass).

The (magnitude of the) binding energy is DEFINED as the difference between the 
(energy equivalent) sums of the individual masses of the consistuents and that 
of the bound state.

===
Now, could we forget about Physics and go back to discussions related to Python?

André Roberge


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

Re: ANN: Wing IDE 5.1.10 released

[Mario R. Osorio]

On Friday, February 26, 2016 at 9:57:21 AM UTC-5, Wingware wrote:
> Hi,
> 
> Wingware has released version 5.1.10 of Wing IDE, our cross-platform 
> integrated development environment for the Python programming language.
> 
> Wing IDE features a professional code editor with vi, emacs, visual 
> studio, and other key bindings, auto-completion, call tips, 
> context-sensitive auto-editing, goto-definition, find uses, refactoring, 
> a powerful debugger, version control, unit testing, search, project 
> management, and many other features.
> 
> This release includes the following minor improvements:
> 
>  Fix issues with Django app creation
>  French localization updates (thanks to Jean Sanchez)
>  Improve analysis cache performance
>  Don't specify Qt dependencies in Debian packages
>  Fix occasional hangs when debugging multi-threaded code
>  Fix display of decimal instances in stack data
>  Don't hide the auto-completer when a debug process exits or on 
> other events that cause update of menus and toolbars
>  Don't show duplicate entries for the same file in Compare to Repository
>  Fix crash triggered by some mako files
>  Fix problem with inspection of bound methods in Python 3
>  12 other bug fixes
> 
> For details see http://wingware.com/news/2016-02-25 and 
> http://wingware.com/pub/wingide/5.1.10/CHANGELOG.txt
> 
> What's New in Wing 5.1:
> 
> Wing IDE 5.1 adds multi-process and child process debugging, syntax 
> highlighting in the shells, support for pytest, Find Symbol in Project, 
> persistent time-stamped unit test results, auto-conversion of indents on 
> paste, an XCode keyboard personality, support for Flask, Django 1.7, 
> 1.8, and 1.9, Python 3.5 and recent Google App Engine versions, improved 
> auto-completion for PyQt, recursive snippet invocation, and many other 
> minor features and improvements.
> 
> Free trial: http://wingware.com/wingide/trial
> Downloads: http://wingware.com/downloads
> Feature list: http://wingware.com/wingide/features
> Sales: http://wingware.com/store/purchase
> Upgrades: https://wingware.com/store/upgrade
> 
> Questions?  Don't hesitate to email us at supp...@wingware.com.
> 
> Thanks,
> 
> -- 
> 
> Stephan Deibel
> Wingware | Python IDE
> 
> The Intelligent Development Environment for Python Programmers
> 
> wingware.com

You seem to be offering a great product; I've read quite a few very nice 
reviews; but your messages area misleading; you should label them as 
ADVERTISEMENT
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: creating zipfile with symlinks

[crankypuss]

Grant Edwards wrote:

> On 2016-03-04, crankypuss  wrote:
>> Larry Martell wrote:
> [...]
>>> Which I don't love as a solution. Anyone know a cleaner way to get
>>> zipfile to zip the links?
>>
>> I don't even know what "zipfile" is, is that a Windows command?
> 
> It's a module in the Python standard library.  You see, this is a
> Python newsgroup/mailing-list.
> 
> Or you could just google "zipfile".  It's the first flippin' link.
> 
> [I've been trolled, right?]

I don't know about that, but you've certainly shown that what I was told 
about this group being helpful and non-combative is bullshit.

Okay, I've looked into Python, best luck all.

-- 
http://totally-portable-software.blogspot.com
  [Mon Feb 29: "Addresses - What Good Are They?"]

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

Re: The Real-Time Use of Python in Data Science World!

[Mario R. Osorio]

On Friday, February 26, 2016 at 2:36:26 PM UTC-5, Anita Goyal wrote:
> This course will help you to expertise the usage of Python in Data Science 
> world.
> 
> Carter your Python Knowledge so that it can be utilized to get the Insights 
> of Data using Methodologies and Techniques of Data Science...
> 
> Objective:
> Understand the concepts of Data science and Python
> You will be able to use Python in Discovering Data.
> You will have an idea of Statistical and Analytical methods to deal with huge 
> data sets.
> You will gain an expertise on Regular Expressions, looping functions and 
> concepts of Object Oriented Programming.
> You will be able to create business algorithms and data models using Python 
> and it's techniques.
> Work on Real-life Projects will help you to get a practical experience of 
> real scenarios of IT Industry.
> 
> Start learning Python for Data Science from basics to advance levels here...
> https://goo.gl/070wXw

Grey area, very dark grey area, just like the guys from wing ide, their last 
posting is "ANN: Wing IDE 5.1.10 released"; they should also label it as 
advertisement
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue26482] Restore pickling recursive dequeues

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

Pickling recursive dequeues was added in issue1062279. But then it was reverted 
in 73f49656420b (unknown issue number).

Proposed patch restores pickling recursive dequeues.

--
assignee: rhettinger
components: Library (Lib)
files: pickle_recursive_deque.patch
keywords: patch
messages: 261194
nosy: alexandre.vassalotti, pitrou, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Restore pickling recursive dequeues
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42069/pickle_recursive_deque.patch

___
Python tracker 

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

Re: Lookahead while doing: for line in fh.readlines():

[MRAB]

On 2016-03-04 13:04, Veek. M wrote:

Terry Reedy wrote:


On 2/27/2016 4:39 AM, Veek. M wrote:

I want to do something like:

#!/usr/bin/env python3

fh = open('/etc/motd')
for line in fh.readlines():
 print(fh.tell())

why doesn't this work as expected.. fh.readlines() should return a
generator object and fh.tell() ought to start at 0 first.


Not after you have already read some data.  Readlines() reads the
entire
file and splits it into lines.  readline reads at least a single
block.
  Reading a single byte or character at a time looking for /n would be
too slow, so even after readline, the file pointer will be somewhere
past the end of the last line returned.


Instead i get the final count repeated for the number of lines.

What i'm trying to do is lookahead:
#!whatever

fh = open(whatever)
for line in fh.readlines():
 x = fh.tell()
 temp = fh.readline()
 fh.seek(x)






I get that readlines() would slurp the whole file for efficiency
reasons. Why doesn't fh.seek() work though. Object 'fh' is a data
structure for the OS file descriptor similar to FILE in C.



> So if seek works in C, how come it doesn't work in python wrt
> readlines() which is just a method. What obviates the functioning of
> seek wrt readlines()?
>
> fh.tell() works at the line level.. and fh.readline() works with
> fh.seek(0)
>

fh.readlines() reads the entire file.

At this point, it's at the end of the file.

The 'body' of the 'for' loop is then executed.

fh.tell() returns the the position of the end of the file because it's 
at the end of the file.


fh.readline() returns an empty string because it's at the end of the file.

fh.seek(x) seeks to the end of the file, which is where it already is.

Is that clearer?

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

[issue26478] dict views don't implement subtraction correctly

[wim glenn]

wim glenn added the comment:

Well that was patched quickly, impressive turnaround on this

--
nosy: +wim.glenn

___
Python tracker 

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

Re: Continuing indentation

[Ethan Furman]

On 03/04/2016 07:25 AM, Ian Kelly wrote:

On Fri, Mar 4, 2016 at 7:03 AM, alister  wrote:

On Fri, 04 Mar 2016 10:12:58 +, cl wrote:


Steven D'Aprano  wrote:

On Fri, 4 Mar 2016 12:23 pm, INADA Naoki wrote:




Indeed. I don't understand why, when splitting a condition such as
this,
people tend to put the operator at the end of each line.



Because PEP8 says:


The preferred place to break around a binary operator is after the

operator, not before it. http://pep8.org/#maximum-line-length


PEP 8 is wrong :-)


Yes, I agree.  In my mind the logic is:-

 IF xxx
 AND yyy AND zzz OR aaa
 THEN do something

The PEP8 correct(er):-

 IF xxx AND
  yyy AND zzz OR aaa
 THEN do something

... just seems all wrong and difficult to understand.


not at all
the split after the operator shows that their is more to that line
splitting before & the reader could believe that the condition ends there

PEP 8 is mos definitely correct on this one


I disagree. When I'm skimming over code, I find it unlikely that I'll
read the last token of the line. That's where trivialities like
arguments to function calls are found. It's much more likely that I'll
read the first token of the next line.


And, as any pythonista knows: The conditions aren't over until the 
indentation changes.  ;)


--
~Ethan~

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

Re: [Still off-top] Physics [was Requests author discusses MentalHealthError exception]

[Oscar Benjamin]

On 4 March 2016 at 10:38, Marko Rauhamaa  wrote:
> Oscar Benjamin :
>
>> The mass is carried by the new particles. The new particles may have a
>> total *rest mass* which differs from the total rest mass of the
>> previous particles. However the total mass is the rest mass plus the
>> mass associated with the "kinetic energy" of the particles.
>>
>> [...]
>>
>> Mass and energy are not interchangeable in the sense that you can
>> exchange one for the other with e=mc^2 giving the exchange rate.
>> Rather mass and energy are *the same thing*. Although they are
>> different concepts defined in different ways and having different
>> dimensions and units they are inseparable: e=mc^2 gives us the
>> proportion in which the two appear together.
>
> A physicist mentioned to me that the word "mass" has replaced the term
> "rest mass" in modern Physics lingo.

It depends on the context. Rest mass or similar can still be used
where you want to stress the difference (as I was doing).

> That's why you say a photon is
> "massless" even though every observable photon has a relativistic mass.
> It's all in the terminology.

That's just a casual use of terminology. If we want to be precise then
it's pointless to even refer to the "rest mass" of something that is
never at rest. The masslessness of photons comes from an extrapolation
that leads to a divide by infinity: strictly speaking it's just
undefined.

> As for the existence of a negative mass, it is interesting to note that
> the (rest) mass of an alpha particle is less than the sum of the (rest)
> masses of its constituents. About 1% of the mass is "missing."

Since the binding is associated with negative energy it has a negative
contribution to the energy/mass of the particle as a whole. This is
true of any bound state.

Something I don't know is if there's some theoretical reason why the
binding energy could never exceed the sum of the energies of the
constituent particles (resulting in an overall negative mass).

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

[issue26481] unittest discovery process not working without .py source files

[Stefan Seefeld]

New submission from Stefan Seefeld:

The unittest test discovery right now only looks into sub-packages if they 
contain a `__init__.py` file. That's an unnecessary requirement, as packages 
are also importable if only `__init__.pyc` is present.

--
components: Library (Lib)
messages: 261192
nosy: stefan
priority: normal
severity: normal
status: open
title: unittest discovery process not working without .py source files

___
Python tracker 

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

[issue26480] add a flag that will not give the set a sys.stdin

[Brett Cannon]

Changes by Brett Cannon :


--
type: behavior -> enhancement

___
Python tracker 

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

[issue26480] add a flag that will not give the set a sys.stdin

[yuriy_levchenko]

Changes by yuriy_levchenko :


--
type:  -> behavior

___
Python tracker 

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

[issue26480] add a flag that will not give the set a sys.stdin

[yuriy_levchenko]

New submission from yuriy_levchenko:

i have Fatal Error 

"Py_Initialize: can't initialize sys standard streams"

because fail to create

fd = fileno(stdin);

std = create_stdio(iomod, fd, 0, "", encoding, errors);

I do not need to create this input|output

if i comment this code, and setup 

__stdin__= None
__stdout__= None
__stderr__= None

all workin fine

--
messages: 261191
nosy: yuriy_levchenko
priority: normal
severity: normal
status: open
title: add a flag that will not give the set a sys.stdin
versions: Python 3.5

___
Python tracker 

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

Re: looking into python...

[Terry Reedy]

On 3/3/2016 8:39 AM, Steven D'Aprano wrote:


I don't think there has ever been a version of Python that ran on DOS :-)


Yep.  That is what I started with (1.3).  It ran fine with 2 megabytes 
of memory and a 10 or 20 MB disk.  No unicode module, database, or 
codecs.  Perhaps no tcl/tk/tkinter.  I don't remember when DOS was 
dropped.  Maybe a decade ago or so.


--
Terry Jan Reedy

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

[issue25702] Link Time Optimizations support for GCC and CLANG

[Alecsandru Patrascu]

Alecsandru Patrascu added the comment:

You are doing measurements on a virtual machine... For sure you are not the 
only user that has active workloads on the physical machine while you do 
benchmarks :)

On the other hand, the path you are going with just LTO is nice for 
experiments, but for real-world usages is not feasible. Using it in conjunction 
with PGO is the way to have the best Python interpreter, and I strongly 
recommend for you to use the v04 versions of the patches.

--

___
Python tracker 

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

Re: creating zipfile with symlinks

[Grant Edwards]

On 2016-03-04, crankypuss  wrote:
> Larry Martell wrote:
[...]
>> Which I don't love as a solution. Anyone know a cleaner way to get
>> zipfile to zip the links?
>
> I don't even know what "zipfile" is, is that a Windows command? 

It's a module in the Python standard library.  You see, this is a
Python newsgroup/mailing-list.

Or you could just google "zipfile".  It's the first flippin' link.

[I've been trolled, right?]

-- 
Grant Edwards   grant.b.edwardsYow! Everybody gets free
  at   BORSCHT!
  gmail.com
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue25702] Link Time Optimizations support for GCC and CLANG

[INADA Naoki]

INADA Naoki added the comment:

The machine is Google Compute Engine n1-highcpu-32 (Intel Ivy Bridge)

Linux bench 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17) 
x86_64 GNU/Linux

cpuinfo:
processor   : 31
vendor_id   : GenuineIntel
cpu family  : 6
model   : 62
model name  : Intel(R) Xeon(R) CPU @ 2.50GHz
stepping: 4
microcode   : 0x1
cpu MHz : 2500.000
cache size  : 30720 KB


command:
$ python perf.py -r -b default ../Python-3.5.1/python-default 
../Python-3.5.1/python-lto

output:
Report on Linux bench 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3 
(2016-01-17) x86_64 
Total CPU cores: 32

### 2to3 ###
Min: 8.692000 -> 8.16: 1.07x faster
Avg: 8.816800 -> 8.253600: 1.07x faster
Significant (t=8.07)
Stddev: 0.12726 -> 0.09027: 1.4098x smaller

### chameleon_v2 ###
Min: 6.756928 -> 6.414046: 1.05x faster
Avg: 6.849192 -> 6.666536: 1.03x faster
Significant (t=20.88)
Stddev: 0.04413 -> 0.07555: 1.7120x larger

### fastpickle ###
Min: 0.540906 -> 0.564253: 1.04x slower
Avg: 0.549624 -> 0.579263: 1.05x slower
Significant (t=-34.29)
Stddev: 0.00427 -> 0.00752: 1.7622x larger

### nbody ###
Min: 0.260169 -> 0.273837: 1.05x slower
Avg: 0.267334 -> 0.280441: 1.05x slower
Significant (t=-34.05)
Stddev: 0.00257 -> 0.00286: 1.1125x larger

### regex_v8 ###
Min: 0.047335 -> 0.044750: 1.06x faster
Avg: 0.049424 -> 0.046788: 1.06x faster
Significant (t=10.46)
Stddev: 0.00174 -> 0.00182: 1.0469x larger

The following not significant results are hidden, use -v to show them:
django_v3, fastunpickle, json_dump_v2, json_load, tornado_http.

--

___
Python tracker 

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

Re: Continuing indentation

[Ian Kelly]

On Fri, Mar 4, 2016 at 7:03 AM, alister  wrote:
> On Fri, 04 Mar 2016 10:12:58 +, cl wrote:
>
>> Steven D'Aprano  wrote:
>>> On Fri, 4 Mar 2016 12:23 pm, INADA Naoki wrote:
>>>
>>>
>>> >>
>>> >> Indeed. I don't understand why, when splitting a condition such as
>>> >> this,
>>> >> people tend to put the operator at the end of each line.
>>> >>
>>> >>
>>> > Because PEP8 says:
>>> >
>>> >> The preferred place to break around a binary operator is after the
>>> > operator, not before it. http://pep8.org/#maximum-line-length
>>>
>>> PEP 8 is wrong :-)
>>>
>> Yes, I agree.  In my mind the logic is:-
>>
>> IF xxx
>> AND yyy AND zzz OR aaa
>> THEN do something
>>
>> The PEP8 correct(er):-
>>
>> IF xxx AND
>>  yyy AND zzz OR aaa
>> THEN do something
>>
>> ... just seems all wrong and difficult to understand.
>
> not at all
> the split after the operator shows that their is more to that line
> splitting before & the reader could believe that the condition ends there
>
> PEP 8 is mos definitely correct on this one

I disagree. When I'm skimming over code, I find it unlikely that I'll
read the last token of the line. That's where trivialities like
arguments to function calls are found. It's much more likely that I'll
read the first token of the next line.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue17720] pickle.py's load_appends should call append() on objects other than lists

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Why this patch was not applied to 2.7? What is the spec of APPENDS?

--

___
Python tracker 

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

Re: creating zipfile with symlinks

[Gene Heskett]

On Friday 04 March 2016 07:18:57 Larry Martell wrote:

> On Thu, Mar 3, 2016 at 10:32 PM, Larry Martell 
 wrote:
> > On Thu, Mar 3, 2016 at 4:58 PM, Chris Angelico  
wrote:
> >> On Fri, Mar 4, 2016 at 8:38 AM, MRAB  
wrote:
> >>> Is it even possible to zip a link?
> >>>
> >>> A quick search came up with this:
> >>>
> >>> Are hard links possible within a zip archive?
> >>> http://stackoverflow.com/questions/8859616/are-hard-links-possible
> >>>-within-a-zip-archive
> >>
> >> Hard links are different. Symlinks are files containing the target
> >> filename, with a special mode bit set. I'm not sure if it's a
> >> standard feature of all zip archivers, but on my Debian system, I
> >> can use "zip --symlinks" to create such a zip. How that will unzip
> >> on a system that doesn't understand symlinks, I don't know.
> >>
> >> rosuav@sikorsky:~/tmp$ ls -l
> >> total 4
> >> -rw-r--r-- 1 rosuav rosuav 162 Mar  4 08:48 aaa.zip
> >> lrwxrwxrwx 1 rosuav rosuav   4 Mar  4 08:49 qwer -> asdf
> >> rosuav@sikorsky:~/tmp$ unzip -l aaa.zip
> >> Archive:  aaa.zip
> >>   Length  DateTimeName
> >> -  -- -   
> >> 4  2016-03-04 08:45   qwer
> >> - ---
> >> 4 1 file
> >>
> >>
> >> That's a broken symlink (there is no "asdf" in the directory), and
> >> zip and unzip are both fine with that.
> >>
> >> Now, how the Python zipfile module handles this, I don't know. The
> >> ZipInfo shows a file mode of 'lrwxrwxrwx', but when I call
> >> extract(), it comes out as a regular file. You might have to do
> >> some work manually, or else just drop to an external command with
> >> --symlinks.
> >
> > Thanks. That's what I ended up doing.
>
> Unfortunately very slow - around 8 minutes to zip a 7GB dir using the
> command line zip vs. 13 seconds with the python zipfile module.

Obviously the python version is not doing very much, or has enough python 
magic in it to be truely called magic. In any case Larry, the operative 
phrase for any of the various compression methods is TANSTAAFL.

To generate a compressed archive of 7GB of data, is going to take time, 
and I don't care what size that compressors dictionary block is. 13 
seconds is simply not a believeable figure.

I also note carefully that no one has allowed as to what exactly this 
python version does do.  Thats scary...

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Off-topic] Requests author discusses MentalHealthError exception

[alister]

On Thu, 03 Mar 2016 18:02:04 -0500, William Ray Wing wrote:

>> On Mar 3, 2016, at 3:20 PM, alister  wrote:
>> 
>> On Thu, 03 Mar 2016 11:03:55 -0700, Ian Kelly wrote:
>> 
>>> On Thu, Mar 3, 2016 at 10:21 AM, alister 
>>> wrote:
 On Thu, 03 Mar 2016 13:35:12 +1100, Chris Angelico wrote:
> 1) No physical object can have negative mass.
> 2) I am a part of the universe and have positive mass.
> 3) I am not Kenneth.
> 4) The sum of my mass and Kenneth's mass must exceed Kenneth's mass
> alone.
> 
> Unless someone wants to dispute 1 or 2, we can be logically certain.
> 
> ChrisA
 
 Anti Matter?
>>> 
>>> Antimatter has positive mass.
>> 
>> Are you sure?
> 
> The ALPHA experiment at CERN is attempting a direct measurement of the
> mass of anti-hydrogen by trapping atoms of the stuff in a penning trap
> at high vacuum. The answer isn’t definitive yet as the error bars are
> huge and extend past zero, but are centered on the positive side.
> 
> -Bill
> 
> 
>> mix 1 atom of hydrogen + 1 of anti hydrogen & you end up with 0 mass (+
>> LOTTS of energy)
>> 
>> To be honest it is all over my head
>> 
>> 
>> 
>> --
>> I used to be Snow White, but I drifted.
>>  -- Mae West
>> --
>> https://mail.python.org/mailman/listinfo/python-list



yes I have found some article that seem to agree with that.

it appears that anti-matter only has -v2 charges
something new & interesting learned today

-- 
"Wish not to seem, but to be, the best."
-- Aeschylus
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[alister]

On Fri, 04 Mar 2016 10:12:58 +, cl wrote:

> Steven D'Aprano  wrote:
>> On Fri, 4 Mar 2016 12:23 pm, INADA Naoki wrote:
>> 
>> 
>> >>
>> >> Indeed. I don't understand why, when splitting a condition such as
>> >> this,
>> >> people tend to put the operator at the end of each line.
>> >>
>> >>
>> > Because PEP8 says:
>> > 
>> >> The preferred place to break around a binary operator is after the
>> > operator, not before it. http://pep8.org/#maximum-line-length
>> 
>> PEP 8 is wrong :-)
>> 
> Yes, I agree.  In my mind the logic is:-
> 
> IF xxx
> AND yyy AND zzz OR aaa
> THEN do something
> 
> The PEP8 correct(er):-
> 
> IF xxx AND
>  yyy AND zzz OR aaa
> THEN do something
> 
> ... just seems all wrong and difficult to understand.

not at all
the split after the operator shows that their is more to that line
splitting before & the reader could believe that the condition ends there

PEP 8 is mos definitely correct on this one



-- 
According to all the latest reports, there was no truth in any of the
earlier reports.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[alister]

On Fri, 04 Mar 2016 10:23:37 +0900, INADA Naoki wrote:


>>
>> Indeed. I don't understand why, when splitting a condition such as
>> this,
>> people tend to put the operator at the end of each line.
>>
>>
> Because PEP8 says:
> 
>> The preferred place to break around a binary operator is after the
> operator, not before it. http://pep8.org/#maximum-line-length

and that is to make it obvious that there is more to come.




-- 
Nonsense.  Space is blue and birds fly through it.
-- Heisenberg
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine

[Michael Felt]

Michael Felt added the comment:

FYI: build as 64-bit (and shall only build as 64-bit from now I expect)
and the output works as:
==
aixtools.python:aixtools.python.man.en_US:2.7.11.0::I:C:N:man pages0::
aixtools.python:aixtools.python.rte:2.7.11.0::I:C:N:built 04-Mar-2016 1232 
UTC0::
==
root@x064:[/data/prj/aixtools/python/python-2.7.11]./python
Python 2.7.11 (default, Mar  4 2016, 12:29:39) [C] on aix5
Type "help", "copyright", "credits" or "license" for more information.
>>> import sysconfig
>>> sysconfig.is_python_build()
True
>>> import distutils.util
>>> distutils.util.get_platform()
'aix-5.3'
>>> import os
>>> os.uname()
('AIX', 'x064', '3', '5', '00C291F54C00')
>>> import platform
>>> platform.architecture()
('64bit', '')
>>> import os, sys
>>> sys.maxsize
9223372036854775807
>>> 2**32
4294967296
>>> 

I was wondering if there is a PEP statement somewhere re: 
distutils.util.get_platform() semantics

--

___
Python tracker 

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

[issue26479] Init documentation typo "may be return" > "may NOT be returned"

[Ronald Oussoren]

Ronald Oussoren added the comment:

The text appears to be correct as it is. What is says is that __init__ must not 
return any value other than None and that is correct, you will get an exception 
when you return a value that is not None.

>>> class C():
...def __init__(self): return 42
... 
>>> 
>>> C()
Traceback (most recent call last):
  File "", line 1, in 
TypeError: __init__() should return None, not 'int'
>>> 

The text is basically a language-lawyer way of stating that __init__ should 
return by either running of the end of the method, or by using a bare return 
statement.

--
nosy: +ronaldoussoren

___
Python tracker 

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

Re: cx_Oracle + array parameter

[sandrof66]

I did your solution. I created a varray like this: TYPE LIST_IDS IS TABLE OF 
INT INDEX BY BINARY_INTEGER, but when I try to use in a sql statement SELECT 
appears an oracle error cannot access row in nested table. I use oracle 11g and 
I read that you can use a varray declare in plsql to sql statement.


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

Re: cx_Oracle + array parameter

[sandrof66]

I did your solution. I created a varray like this: TYPE LIST_IDS IS TABLE OF 
INT INDEX BY BINARY_INTEGER, but when I try to use in a sql statement SELECT 
appears an oracle error cannot access row in nested table. I use oracle 11g and 
I read that you can use a varray declare in plsql to sql statement.


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

Re: [Still off-top] Physics [was Requests author discusses MentalHealthError exception]

[Dan Sommers]

On Fri, 04 Mar 2016 12:38:28 +0200, Marko Rauhamaa wrote:

> As for the existence of a negative mass, it is interesting to note
> that the (rest) mass of an alpha particle is less than the sum of the
> (rest) masses of its constituents. About 1% of the mass is "missing."

https://en.wikipedia.org/wiki/Binding_energy
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue26479] Init documentation typo "may be return" > "may NOT be returned"

[Samuel Colvin]

New submission from Samuel Colvin:

https://docs.python.org/3/reference/datamodel.html#object.__init__

"no non-None value may be returned by __init__();" should read "no non-None 
value may *not* be returned by __init__();"

--
assignee: docs@python
components: Documentation
messages: 261185
nosy: Samuel Colvin, docs@python
priority: normal
severity: normal
status: open
title: Init documentation typo "may be return" > "may NOT be returned"
versions: Python 3.4, Python 3.5, Python 3.6

___
Python tracker 

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

Re: (Initial) Questions about sysconfig.*

[Michael Felt]

Thanks for the quick reply. My mailer lost it (rather remembered it 
originiated as a reply to something else, and stored it there) - :)


I would reply between the text below - but, mainly thanks for showing 
the use of 'inspect' - will be extremely handy as I learn enough to make 
a (local) patch.


Michael

p.s. the >>> prompts make it look very colorful in my mail program!

On 2016-03-04 11:22, Peter Otten wrote:

Michael Felt wrote:


First, a simple one:

sysconfig.is_python_build()

  Return True if the current Python installation was built from source.


  sysconfig.is_python_build()

False

Now, not earth shattering, but I did build this from source - so can
someone help me with understanding why Python says no?

Looking into the source of a self-compilee Python version:

$ python3.6
Python 3.6.0a0 (default:c092148a1b55+, Mar  1 2016, 15:26:05)
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.

import sysconfig, inspect
print(inspect.getsource(sysconfig.is_python_build))

def is_python_build(check_home=False):
 if check_home and _sys_home:
 return _is_python_source_dir(_sys_home)
 return _is_python_source_dir(_PROJECT_BASE)


print(inspect.getsource(sysconfig._is_python_source_dir))

def _is_python_source_dir(d):
 for fn in ("Setup.dist", "Setup.local"):
 if os.path.isfile(os.path.join(d, "Modules", fn)):
 return True
 return False


sysconfig._PROJECT_BASE

'/usr/local/bin'

So this effectively looks for the file /usr/local/bin/Modules/Setup.dist
or /usr/local/bin/Modules/Setup.local which of course fails. You have to
invoke the interpreter in the directory where it was built:

$ /wherever/you/unpacked/and/compiled/python
Python 3.6.0a0 (default:c092148a1b55+, Mar  1 2016, 15:26:05)
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.

import sysconfig
sysconfig.is_python_build()

True


And a last question (more about the configure phase I expect)

...() returns, among other things:

'LIBRARY_OBJS': '\\',
'MODULE_OBJS': '\\',
'PARSER_HEADERS': '\\',
'PGENSRCS': '\\ \\',
'PYTHON_OBJS': '\\',
'QUICKTESTOPTS': '-l -x test_subprocess test_io test_lib2to3 \\',

'SHLIB_EXT': '".so"',

Why are any of these using '\\' for anything on 'posix'?

Is that data actually used anywhere? I suspect this is a parsing mishap and
these are actually line continuation indicators. In the Makefile I find (e.
g.)

PYTHON_OBJS=\
Python/_warnings.o \
Python/Python-ast.o \
Python/asdl.o \
[snip]




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

Re: Lookahead while doing: for line in fh.readlines():

[Veek. M]

Terry Reedy wrote:

> On 2/27/2016 4:39 AM, Veek. M wrote:
>> I want to do something like:
>>
>> #!/usr/bin/env python3
>>
>> fh = open('/etc/motd')
>> for line in fh.readlines():
>>  print(fh.tell())
>>
>> why doesn't this work as expected.. fh.readlines() should return a
>> generator object and fh.tell() ought to start at 0 first.
> 
> Not after you have already read some data.  Readlines() reads the
> entire
> file and splits it into lines.  readline reads at least a single
> block.
>   Reading a single byte or character at a time looking for /n would be
> too slow, so even after readline, the file pointer will be somewhere
> past the end of the last line returned.
> 
>> Instead i get the final count repeated for the number of lines.
>>
>> What i'm trying to do is lookahead:
>> #!whatever
>>
>> fh = open(whatever)
>> for line in fh.readlines():
>>  x = fh.tell()
>>  temp = fh.readline()
>>  fh.seek(x)
>>
> 
> 

I get that readlines() would slurp the whole file for efficiency 
reasons. Why doesn't fh.seek() work though. Object 'fh' is a data 
structure for the OS file descriptor similar to FILE in C.


So if seek works in C, how come it doesn't work in python wrt 
readlines() which is just a method. What obviates the functioning of 
seek wrt readlines()?

fh.tell() works at the line level.. and fh.readline() works with 
fh.seek(0)
-- 
https://mail.python.org/mailman/listinfo/python-list

ANN Nanpy 0.9.6 - Use your Arduino board with Python

[Andrea Stagi]

Nanpy 0.9.6 is out! Nanpy is a library that use your Arduino as a slave,
controlled by a master device where you run your scripts, such as a PC, a
Raspberry Pi etc. The main purpose of Nanpy is making programmers' life
easier, providing them a powerful library to create prototypes faster and
make Arduino programming a game for kids. Read more about Nanpy here
http://nanpy.github.io/

0.9.6 release includes:

- Add support for Adafruit TLC5947 24-Channel PWM Driver
- Add LCD Autoscroll support
- Add LCD clear method
- Add INPUT_PULLUP support
- Add 4 pins support to the Stepper
- Add LCD createChar API
- Now supports only Python 2.7, 3.3, 3.4, 3.5
- Minfixes

-- 
Andrea Stagi (@4stagi) - Senior Full Stack Developer @Nephila
Job profile: http://linkedin.com/in/andreastagi
Website: http://4spills.blogspot.it/
Github: http://github.com/astagi
-- 
https://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/

Re: creating zipfile with symlinks

[Chris Angelico]

On Fri, Mar 4, 2016 at 11:18 PM, Larry Martell  wrote:
> Unfortunately very slow - around 8 minutes to zip a 7GB dir using the
> command line zip vs. 13 seconds with the python zipfile module.

13 seconds? That sounds wrong for 7GB. I doubt you can deflate that
much data that quickly on any modern system. Check if it's actually
doing what you think it is.

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

Re: Any comment on using ctypesgen package?

[Peter Otten]

jf...@ms4.hinet.net wrote:

> I try to test this package but with no luck. This module was written for
> Python 2.x but mine is 3.4 so I use the 2To3 to "upgrade" it first (it
> seems OK). Then I run "python setup.py install" and get the following
> error:
>...
>...
>File "D:\Patch\ctypesgen-master\ctypesgencore\parser\lex.py", line 41,
>in 
> _INSTANCETYPE = types.InstanceType
>AttributeError: 'module' object has no attribute 'InstanceType'
> 
> Below is the troubled codes in file lex.py:
> Note: In original codes (before 2To3 modify), there is "types.ObjectType"
> instead of "object". -
> # Available instance types.  This is used when lexers are defined by a
> # class. It's a little funky because I want to preserve backwards
> # compatibility with Python 2.0 where types.ObjectType is undefined.
> try:
> _INSTANCETYPE = (types.InstanceType, object)
> except AttributeError:
> _INSTANCETYPE = types.InstanceType
> class object: pass   # Note: needed if no new-style classes present
> ---
> The author had put some comments above these codes but I have no idea what
> he is talking about.
> 
> There is someone who had encountered the same problem last year and raise
> a question at its home page, but the author seems has no interest on doing
> anything on it anymore.
> https://github.com/davidjamesca/ctypesgen/issues/53
> 
> Does anyone know how to fix it? or the whole job will be a mission
> impossible if no help from its author?

Nothing is impossible with open source ;)

What's possible for you depends on your knowledge and the amount of effort 
you are willing to spend. The page you link to has the comment

"""
The 2to3 route is not likely to apply since ctypesgen actually writes Python 
code and the 2to3 utility will probably miss a good portion of that logic.
"""

But as someone else seems to have done the work already

https://github.com/davidjamesca/ctypesgen/issues/51

I'd try his version first.


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

Re: creating zipfile with symlinks

[Larry Martell]

On Thu, Mar 3, 2016 at 10:32 PM, Larry Martell  wrote:
> On Thu, Mar 3, 2016 at 4:58 PM, Chris Angelico  wrote:
>> On Fri, Mar 4, 2016 at 8:38 AM, MRAB  wrote:
>>> Is it even possible to zip a link?
>>>
>>> A quick search came up with this:
>>>
>>> Are hard links possible within a zip archive?
>>> http://stackoverflow.com/questions/8859616/are-hard-links-possible-within-a-zip-archive
>>
>> Hard links are different. Symlinks are files containing the target
>> filename, with a special mode bit set. I'm not sure if it's a standard
>> feature of all zip archivers, but on my Debian system, I can use "zip
>> --symlinks" to create such a zip. How that will unzip on a system that
>> doesn't understand symlinks, I don't know.
>>
>> rosuav@sikorsky:~/tmp$ ls -l
>> total 4
>> -rw-r--r-- 1 rosuav rosuav 162 Mar  4 08:48 aaa.zip
>> lrwxrwxrwx 1 rosuav rosuav   4 Mar  4 08:49 qwer -> asdf
>> rosuav@sikorsky:~/tmp$ unzip -l aaa.zip
>> Archive:  aaa.zip
>>   Length  DateTimeName
>> -  -- -   
>> 4  2016-03-04 08:45   qwer
>> - ---
>> 4 1 file
>>
>>
>> That's a broken symlink (there is no "asdf" in the directory), and zip
>> and unzip are both fine with that.
>>
>> Now, how the Python zipfile module handles this, I don't know. The
>> ZipInfo shows a file mode of 'lrwxrwxrwx', but when I call extract(),
>> it comes out as a regular file. You might have to do some work
>> manually, or else just drop to an external command with --symlinks.
>
> Thanks. That's what I ended up doing.

Unfortunately very slow - around 8 minutes to zip a 7GB dir using the
command line zip vs. 13 seconds with the python zipfile module.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Any comment on using ctypesgen package?

[Chris Angelico]

On Fri, Mar 4, 2016 at 10:08 PM,   wrote:
> Below is the troubled codes in file lex.py:
> Note: In original codes (before 2To3 modify), there is "types.ObjectType" 
> instead of "object".
> -
> # Available instance types.  This is used when lexers are defined by a class.
> # It's a little funky because I want to preserve backwards compatibility
> # with Python 2.0 where types.ObjectType is undefined.
> try:
> _INSTANCETYPE = (types.InstanceType, object)
> except AttributeError:
> _INSTANCETYPE = types.InstanceType
> class object: pass   # Note: needed if no new-style classes present
> ---
> The author had put some comments above these codes but I have no idea what he 
> is talking about.

I'm not sure exactly what this is trying to do, but if it's just for
isinstance testing, you can save yourself a lot of trouble. In Python
3, *every* type inherits from 'object'. So _INSTANCETYPE can be set to
just object - and anything that's trying to query that can simply
assume it's true.

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

Re: creating zipfile with symlinks

[Tim Golden]

On 04/03/2016 11:03, crankypuss wrote:
> Larry Martell wrote:
> 
>> I have a script that creates zip files of dirs containing symlinks. I
>> was surprised to find that the zipfiles have zipped the targets of the
>> links as opposed to the links themselves, which is what I wanted and
>> expected. Googling I found this:
>>
>> https://doeidoei.wordpress.com/2010/11/23/compressing-files-with-python-symlink-trouble/
>>
>> Which I don't love as a solution. Anyone know a cleaner way to get
>> zipfile to zip the links?
> 
> I don't even know what "zipfile" is, is that a Windows command?  

It's a Python module:

https://docs.python.org/3.5/library/zipfile.html

TJG

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

Any comment on using ctypesgen package?

[jfong]

I try to test this package but with no luck. This module was written for Python 
2.x but mine is 3.4 so I use the 2To3 to "upgrade" it first (it seems OK). Then 
I run "python setup.py install" and get the following error:
   ...
   ...
   File "D:\Patch\ctypesgen-master\ctypesgencore\parser\lex.py", line 41, in 

_INSTANCETYPE = types.InstanceType
   AttributeError: 'module' object has no attribute 'InstanceType'

Below is the troubled codes in file lex.py:
Note: In original codes (before 2To3 modify), there is "types.ObjectType" 
instead of "object".
-
# Available instance types.  This is used when lexers are defined by a class.
# It's a little funky because I want to preserve backwards compatibility
# with Python 2.0 where types.ObjectType is undefined.
try:
_INSTANCETYPE = (types.InstanceType, object)
except AttributeError:
_INSTANCETYPE = types.InstanceType
class object: pass   # Note: needed if no new-style classes present 
---
The author had put some comments above these codes but I have no idea what he 
is talking about.

There is someone who had encountered the same problem last year and raise a 
question at its home page, but the author seems has no interest on doing 
anything on it anymore.
https://github.com/davidjamesca/ctypesgen/issues/53

Does anyone know how to fix it? or the whole job will be a mission impossible 
if no help from its author?

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

Re: creating zipfile with symlinks

[crankypuss]

Larry Martell wrote:

> I have a script that creates zip files of dirs containing symlinks. I
> was surprised to find that the zipfiles have zipped the targets of the
> links as opposed to the links themselves, which is what I wanted and
> expected. Googling I found this:
> 
> https://doeidoei.wordpress.com/2010/11/23/compressing-files-with-python-symlink-trouble/
> 
> Which I don't love as a solution. Anyone know a cleaner way to get
> zipfile to zip the links?

I don't even know what "zipfile" is, is that a Windows command?  On 
linux the tar command's --dereference option causes the behavior you 
describe, which is not its default.  Not sure if this is applicable to 
your situation, or not:

http://www.gnu.org/software/tar/manual/html_node/dereference.html

-- 
http://totally-portable-software.blogspot.com
  [Mon Feb 29: "Addresses - What Good Are They?"]

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

Re: looking into python...

[crankypuss]

Steven D'Aprano wrote:

> On Thu, 3 Mar 2016 09:45 pm, crankypuss wrote:
> 
>> Ben Finney wrote:
>> 
>>> crankypuss  writes:
>>> 
 "Python code can be packaged into stand-alone executable programs
 for some of the most popular operating systems, allowing the
 distribution of Python-based software for use on those environments
 without requiring the installation of a Python interpreter."
 (wikipedia)

 How correct is that?  Which "most popular operating systems" are
 those?
>>> 
>>> Python's web site covers this. The Python environment is available
>>> for download  for all major
>>> operating systems.
>> 
>> Looking at https://www.python.org/downloads/release/python-344/
>> it appears that "all major operating systems" includes "Mac OS X",
>> "Windows", and "Source release".  I'm seeing nothing about Android,
>> or
>> BlackBerry OS-10, or mainframes, or linux.  Presumably the source
>> code
>> has been pre-built for linux in various distro repositories.  Maybe
>> I'm missing the obvious as usual.
> 
> Yes, all the major Linux distros (Red Hat, Centos, Fedora, Debian,
> Ubuntu, Mint, Suse, ...) will either install Python by default or at
> least provide it through their official package management software.
> 
> Likewise, FreeBSD and OpenBSD certainly have Python available.
> 
> I doubt Blackberry has Python available, but that's hardly a major or
> important platform.

I'd say its importance depends on what kind of phone you carry. 

FWIW, "BlackBerry 10 is based on QNX, a Unix-like operating system that 
was originally developed by QNX Software Systems until the company was 
acquired by BlackBerry in April 2010."

from https://en.wikipedia.org/wiki/BlackBerry_10

> For Android, the answer is mixed. I don't have an Android device to
> try it on, but I'm told that it is possible to install Python on
> Android, but it may be difficult. Probably the easiest way is to
> install Kivy:
> 
> https://kivy.org/
> 
> Kivy is a cross-platform Python development system that runs on OS X,
> Linux, Windows, iOS (iPad, iPhone) and Android.
> 
> For mainframes, the answer is maybe". If your mainframe supports the
> C89 standard, it will probably work. If it can run x86 machine code,
> or emulate it in a VM, that's probably the way to go.
> 
> Some older versions of Python supported mainframes like VMS, but in
> 2011, support for OS\2, VMS and Windows 2000 was dropped:
> 
> http://blog.python.org/2011/05/python-33-to-drop-support-for-os2.html
> 
> There is a Nokia project called PyS60 that runs Python on Nokia Series
> 60 mobile phones. I don't know if it is still maintained.
> 
> Classic Mac OS (System 9 and older) was supported in older Python
> versions, but not the more recent ones.
> 
> I don't think there has ever been a version of Python that ran on DOS
> :-)

It sounds as though Python will run on pretty much anything that's close 
to POSIX-compliant?

>> Referring back to the wikipedia quote at the start of the post, I'm
>> interested in how Python code is packaged into stand-alone
>> executables.
> 
> I'm only really familiar with the situation on Linux.

That's where I'm from these days.

> On Linux, you
> usually wouldn't bother. Since Python is almost always already
> installed on the system, and even if it is not, it's usually only a
> single command away (like `yum install python`, say), there's very
> little point in packaging your scripts or applications up in a
> stand-alone exe file.

Nice, with PHP it isn't so easy; not only is there often no PHP 
interpreter, to install one you have to fiddle with a config file.

> Somewhat intermediate between stand-alone exe applications and a
> directory full of scripts is to create a package, compress it into a
> zip file, and run that zip file with the Python interpreter installed
> on your system. Since it relies on there being an external Python
> interpreter, it's not exactly stand-alone, but it may be close enough
> for what you're doing.

Reminds me of docker stuff.

> Python packages are dead-simple: create a directory called "foo", and
> put a file inside it called "__init__.py". It can even be an empty
> file. That's a package. Obviously there is more to it than that, but
> that's the basics.

Okay, thanks.

-- 
http://totally-portable-software.blogspot.com
  [Mon Feb 29: "Addresses - What Good Are They?"]

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

Re: [Still off-top] Physics [was Requests author discusses MentalHealthError exception]

[Marko Rauhamaa]

Oscar Benjamin :

> The mass is carried by the new particles. The new particles may have a
> total *rest mass* which differs from the total rest mass of the
> previous particles. However the total mass is the rest mass plus the
> mass associated with the "kinetic energy" of the particles.
>
> [...]
>
> Mass and energy are not interchangeable in the sense that you can
> exchange one for the other with e=mc^2 giving the exchange rate.
> Rather mass and energy are *the same thing*. Although they are
> different concepts defined in different ways and having different
> dimensions and units they are inseparable: e=mc^2 gives us the
> proportion in which the two appear together.

A physicist mentioned to me that the word "mass" has replaced the term
"rest mass" in modern Physics lingo. That's why you say a photon is
"massless" even though every observable photon has a relativistic mass.
It's all in the terminology.

As for the existence of a negative mass, it is interesting to note that
the (rest) mass of an alpha particle is less than the sum of the (rest)
masses of its constituents. About 1% of the mass is "missing."


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

Re: (Initial) Questions about sysconfig.*

[Peter Otten]

Michael Felt wrote:

> First, a simple one:
> 
> sysconfig.is_python_build()
> 
>  Return True if the current Python installation was built from source.
> 
  sysconfig.is_python_build()
> False
> 
> Now, not earth shattering, but I did build this from source - so can
> someone help me with understanding why Python says no?

Looking into the source of a self-compilee Python version:

$ python3.6
Python 3.6.0a0 (default:c092148a1b55+, Mar  1 2016, 15:26:05) 
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sysconfig, inspect
>>> print(inspect.getsource(sysconfig.is_python_build))
def is_python_build(check_home=False):
if check_home and _sys_home:
return _is_python_source_dir(_sys_home)
return _is_python_source_dir(_PROJECT_BASE)

>>> print(inspect.getsource(sysconfig._is_python_source_dir))
def _is_python_source_dir(d):
for fn in ("Setup.dist", "Setup.local"):
if os.path.isfile(os.path.join(d, "Modules", fn)):
return True
return False

>>> sysconfig._PROJECT_BASE
'/usr/local/bin'

So this effectively looks for the file /usr/local/bin/Modules/Setup.dist
or /usr/local/bin/Modules/Setup.local which of course fails. You have to 
invoke the interpreter in the directory where it was built:

$ /wherever/you/unpacked/and/compiled/python
Python 3.6.0a0 (default:c092148a1b55+, Mar  1 2016, 15:26:05) 
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sysconfig
>>> sysconfig.is_python_build()
True

> And a last question (more about the configure phase I expect)
> 
> ...() returns, among other things:
> 
> 'LIBRARY_OBJS': '\\',
> 'MODULE_OBJS': '\\',
> 'PARSER_HEADERS': '\\',
> 'PGENSRCS': '\\ \\',
> 'PYTHON_OBJS': '\\',
> 'QUICKTESTOPTS': '-l -x test_subprocess test_io test_lib2to3 \\',
> 
> 'SHLIB_EXT': '".so"',
> 
> Why are any of these using '\\' for anything on 'posix'?

Is that data actually used anywhere? I suspect this is a parsing mishap and 
these are actually line continuation indicators. In the Makefile I find (e. 
g.)

PYTHON_OBJS=\
Python/_warnings.o \
Python/Python-ast.o \
Python/asdl.o \
[snip]



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

Re: Continuing indentation

[cl]

Steven D'Aprano  wrote:
> On Fri, 4 Mar 2016 12:23 pm, INADA Naoki wrote:
> 
> >>
> >>
> >> Indeed. I don't understand why, when splitting a condition such as this,
> >> people tend to put the operator at the end of each line.
> >>
> >>
> > Because PEP8 says:
> > 
> >> The preferred place to break around a binary operator is after the
> > operator, not before it.
> > http://pep8.org/#maximum-line-length
> 
> PEP 8 is wrong :-)
> 
Yes, I agree.  In my mind the logic is:-

IF xxx
AND yyy
AND zzz
OR aaa
THEN do something

The PEP8 correct(er):-

IF xxx AND
 yyy AND
 zzz OR
 aaa
THEN do something

... just seems all wrong and difficult to understand.

-- 
Chris Green
·
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Still off-top] Physics [was Requests author discusses MentalHealthError exception]

[Oscar Benjamin]

On 4 March 2016 at 00:04, Steven D'Aprano  wrote:
> On Fri, 4 Mar 2016 07:20 am, alister wrote:
>
>> On Thu, 03 Mar 2016 11:03:55 -0700, Ian Kelly wrote:
>
>>> Antimatter has positive mass.
>>
>> Are you sure?
>>  mix 1 atom of hydrogen + 1 of anti hydrogen & you end up with 0 mass (+
>> LOTTS of energy)

This is incorrect. Mass and energy are both conserved. In a
particle/antiparticle annihilation new particles are created. See
here:
https://en.wikipedia.org/wiki/Annihilation

The mass is carried by the new particles. The new particles may have a
total *rest mass* which differs from the total rest mass of the
previous particles. However the total mass is the rest mass plus the
mass associated with the "kinetic energy" of the particles.

> As far as the reaction of matter and anti-matter, we've known for about a
> century that mass and energy are related and freely convertible from one to
> the other. That's the famous equation by Einstein: E = m*c**2. Even tiny
> amounts of energy (say, the light and heat released from a burning match)
> involve a correspondingly tiny reduction in mass.

This is also incorrect and suffers from the same misinterpretation as
above. Mass and energy are not interchangeable in the sense that you
can exchange one for the other with e=mc^2 giving the exchange rate.
Rather mass and energy are *the same thing*. Although they are
different concepts defined in different ways and having different
dimensions and units they are inseparable: e=mc^2 gives us the
proportion in which the two appear together.

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

(Initial) Questions about sysconfig.*

[Michael Felt]

First, a simple one:

sysconfig.is_python_build()

Return True if the current Python installation was built from source.


 sysconfig.is_python_build()

False

Now, not earth shattering, but I did build this from source - so can someone 
help me with understanding why Python says no?

FYI: These are accurate: (reformated for legibility, where needed)


 sysconfig.get_paths()

{'platinclude': '/opt/include/python2.7',
 'platstdlib': '/opt/lib/python2.7',
 'platlib': '/opt/lib/python2.7/site-packages',
 'purelib': '/opt/lib/python2.7/site-packages',
 'stdlib': '/opt/lib/python2.7',
 'scripts': '/opt/bin',
 'include': '/opt/include/python2.7',
 'data': '/opt'
}


 sysconfig.get_platform()

'aix-5.3'

And a last question (more about the configure phase I expect)

...() returns, among other things:

'LIBRARY_OBJS': '\\',
'MODULE_OBJS': '\\',
'PARSER_HEADERS': '\\',
'PGENSRCS': '\\ \\',
'PYTHON_OBJS': '\\',
'QUICKTESTOPTS': '-l -x test_subprocess test_io test_lib2to3 \\',

'SHLIB_EXT': '".so"',

Why are any of these using '\\' for anything on 'posix'?

And, as a DLL object on AIX (in the same sense as linux) is both 'libNAME.so'
when available as a file AND libNAME.a(anything.so) when a MEMBER in an archive.

Or are there variables there I should ignore (on 'posix')?

And, having read a bit - is there a PEP on these variables, meaning, and usage?

Thanks for your assistance!

Michael

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

Confirm: About python Registration

[Jonathan Qin]

Dear Manager,
(Please forward this to your CEO, because this is urgent. Thanks!)
This is Jonathan Qin---the manager of domain name registration and solution 
center in China. On February 29th, 2016, we received an application from Baiyao 
Holdings Ltd requested “python” as their internet keyword and China (CN) domain 
names. But after checking it, we find this name conflict with your company name 
or trademark. In order to deal with this matter better, it‘s necessary to send 
an email to you and confirm whether this company is your distributor or 
business partner in China?
Kind regards
Jonathan Qin
Manager  
Cname (Head Office)
8008, Tianan Building, 
No. 1399 Jinqiao Road, 
Shanghai 200120
Tel: +86-21-6191-8696
Mobile: +86-1377-4400-340 
Fax:+86-21-6191-8697 
www.cname.org.cn
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue26456] import _tkinter + TestForkInThread leaves zombie with stalled thread

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

But please add a reference to this issue.

--

___
Python tracker 

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