Re: Make a unique filesystem path, without creating the file

[Paul Rubin]

Marko Rauhamaa  writes:
> It is also correct that /dev/urandom depletes the entropy pool as
> effectively as /dev/random. 

I think see what's confusing you: the above is a misconception that is
probably held by lots of people.  Entropy is not water and from a
cryptographic standpoint there is essentially no such thing as
"depleting" an entropy pool.  There is either enough entropy (say 256
bits or more) in the PRNG or else there isn't.  If there's not enough,
urandom can misbehave by giving you bad output because it doesn't block
until more is gathered.  If there is enough, /dev/random misbehaves by
blocking under this bogus concept of "depletion".  If you have a seed
with 256 bits of entropy and you generate a gigabyte of random numbers
from it, you have not increased the predictability of the seed in any
significant way.

So once /dev/random unblocks, it should never again block, the behavior
of getrandom.  There used to be an article on David Wagner's web site
(cs.berkeley.edu/~daw) about the concept of "depleting" entropy by
iterated hashing, but I can't find it now.  That's unfortunate since it
might help cast light on the subject.

>> http://www.2uo.de/myths-about-urandom/
> Already addressed.

No really, all you've done is repeat bad advice.  The people cited in
that article are very knowledgeable and the stuff they say makes good
mathematical sense.  The stuff you say makes no sense and you haven't
given any convincing reason for anyone to listen to you.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Make a unique filesystem path, without creating the file

[Marko Rauhamaa]

Steven D'Aprano :

> On Tue, 23 Feb 2016 06:32 am, Marko Rauhamaa wrote:
>> Under Linux, /dev/random is the way to go when strong security is
>> needed. Note that /dev/random is a scarce resource on ordinary
>> systems.
>
> That's actually incorrect, but you're not the only one to have been
> mislead by the man pages.
>
> http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/

Still, mostly hypnotic repetitions.

However, it admits:

   But /dev/random also tries to keep track of how much entropy remains
   in its kernel pool, and will occasionally go on strike if it decides
   not enough remains.

That's the whole point. /dev/random will rather block the program than
lower the quality of the random numbers below a threshold. /dev/urandom
has no such qualms.

   If you use /dev/random instead of urandom, your program will
   unpredictably (or, if you’re an attacker, very predictably) hang when
   Linux gets confused about how its own RNG works.

Yes, possibly indefinitely, too.

   Using /dev/random will make your programs less stable, but it won’t
   make them any more cryptographically safe.

It is correct that you shouldn't use /dev/random as a routine source of
bulk random numbers. It is also correct that /dev/urandom depletes the
entropy pool as effectively as /dev/random. However, when you are
generating signing or encryption keys, you should use /dev/random.

As stated in https://lwn.net/Articles/606141/>:

   /dev/urandom should be used for essentially all random numbers
   required, but /dev/random is sometimes used for things like extremely
   sensitive, long-lived keys (e.g. GPG) or one-time pads.

> See also:
>
> http://www.2uo.de/myths-about-urandom/

Already addressed.


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

good python tutorial

[Mike S via Python-list]

This site was recommended by a friend, it looks really well put 
together, I thought it might be of interest to people considering online 
tutorials.


http://www.python-course.eu/index.php
--
https://mail.python.org/mailman/listinfo/python-list

[issue26417] Default IDLE 2.7.11 configuration files are out-of-sync on OS X framework installs

[Ned Deily]

New submission from Ned Deily:

On OS X framework installs, the Mac-specific sub-makefiles do some important 
tailoring of IDLE/s config-extensions.def and config-main.def files, among 
other things changing Tk some Tk events for more appropriate keyboard bindings 
(e.g. "

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

[issue26366] Use “.. versionadded” over “.. versionchanged” where appropriate

[Fred L. Drake, Jr.]

Fred L. Drake, Jr. added the comment:

For anyone following along only via the tracker, it's worth noting that 
proposals for new markup are welcome on the docs mailing list.  More 
information is available at:

https://mail.python.org/mailman/listinfo/docs

--

___
Python tracker 

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

Re: Make a unique filesystem path, without creating the file

[Paul Rubin]

Chris Angelico  writes:
> How much future are you expecting?

This is old but its methodology still seems ok:

  http://saluc.engr.uconn.edu/refs/keymgr/blaze95minimalkeylength.pdf

I also like this:

  http://cr.yp.to/talks/2015.10.05/slides-djb-20151005-a4.pdf

Quote (slide 37): 

  The crypto users' fantasy is boring crypto: crypto that simply works,
  solidly resists attacks, never needs any upgrades.

HN discussion: https://news.ycombinator.com/item?id=10345965
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Make a unique filesystem path, without creating the file

[Chris Angelico]

On Tue, Feb 23, 2016 at 1:27 PM, Paul Rubin  wrote:
>   3) The default token length should be long enough to not have to "change
>   in the future".  If the user wants a shorter token, they ask for that,
>   or can truncate a longer one that they receive from the default.

How much future are you expecting?

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

Re: Make a unique filesystem path, without creating the file

[Paul Rubin]

Steven D'Aprano  writes:
> https://www.python.org/dev/peps/pep-0506/

I didn't know about this!  The discussion was all on mailing lists?

A few things I suggest changing:

  1) the default system RNG for Linux should be getrandom(2) on kernels
  that support it (3.17 and later).

  2) Some effort should be directed at simulating getrandom's behaviour
  on kernels that don't have it, using the /dev/random entropy estimator
  and the /dev/urandom interface.  I.e. it should block if the system
  hasn't seen enough entropy to get the CSPRNG started securely, and
  never block after that.

  3) The default token length should be long enough to not have to "change
  in the future".  If the user wants a shorter token, they ask for that,
  or can truncate a longer one that they receive from the default.

There are a few other choices in the PEP whose benefit is unclear to me,
but they aren't harmful, and I guess the decisions have already been
made.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue26323] Add assert_called() and assert_called_once() methods for mock objects

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
assignee:  -> michael.foord

___
Python tracker 

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

[issue26366] Use “.. versionadded” over “.. versionchanged” where appropriate

[Raymond Hettinger]

Raymond Hettinger added the comment:

Fred, thanks for chiming in.  Let's do close this one.

--
nosy: +rhettinger
resolution:  -> not a bug
status: open -> closed

___
Python tracker 

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

Re: Make a unique filesystem path, without creating the file

[Jon Ribbens]

On 2016-02-23, Ben Finney  wrote:
> Oscar Benjamin  writes:
>> What does unpredictable mean in this context? Maybe I'm reading too
>> much into that...
>
> I think you may be, yes. The request in this thread requires making
> direct use of the “generate a new valid temporary fielsystem path”
> functionality already implemented in ‘tempfile’.
>
> Implementations of that functionality outside of ‘tempfile’ are a fun
> exercise, but miss the point of this thread.

I think you have missed the point of your own thread.

You can't do what you wanted using tempfile, the only possible
answer is to choose a filename that is sufficiently random that
your hope that it is unique won't be proven futile. tempfile has
two main modes, mktemp which meets your requirements but should
never be used as it is insecure, and mkstemp which doesn't meet
your requirements because it fundamentally operates by actually
creating the file in question and relying on the filesystem to
guarantee uniqueness.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Make a unique filesystem path, without creating the file

[Chris Angelico]

On Tue, Feb 23, 2016 at 11:44 AM, Jon Ribbens
 wrote:
> On 2016-02-23, Chris Angelico  wrote:
>> On Tue, Feb 23, 2016 at 11:26 AM, Jon Ribbens
>> wrote:
>>> On 2016-02-23, Chris Angelico  wrote:
 On Tue, Feb 23, 2016 at 11:08 AM, Jon Ribbens
 wrote:
>> If you generate 2**128 + 1 such numbers, you are *guaranteed* to
>
> ... have expired due to the heat death of the universe.

 Maybe... but by the time you get to 2**64 of them, you have a 50%
 chance of a collision. (That's either utterly intuitive or completely
 counter-intuitive, depending on who you are.)
>>>
>>> Um, did you mean to say 2**127? Are you thinking of the
>>> birthday paradox or something, which doesn't apply here?
>>
>> By the time you generate 2**64 of them, you have a 50% chance that
>> some pair of them collides. Yes, the birthday paradox does apply here.
>
> Oh, I see, you're thinking of it differently. I was thinking of it as
> Alice is choosing a filename and Mallet is trying to guess it, in which
> case the birthday paradox doesn't apply. You're thinking of it as Alice
> is generating many random filenames and, even though she could avoid
> collisions with 100% certainty by remembering what she's already had,
> isn't doing so, and must avoid colliding with herself. I don't think
> your version makes has much relevance as an attack model.

Ah. Steven was talking about collisions; once you have 2**128+1 of
them, you're guaranteed a collision (pigeonhole principle). What
you're talking about gives certainty slightly sooner - specifically,
once you've tried 2**128 of them, you're guaranteed to have hit it :)

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

Re: Make a unique filesystem path, without creating the file

[Jon Ribbens]

On 2016-02-23, Chris Angelico  wrote:
> On Tue, Feb 23, 2016 at 11:26 AM, Jon Ribbens
> wrote:
>> On 2016-02-23, Chris Angelico  wrote:
>>> On Tue, Feb 23, 2016 at 11:08 AM, Jon Ribbens
>>> wrote:
> If you generate 2**128 + 1 such numbers, you are *guaranteed* to

 ... have expired due to the heat death of the universe.
>>>
>>> Maybe... but by the time you get to 2**64 of them, you have a 50%
>>> chance of a collision. (That's either utterly intuitive or completely
>>> counter-intuitive, depending on who you are.)
>>
>> Um, did you mean to say 2**127? Are you thinking of the
>> birthday paradox or something, which doesn't apply here?
>
> By the time you generate 2**64 of them, you have a 50% chance that
> some pair of them collides. Yes, the birthday paradox does apply here.

Oh, I see, you're thinking of it differently. I was thinking of it as
Alice is choosing a filename and Mallet is trying to guess it, in which
case the birthday paradox doesn't apply. You're thinking of it as Alice
is generating many random filenames and, even though she could avoid
collisions with 100% certainty by remembering what she's already had,
isn't doing so, and must avoid colliding with herself. I don't think
your version makes has much relevance as an attack model.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How the heck does async/await work in Python 3.5

[Ian Kelly]

On Mon, Feb 22, 2016 at 3:16 PM, Sven R. Kunze  wrote:
> Is something like shown in 12:50 ( cout << tcp_reader(1000).get() ) possible
> with asyncio? (tcp_reader would be async def)

loop = asyncio.get_event_loop()
print(loop.run_until_complete(tcp_reader(1000)))
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Make a unique filesystem path, without creating the file

[Steven D'Aprano]

On Tue, 23 Feb 2016 06:32 am, Marko Rauhamaa wrote:

> Jon Ribbens :
> 
>> Suppose you had code like this:
>>
>>   filename = binascii.hexlify(os.urandom(16)).decode("ascii")
>>
>> Do we really think that is insecure or that there are any practical
>> attacks against it? It would be basically the same as saying that
>> urandom() is broken, surely?
> 
> urandom() is not quite random and so should not be considered
> cryptographically airtight.
> 
> Under Linux, /dev/random is the way to go when strong security is
> needed. Note that /dev/random is a scarce resource on ordinary systems.

That's actually incorrect, but you're not the only one to have been mislead
by the man pages.

http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/


On non-Linux Unixes, the difference between urandom and random is mostly, or
entirely, gone, in favour of urandom's non-blocking behaviour. And it's a
myth that the output of random is "more random" or "more pure" than
urandom's. In reality, on Linux both urandom and random use exactly the
same CSPRNG.

See also:

http://www.2uo.de/myths-about-urandom/


for a good explanation of how random and urandom actually work on Linux.






-- 
Steven

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

Re: Make a unique filesystem path, without creating the file

[Chris Angelico]

On Tue, Feb 23, 2016 at 11:26 AM, Jon Ribbens
 wrote:
> On 2016-02-23, Chris Angelico  wrote:
>> On Tue, Feb 23, 2016 at 11:08 AM, Jon Ribbens
>> wrote:
 If you generate 2**128 + 1 such numbers, you are *guaranteed* to
>>>
>>> ... have expired due to the heat death of the universe.
>>
>> Maybe... but by the time you get to 2**64 of them, you have a 50%
>> chance of a collision. (That's either utterly intuitive or completely
>> counter-intuitive, depending on who you are.)
>
> Um, did you mean to say 2**127? Are you thinking of the
> birthday paradox or something, which doesn't apply here?

By the time you generate 2**64 of them, you have a 50% chance that
some pair of them collides. Yes, the birthday paradox does apply here.

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

Re: Make a unique filesystem path, without creating the file

[Ben Finney]

Oscar Benjamin  writes:

> What does unpredictable mean in this context? Maybe I'm reading too
> much into that...

I think you may be, yes. The request in this thread requires making
direct use of the “generate a new valid temporary fielsystem path”
functionality already implemented in ‘tempfile’.

Implementations of that functionality outside of ‘tempfile’ are a fun
exercise, but miss the point of this thread.

-- 
 \   “But Marge, what if we chose the wrong religion? Each week we |
  `\  just make God madder and madder.” —Homer, _The Simpsons_ |
_o__)  |
Ben Finney

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

Re: Make a unique filesystem path, without creating the file

[Jon Ribbens]

On 2016-02-23, Chris Angelico  wrote:
> On Tue, Feb 23, 2016 at 11:08 AM, Jon Ribbens
> wrote:
>>> If you generate 2**128 + 1 such numbers, you are *guaranteed* to
>>
>> ... have expired due to the heat death of the universe.
>
> Maybe... but by the time you get to 2**64 of them, you have a 50%
> chance of a collision. (That's either utterly intuitive or completely
> counter-intuitive, depending on who you are.)

Um, did you mean to say 2**127? Are you thinking of the
birthday paradox or something, which doesn't apply here?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Make a unique filesystem path, without creating the file

[Steven D'Aprano]

On Tue, 23 Feb 2016 05:17 am, Jon Ribbens wrote:

> On 2016-02-22, Ethan Furman  wrote:
>> On 02/14/2016 04:08 PM, Ben Finney wrote:
>>> I am unconcerned with whether there is a real filesystem entry of that
>>> name; the goal entails having no filesystem activity for this. I want a
>>> valid unique filesystem path, without touching the filesystem.
>>
>> This is impossible.  If you don't touch the file system you have no way
>> to know if the path is unique.
> 
> Weell, I have a lot of sympathy for that point, but on the other
> hand the whole concept of UUIDs ("import uuid") is predicated on the
> opposite assumption.

You're referring to uuid4, presumably, as the other varieties of UUID use
non-secret information, such as the time, or a namespace, either of which
is potentially public knowledge. 

Only uuid4 is considered "globally unique", and that's not *certainly*
globally unique, only that the chances of an *accidental* collision is
below some threshold deemed "small enough that we don't care".

Deliberate collisions of public UUIDs are *trivial*. Pick a UUID you know is
already in use, and use it again.

There's a lot of assumptions involved in the "globally unique" claim, and
there are probably ways to contrive to generate the same UUIDs as someone
else. But to what benefit? UUIDs are not intended as security tokens, and
are not hardened against attack. Even uuid4 may not be suitable for
security, since it may use a cryptographically weak PRNG such as Mersenne
Twister.



-- 
Steven

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

Re: Make a unique filesystem path, without creating the file

[Chris Angelico]

On Tue, Feb 23, 2016 at 11:08 AM, Jon Ribbens
 wrote:
> On 2016-02-22, Steven D'Aprano  wrote:
>> On Tue, 23 Feb 2016 05:48 am, Marko Rauhamaa wrote:
>>> Jon Ribbens :
 I was under the impression that the point of UUIDs is that you can be
 *so* confident that there won't be a collision that for all practical
 purposes it's indistinguishable from being certain.
>>>
>>> Yes, if you generate a random 128-bit number, it will be unique --
>>
>> If you generate a second random 128 bit number, you have a chance of 1 in
>> 2**128 of a collision. All you can say is that it will be *very probably*
>> unique. (I might even allow "almost certainly" unique.)
>
> If you are not prepared to say that something with a
> 340282366920938463463374607431768211455 /
> 340282366920938463463374607431768211456 chance of being true
> is not "certainly true" then I'm not sure how you would not
> be too scared to ever leave the house. Or not leave the house.
> I mean, you're probably going to be hit by 10^25 meteorites,
> which sounds painful.
>
>> If you generate 2**128 + 1 such numbers, you are *guaranteed* to
>
> ... have expired due to the heat death of the universe.

Maybe... but by the time you get to 2**64 of them, you have a 50%
chance of a collision. (That's either utterly intuitive or completely
counter-intuitive, depending on who you are.)

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

Re: Make a unique filesystem path, without creating the file

[Jon Ribbens]

On 2016-02-22, Steven D'Aprano  wrote:
> On Tue, 23 Feb 2016 05:48 am, Marko Rauhamaa wrote:
>> Jon Ribbens :
>>> I was under the impression that the point of UUIDs is that you can be
>>> *so* confident that there won't be a collision that for all practical
>>> purposes it's indistinguishable from being certain.
>> 
>> Yes, if you generate a random 128-bit number, it will be unique --
>
> If you generate a second random 128 bit number, you have a chance of 1 in
> 2**128 of a collision. All you can say is that it will be *very probably*
> unique. (I might even allow "almost certainly" unique.)

If you are not prepared to say that something with a
340282366920938463463374607431768211455 /
340282366920938463463374607431768211456 chance of being true
is not "certainly true" then I'm not sure how you would not
be too scared to ever leave the house. Or not leave the house.
I mean, you're probably going to be hit by 10^25 meteorites,
which sounds painful.

> If you generate 2**128 + 1 such numbers, you are *guaranteed* to

... have expired due to the heat death of the universe.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Make a unique filesystem path, without creating the file

[Jon Ribbens]

On 2016-02-23, Steven D'Aprano  wrote:
> On Tue, 23 Feb 2016 06:22 am, Jon Ribbens wrote:
>> Suppose you had code like this:
>> 
>> filename = binascii.hexlify(os.urandom(16)).decode("ascii")
>> 
>> Do we really think that is insecure or that there are any practical
>> attacks against it? It would be basically the same as saying that
>> urandom() is broken, surely?
>
> Correct. Any attack against urandom would be an attack on this. You would
> just have to trust that the kernel devs have made urandom as secure as
> possible, and pay no attention to what the man page says, as its wrong.
>
> By the way, Python 3.6 will have (once Guido formally approves it) a new
> module, "secrets", for securely generating (pseudo)random tokens like this:
>
> import secrets
> filename = secrets.token_hex(16)

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

Re: Make a unique filesystem path, without creating the file

[Steven D'Aprano]

On Tue, 23 Feb 2016 06:22 am, Jon Ribbens wrote:

> Suppose you had code like this:
> 
> filename = binascii.hexlify(os.urandom(16)).decode("ascii")
> 
> Do we really think that is insecure or that there are any practical
> attacks against it? It would be basically the same as saying that
> urandom() is broken, surely?

Correct. Any attack against urandom would be an attack on this. You would
just have to trust that the kernel devs have made urandom as secure as
possible, and pay no attention to what the man page says, as its wrong.

By the way, Python 3.6 will have (once Guido formally approves it) a new
module, "secrets", for securely generating (pseudo)random tokens like this:

import secrets
filename = secrets.token_hex(16)


https://www.python.org/dev/peps/pep-0506/




-- 
Steven

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

[issue26335] Make mmap.write return the number of bytes written like other write methods

[Berker Peksag]

Berker Peksag added the comment:

Thanks for the patch, Jakub. I don't use mmap module much so I don't have an 
opinion about the feature, but it sounds reasonable.

I left some review comments on Rietveld: http://bugs.python.org/review/26335/

--
components: +Extension Modules -IO, Library (Lib)
nosy: +berker.peksag
stage:  -> patch review

___
Python tracker 

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

Re: Make a unique filesystem path, without creating the file

[Oscar Benjamin]

On 22 Feb 2016 22:50, "Ben Finney"  wrote:
>
> Ethan Furman  writes:
>
> > On 02/14/2016 04:08 PM, Ben Finney wrote:
> >
> > > I am unconcerned with whether there is a real filesystem entry of that
> > > name; the goal entails having no filesystem activity for this. I want
a
> > > valid unique filesystem path, without touching the filesystem.
> >
> > This is impossible.  If you don't touch the file system you have no
> > way to know if the path is unique.
>
> That was unclear. Later in the same thread, I clarified that by “unique”
> I mean nothing about entries already on the filesystem. Instead it means
> “unpredictably different each time the function is called”.

What does unpredictable mean in this context? Maybe I'm reading too much
into that... What's wrong with the example I posted before?

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

Re: Make a unique filesystem path, without creating the file

[Steven D'Aprano]

On Tue, 23 Feb 2016 06:22 am, Paul Rubin wrote:

> Chris Angelico  writes:
>>> I was under the impression that the point of UUIDs is that you can be
>>> *so* confident that there won't be a collision that for all practical
>>> purposes it's indistinguishable from being certain.
>> Maybe, if everyone's cooperating. I'm not sure how they fare in the
>> face of malice though.
> 
> There are different UUID algorithms, some of which have useful syntax
> but are easy to spoof.  Uuid4 is random and implemented properly, should
> be hard to spoof.

I'm not sure what you mean by "spoof" in this context. Do you mean generate
collisions?

Do you mean "pretend to generate a UUID, but without actually doing so"?
That's how I interpret "spoof", but I don't quite understand why that would
be difficult. Here's one I just made now:

{00010203-0405-0607-0809-0a0b0c0d0e0f}

And another:

{836313e2-3b8a-53f2-9b90-0c9ade199e5d}

They weren't hard to spoof :-)


-- 
Steven

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

Re: Make a unique filesystem path, without creating the file

[Steven D'Aprano]

On Tue, 23 Feb 2016 05:48 am, Marko Rauhamaa wrote:

> Jon Ribbens :
> 
>> I was under the impression that the point of UUIDs is that you can be
>> *so* confident that there won't be a collision that for all practical
>> purposes it's indistinguishable from being certain.
> 
> Yes, if you generate a random 128-bit number, it will be unique --


If you generate a second random 128 bit number, you have a chance of 1 in
2**128 of a collision. All you can say is that it will be *very probably*
unique. (I might even allow "almost certainly" unique.)

If you generate 2**128 + 1 such numbers, you are *guaranteed* to have at
least one collision.

If I can arrange matters so that I am using the same seed as you, then I can
generate the same UUIDs as you.

If I know you are using the Mersenne Twister PRNG, and I can get hold of (by
memory) 128 consecutive UUIDs, I can reconstruct the seed you are using and
generate all future (and past) UUIDs the same as yours. (Well, when I
say "I can", I don't mean *me*, I mean some attacker who is smarter than
me, but not that much smarter.)



> unless someone clones it.
> 
> Cloning will be a practical issue when you clone virtual machines, for
> example.

This is certainly a practical issue that people have to be aware of.




-- 
Steven

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

Re: Make a unique filesystem path, without creating the file

[Paul Rubin]

Marko Rauhamaa  writes:
 http://www.2uo.de/myths-about-urandom/
>> I don't know what web pamphlet you mean,
> The only one linked above.

Oh, I wouldn't have called that a pamphlet.  I could quibble with the
writing style but the points in the article are basically correct.

> getrandom(2) is a good interface that distinguishes between the flag
> values
>0=>  /dev/urandom
>GRND_RANDOM  =>  /dev/random
>GRND_RANDOM | GRND_NONBLOCK  =>  /dev/random (O_NONBLOCK)
> However, although os.urandom() delegates to getrandom(), the
> documentation suggests it uses the flag value 0 (/dev/urandom).

Flag value 0 does the right thing and blocks if the entropy pool is not
yet initialized, and doesn't block after that.  That fixes the errors of
both urandom (fails to block before there's enough entropy) and random
(blocks even after there's enough entropy).  The getrandom doc is also
misleading about the workings of the entropy pools but that's ok.  The
actual algorithm is described here:

  http://www.pinkas.net/PAPERS/gpr06.pdf

It's pretty clumsy but discussions about replacing it have gotten bogged
down several times.  OTOH maybe I'm out of date on this.

>> The random/urandom interface was poorly designed and misleadingly
>> documented.
> It could be better I suppose, but I never found it particularly bad. The
> nice thing about it is that it is readily usable in shell scripts.

DJB describes the problems:

https://groups.google.com/forum/#!msg/randomness-generation/4opmDHA6_3w/__TyKhbnNWsJ

Regarding shell scripts, it should be a simple matter to put a wrapper
around the system call.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue26416] Deprecate the regex_v8, telco, and spectral_norm benchmarks

[Brett Cannon]

Changes by Brett Cannon :


--
keywords: +easy

___
Python tracker 

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

[issue26415] Out of memory, trying to parse a 35MB dict

[A. Skrobov]

New submission from A. Skrobov:

I have a one-line module that assigns a tuple->int dictionary:

holo_table = {(0, 0, 0, 0, 0, 0, 1, 41, 61, 66, 89): 9, (0, 0, 0, 70, 88, 98, 
103, 131, 147, 119, 93): 4, [35MB skipped], (932, 643, 499, 286, 326, 338, 279, 
200, 280, 262, 115): 5}

When I try to import this module, Python grinds 100% of my CPU for like half an 
hour, then ultimately crashes with a MemoryError.

How much memory does it need to parse 35MB of data, of a rather simple 
structure?

Attaching the module, zipped to 10MB.

--
components: Interpreter Core
files: crash.zip
messages: 260704
nosy: A. Skrobov
priority: normal
severity: normal
status: open
title: Out of memory, trying to parse a 35MB dict
type: resource usage
versions: Python 2.7
Added file: http://bugs.python.org/file42011/crash.zip

___
Python tracker 

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

[issue26416] Deprecate the regex_v8, telco, and spectral_norm benchmarks

[Brett Cannon]

New submission from Brett Cannon:

In the thread at 
https://mail.python.org/pipermail/speed/2016-February/000272.html it came up 
that the regex_v8, telco, and spectral_norm benchmarks are all very 
inconsistent. That means they should be deprecated.

--
components: Benchmarks
messages: 260705
nosy: brett.cannon, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Deprecate the regex_v8, telco, and spectral_norm benchmarks
type: enhancement

___
Python tracker 

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

Re: Make a unique filesystem path, without creating the file

[Cameron Simpson]

On 22Feb2016 12:34, Alan Bawden  wrote:

Cameron Simpson  writes:


On 16Feb2016 19:24, Alan Bawden  wrote:

So in the FIFO case, I might write something like the following:

   def make_temp_fifo(mode=0o600):
   while True:
   path = tempfile.mktemp()
   try:
   os.mkfifo(path, mode=mode)
   except FileExistsError:
   pass
   else:
   return path

So is there something wrong with the above code?  Other than the fact
that the documentation says something scary about mktemp()?


Well, it has a few shortcomings.

It relies on mkfifo reliably failing if the name exists. It shounds like
mkfifo is reliable this way, but I can imagine analogous use cases without
such a convenient core action, and your code only avoids mktemp's security
issue _because_ mkfifo has that fortuitous aspect.


I don't understand your use of the word "fortuitous" here.  mkfifo is
defined to act that way according to POSIX.  I wrote the code that way
precisely because of that property.  I sometimes write code knowing that
adding two even numbers together results in an even answer.  I suppose
you might describe that as "fortuitous", but it's just things behaving
as they are defined to behave!


I mean here that your scheme isn't adaptable to a system call which will reuse 
an existing name. Of course, mkfifo, mkdir and open(.., O_EXCL) all have this 
nice feature.



Secondly, why is your example better than::
 os.mkfifo(os.path.join(mkdtemp(), 'myfifo'))


My way is not much better, but I think it is a little better because
your way I have to worry about deleting both the file and the directory
when I am done, and I have to get the permissions right on two
filesystem objects.  (If I can use a TemporaryDirectory() context
manager, the cleaning up part does get easier.)

And it also seems wasteful to me, given that the way mkdtemp() is
implemented is to generate a possible name, try creating it, and loop if
the mkdir() call fails.  (POSIX makes the same guarantee for mkdir() as
it does for mkfifo().)  Why not just let me do an equivalent loop
myself?


Go ahead. But I think Ben's specificly trying to avoid writing his own loop.


On that basis, this example doesn't present a use case what can't be
addressed by mkstemp or mkdtemp.


Yes, if mktemp() were taken away from me, I could work around it.  I'm
just saying that in order to justify taking something like this away, it
has to be both below some threshold of utility and above some threshold
of dangerousness.  In the canonical case of gets() in C, not only is
fgets() almost a perfectly exact replacement for gets(), gets() is
insanely dangerous.  But the case of mktemp() doesn't seem to me to come
close to this combination of redundancy and danger.


You _do_ understand the security issue, yes? I sure looked like you did,
until here.


Well, it's always dangerous to say that you understand all the security
issues of anything.  In part that is why I wrote the code quoted above.
I am open to the possibility that there is a security problem here that
I haven't thought of.  But so far the only problem anybody has with it
is that you think there is something "fortuitous" about the way that it
works.


(As if that would be of any use in the
situation above!)  It looks like anxiety that some people might use
mktemp() in a stupid way has caused an over-reaction.


No, it is anxiety that mktemp's _normal_ use is inherently unsafe.


So are you saying that the way I used mktemp() above is _abnormal_?


In that you're not making a file. I mean "abnormal" in a statistical sense, and 
also in the "anticipated use case for mktemp's design". I'm not suggestioning 
you're wrong to use it like this.



[ Here I have removed some perfectly reasonable text describing the
  race condition in question -- yes I really do understand that. ]

This is neither weird nor even unlikely which is why kmtemp is strongly
discouraged - naive (and standard) use is not safe.

That you have contrived a use case where you can _carefully_ use mktemp in
safety in no way makes mktemp recommendable.


OK, so you _do_ seem to be saying that I have used mktemp() in a
"contrived" and "non-standard" (and "non-naive"!) way.  I'm genuinely
surprised.  I though I was just writing straightforward correct code and
demonstrating that this was a useful utility that it was not hard to use
safely.  You seem to think what I did is something that ordinary
programmers can not be expected to do.  Your judgement is definitely
different from mine!


No, I meant only that (a) mktemp is normally used for regular files and (b) 
that mkdtemp()/mkfifo() present equivalent results without hand making a 
pick-a-name loop. Of course any programmer should be able to read the mktemp() 
spec and built from it.



And ultimately this does all boil down to making judgements.  It does
make sense to remove things from libraries that 

[issue26414] os.defpath too permissive

[Guido van Rossum]

Changes by Guido van Rossum :


--
nosy: +gvanrossum

___
Python tracker 

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

[issue26414] os.defpath too permissive

[Danek Duvall]

Changes by Danek Duvall :


--
nosy: +dhduvall

___
Python tracker 

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

Re: Make a unique filesystem path, without creating the file

[Ethan Furman]

On 02/22/2016 02:25 PM, Cameron Simpson wrote:

On 22Feb2016 10:11, Ethan Furman  wrote:

On 02/14/2016 04:08 PM, Ben Finney wrote:


I am unconcerned with whether there is a real filesystem entry of that
name; the goal entails having no filesystem activity for this. I want a
valid unique filesystem path, without touching the filesystem.


This is impossible.  If you don't touch the file system you have no
way to know if the path is unique.


I think Ben wants to avoid filesystem modification (let us ignore atime
here). So one can read the filesystem to see what is current, but he
does not want to actually make any new filesystem entry.


Hmm -- well, he says "the goal entails having no filesystem activity for 
this", and seeing what already exists definitely requires file system 
activity . . .


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

[issue26414] os.defpath too permissive

[John Beck]

New submission from John Beck:

A bug has been filed against Solaris' internal version of Python, which is
largely the same (including in this case) as the base version we get from
python.org.  The bug is that os.defpath starts with ':' and thus any Python
script run with a null PATH environment variable will use the current
working directory as its first entry.  This is generally considered to
be bad practice, and especially dangerous for anyone running with root
privileges on a Unix box.  So we intend to change Solaris' version of
Python to elide this, i.e., to apply the attached patch to our 2.7 version
and comparable patches to our 3.4 and 3.5 versions

As a precaution, I queried the security list before filing this bug, asking:

* Is this intentional?  (Seems like it but I couldn't find any documentation
  to confirm.)
* If so, why?  (Feel free to point me to any docs I missed.)
* If it is intentional, and we were to change our version anyway, do you know
  of any gotchas we should look out for?  There were no regressions when I
  ran the Python test suite.

and got the following reply:

---
From: Guido van Rossum 
Date: Sat, 20 Feb 2016 09:29:11 -0800
Subject: Re: [PSRT] os.defpath too permissive

Wow. That looks like something really old. I think you can just file
an issue with a patch for this at bugs.python.org. I agree that it
should be fixed. I don't think there are many users that would be
vulnerable, nor do I think that much code would break; the only use in
the stdlib has os.environ.get("PATH", os.defpath) so in all practical
cases it would get the user's $PATH variable (which is presumably
safe) anyway.
---

So I am now filing this bug as suggested.

--
components: Library (Lib)
files: 2.7-defpath.patch
keywords: patch
messages: 260703
nosy: jbeck
priority: normal
severity: normal
status: open
title: os.defpath too permissive
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42010/2.7-defpath.patch

___
Python tracker 

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

Re: Make a unique filesystem path, without creating the file

[Ben Finney]

Ethan Furman  writes:

> On 02/14/2016 04:08 PM, Ben Finney wrote:
>
> > I am unconcerned with whether there is a real filesystem entry of that
> > name; the goal entails having no filesystem activity for this. I want a
> > valid unique filesystem path, without touching the filesystem.
>
> This is impossible.  If you don't touch the file system you have no
> way to know if the path is unique.

That was unclear. Later in the same thread, I clarified that by “unique”
I mean nothing about entries already on the filesystem. Instead it means
“unpredictably different each time the function is called”.

-- 
 \  “It is difficult to get a man to understand something when his |
  `\   salary depends upon his not understanding it.” —Upton Sinclair, |
_o__) 1935 |
Ben Finney

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

Re: Make a unique filesystem path, without creating the file

[Cameron Simpson]

On 22Feb2016 10:11, Ethan Furman  wrote:

On 02/14/2016 04:08 PM, Ben Finney wrote:


I am unconcerned with whether there is a real filesystem entry of that
name; the goal entails having no filesystem activity for this. I want a
valid unique filesystem path, without touching the filesystem.


This is impossible.  If you don't touch the file system you have no way to 
know if the path is unique.


I think Ben wants to avoid filesystem modification (let us ignore atime here).  
So one can read the filesystem to see what is current, but he does not want to 
actually make any new filesystem entry. 


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

[issue26366] Use “.. versionadded” over “.. versionchanged” where appropriate

[Fred L. Drake, Jr.]

Fred L. Drake, Jr. added the comment:

If no one is planning to propose specific new markup for more fine-grained 
version annotations, this issue can be closed.

--

___
Python tracker 

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

Re: How the heck does async/await work in Python 3.5

[Sven R. Kunze]

On 20.02.2016 07:53, Christian Gollwitzer wrote:
If you have difficulties wit hthe overall concept, and if you are open 
to discussions in another language, take a look at this video:


https://channel9.msdn.com/Shows/C9-GoingNative/GoingNative-39-await-co-routines 



MS has added coroutine support with very similar syntax to VC++ 
recently, and the developer tries to explain it to the "stackful" 
programmers.


Thanks, Christian. Very informative video.

Is something like shown in 12:50 ( cout << tcp_reader(1000).get() ) 
possible with asyncio? (tcp_reader would be async def)



Best,
Sven
--
https://mail.python.org/mailman/listinfo/python-list

[issue26413] python 3.5.1 uses wrong registry in system-wide installation

[Eryk Sun]

Changes by Eryk Sun :


--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Windows AllUsers installation places uninstaller in user profile

___
Python tracker 

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

[issue26388] Disabling changing sys.argv[0] with runpy.run_module(...alter_sys=True)

[Mike Kaplinskiy]

Mike Kaplinskiy added the comment:

Looks like by signed CLA just made it through, so that should be settled.

For the other bugs, it seems that overloading run_module & run_path seems to be 
getting a bit cumbersome, so it might make sense to have some sort of Runner 
object that has things like `Runner(module=..., code=..., path=...)` and then 
has properties like `argv = ...`, `module_dict = ...` and maybe attributes for 
the loader and the filepath. "Advanced" usage can use that over the vanilla 
run_module & run_path.

Either way, I think that's outside the scope of this change. Unfortunately this 
is already shaving a yak for me 
(https://github.com/facebook/buck/pull/651#issuecomment-185030156) and I'd 
rather not go deeper.

--

___
Python tracker 

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

[issue26413] python 3.5.1 uses wrong registry in system-wide installation

[Mike]

New submission from Mike:

The installer for python 3.5.1 (observed with the x64-86 executable installer, 
assumed to happen with all installers) allows users to install python either 
just for themselves or do a system-wide installation (provided they have 
sufficient privileges).

However, when selecting a system-wide installation, the uninstall information 
is registered to a key under HKEY_CURRENT_USER.

The result of this is that any user can run python 3.5.1; however, the entry in 
the "uninstall programs" list shows only for the original user that installed 
it.

This is in contrast to previous versions of python (e.g. 3.4.4) where any user 
could uninstall it (provided they have sufficient privileges). It is also in 
contrast to pylauncher of the same version (i.e. 3.5.1) which properly 
registers itself under HKEY_LOCAL_MACHINE when selected to be installed for all 
users.

The key in question is at this path:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall\{b8440650-9dbe-4b7d-8167-6e0e3dcdf5d0}

I believe it should be here:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall\{b8440650-9dbe-4b7d-8167-6e0e3dcdf5d0}

--
components: Installation
messages: 260700
nosy: mray
priority: normal
severity: normal
status: open
title: python 3.5.1 uses wrong registry in system-wide installation
type: behavior
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: Considering migrating to Python from Visual Basic 6 for engineering applications

[Gregory Ewing]

BartC wrote:
Our system must have been more advanced then, or designed for training. 
We used a time-sharing 'dec-system 10' and it was usually accessed via 
interactive terminals, either teletypes or the odd VDU.


According to Wikipedia the first interactive version of
Dartmouth BASIC appeared in 1964:

https://en.wikipedia.org/wiki/Dartmouth_BASIC

Also, the *very* earliest computer systems were all
interactive -- you sat in front of a panel flipping
switches and reading lights!

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

Re: Make a unique filesystem path, without creating the file

[Marko Rauhamaa]

Paul Rubin :

>>> http://www.2uo.de/myths-about-urandom/
>> Did you post the link because you agreed with the Web pamphlet?
>
> I don't know what web pamphlet you mean,

The only one linked above.

Cryptography is tricky business, indeed. I know enough about it not to
improvise too much. Infinitesimal weaknesses can make a difference
between feasible and unfeasible attacks.

> but the right thing to use now is getrandom(2).

getrandom(2) is a good interface that distinguishes between the flag
values

   0=>  /dev/urandom
   GRND_RANDOM  =>  /dev/random
   GRND_RANDOM | GRND_NONBLOCK  =>  /dev/random (O_NONBLOCK)

However, although os.urandom() delegates to getrandom(), the
documentation suggests it uses the flag value 0 (/dev/urandom).

> The random/urandom interface was poorly designed and misleadingly
> documented.

It could be better I suppose, but I never found it particularly bad. The
nice thing about it is that it is readily usable in shell scripts.


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

Re: Make a unique filesystem path, without creating the file

[Paul Rubin]

Marko Rauhamaa  writes:
>> http://www.2uo.de/myths-about-urandom/
> Did you post the link because you agreed with the Web pamphlet?

I don't know what web pamphlet you mean, but the right thing to use now
is getrandom(2).  The random/urandom interface was poorly designed and
misleadingly documented.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue26403] Catch FileNotFoundError in socketserver.DatagramRequestHandler

[desbma]

Changes by desbma :


--
title: Don't call sendto in socketserver.DatagramRequestHandler if there is 
nothing to send -> Catch FileNotFoundError in 
socketserver.DatagramRequestHandler

___
Python tracker 

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

[issue26403] Don't call sendto in socketserver.DatagramRequestHandler if there is nothing to send

[desbma]

desbma added the comment:

OK, so first part of this issue (sendto called even if no data has been 
written) is indeed a duplicate of https://bugs.python.org/issue1767511 sorry 
for that.

For the second part of the issue (the exception not silenced), I have attached 
a new patch.

--
Added file: http://bugs.python.org/file42009/issue26403_v2.patch

___
Python tracker 

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

Re: Make a unique filesystem path, without creating the file

[Marko Rauhamaa]

Random832 :

> On Mon, Feb 22, 2016, at 14:32, Marko Rauhamaa wrote:
>> urandom() is not quite random and so should not be considered
>> cryptographically airtight.
>> 
>> Under Linux, /dev/random is the way to go when strong security is
>> needed. Note that /dev/random is a scarce resource on ordinary
>> systems.
>
> http://www.2uo.de/myths-about-urandom/

Did you post the link because you agreed with the Web pamphlet?


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

[issue1767511] SocketServer.DatagramRequestHandler with empty response

[desbma]

Changes by desbma :


--
nosy: +desbma

___
Python tracker 

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

[issue26377] Tkinter dialogs will not close if root window not packed.

[Sam Yeager]

Sam Yeager added the comment:

Updated script with the adding 'parent-Rootwin' to messagebox() arguments. The 
issue persists.

Following advice in #26376:
Ran script on Terminal. The issue disappears, and everything works normally.
Running through IDLE, the issue returns.

--

___
Python tracker 

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

[issue26376] Tkinter root window won't close if packed.

[Sam Yeager]

Sam Yeager added the comment:

Ran script on Terminal. The issue disappears, and everything works normally.

Running through IDLE, the issue returns. Sorry, Terry.

--

___
Python tracker 

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

Re: Make a unique filesystem path, without creating the file

[Random832]

On Mon, Feb 22, 2016, at 14:32, Marko Rauhamaa wrote:
> urandom() is not quite random and so should not be considered
> cryptographically airtight.
> 
> Under Linux, /dev/random is the way to go when strong security is
> needed. Note that /dev/random is a scarce resource on ordinary systems.

http://www.2uo.de/myths-about-urandom/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Make a unique filesystem path, without creating the file

[Chris Angelico]

On Tue, Feb 23, 2016 at 6:22 AM, Jon Ribbens
 wrote:
>> Maybe, if everyone's cooperating. I'm not sure how they fare in the
>> face of malice though.
>
> Suppose you had code like this:
>
>   filename = binascii.hexlify(os.urandom(16)).decode("ascii")
>
> Do we really think that is insecure or that there are any practical
> attacks against it? It would be basically the same as saying that
> urandom() is broken, surely?

Sure, that would be safe. But UUIDs aren't necessarily based on "give
me sixteen bytes from urandom". They can involve
potentially-predictable information such as MAC addresses, current
time of day, and so on, which gives them significantly less
randomness. In that kind of usage, they're not intended to be
cryptographically secure.

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

Re: Make a unique filesystem path, without creating the file

[Marko Rauhamaa]

Jon Ribbens :

> Suppose you had code like this:
>
>   filename = binascii.hexlify(os.urandom(16)).decode("ascii")
>
> Do we really think that is insecure or that there are any practical
> attacks against it? It would be basically the same as saying that
> urandom() is broken, surely?

urandom() is not quite random and so should not be considered
cryptographically airtight.

Under Linux, /dev/random is the way to go when strong security is
needed. Note that /dev/random is a scarce resource on ordinary systems.


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

Re: Make a unique filesystem path, without creating the file

[Jon Ribbens]

On 2016-02-22, Chris Angelico  wrote:
> On Tue, Feb 23, 2016 at 5:39 AM, Jon Ribbens
> wrote:
>> On 2016-02-22, Chris Angelico  wrote:
>>> On Tue, Feb 23, 2016 at 5:17 AM, Jon Ribbens
>>> wrote:
 Weell, I have a lot of sympathy for that point, but on the other
 hand the whole concept of UUIDs ("import uuid") is predicated on the
 opposite assumption.
>>>
>>> Not quite opposite. Ethan is asserting that you cannot be *certain*
>>> without actually checking the FS; the point of UUIDs is that you can
>>> be fairly *confident* that there won't be a collision. There is a
>>> nonzero probability of accidental collisions, and if an attacker is
>>> deliberately trying to _force_ a collision, it's most definitely
>>> possible. So both views are correct.
>>
>> I was under the impression that the point of UUIDs is that you can be
>> *so* confident that there won't be a collision that for all practical
>> purposes it's indistinguishable from being certain.
>
> Maybe, if everyone's cooperating. I'm not sure how they fare in the
> face of malice though.

Suppose you had code like this:

  filename = binascii.hexlify(os.urandom(16)).decode("ascii")

Do we really think that is insecure or that there are any practical
attacks against it? It would be basically the same as saying that
urandom() is broken, surely?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Make a unique filesystem path, without creating the file

[Paul Rubin]

Chris Angelico  writes:
>> I was under the impression that the point of UUIDs is that you can be
>> *so* confident that there won't be a collision that for all practical
>> purposes it's indistinguishable from being certain.
> Maybe, if everyone's cooperating. I'm not sure how they fare in the
> face of malice though.

There are different UUID algorithms, some of which have useful syntax
but are easy to spoof.  Uuid4 is random and implemented properly, should
be hard to spoof.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: 0x80070570-The file or directory is corrupted and unreadable

[felipe . gomez . rojas]

El martes, 22 de diciembre de 2015, 13:46:01 (UTC-3), eryk sun  escribió:
> On Tue, Dec 22, 2015 at 8:02 AM, muizz hasan  wrote:
> > Hi there! I've been recently trying to install Python for Windows 10
> > and I've been encountering some issues. Every time i try to install
> > the program it just says"0x80070570-The file or directory is corrupted
> > and unreadable". I have attached my log file and i hope that you guys
> > might enlighten me on how to solve my problem. Thank you!
> 
> Try downloading a new copy of the installer. Clear your browser cache first.

Thank you!! this was usefull!!

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

Re: Make a unique filesystem path, without creating the file

[Chris Angelico]

On Tue, Feb 23, 2016 at 5:39 AM, Jon Ribbens
 wrote:
> On 2016-02-22, Chris Angelico  wrote:
>> On Tue, Feb 23, 2016 at 5:17 AM, Jon Ribbens
>> wrote:
>>> Weell, I have a lot of sympathy for that point, but on the other
>>> hand the whole concept of UUIDs ("import uuid") is predicated on the
>>> opposite assumption.
>>
>> Not quite opposite. Ethan is asserting that you cannot be *certain*
>> without actually checking the FS; the point of UUIDs is that you can
>> be fairly *confident* that there won't be a collision. There is a
>> nonzero probability of accidental collisions, and if an attacker is
>> deliberately trying to _force_ a collision, it's most definitely
>> possible. So both views are correct.
>
> I was under the impression that the point of UUIDs is that you can be
> *so* confident that there won't be a collision that for all practical
> purposes it's indistinguishable from being certain.

Maybe, if everyone's cooperating. I'm not sure how they fare in the
face of malice though.

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

Re: PyPDF2 merge / out of memory

[cpoline95]

Le dimanche 21 février 2016 11:42:33 UTC+1, cpol...@gmail.com a écrit :
> Hello,
> 
> There is an issue with PyPDF2 and merging file
> https://github.com/mstamy2/PyPDF2/issues/189
> 
> Does anybody know an alternate library to merge PDF and produce optimized pdf 
> file ?
> 
> Thanks a lot
> 
> Clement

Thanks Mark, I'll dig these tools.
Regards,

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

Re: Make a unique filesystem path, without creating the file

[Marko Rauhamaa]

Jon Ribbens :

> I was under the impression that the point of UUIDs is that you can be
> *so* confident that there won't be a collision that for all practical
> purposes it's indistinguishable from being certain.

Yes, if you generate a random 128-bit number, it will be unique --
unless someone clones it.

Cloning will be a practical issue when you clone virtual machines, for
example.


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

Re: Make a unique filesystem path, without creating the file

[Jon Ribbens]

On 2016-02-22, Chris Angelico  wrote:
> On Tue, Feb 23, 2016 at 5:17 AM, Jon Ribbens
> wrote:
>> Weell, I have a lot of sympathy for that point, but on the other
>> hand the whole concept of UUIDs ("import uuid") is predicated on the
>> opposite assumption.
>
> Not quite opposite. Ethan is asserting that you cannot be *certain*
> without actually checking the FS; the point of UUIDs is that you can
> be fairly *confident* that there won't be a collision. There is a
> nonzero probability of accidental collisions, and if an attacker is
> deliberately trying to _force_ a collision, it's most definitely
> possible. So both views are correct.

I was under the impression that the point of UUIDs is that you can be
*so* confident that there won't be a collision that for all practical
purposes it's indistinguishable from being certain.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue26404] socketserver context manager

[Aviv Palivoda]

Aviv Palivoda added the comment:

Only closing the server :).
1. Did the changes requested in the CR.
2. Changed the example's in xmlrpc.server, http.server to use context manager.
3. Changed the xmlrpc.server, http.server server implementation when running 
python -m {xmlrpc.server, http.server} to use context manager.

--
Added file: http://bugs.python.org/file42008/socketserver_context_manager2.patch

___
Python tracker 

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

Re: Make a unique filesystem path, without creating the file

[Jon Ribbens]

On 2016-02-22, Ethan Furman  wrote:
> On 02/14/2016 04:08 PM, Ben Finney wrote:
>> I am unconcerned with whether there is a real filesystem entry of that
>> name; the goal entails having no filesystem activity for this. I want a
>> valid unique filesystem path, without touching the filesystem.
>
> This is impossible.  If you don't touch the file system you have no way 
> to know if the path is unique.

Weell, I have a lot of sympathy for that point, but on the other
hand the whole concept of UUIDs ("import uuid") is predicated on the
opposite assumption.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Make a unique filesystem path, without creating the file

[Chris Angelico]

On Tue, Feb 23, 2016 at 5:17 AM, Jon Ribbens
 wrote:
> On 2016-02-22, Ethan Furman  wrote:
>> On 02/14/2016 04:08 PM, Ben Finney wrote:
>>> I am unconcerned with whether there is a real filesystem entry of that
>>> name; the goal entails having no filesystem activity for this. I want a
>>> valid unique filesystem path, without touching the filesystem.
>>
>> This is impossible.  If you don't touch the file system you have no way
>> to know if the path is unique.
>
> Weell, I have a lot of sympathy for that point, but on the other
> hand the whole concept of UUIDs ("import uuid") is predicated on the
> opposite assumption.

Not quite opposite. Ethan is asserting that you cannot be *certain*
without actually checking the FS; the point of UUIDs is that you can
be fairly *confident* that there won't be a collision. There is a
nonzero probability of accidental collisions, and if an attacker is
deliberately trying to _force_ a collision, it's most definitely
possible. So both views are correct.

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

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

[Alessandro Cucci]

Alessandro Cucci added the comment:

New patch after @martin.panter comments on Rietveld. I left only this:

- ``'milliseconds'``: Append the hours, minutes, seconds and milliseconds.

> vadmium 2016/02/21 23:30:20
> I think this should explain that fractions are truncated to zero, never 
> rounded
> up. At least for fractions of milliseconds, although this could apply 
> to the
> other options as well.

I think is quite obvious that a datetime.now() can't be rounded to the future 
if microseconds are 999500.

--
Added file: http://bugs.python.org/file42007/issue19475_v15.patch

___
Python tracker 

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

Re: Make a unique filesystem path, without creating the file

[Ethan Furman]

On 02/14/2016 04:08 PM, Ben Finney wrote:


I am unconcerned with whether there is a real filesystem entry of that
name; the goal entails having no filesystem activity for this. I want a
valid unique filesystem path, without touching the filesystem.


This is impossible.  If you don't touch the file system you have no way 
to know if the path is unique.


--
~Ethan~

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

[issue25136] Python doesn't find Xcode 7 stub libraries

[Brett Cannon]

Brett Cannon added the comment:

We should update the devguide to specify that the command-line tools need to be 
installed and either explain or point to documentation on how to install the 
tools.

--
nosy: +brett.cannon

___
Python tracker 

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

[issue15216] Support setting the encoding on a text stream after creation

[Andrei Dorian Duma]

Changes by Andrei Dorian Duma :


--
nosy:  -andrei.duma

___
Python tracker 

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

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

[Andrei Dorian Duma]

Changes by Andrei Dorian Duma :


--
nosy:  -andrei.duma

___
Python tracker 

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

[issue26411] Suggestion concerning compile-time warnings

[Brett Cannon]

Changes by Brett Cannon :


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

___
Python tracker 

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

[issue25801] ResourceWarning in test_zipfile64

[SilentGhost]

Changes by SilentGhost :


--
status: open -> languishing

___
Python tracker 

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

[issue26405] tkinter askopenfilename doubleclick issue on windows

[SilentGhost]

Changes by SilentGhost :


--
components: +Windows
nosy: +gpolo, paul.moore, serhiy.storchaka, steve.dower, tim.golden, zach.ware

___
Python tracker 

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

[issue26411] Suggestion concerning compile-time warnings

[SilentGhost]

Changes by SilentGhost :


--
nosy: +benjamin.peterson, brett.cannon, georg.brandl, ncoghlan, yselivanov

___
Python tracker 

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

[issue25910] Fixing links in documentation

[SilentGhost]

Changes by SilentGhost :


--
status: open -> languishing

___
Python tracker 

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

[issue26281] Clear sys.path_importer_cache from importlib.invalidate_caches()

[Brett Cannon]

Brett Cannon added the comment:

Sorry, this has not been decided upon yet. Since it's a change in semantics 
either I just need to make a decision or convince someone else to provide an 
opinion as to whether this change makes sense.

--

___
Python tracker 

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

Re: Make a unique filesystem path, without creating the file

[Alan Bawden]

Cameron Simpson  writes:

> On 16Feb2016 19:24, Alan Bawden  wrote:
>>So in the FIFO case, I might write something like the following:
>>
>>def make_temp_fifo(mode=0o600):
>>while True:
>>path = tempfile.mktemp()
>>try:
>>os.mkfifo(path, mode=mode)
>>except FileExistsError:
>>pass
>>else:
>>return path
>>
>>So is there something wrong with the above code?  Other than the fact
>>that the documentation says something scary about mktemp()?
>
> Well, it has a few shortcomings.
>
> It relies on mkfifo reliably failing if the name exists. It shounds like
> mkfifo is reliable this way, but I can imagine analogous use cases without
> such a convenient core action, and your code only avoids mktemp's security
> issue _because_ mkfifo has that fortuitous aspect.

I don't understand your use of the word "fortuitous" here.  mkfifo is
defined to act that way according to POSIX.  I wrote the code that way
precisely because of that property.  I sometimes write code knowing that
adding two even numbers together results in an even answer.  I suppose
you might describe that as "fortuitous", but it's just things behaving
as they are defined to behave!

> Secondly, why is your example better than::
>
>  os.mkfifo(os.path.join(mkdtemp(), 'myfifo'))

My way is not much better, but I think it is a little better because
your way I have to worry about deleting both the file and the directory
when I am done, and I have to get the permissions right on two
filesystem objects.  (If I can use a TemporaryDirectory() context
manager, the cleaning up part does get easier.)

And it also seems wasteful to me, given that the way mkdtemp() is
implemented is to generate a possible name, try creating it, and loop if
the mkdir() call fails.  (POSIX makes the same guarantee for mkdir() as
it does for mkfifo().)  Why not just let me do an equivalent loop
myself?

> On that basis, this example doesn't present a use case what can't be
> addressed by mkstemp or mkdtemp.

Yes, if mktemp() were taken away from me, I could work around it.  I'm
just saying that in order to justify taking something like this away, it
has to be both below some threshold of utility and above some threshold
of dangerousness.  In the canonical case of gets() in C, not only is
fgets() almost a perfectly exact replacement for gets(), gets() is
insanely dangerous.  But the case of mktemp() doesn't seem to me to come
close to this combination of redundancy and danger.

> You _do_ understand the security issue, yes? I sure looked like you did,
> until here.

Well, it's always dangerous to say that you understand all the security
issues of anything.  In part that is why I wrote the code quoted above.
I am open to the possibility that there is a security problem here that
I haven't thought of.  But so far the only problem anybody has with it
is that you think there is something "fortuitous" about the way that it
works.

>>(As if that would be of any use in the
>>situation above!)  It looks like anxiety that some people might use
>>mktemp() in a stupid way has caused an over-reaction.
>
> No, it is anxiety that mktemp's _normal_ use is inherently unsafe.

So are you saying that the way I used mktemp() above is _abnormal_?

> [ Here I have removed some perfectly reasonable text describing the
>   race condition in question -- yes I really do understand that. ]
>
> This is neither weird nor even unlikely which is why kmtemp is strongly
> discouraged - naive (and standard) use is not safe.
>
> That you have contrived a use case where you can _carefully_ use mktemp in
> safety in no way makes mktemp recommendable.

OK, so you _do_ seem to be saying that I have used mktemp() in a
"contrived" and "non-standard" (and "non-naive"!) way.  I'm genuinely
surprised.  I though I was just writing straightforward correct code and
demonstrating that this was a useful utility that it was not hard to use
safely.  You seem to think what I did is something that ordinary
programmers can not be expected to do.  Your judgement is definitely
different from mine!

And ultimately this does all boil down to making judgements.  It does
make sense to remove things from libraries that are safety hazards (like
gets() in C), I'm just trying to argue that mktemp() isn't nearly
dangerous enough to deserve more than a warning in its documentation.
You don't agree.  Oh well...

Up until this point, you haven't said anything that I actually think is
flat out wrong, we just disagree about what tools it is reasonable to
take away from _all_ programmers just because _some_ programmers might
use them to make a mess.

> In fact your use case isn't safe, because _another_ task using mktemp
> in conflict as a plain old temporary file may grab your fifo.

But here in very last sentence I really must disagree.  If the code I
wrote above is "unsafe" because some _other_ process might be 

[issue26412] Segmentation Fault: 11

[Christian Heimes]

Christian Heimes added the comment:

pysodium is not part of Python's standard library. Please report 3rd party bugs 
in the project's bug tracker.

--
nosy: +christian.heimes
resolution:  -> third party
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue26412] Segmentation Fault: 11

[Payden Comer]

New submission from Payden Comer:

A "Segmentation Fault:11" crash occurs on OS X El Captain when using `return 
pysodium.sodium.crypto_box_beforenm(clientpub, serverprivatekey)`, with args as 
None, serverprivatekey, rather than a traceback dissallowing a NoneType 
Argument.

Crash Log attached.

--
components: Macintosh
files: Python_2016-02-22-110201_Shuros-MacBook-Pro.crash
messages: 260690
nosy: ned.deily, ronaldoussoren, thecheater887
priority: normal
severity: normal
status: open
title: Segmentation Fault: 11
type: crash
versions: Python 2.7
Added file: 
http://bugs.python.org/file42006/Python_2016-02-22-110201_Shuros-MacBook-Pro.crash

___
Python tracker 

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

[issue26281] Clear sys.path_importer_cache from importlib.invalidate_caches()

[Anish Shah]

Anish Shah added the comment:

Hi Brett, I'm looking for some issues to solve. Is this issue confirmed? Can I 
work on this?

--

___
Python tracker 

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

[issue26396] Create json.JSONType

[Anish Shah]

Changes by Anish Shah :


--
nosy: +anish.shah

___
Python tracker 

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

[issue22234] urllib.parse.urlparse accepts any falsy value as an url

[Anish Shah]

Changes by Anish Shah :


--
nosy: +anish.shah

___
Python tracker 

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

[issue26408] pep-8 requires a few corrections

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

On Feb 22, 2016, at 02:20 PM, Georg Brandl wrote:

>Georg Brandl added the comment:
>
>-Consistency within one module or function is most important.
>+Consistency within one module or function is the most important.
>
>You left out "thing" from the patch; is that intended?

Yes.

--

___
Python tracker 

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

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[BartC]

On 22/02/2016 10:46, Steven D'Aprano wrote:

On Mon, 22 Feb 2016 08:52 am, Jussi Piitulainen wrote:


BartC writes:



IIRC, the first programming exercise I ever did (in 1976 using Algol
60) involved reading 3 numbers from the teletype and working out if
those could form sides of a triangle.


That was a lousy user interface even then - an inflexible user
interaction without even a possibility of handling errors interactively?
Command line arguments would have been better (if available, that is).


Jussi, I think you have an inflated expectation of what was available in
1976. Command line? What's that? Programs ran in batch mode,
and 'interactive' meant that you could easily slip out one punched card,
replace it with a different one, and run the program again.


Our system must have been more advanced then, or designed for training. 
We used a time-sharing 'dec-system 10' and it was usually accessed via 
interactive terminals, either teletypes or the odd VDU.


It still supported punched cards but that was more because they were 
still being used in the real world.


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

[issue26410] "incompatible pointer type" while compiling Python3.5.1

[STINNER Victor]

STINNER Victor added the comment:

This issue is a duplicate of the issue #26161, waybe we can backport the 
changeset ff68ffcc6244 to the Python 3.5 branch.

--
nosy: +haypo

___
Python tracker 

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

Re: avoid for loop calling Generator function

[Ian Kelly]

On Mon, Feb 22, 2016 at 8:38 AM, Arshpreet Singh  wrote:
> On Monday, 22 February 2016 19:05:24 UTC+5:30, Peter Otten  wrote:
>> or the slightly less convoluted
>>
>> sys.stdout.writelines(map("{}\n".format, read_pdf("book.pdf")))
>
> Actually I am using this function in Android App which is being built
using Kivy, Where I am returning whole text into a file, So what you think
will be more efficient way?

Profile them and find out, but I don't think you'll find the difference is
great enough to be overly concerned with. Pick the way that is more
readable and doesn't introduce any gross inefficiencies (such as
concatenating strings in a loop).

> But when I am calling pdf_read() from nother function to avoid for loop
why it is not working?
> say:
>
> def hello()
> yield from read_pdf('book.pdf')

This uses yield from, which makes it a generator function.

>
> print(hello()) # still returns memory location instead of text. If I am
not wrong yield from can be used to avoid for loop?

hello is a generator function, so calling it just creates a generator
object. Printing it then prints out the repr of that generator object,
which is just something like .

Notably, you haven't actually *executed* the generator object, which would
require iterating over it, e.g.:

for i in hello():
print(i)

So you haven't actually avoided creating a for loop; you've just added a
redundant layer between the for loop and the thing it's actually iterating
over.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: avoid for loop calling Generator function

[Chris Angelico]

On Tue, Feb 23, 2016 at 2:38 AM, Arshpreet Singh  wrote:
>> next(filter(print, read_pdf("book.pdf")), None)
>
> Why we are w=using filter here?

It's a beautiful hack. It'll filter according to the "print"
predicate, which always returns None, and will thus filter everything
out. One single call to next() will thus process and print the entire
PDF, and then - since it has a second parameter - return None instead
of raising StopIteration.

Or maybe it's a gross and ugly hack, with the exact same description.

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

[issue26395] asyncio does not support yielding from recvfrom (socket/udp)

[Simon Bernier St-Pierre]

Changes by Simon Bernier St-Pierre :


--
status: open -> closed

___
Python tracker 

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

Re: avoid for loop calling Generator function

[Arshpreet Singh]

On Monday, 22 February 2016 19:05:24 UTC+5:30, Peter Otten  wrote:
> Arshpreet Singh wrote:
> 
> > Hi, I am converting PDF into text file, I am using following code.
> > 
> > from pypdf2 import PdfFileReader
> > 
> > def read_pdf(pdfFileName):
> > 
> > pdf = PdfFileReader(pdfFileName)
> > 
> > yield from (pg.extractText() for pg in pdf.pages)
> > 
> > for i in read_pdf('book.pdf'):
> >  print(i)
> > 
> > I want to avoid for loop , I also tried to create another function and
> > call read_pdf() inside that new function using yield from but I think I am
> > missing real picture here
> 
> While it is possible to replace the loop with
> 
> next(filter(print, read_pdf("book.pdf")), None)

Why we are w=using filter here?
 
> or the slightly less convoluted
> 
> sys.stdout.writelines(map("{}\n".format, read_pdf("book.pdf")))

Actually I am using this function in Android App which is being built using 
Kivy, Where I am returning whole text into a file, So what you think will be 
more efficient way? 

> the for loop is the obvious and therefore recommended solution. Personally, 
> I would also replace
> 
> > yield from (pg.extractText() for pg in pdf.pages)
> 
> with the good old
> 
> for pg in pdf.pages:
> yield pg.extractText()
> 
> and reserve the generator expression for occasions where it has a 
> demonstrable advantage in readability.
But when I am calling pdf_read() from nother function to avoid for loop why it 
is not working?
say:

def hello()
yield from read_pdf('book.pdf')

print(hello()) # still returns memory location instead of text. If I am not 
wrong yield from can be used to avoid for loop? 
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue26411] Suggestion concerning compile-time warnings

[Devyn Johnson]

New submission from Devyn Johnson:

I understand that compile-time warnings can typically be ignored. However, from 
my experience with programming (C STD-2011, for instance), "weird bugs", 
non-easily-replicable bugs, and odd behaviors disappear when warnings like this 
are fixed. I also understand that it will be time-consuming to fix each and 
every minor warning.

I have also noticed (in my own coding-projects) that fixing all warnings 
generated by -Wextra (and the many other warning flags) allows the compiler to 
more easily apply various optimizations.

--
components: Interpreter Core
messages: 260686
nosy: Devyn Johnson
priority: normal
severity: normal
status: open
title: Suggestion concerning compile-time warnings
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

[issue26410] "incompatible pointer type" while compiling Python3.5.1

[Devyn Johnson]

New submission from Devyn Johnson:

When compiling Python3.5.1 on Ubuntu 15.10 (64-bit), I see three "incompatible 
pointer type" warnings (copy-pasted below). I understand that they can be 
ignored. However, from my experience with programming (in C STD-2011), "weird 
bugs" and other odd behavior disappears when warnings like this are fixed.

Environment flags (such as CFLAGS) and the configure settings do not appear to 
influence that warning (i.e. my settings are irrelevant to this bug report).

I hope that this bug report is found to be helpful. Also, thank you 
Python-developers for making and maintaining Python as open-source software.

Python/ceval_gil.h: In function drop_gil:
Python/ceval_gil.h:181:9: warning: initialization from incompatible pointer 
type [-Wincompatible-pointer-types]
 _Py_atomic_store_relaxed(_last_holder, tstate);
 ^
Python/ceval_gil.h: In function take_gil:
Python/ceval_gil.h:243:9: warning: initialization from incompatible pointer 
type [-Wincompatible-pointer-types]
 _Py_atomic_store_relaxed(_last_holder, tstate);
 ^
Python/pystate.c: In function PyThreadState_Swap:
Python/pystate.c:509:5: warning: initialization from incompatible pointer type 
[-Wincompatible-pointer-types]
 _Py_atomic_store_relaxed(&_PyThreadState_Current, newts);

--
components: Build
messages: 260685
nosy: Devyn Johnson
priority: normal
severity: normal
status: open
title: "incompatible pointer type" while compiling Python3.5.1
type: behavior
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

[issue25080] The example-code for making XML-RPC requests through proxy, fail!

[Berker Peksag]

Berker Peksag added the comment:

This has been fixed in cf842a8ccb77. Thank you for reporting this, Kostis!

--
nosy: +berker.peksag
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed
versions:  -Python 3.4

___
Python tracker 

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

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Random832]

On Mon, Feb 22, 2016, at 05:46, Steven D'Aprano wrote:
> Jussi, I think you have an inflated expectation of what was available in
> 1976. Command line? What's that? Programs ran in batch mode,
> and 'interactive' meant that you could easily slip out one punched card,
> replace it with a different one, and run the program again.

User experience was hardly uniform across different systems in that era.
The book "Hackers", for example, describes an interactive computer that
was used at MIT in *1959*. More relevantly to the lineage of the systems
we use today, PDP-7 Unix was first developed in 1969 - and PDP-11 6th
Edition Unix, very close to a recognizable modern system, was released
in 1975.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue26408] pep-8 requires a few corrections

[Georg Brandl]

Georg Brandl added the comment:

-Consistency within one module or function is most important.
+Consistency within one module or function is the most important.

You left out "thing" from the patch; is that intended?

--

___
Python tracker 

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

[issue26408] pep-8 requires a few corrections

[Roundup Robot]

Roundup Robot added the comment:

New changeset 43d612fc6b12 by Barry Warsaw in branch 'default':
Gramatical and other improvements given by thefourtheye.
https://hg.python.org/peps/rev/43d612fc6b12

--
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue26249] Change PyMem_Malloc to use PyObject_Malloc allocator?

[Catalin Gabriel Manciu]

Catalin Gabriel Manciu added the comment:

I've just posted the results to an OpenStack Swift benchmark run using the 
patch from my proposition, issue #26382. 
Victor's patch, applied to CPython 2.7, adds an extra 1% compared to mine 
(which improved throughput by 1%), effectively doubling the performance gain. 
Swift is a highly complex real-world workload, so this result is quite 
significant.

--

___
Python tracker 

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

[issue26408] pep-8 requires a few corrections

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

Thanks!  I like some of the changes, and may tweak a few others.  Thanks for 
the contribution.

--

___
Python tracker 

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

[issue26408] pep-8 requires a few corrections

[Barry A. Warsaw]

Changes by Barry A. Warsaw :


--
assignee: docs@python -> barry

___
Python tracker 

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

[issue26408] pep-8 requires a few corrections

[Barry A. Warsaw]

Changes by Barry A. Warsaw :


--
nosy: +barry

___
Python tracker 

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

[issue26408] pep-8 requires a few corrections

[Georg Brandl]

Georg Brandl added the comment:

I can't really comment on the grammar changes, but the rest looks good to me.

This is not very smooth, in both versions:

-Consistency within one module or function is most important.
+Consistency within one module or function is the most important thing.
 
-But most importantly: know when to be inconsistent -- sometimes the
-style guide just doesn't apply.  When in doubt, use your best
+But more importantly: know when to be inconsistent -- sometimes the
+style guide just isn't applicable.  When in doubt, use your best

(Consistency is already *most* important, but then comes something *more* 
important?)

--
nosy: +georg.brandl

___
Python tracker 

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