Re: The Joys Of Data-Driven Programming

[Chris Angelico]

On Thu, Aug 18, 2016 at 2:47 PM, Marko Rauhamaa  wrote:
> Lawrence D’Oliveiro :
>
>> Solution: set up a table of rules
>
> Without judging the individual merits of rules for your use case, I just
> want to mention that as a rule, I dislike rules. Rule languages tend to
> grow out of all bounds, always remain deficient and have impenetrable,
> ad-hoc semantics.

So you'd be with the Queen Elsa in singing "Doğru yanliş, bir kural
yok"? (I figure this song's famous enough that you probably know what
I mean even without seeing it in English.)

Rule-based code adds a level of abstraction above raw code. Thing is,
though, I actually have no idea about the merits of this exact
example, because (a) the actual rules don't seem to be there, and (b)
there's a lot of guff in the code that makes it very hard to skim. (I
include the "#end if" lines as guff. They're nothing but distraction,
plus a good chance at mismatching stuff when you edit.

Here's how *I* would do this kind of problem.
> Problem: let the user specify certain parameters for a screen display (width, 
> height, diagonal, pixel density, pixels across, pixels down, optimum viewing 
> distance) and from the ones specified, work out the parameters which were not 
> specified.
>

For each parameter, define zero or more sets of parameters from which
it can be calculated. Then iterate over the parameters you don't have,
iterate over the sets, and when you find one that's <= the parameters
you have, call the corresponding function. It's a variant of a
rule-based solution, where the rules are functions tagged with a
decorator.

parameters = defaultdict(dict)
def param(func):
target = func.__name__
source = func.__code__.co_varnames[:func.__code__.co_argcount]
parameters[target][frozenset(source)] = func
return func

@param
def width(height, diagonal):
"""Calculate the width from the height and diagonal"""
# Probably the wrong way to calculate this but whatev, this is an example
return diagonal*diagonal - height*height

@param
def width(pixel_density, pixels_across):
return pixels_across / pixel_density

@param
def diagonal(height, width):
return math.hypot(height, width)

# ... etc etc etc

def make_display(**args):
for kwd, sources in parameters.items():
if kwd in args: continue
for source, func in sources.items():
if source <= set(args):
args[kwd] = func(**{arg:args[arg] for arg in source})
break
else:
# TODO: Queue this for retry down below, or something
if set(args) <= set(parameters):
raise InsufficientInformation


This is a variant of data-driven code. The work is broken out into
individual functions whose names and parameters are used to create the
lookups. Then the actual searching is fairly compact (and could be
done better than this, too). You may notice that very little of this
code is actually aware of specific parameter names - only the formula
functions themselves. Everything else is completely generic.

(There may be bugs in the above code. It's completely untested.
Correction: The above code is completely untested, therefore there are
definitely bugs in it.)

ChrisA

PS. "No right, no wrong, no rules for me".
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why monkey patching on module object doesn't work ?

[Ian Kelly]

On Wed, Aug 17, 2016 at 10:14 PM, Shiyao Ma  wrote:
> Hi,
>
> I am using Python2.
>
> For the following snippet,
>
> http://ideone.com/i36pKO
>
> I'd suppose the dummy_func would be invoked, but seems not.
>
> Indeed, heapq.heapify does invoke cmp_lt per here:
> https://hg.python.org/cpython/file/2.7/Lib/heapq.py#l136
>
> So why this way of monkey patching failed?

Because of this:
https://hg.python.org/cpython/file/2.7/Lib/heapq.py#l351

When you call heapq.heapify, it's not actually calling the reference
implementation in that file. It's actually calling a C implementation
that totally ignores everything in that module.

If you really want to do this, you can disable the C implementation by
adding this before importing heapq:

import sys
sys.modules['_heapq'] = None

This marks the _heapq module as not found in the module cache, which
prevents he module loader from trying to import it, resulting in heapq
using the reference implementation instead.

I don't recommend doing this, however. You'd be disabling the more
efficient implementation in order to monkey-patch an undocumented
function that should be considered an implementation detail. For
example, that cmp_lt function doesn't even exist in Python 3:
https://hg.python.org/cpython/file/tip/Lib/heapq.py
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The Joys Of Data-Driven Programming

[Marko Rauhamaa]

Lawrence D’Oliveiro :

> Solution: set up a table of rules

Without judging the individual merits of rules for your use case, I just
want to mention that as a rule, I dislike rules. Rule languages tend to
grow out of all bounds, always remain deficient and have impenetrable,
ad-hoc semantics.

Instead of rules, I prefer programming language hooks. I do realize that
with the power comes a large can of worms.

> #end if
> #end for

Consider leaving these out.


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

Why monkey patching on module object doesn't work ?

[Shiyao Ma]

Hi,

I am using Python2.

For the following snippet,

http://ideone.com/i36pKO

I'd suppose the dummy_func would be invoked, but seems not.

Indeed, heapq.heapify does invoke cmp_lt per here:
https://hg.python.org/cpython/file/2.7/Lib/heapq.py#l136

So why this way of monkey patching failed?



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

[issue27558] SystemError with bare `raise` in threading or multiprocessing

[Xiang Zhang]

Xiang Zhang added the comment:

Victor, upload a new patch, changing the test case to the approach you prefer. 
;)

--
Added file: http://bugs.python.org/file44137/issue27558_v3.patch

___
Python tracker 

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

Re: type lookuperror

[meInvent bbird]

when try keystone_client.tenants.get
got error,

isn't this method for all kinds of function?

>>> m = "4c9a0da00b904422a23341e35be7f8d7"
>>> ten = checkexception(keystone_client.tenants.get, 
>>> tenant_id=checkexception(m.encode,encoding='ascii',errors='ignore'))
Unexpected error: 
None




On Thursday, August 18, 2016 at 10:22:43 AM UTC+8, Chris Angelico wrote:
> On Thu, Aug 18, 2016 at 12:13 PM, meInvent bbird  wrote:
> > would like to check errors for every function i run,
> > got error type lookuperror
> >
> > def checkexception(func, **kwargs):
> > try:
> > result = func(*tuple(value for _, value in kwargs.iteritems()))
> > except:
> > print "Unexpected error:", sys.exc_info()[0]
> > try:
> > print(func.__doc__)
> > except:
> > print("no doc error")
> >
> 
> I'm going to be brutally honest, and simply say that this is terrible
> code. I'm not even going to _try_ to fix it. Instead, here's a
> completely rewritten form:
> 
> def checkexception(func, *args, **kwargs):
> try:
> result = func(*args, **kwargs)
> except BaseException as e:
> print("Exception raised: %s" % e)
> try: print(func.__doc__)
> except AttributeError: pass
> raise # Let the exception keep happening.
> 
> But really, there are even better ways to do this. Just let the
> exception happen, and then use something like ipython to help you
> analyze the traceback.
> 
> ChrisA

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

Re: I am new to python. I have a few questions coming from an armature!

[Lawrence D’Oliveiro]

On Thursday, August 18, 2016 at 12:55:33 PM UTC+12, Terry Reedy wrote:
>
> On 8/17/2016 7:13 PM, Lawrence D’Oliveiro wrote:
>
>> On Thursday, August 18, 2016 at 8:25:37 AM UTC+12, Terry Reedy wrote:
>>>
>>>  for section_name, line_number in text.parser.toc:
>>>  def goto(line=line_number):
>>>  text.yview(line)
>>>  drop.add_command(label=section_name, command=goto)
>>
>> You don’t think of that as having its own bit of subtle nastiness?
> 
> No, you will have to be explicit.

That’s not my idea of being “explicit” at all. I hit a similar issue here 
. My solution took this sort of form:

...
#end Face

def def_face_props(celf) :
# get/set index, upem and glyph_count all have the same form:
# all these properties are unsigned integers.

def def_face_prop(propname) :
# need separate inner function so each method gets
# correct values for hb_getter and hb_setter
hb_getter = "hb_face_get_%s" % propname
hb_setter = "hb_face_set_%s" % propname

def getter(self) :
return \
getattr(hb, hb_getter)(self._hbobj)
#end getter

def setter(self, newval) :
getattr(hb, hb_setter)(self._hbobj, newval)
#end setter

getter.__name__ = propname
getter.__doc__ = "the %s property." % propname
setter.__name__ = propname
setter.__doc__ = "sets the %s property." % propname
propmethod = property(getter)
propmethod = propmethod.setter(setter)
setattr(celf, propname, propmethod)
#end def_face_prop

#begin def_face_props
for propname in ("index", "upem", "glyph_count") :
def_face_prop(propname)
#end for
#end def_face_props
def_face_props(Face)
del def_face_props
-- 
https://mail.python.org/mailman/listinfo/python-list

The Joys Of Data-Driven Programming

[Lawrence D’Oliveiro]

Problem: let the user specify certain parameters for a screen display (width, 
height, diagonal, pixel density, pixels across, pixels down, optimum viewing 
distance) and from the ones specified, work out the parameters which were not 
specified.

Solution: set up a table of rules  listing 
all the ways in which parameters can be computed from other parameters. (The 
table is called “paramdefs”.)

This one table saves so much code. It is used to drive the command-line parsing:

opts, args = getopt.getopt \
  (
sys.argv[1:],
"",
list(k + "=" for k in paramdefs)
  )

and again:

params = dict((k, None) for k in paramdefs) # None indicates unspecified 
parameter value
for keyword, value in opts :
if keyword.startswith("--") :
param = keyword[2:]
params[param] = paramdefs[param]["parse"](value)
#end if
#end for

and of course the actual parameter dependency determinations and value 
calculations:

while True :
# try to calculate all remaining unspecified parameter values
did_one = False
undone = set()
for param in params :
if params[param] == None :
calculate = paramdefs[param]["calculate"]
trycalc = iter(calculate.keys())
while True :
# try next way to calculate parameter value
trythis = next(trycalc, None)
if trythis == None :
# run out of ways
undone.add(param)
break
#end if
if all(params[k] != None for k in trythis) :
# have all values needed to use this calculation
params[param] = calculate[trythis](*tuple(params[k] for 
k in trythis))
did_one = True
break
#end if
#end while
#end if
#end for
if len(undone) == 0 or not did_one :
break # all done, or can't make further progress
#end while

I also did the same sort of thing in Java for Android 
. Guess which version is more 
concise...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: I am new to python. I have a few questions coming from an armature!

[Larry Hudson via Python-list]

On 08/17/2016 04:24 AM, Jussi Piitulainen wrote:
...

http://www-formal.stanford.edu/jmc/recursive/node2.html (the paper
famously titled "Part I" without any Part II, unless I mistake much.)



Totally OT here, but...

This reminds me of a old record I have with the (deliberately tongue-in-cheek) title "Joe 
'Fingers' Karr and Ira Ironstrings Together for the Last Time, Volume I".  Of course, there was 
never a Volume II either.  [In case you don't know those performers:  Joe 'Fingers' Karr was the 
stage-name of Joe Busch when he played honky-tonk style piano, Ira Ironstrings (don't know real 
name) played banjo.]


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

[issue27714] some test_idle tests are not re-runnable, producing false failures with regrtest -w option

[Ned Deily]

Ned Deily added the comment:

"Could you try the comment out test of macosx call for test_autocomplete 
(around line 30 to 35) in 2.7 and 3.5?"

Commenting out the mac.setupApp call in the test setup class did not appear to 
affect the running of the tests for either 2.7 or 3.5.

--

___
Python tracker 

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

Re: type lookuperror

[Chris Angelico]

On Thu, Aug 18, 2016 at 12:13 PM, meInvent bbird  wrote:
> would like to check errors for every function i run,
> got error type lookuperror
>
> def checkexception(func, **kwargs):
> try:
> result = func(*tuple(value for _, value in kwargs.iteritems()))
> except:
> print "Unexpected error:", sys.exc_info()[0]
> try:
> print(func.__doc__)
> except:
> print("no doc error")
>

I'm going to be brutally honest, and simply say that this is terrible
code. I'm not even going to _try_ to fix it. Instead, here's a
completely rewritten form:

def checkexception(func, *args, **kwargs):
try:
result = func(*args, **kwargs)
except BaseException as e:
print("Exception raised: %s" % e)
try: print(func.__doc__)
except AttributeError: pass
raise # Let the exception keep happening.

But really, there are even better ways to do this. Just let the
exception happen, and then use something like ipython to help you
analyze the traceback.

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

type lookuperror

[meInvent bbird]

would like to check errors for every function i run, 
got error type lookuperror

def checkexception(func, **kwargs):
try:
result = func(*tuple(value for _, value in kwargs.iteritems()))
except:
print "Unexpected error:", sys.exc_info()[0]
try: 
print(func.__doc__)
except:
print("no doc error")
   

>>> mm =checkexception("".encode,encoding='ascii',errors='ignore')
Unexpected error: 
S.encode([encoding[,errors]]) -> object

Encodes S using the codec registered for encoding. encoding defaults
to the default encoding. errors may be given to set a different error
handling scheme. Default is 'strict' meaning that encoding errors raise
a UnicodeEncodeError. Other possible values are 'ignore', 'replace' and
'xmlcharrefreplace' as well as any other name registered with
codecs.register_error that is able to handle UnicodeEncodeErrors.


for p in val_list:
   for k, v in p.items():
   if k == "tenant_id":
   print(v)
   m = v
   ten = checkexception(keystone_client.tenants.get, 
checkexception(m.encode,encoding='ascii',errors'ignore'))
   print(ten.name)
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue27598] Add SizedIterable to collections.abc and typing

[Guido van Rossum]

Guido van Rossum added the comment:

Ping -- I'd really like to see this happening, with "Collection" as the name.

--

___
Python tracker 

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

[issue27506] make bytes/bytearray delete a keyword argument

[Martin Panter]

Martin Panter added the comment:

I can look at enhancing the tests at some stage, but it isn’t a high priority 
for me.

Regarding translate() with no arguments, it makes sense if you see it as a kind 
of degenerate case of neither using a translation table, nor any set of bytes 
to delete:

x.translate() == x.translate(None, b"")

I admit it reads strange and probably isn’t useful. If people dislike it, it 
might be easiest to just add the keyword support and keep the first parameter 
as mandatory:

without_nulls = bytes_with_nulls.translate(None, delete=b"\x00")

--

___
Python tracker 

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

Re: I am new to python. I have a few questions coming from an armature!

[Terry Reedy]

On 8/17/2016 7:13 PM, Lawrence D’Oliveiro wrote:

On Thursday, August 18, 2016 at 8:25:37 AM UTC+12, Terry Reedy wrote:


 for section_name, line_number in text.parser.toc:
 def goto(line=line_number):
 text.yview(line)
 drop.add_command(label=section_name, command=goto)


You don’t think of that as having its own bit of subtle nastiness?


No, you will have to be explicit.


--
Terry Jan Reedy


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

[issue27789] test_asyncio Resource Warnings

[Berker Peksag]

Changes by Berker Peksag :


--
stage: needs patch -> 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

[issue27749] multprocessing errors on Windows: WriteFile() argument 1 must be int, not None; OSError: handle is closed

[wevsty]

wevsty added the comment:

A similar situation also occurs in the following Linux，A similar situation on 
stackoverflow

http://stackoverflow.com/questions/29277150/python-3-4-multiprocessing-bug-on-lock-acquire-typeerror-integer-required

--

___
Python tracker 

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

[issue26988] Add AutoNumberedEnum to stdlib

[David Hagen]

David Hagen added the comment:

> Secondarily, the doesn't seem to be any use case that can't be readily 
> covered by the existing classes.

The use case that doesn't have a clean interface in 3.5 at the moment is the 
most common use case of enums: just a collection of named objects of given 
type; I don't care about the values because they don't really have values apart 
from their object identities.

When writing enums in Rust, Swift, C#, etc., the bare identifier not only saves 
typing--it allows the developer to explicitly indicate that the underlying 
value has no meaning. (It may be better to use "object()" rather than an 
integer on AutoEnum, but that is not very important.)

It was said that Python has this feature already:

> Yes, Python 3.4 too: Animal = Enum('Animal', 'ant bee cat dog')

I will concede that this can do what I want. I hope others will concede that 
this is not a clean interface. The class name is duplicated and the members are 
regexed out of a space-delimited string. This same argument could be made to 
deprecate the unnecessary "class" keyword in favor of the "type" function.

I will also concede that there is some deep magic going on in AutoEnum and that 
magic should be avoided when it obscures. I personally think the only people 
who will be truly surprised will be those who already know Python at a deep 
enough level to know that deep magic must be required here. Everyone else will 
see "Enum" and a list of bare identifiers, and correctly conclude that this is 
your basic enum from everyone other language.

Perhaps an ideal solution would be an enum keyword:

enum PrimaryColor:
red
blue
green

But that's not happening ever.

The next best solution is the current implementation:

class PrimaryColor(AutoEnum):
red
blue
green

But because of the magic, it only barely beats out what I think is the other 
great solution already mentioned here:

class PrimaryColor(AutoEnum):
red = ()
blue = ()
green = ()

These two solutions are isomorphic. Both save the developer from having to 
provide a (possibly meaningless) value. Both let docstrings be added. Both 
provide the ability to reorganize without renumbering. The last one trades 
magic for boilerplate.

I'll keep using them from the aenum package if they don't make it into 3.6, but 
I think this is a fundamental enough construct that it belongs in the standard 
library. It is hard to convince tool maintainers to fully support these until 
they are blessed here.

--
nosy: +David Hagen

___
Python tracker 

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

[issue27643] test_ctypes fails on AIX with xlc

[Martin Panter]

Changes by Martin Panter :


--
stage:  -> patch review

___
Python tracker 

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

[issue27643] test_ctypes fails on AIX with xlc

[Martin Panter]

Martin Panter added the comment:

Michael, byref() is just a helper for passing an object’s address to a C 
function. Calling func(byref(b), ...) in Python is equivalent to the C code

unpack_bitfields(, ...)

I still think the root problem is in unpack_bitfields(). When compiled with 
XLC, your experiments confirm that it always returns unsigned values, and with 
GCC, it returns signed values.

It looks like you can detect XLC with the __IBMC__ and __xlC__ macros (not sure 
if there is a practical difference). So perhaps we can fix this with

#ifndef __xlC__

--

___
Python tracker 

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

[issue27787] Avoid test_main() in test_httplib; gc.collect() dangling threads

[Martin Panter]

Martin Panter added the comment:

Yes I agree it would make sense to separate the test_httplib changes from the 
general change. I thought this task would be a very easy change, and noticed it 
wasn’t that simple the last minute.

I would like to adjust the cleanup call to

self.addCleanup(thread.join, float(1))

That should be a better equivalent to what @reap_threads does. Or I can just 
use @reap_threads directly on test_response_fileno(), if people prefer.

--

___
Python tracker 

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

[issue24773] Implement PEP 495 (Local Time Disambiguation)

[Roundup Robot]

Roundup Robot added the comment:

New changeset 617104a6b759 by Alexander Belopolsky in branch 'default':
Issue #24773: Include Tallinn 1999-10-31 transition in tests.
https://hg.python.org/cpython/rev/617104a6b759

--

___
Python tracker 

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

[issue27791] test_threading: test_threads_join_2() failed with "Fatal Python error: Py_EndInterpreter: not the last thread"

[Martin Panter]

Martin Panter added the comment:

I just happened to notice this failure on 3.5 as well:

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.x%20Shared%203.5/builds/791/steps/test/logs/stdio

--
nosy: +martin.panter
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

[issue27784] Random failure of test_TCPServer() of test.test_socketserver.SocketServerTest and test_handle_accept() of test.test_asyncore.TestAPI_UseIPv6Select on FreeBSD buildbots

[Martin Panter]

Martin Panter added the comment:

I think I have seen these kind of errors pop up randomly on various tests on 
Free BSD buildbots (at least in the last few months or so).

Are the buildbots so overloaded that they drop localhost connections? Or are 
localhost TCP connections generally just that unreliable on Free BSD? Or is 
something else going on? I’m not faimilar with the OS.

This only seems to affect 3.6, not the equivalent 3.5 buildbot.

--
nosy: +martin.panter
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

Re: I am new to python. I have a few questions coming from an armature!

[Chris Angelico]

On Thu, Aug 18, 2016 at 9:13 AM, Dennis Lee Bieber
 wrote:
> On Wed, 17 Aug 2016 18:52:22 +0100, MRAB 
> declaimed the following:
>
>
>>
>>If "p" points to a struct (record), then "*p" is that struct, and if
>>that struct has a member (field) "m", then that member can be accessed
>>by "(*p)->m" (the parens are necessary because of the operator
>>precedence). This can be abbreviated to "p->m".
>>
>
> I'd have to test, but I think
>
> (*p).m  is what is equivalent top->m
>
> IE; dereference the pointer, and then access the member of the struct

Folks, read the whole thread before posting :) This was a simple error
that has already been mentioned earlier in the thread. (Sorry to
single you out, Dennis - I'm not trying to hate on you personally
here.)

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

Re: I am new to python. I have a few questions coming from an armature!

[Lawrence D’Oliveiro]

On Thursday, August 18, 2016 at 8:25:37 AM UTC+12, Terry Reedy wrote:
>
>  for section_name, line_number in text.parser.toc:
>  def goto(line=line_number):
>  text.yview(line)
>  drop.add_command(label=section_name, command=goto)

You don’t think of that as having its own bit of subtle nastiness?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: I am new to python. I have a few questions coming from an armature!

[Lawrence D’Oliveiro]

On Thursday, August 18, 2016 at 6:28:06 AM UTC+12, Terry Reedy wrote:
>> https://www.python.org/dev/peps/pep-0308/
> 
> What the *current* version removed from an earlier version is that there 
> was a clear community consensus against the condition-in-the-middle 
> syntax Guido proposed and for some version of "if condition then 
> True-alternative else False-alternative".  Where consensus was lacking 
> was which of multiple 'normal order' alternatives to choose.  Part of 
> the problem was a lack of knowledge of which alternative Guido might 
> accept.  In any case, a runoff vote among the top contenders was not 
> allowed.

Sounds like Conway’s Law strikes again: a flawed development process led to the 
creation of a flawed solution.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: I am new to python. I have a few questions coming from an armature!

[Lawrence D’Oliveiro]

On Thursday, August 18, 2016 at 5:53:14 AM UTC+12, MRAB wrote:

> C uses "->" for dereferencing a pointer to the member of a struct.

The only reason why “s->f” was added was because “(*s).f” was considered an 
unwieldy thing to have to write all the time.

And the only thing that made that unwieldy was that pointer dereferencing was a 
prefix operator, rather than postfix as in Pascal.

> Pascal, on the other hand, dereferences with a postfixed "^", so that 
> would be "p^.m".

And you will notice that nobody felt the need for an alternative form to 
abbreviate that.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: I am new to python. I have a few questions coming from an armature!

[Lawrence D’Oliveiro]

On Thursday, August 18, 2016 at 6:28:06 AM UTC+12, Terry Reedy wrote:
>
>> Why couldn’t they have adopted the standard C
>> syntax, as used in a whole bunch of other C-derivative languages?
>> cond ? trueval : falseval
> 
> That particular syntax was not really considered.  At least 10 versions 
> using 'if', 'then', 'else', and other tokens were.
> 
> They all had the problem of requiring a new keyword such as 'then' or 
> some other innovation.

What was wrong with adopting the C syntax? That would have introduced “?” as a 
new symbol. What impact what that have had on existing Python code? None that I 
can think of.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue18295] Possible integer overflow in PyCode_New()

[Mark Lawrence]

Changes by Mark Lawrence :


--
nosy:  -BreamoreBoy

___
Python tracker 

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

[issue27780] memory leaks in pgen build step abort build with address sanitizer enabled

[Ned Deily]

Ned Deily added the comment:

OK, that's not unreasonable and I see there have been earlier issues opened and 
addressed for similar problems (e.g. Issue18695).  Perhaps someone will want to 
dive in.

--
resolution: wont fix -> 
stage: resolved -> needs patch
status: closed -> open
title: Memory leak during Python build (from git c3ff7e7) on Debian 8.5 x64 -> 
memory leaks in pgen build step abort build with address sanitizer enabled
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

[issue27790] test_distutils spews linker messages on Windows

[Steve Dower]

Steve Dower added the comment:

It certainly looks like more than we used to get...

Ideally we'd capture the output from the build process and only write it out if 
the test failed. I'm not entirely sure why that isn't happening here. The 
warnings themselves are harmless (you get a nearly identical warning if you 
*don't* put /LTCG on the command line and need it - I'd guess there was a 
stalemate between two factions on the compiler team at some point and they 
resolved it with this warning).

--

___
Python tracker 

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

[issue26750] Mock autospec does not work with subclasses of property()

[Gregory P. Smith]

Changes by Gregory P. Smith :


--
stage: commit review -> resolved

___
Python tracker 

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

[issue27780] Memory leak during Python build (from git c3ff7e7) on Debian 8.5 x64

[geeknik]

geeknik added the comment:

FYI, I was only able to build Python with ASAN by passing 
ASAN_OPTIONS=detect_leaks=0 along with the make command, otherwise ASAN wanted 
to stop the build process as soon as it detected this leak.

--

___
Python tracker 

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

[issue26750] Mock autospec does not work with subclasses of property()

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc added the comment:

inspect.isdatadescriptor() is better indeed.
(I was initially working on an old version of mock.py which does not import 
inspect, and I did not want to add the dependency there).

- inspect uses hasattr(type(obj)) instead of hasatr(obj). This is better, (but 
does not work for 2.x old-style classes)

- my patch tested for __del__... this is completely wrong, it should have been 
__delete__. oops.
inspect.isdatadescriptor() does not test for __delete__. This is insaccurate, 
but I doubt it will ever matter. This is only possible for Python-defined 
descriptors, the C implementation always exposes both __set__ and __delete__ 
when tp_set is filled.

IOW, I'm happy with the current state.

--

___
Python tracker 

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

[issue27780] Memory leak during Python build (from git c3ff7e7) on Debian 8.5 x64

[Ned Deily]

Ned Deily added the comment:

Thanks for the report but, AFAIK, pgen is only used during the build of Python 
and pgen is not installed (by "make install").  This doesn't seem like it is 
worth worrying about.  Or am I missing something?  Feel free to reopen if so or 
if someone comes up with a patch.

--
nosy: +ned.deily
priority: normal -> low
resolution:  -> wont fix
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

Re: I am new to python. I have a few questions coming from an armature!

[Terry Reedy]

On 8/17/2016 2:39 PM, Random832 wrote:

On Wed, Aug 17, 2016, at 14:27, Terry Reedy wrote:

That particular syntax was not really considered.  At least 10 versions
using 'if', 'then', 'else', and other tokens were.

They all had the problem of requiring a new keyword such as 'then' or
some other innovation.


Why not just if(cond, trueval, falseval), a la Visual Basic?

It's too late to change now, but I'm curious as to whether it was
considered or not.


It is already valid Python, parsed as 'if' 'tuple'

>>> if(1,2): 3

3

A space after 'if' is not optional if the next char is an identifier 
char, as in 'ifx' as this is parsed as the identifier 'ifx', not 'if' 'x'.


Anyone can define an iff(cond, true_func, false_func) function

def iff(cond, f_true, f_false):
return (f_true if cond else f_false)()

or a non-short-circuiting iff(cond, true_val, false_val) function, but 
it hardly seems worth the effort.


--
Terry Jan Reedy

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

Re: I am new to python. I have a few questions coming from an armature!

[Terry Reedy]

On 8/17/2016 2:43 PM, Marko Rauhamaa wrote:

Terry Reedy :


On 8/17/2016 2:39 AM, Steven D'Aprano wrote:
"If I finish work on on time, go to the movies, otherwise just go home."
is also real English syntax, and to me, more graceful.  It is certainly
more neutral among the alternatives.  The inverted version implies a
clear preference for the first alternative.

It would be an interesting exercise to see which order for ternary
expressions is more common in some large corpus of English text.


Python's ternary expression has a distinct Perl flavor to it.


One of the ironies (or puzzles) of Guido's choice is that he once 
condemned Perl's 'value if cond' as wretched.  I never got an answer as 
to whether he changed his mind on that or if adding 'else otherval' made 
it unwretched.  Whatever the case, it does not matter to me now. I once 
'boycotted' the ternary but now use it where I think it better than the 
alternative.


--
Terry Jan Reedy

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

[issue27791] test_threading: test_threads_join_2() failed with "Fatal Python error: Py_EndInterpreter: not the last thread"

[STINNER Victor]

New submission from STINNER Victor:

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.x%20Shared%203.x/builds/4769/steps/test/logs/stdio

0:00:46 [ 41/402] test_threading crashed
Fatal Python error: Py_EndInterpreter: not the last thread

Current thread 0x000802006400 (most recent call first):
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/support/__init__.py",
 line 2445 in run_in_subinterp
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_threading.py",
 line 877 in test_threads_join_2
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/case.py", 
line 600 in run
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/case.py", 
line 648 in __call__
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", 
line 122 in run
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", 
line 84 in __call__
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", 
line 122 in run
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", 
line 84 in __call__
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", 
line 122 in run
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", 
line 84 in __call__
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/runner.py", 
line 176 in run
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/support/__init__.py",
 line 1810 in _run_suite
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/support/__init__.py",
 line 1844 in run_unittest
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/runtest.py",
 line 179 in test_runner
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/runtest.py",
 line 180 in runtest_inner
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/runtest.py",
 line 133 in runtest
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/runtest_mp.py",
 line 71 in run_tests_slave
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/main.py",
 line 472 in _main
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/main.py",
 line 465 in main
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/main.py",
 line 527 in main
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/regrtest.py", 
line 46 in _main
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/regrtest.py", 
line 50 in 
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/runpy.py", line 
85 in _run_code
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/runpy.py", line 
184 in _run_module_as_main
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/runpy.py", line 
184, in _run_module_as_main
"__main__", mod_spec)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/runpy.py", line 
85, in _run_code
exec(code, run_globals)
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/__main__.py", 
line 2, in 
main()
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/main.py",
 line 527, in main
Regrtest().main(tests=tests, **kwargs)
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/main.py",
 line 465, in main
self._main(tests, kwargs)
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/main.py",
 line 485, in _main
self.run_tests()
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/main.py",
 line 413, in run_tests
run_tests_multiprocess(self)
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/runtest_mp.py",
 line 221, in run_tests_multiprocess
raise Exception(msg)
Exception: Child error on test_threading: Exit code -6
*** Error code 1

--
components: Tests
keywords: buildbot
messages: 272995
nosy: haypo, koobs
priority: normal
severity: normal
status: open
title: test_threading: test_threads_join_2() failed with "Fatal Python error: 
Py_EndInterpreter: not the last thread"
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

[issue27594] Assertion failure when running "test_ast" tests with coverage.

[Ivan Levkivskyi]

Ivan Levkivskyi added the comment:

Ned, thank you for applying the patch!

I have discovered this same issue accidentally while playing with possible 
implementations of PEP 526. It appeared as a failure in
test_sys_settrace in my fork.

--

___
Python tracker 

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

[issue27706] Random.seed, whose purpose is purportedly determinism, behaves non-deterministically with strings due to hash randomization

[Glyph Lefkowitz]

Glyph Lefkowitz added the comment:

For what it's worth, I don't much care whether this is fixed or not; I ended up 
wanting to leak less information from the RNG output anyway so I wrote this:

https://gist.github.com/glyph/ceca96100a3049fefea6f2035abbd9ea

but I felt like it should be reported.

--

___
Python tracker 

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

[issue27594] Assertion failure when running "test_ast" tests with coverage.

[Ned Deily]

Ned Deily added the comment:

Thanks for the report.  It looks the assert error is triggered by the new test 
case added in 59638baee25e for Issue13436.  Since that test case was only added 
for 3.6, I've only applied Ivan's suggested fix for 3.6 as well, although you 
could trigger the same assert in earlier releases.  Thanks, Ivan!

--
nosy: +ned.deily
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

[issue27790] test_distutils spews linker messages on Windows

[Terry J. Reedy]

New submission from Terry J. Reedy:

3.6, Win10, VS recently reinstalled to 'Update 3'.  I believe these messages 
are somewhat new.

0:01:00 [111/402] test_distutils failed (env changed)
xxmodule.c
   Creating library 
C:\Users\Terry\AppData\Local\Temp\tmpbjffnmc3\Debug\Users\Terry\AppData\Local\Temp\tmpbjffnmc3\xx_d.cp36-win32.lib
 and object 
C:\Users\Terry\AppData\Local\Temp\tmpbjffnmc3\Debug\Users\Terry\AppData\Local\Temp\tmpbjffnmc3\xx_d.cp36-win32.exp
LINK : /LTCG specified but no code generation required; remove /LTCG from the 
link command line to improve linker performance
foo.c
   Creating library 
C:\Users\Terry\AppData\Local\Temp\tmp7302jrpo\tempt\Users\Terry\AppData\Local\Temp\tmp9132twos\foo_d.cp36-win32.lib
 and object 
C:\Users\Terry\AppData\Local\Temp\tmp7302jrpo\tempt\Users\Terry\AppData\Local\Temp\tmp9132twos\foo_d.cp36-win32.exp
LINK : /LTCG specified but no code generation required; remove /LTCG from the 
link command line to improve linker performance
foo.c
   Creating library 
C:\Users\Terry\AppData\Local\Temp\tmp7302jrpo\tempt\Users\Terry\AppData\Local\Temp\tmp9132twos\foo_d.cp36-win32.lib
 and object 
C:\Users\Terry\AppData\Local\Temp\tmp7302jrpo\tempt\Users\Terry\AppData\Local\Temp\tmp9132twos\foo_d.cp36-win32.exp
LINK : /LTCG specified but no code generation required; remove /LTCG from the 
link command line to improve linker performance
xxmodule.c
   Creating library 
C:\Users\Terry\AppData\Local\Temp\tmp9hq4ci8e\Debug\Users\Terry\AppData\Local\Temp\tmp9hq4ci8e\xx_d.cp36-win32.lib
 and object 
C:\Users\Terry\AppData\Local\Temp\tmp9hq4ci8e\Debug\Users\Terry\AppData\Local\Temp\tmp9hq4ci8e\xx_d.cp36-win32.exp
LINK : /LTCG specified but no code generation required; remove /LTCG from the 
link command line to improve linker performance
foo.c
   Creating library 
C:\Users\Terry\AppData\Local\Temp\tmp3qv0ulce\tempt\Users\Terry\AppData\Local\Temp\tmph1jy_aqh\foo_d.cp36-win32.lib
 and object 
C:\Users\Terry\AppData\Local\Temp\tmp3qv0ulce\tempt\Users\Terry\AppData\Local\Temp\tmph1jy_aqh\foo_d.cp36-win32.exp
LINK : /LTCG specified but no code generation required; remove /LTCG from the 
link command line to improve linker performance
foo.c
   Creating library 
C:\Users\Terry\AppData\Local\Temp\tmp3qv0ulce\tempt\Users\Terry\AppData\Local\Temp\tmph1jy_aqh\foo_d.cp36-win32.lib
 and object 
C:\Users\Terry\AppData\Local\Temp\tmp3qv0ulce\tempt\Users\Terry\AppData\Local\Temp\tmph1jy_aqh\foo_d.cp36-win32.exp
LINK : /LTCG specified but no code generation required; remove /LTCG from the 
link command line to improve linker performance
xxmodule.c
   Creating library build\temp.win32-3.6-pydebug\Debug\xx_d.cp36-win32.lib and 
object build\temp.win32-3.6-pydebug\Debug\xx_d.cp36-win32.exp
LINK : /LTCG specified but no code generation required; remove /LTCG from the 
link command line to improve linker performance

F:\Python\dev\36\build\test_python_3596>exit 1

F:\Python\dev\36\build\test_python_3596>exit 0
Warning -- files was modified by test_distutils

--
components: Distutils, Tests, Windows
messages: 272991
nosy: dstufft, eric.araujo, haypo, paul.moore, steve.dower, terry.reedy, 
tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: test_distutils spews linker messages on Windows

___
Python tracker 

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

[issue27746] ResourceWarnings in test_asyncio

[STINNER Victor]

STINNER Victor added the comment:

I marked the issue #272989 as a duplicate of this one. Copy of the msg272986 by 
Terry J. Reedy:

3.6, Windows 10, debug build. The following appeared before and after pulling 
and rebuilding today. I am reporting as per Victor's request on pydev list.

0:00:22 [ 52/402] test_asyncio passed
F:\Python\dev\36\lib\asyncio\sslproto.py:329: ResourceWarning: unclosed 
transport 
  source=self)
F:\Python\dev\36\lib\asyncio\sslproto.py:329: ResourceWarning: unclosed 
transport 
  source=self)
F:\Python\dev\36\lib\asyncio\sslproto.py:329: ResourceWarning: unclosed 
transport 
  source=self)

--

___
Python tracker 

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

[issue27789] test_asyncio Resource Warnings

[STINNER Victor]

STINNER Victor added the comment:

Duplicate of issue #27746.

--
resolution:  -> duplicate
superseder:  -> ResourceWarnings in test_asyncio

___
Python tracker 

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

[issue27706] Random.seed, whose purpose is purportedly determinism, behaves non-deterministically with strings due to hash randomization

[STINNER Victor]

STINNER Victor added the comment:

> Changing the affected version to just 2.7.

Oh. The request looks like an enhancement. The problem is that if you add a new 
feature in Python 2.7.n+1, it's not available on Python 2.7.n. Support 2.7.n as 
well, you have to backport the code in your application.

I'm not sure that it's worth to add such enhancement to the random at this 
point in Python 2.

I suggest you to either upgrade to Python 3 (hello, Python 3!) or implement the 
SHA512 in your application. I expect that random.seed() in only called at one 
or maybe two places, so it shouldn't be hard to patch your code ;-)

In short, I suggest to close the issue as wont fix.

--

___
Python tracker 

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

[issue27594] Assertion failure when running "test_ast" tests with coverage.

[Roundup Robot]

Roundup Robot added the comment:

New changeset 1bf307f42a6b by Ned Deily in branch 'default':
Issue #27594: Prevent assertion error when running test_ast with coverage
https://hg.python.org/cpython/rev/1bf307f42a6b

--
nosy: +python-dev

___
Python tracker 

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

[issue27789] test_asyncio Resource Warnings

[Terry J. Reedy]

New submission from Terry J. Reedy:

3.6, Windows 10, debug build. The following appeared before and after pulling 
and rebuilding today. I am reporting as per Victor's request on pydev list.

0:00:22 [ 52/402] test_asyncio passed
F:\Python\dev\36\lib\asyncio\sslproto.py:329: ResourceWarning: unclosed 
transport 
  source=self)
F:\Python\dev\36\lib\asyncio\sslproto.py:329: ResourceWarning: unclosed 
transport 
  source=self)
F:\Python\dev\36\lib\asyncio\sslproto.py:329: ResourceWarning: unclosed 
transport 
  source=self)

--
components: Tests, asyncio
messages: 272986
nosy: giampaolo.rodola, gvanrossum, haypo, terry.reedy, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: test_asyncio Resource Warnings
type: behavior
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

[issue27786] longobject.c: simplify x_sub(), inline _PyLong_Negate()

[STINNER Victor]

STINNER Victor added the comment:

Serhiy Storchaka: "LGTM."

Oh, you posted your comment while I was pushing the patch after Brett wrote 
LGTM on the review (not on the bug tracker).

> Maybe use size_a instead of Py_SIZE(z)?
> And look at "sign". Currently it takes values 1 and -1. Is it worth to 
> replace it with boolean variable "negative"? Or Py_ssize_t variable size_z 
> that takes values size_a and -size_a?

Hum, I don't know what is the best. I don't think that it has an impact on 
performance. Feel free to modify directly the code, your proposed changes look 
safe and simple enough.

--

___
Python tracker 

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

Re: JSON confusion

[Terry Reedy]

On 8/17/2016 12:35 PM, Steve Simmons wrote:

I'm trying to write a small utility to find the closest railway station
to a given (UK) postcode but the result is in JSON and I'm not familiar
with it. I've got as far as extracting the JSON object and I can print
the first level elements ("success" and "result") but I've totally
confused myself about how to delve into the rest of the data structure.
Can anyone point me to a 'how-to' for tackling a fairly complex SJON
object or give me some pointers. ... or maybe point out if I'm taking an
unnecessarily complex approach. Initially, I'm Looking to extract
'stationname', 'distance' and one or two of the coordinate pairs. To be
honest, I'd rather have some hints rather than the whole solution
otherwise I'll not learn anything :-) SteveS def main():
import urllib
import urllib.request
import urllib.parse
import urllib.response
import json

add   import pprint



url
='https://data.gov.uk/data/api/service/transport/naptan_railway_stations/postcode?postcode=CT16+1ez=2'
req = urllib.request.urlopen(url)

req_json = req.read()
str_json = req_json.decode("utf-8")

p_json = json.loads(str_json)


This result is nexted dicts and lists


print(p_json)
print ('==')
print(repr(p_json))
print('SUCCESS: ',repr(p_json['success']))
print ('==')
print('RESULT : ',repr(p_json['result']))


Replace prints above with
pprint.pprint(p_json)
and you will see the better formatted

{'result': [{'atcocode': '9100DOVERP',
 'crscode': 'DVP',
 'distance': 881.148432224,
 'latlong': {'coordinates': [1.3052936134036113, 
51.12569875059288],

 'crs': {'properties': {'name': 'EPSG4326'},
 'type': 'name'},
 'type': 'Point'},
 'ospoint': {'coordinates': [631380.0, 141464.0],
 'crs': {'properties': {'name': 'EPSG27700'},
 'type': 'name'},
 'type': 'Point'},
 'stationname': 'Dover Priory Rail Station',
 'tiploccode': 'DOVERP'}],
 'success': True}

Use this in combination with Jon Ribbens' answer.


--
Terry Jan Reedy

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

[issue27788] platform module's version number doesn't match its docstring

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

That must have been an oversight. __version__ should read '0.8.0'.

--

___
Python tracker 

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

Re: I am new to python. I have a few questions coming from an armature!

[Ben Bacarisse]

Jussi Piitulainen  writes:

> BartC writes:
>
>> On 17/08/2016 07:39, Steven D'Aprano wrote:
>>> Rather than ask why Python uses `trueval if cond else falseval`, you
>>> should ask why C uses `cond ? trueval : falseval`. Is that documented
>>> anywhere?
>>
>> I'm not fond of C's a ? b : c but the principle is sound. I generally
>
> [- -]
>
>> Anyway a?b:c was existing practice. At least the order of a,b,c could
>> have been retained if not the exact syntax.
>
> The original was (c1 -> e1, c2 -> e2, ..., cn -> en) in John McCarthy's
> 1960 paper on symbolic expressions, with an actual arrow glyph in place
> of hyphen-greater-than.

And BCPL (Martin Richards 1967) took the same arrow and comma syntax.
BCPL spawned B which led to C, but in B Thompson used ? and : but kept
the right-to-left binding.  I think the change was unfortunate because
the arrow works well in various layouts and looks much better when
chained (though that might just be my bias from being a BCPL coder from
way back).


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

Re: I am new to python. I have a few questions coming from an armature!

[Ben Bacarisse]

MRAB  writes:

> On 2016-08-17 18:19, Jussi Piitulainen wrote:
>> MRAB writes:
>>
>>> On 2016-08-17 12:24, Jussi Piitulainen wrote:
 BartC writes:

> On 17/08/2016 07:39, Steven D'Aprano wrote:
>> Rather than ask why Python uses `trueval if cond else falseval`, you
>> should ask why C uses `cond ? trueval : falseval`. Is that documented
>> anywhere?
>
> I'm not fond of C's a ? b : c but the principle is sound. I generally

 [- -]

> Anyway a?b:c was existing practice. At least the order of a,b,c could
> have been retained if not the exact syntax.

 The original was (c1 -> e1, c2 -> e2, ..., cn -> en) in John
 McCarthy's 1960 paper on symbolic expressions, with an actual arrow
 glyph in place of hyphen-greater-than.

>>> [snip]
>>>
>>> BCPL, the ancestor of  C, had:
>>>
>>> a -> b, c
>>
>> Nice. Add a redundant pair of parentheses and it's the same. (When used
>> as an expression, a final else-branch is mandatory-ish.)
>>
>> But C uses -> for something else, I think. And other languages use it
>> for lambda expressions (succesfully, I think, but then they don't have
>> it available for this purpose).
>>
> C uses "->" for dereferencing a pointer to the member of a struct.

Slightly better wording: it uses -> to access a struct member via a
pointer to the struct.

> If "p" points to a struct (record), then "*p" is that struct, and if
> that struct has a member (field) "m", then that member can be accessed
> by "(*p)->m" (the parens are necessary because of the operator
> precedence).

I think you meant (*p).m here because you go on to correct say that ->
offers a shorthand for this rather messy access:

> This can be abbreviated to "p->m".
>
> Pascal, on the other hand, dereferences with a postfixed "^", so that
> would be "p^.m".
>

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

Re: I am new to python. I have a few questions coming from an armature!

[Terry Reedy]

On 8/17/2016 2:07 AM, Steven D'Aprano wrote:


I realise that there are occasions where we might deliberate choose to assign
an intermediate value to its own variable, but all else being equal, which
would you prefer?

#A
alist = []
alist.append(2)
alist.append(4)
alist.append(8)
process(alist)

#B
process([2, 4, 8])

#A
value = 0
for i in range(100):
value += 1
process(value)

#B
process(100)

#A
tmp = get_some_string()
s = tmp[1]
s += tmp[2]
s += tmp[3]
process(s)

#B
process(get_some_string()[1:4])


Up to here, #A is a useless and stupid.  Have you seen such code written?


#A
def callback(btn):
return btn.do_the_thing(42) or default
the_button.setcommand(callback)
process(the_button)

#B
the_button.setcommand(lambda btn: btn.do_the_thing(42) or default)
process(the_button)


This example is *not* parallel to the other 3.  Here, A is useful real 
code and might be preferred for multiple reasons.



If you find yourself preferring B, B, B, A, you might ask yourself what makes a
function different that you prefer to keep temporary functions around where
they're not needed.


When 'callback' is set as the command of the button, it is not 
temporary, but must remain as long as the button remains.  Only the name 
binding is (possibly) disposable.


One may want the function to have a meaningful name that says what it does.

One may want the function to have a name for tracebacks.

In a framework that passes the button to button callbacks (not tk, 
unfortunately), the same callback might be used for multiple buttons. 
(In tk, one must create a wrapper of callback for each button.)


The example is misleading in that the return value of a Button callback 
is likely irrelevant.  (This is true of all tkinter/tk callbacks that I 
can think of.)  More realistic is


#A
def callback(btn):
btn.do_the_thing(42)
the_button.setcommand(callback)

#A'
def cb(btn): btn.do_the_thing(42)
the_button.setcommand(cb)

#B
the_button.setcommand(lambda btn: btn.do_the_thing(42)

I have written code like #B, but #A is more correct, to me, in returning 
None instead of the ignored value of the call.


Beginners often do not understand that the body of a lambda expression 
is evaluated in a new local namespace, and only when the resulting 
function is called, the same as with a def statement.  They then neglect 
to capture current values when writing lambda expressions in a for loop.


In many cases, there is a third alternative using functools.partial.

Production gui code is typically written with classes.  This adds the 
possibility of using bound methods.


This example require the_button to be defined elsewhere.  Typically, the 
command can and should be set when the button is defined, along with 
other options.  Having 'cb' pre-defined may make the defining call more 
readable and the arg list fall on one line rather than two.



Here is a real example from idlelib/help.py

def toc_menu(self, text):
"Create table of contents as drop-down menu."
toc = Menubutton(self, text='TOC')
drop = Menu(toc, tearoff=False)
for lbl, dex in text.parser.toc:
drop.add_command(label=lbl, command=lambda 
dex=dex:text.yview(dex))

toc['menu'] = drop
return toc

The local names 'lbl' and 'dex' were chosen short so that the long line 
would be exactly at the limit of 79 chars.  Here is a rewrite of the for 
loop.


for section_name, line_number in text.parser.toc:
def goto(line=line_number):
text.yview(line)
drop.add_command(label=section_name, command=goto)

To me, this is much better and I intend to commit it.  Thank you for 
prodding me to think through how bad the lambda form can be and to 
rewrite the loop so I don't cringe reading it.


--
Terry Jan Reedy


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

[issue27645] Supporting native backup facility of SQLite

[Cédric Krier]

Changes by Cédric Krier :


--
nosy: +ced

___
Python tracker 

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

Re: I am new to python. I have a few questions coming from an armature!

[Marko Rauhamaa]

MRAB :

> On 2016-08-17 19:39, Random832 wrote:
>> Why not just if(cond, trueval, falseval), a la Visual Basic?
>
> Well, it looks too much like a function call, which don't
> short-circuit.

Well, in Scheme, everything looks like a function call:

(define (deflate x)
  (if (> 0 x)
  (1+ x)
  (1- x)))


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

Re: I am new to python. I have a few questions coming from an armature!

[MRAB]

On 2016-08-17 19:39, Random832 wrote:

On Wed, Aug 17, 2016, at 14:27, Terry Reedy wrote:

That particular syntax was not really considered.  At least 10 versions
using 'if', 'then', 'else', and other tokens were.

They all had the problem of requiring a new keyword such as 'then' or
some other innovation.


Why not just if(cond, trueval, falseval), a la Visual Basic?

It's too late to change now, but I'm curious as to whether it was
considered or not.


Well, it looks too much like a function call, which don't short-circuit.

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

Re: I am new to python. I have a few questions coming from an armature!

[MRAB]

On 2016-08-17 19:00, Grant Edwards wrote:

On 2016-08-17, MRAB  wrote:


C uses "->" for dereferencing a pointer to the member of a struct.

If "p" points to a struct (record), then "*p" is that struct, and if
that struct has a member (field) "m", then that member can be accessed
by "(*p)->m" (the parens are necessary because of the operator
precedence).


ITYM (*p).m


Correct.


This can be abbreviated to "p->m".

Pascal, on the other hand, dereferences with a postfixed "^", so that
would be "p^.m".




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

Re: I am new to python. I have a few questions coming from an armature!

[MRAB]

On 2016-08-17 18:58, Marko Rauhamaa wrote:

MRAB :


C uses "->" for dereferencing a pointer to the member of a struct.


What "->" is for C, "." is Python and Java.

Python doesn't have C's ".".

C has both stacked-allocated and heap-allocated records. That's not the 
case with Python or Java.


Delphi, which is basically an extended Pascal, allows you to omit the 
"^" when dereferencing a pointer to a field in a record, so you can 
write "p.m" instead of "p^.m" when "p" is a pointer to a record.


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

[issue27574] Faster parsing keyword arguments

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Yes, I came to conclusion than needed to push existing issues for separate 
files. I'm sure there are ready patches waiting for review. Now there is 
additional reason for converting to Argument Clinic. But some files contain 
only one PyArg_ParseTupleAndKeywords(), I think we can convert them in one 
patch.

--

___
Python tracker 

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

Re: I am new to python. I have a few questions coming from an armature!

[Marko Rauhamaa]

Terry Reedy :

> On 8/17/2016 2:39 AM, Steven D'Aprano wrote:
> "If I finish work on on time, go to the movies, otherwise just go home."
> is also real English syntax, and to me, more graceful.  It is certainly
> more neutral among the alternatives.  The inverted version implies a
> clear preference for the first alternative.
>
> It would be an interesting exercise to see which order for ternary
> expressions is more common in some large corpus of English text.

Python's ternary expression has a distinct Perl flavor to it. However,
the problem with the "then" keyword was valid. Also, Python's
comprehensions already had a postfix "if".

Personally, I'd normally steer clear of ternary conditionals both in C
and Python.

This reminds me of a discussion I had yesterday about why Scheme can't
implement a proper try/finally construct. That's because Scheme supports
continuations; nothing is really final. Python would gain a similar
power if there were a way to cancel exceptions:

 try:
 do_something()
 except ValueError:
 retry 123

where:

 def do_something():
 def_value = raise ValueError
 a += def_value


What Python would then need is a try/nevermind:

 resource = grab_it()
 while True:
  try:
   resource.operate()
  finally:
   resource.release()
   break
  nevermind:
   resource.take_back()


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

[issue18880] ssl.SSLSocket shutdown doesn't behave like socket.shutdown

[Ned Deily]

Changes by Ned Deily :


--
nosy: +alex, dstufft, giampaolo.rodola, janssen
versions: +Python 3.6 -Python 2.6, Python 3.1

___
Python tracker 

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

Re: I am new to python. I have a few questions coming from an armature!

[Random832]

On Wed, Aug 17, 2016, at 14:27, Terry Reedy wrote:
> That particular syntax was not really considered.  At least 10 versions 
> using 'if', 'then', 'else', and other tokens were.
> 
> They all had the problem of requiring a new keyword such as 'then' or 
> some other innovation.

Why not just if(cond, trueval, falseval), a la Visual Basic?

It's too late to change now, but I'm curious as to whether it was
considered or not.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue26988] Add AutoNumberedEnum to stdlib

[Raymond Hettinger]

Raymond Hettinger added the comment:

> you ran your test script with the -m "run module as script" flag

Right, that was a mistest, so it looks like triple quotes do work.

I did notice that there's also an issue if one line reads, "red='hello'".

But really, the big issue is using a bare-identifier to fiat an attribute into 
existence.  That's a door that really shouldn't be opened.

Secondarily, the doesn't seem to be any use case that can't be readily covered 
by the existing classes.  There is no real need for the witchcraft and the 
departure from Python norms.

--

___
Python tracker 

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

Re: I am new to python. I have a few questions coming from an armature!

[Terry Reedy]

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

On Wednesday 17 August 2016 06:59, Lawrence D’Oliveiro wrote:



Here

are some examples of that varying mileage.


Quote:

The Python syntax for conditional expressions (introduced in Python 2.5) is

trueval if cond else falseval

I think this is bloody awful.


When this was initially considered, this was the majority view.


Why couldn’t they have adopted the standard C
syntax, as used in a whole bunch of other C-derivative languages?
cond ? trueval : falseval


That particular syntax was not really considered.  At least 10 versions 
using 'if', 'then', 'else', and other tokens were.


They all had the problem of requiring a new keyword such as 'then' or 
some other innovation.



Because the C syntax is horrifically ugly, whereas the Python syntax is very
close to real English syntax.

"What will you do tonight?"

"Go to the movies, if I finish work on time, otherwise just go home."


"If I finish work on on time, go to the movies, otherwise just go home."
is also real English syntax, and to me, more graceful.  It is certainly 
more neutral among the alternatives.  The inverted version implies a 
clear preference for the first alternative.


It would be an interesting exercise to see which order for ternary 
expressions is more common in some large corpus of English text.



Every time you read the C syntax, you lose another three minutes off your
lifespan. That's how ugly it is.


Every time I write or read the Python syntax chosen, I lose time 
rearranging the terms.



The background to the Python ternary operator is documented here:

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


What the *current* version removed from an earlier version is that there 
was a clear community consensus against the condition-in-the-middle 
syntax Guido proposed and for some version of "if condition then 
True-alternative else False-alternative".  Where consensus was lacking 
was which of multiple 'normal order' alternatives to choose.  Part of 
the problem was a lack of knowledge of which alternative Guido might 
accept.  In any case, a runoff vote among the top contenders was not 
allowed.



Rather than ask why Python uses `trueval if cond else falseval`, you should ask
why C uses `cond ? trueval : falseval`. Is that documented anywhere?


The ordering of the if-then-else terms is obvious.  '?' ending a 
question (in English) is obvious.  ';' was already used to end 
statememts and could not be used here. Could ',' have been used instead 
of ':'?  I am not sure, but it is used elsewhere in C.  ':' is the only 
other within-Englich-sentence separator available.


The ':' naturally translates to 'else', which was already a keyword. 
There was consensus on this.


The problem for a pythonic (wordy) version of the C expression is that 
the word marker for questions, 'if', normally begins rather than ending 
a question*.  So "cond if trueval else falseval" is likely to be 
misinterpreted.  Hence proposals for "cond then trueval else falseval" 
and "if cond then trueval else falseval" and other variations.


* In a construction like "The cock crows?  If so, I must go, else I 
would tarry with thee longer."  the 'if' follows the question, yet 
cannot standalone but must be followed by something referring back to 
the question.


--
Terry Jan Reedy


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

[issue27574] Faster parsing keyword arguments

[Brett Cannon]

Brett Cannon added the comment:

I think for converting uses to Argument Clinic it can be done in a more 
iterative process on a per-module basis. How many modules do we have left to 
convert? If it isn't ridiculously huge we could open individual issues to 
convert them each.

--

___
Python tracker 

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

[issue26200] SETREF adds unnecessary work in some cases

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Thank you Raymond and Victor.

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

[issue27574] Faster parsing keyword arguments

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I left this issue open for three reasons.

1. I had ideas and almost finished patch for different optimization. 
Unfortunately my hope was not justified, new implementation is slower. If I 
fail to fix it in few days, I'll close the issue.

2. For bikeshedding in case somebody want to suggest different names or 
interface.

3. I was going to convert most occurrences of PyArg_ParseTupleAndKeywords() to 
Argument Clinic for achieving larger effect of this optimization. But this 
patch was larger than I expected.

--

___
Python tracker 

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

Re: I am new to python. I have a few questions coming from an armature!

[Grant Edwards]

On 2016-08-17, MRAB  wrote:

> C uses "->" for dereferencing a pointer to the member of a struct.
>
> If "p" points to a struct (record), then "*p" is that struct, and if 
> that struct has a member (field) "m", then that member can be accessed 
> by "(*p)->m" (the parens are necessary because of the operator 
> precedence).

ITYM (*p).m

> This can be abbreviated to "p->m".
>
> Pascal, on the other hand, dereferences with a postfixed "^", so that 
> would be "p^.m".

-- 
Grant Edwards   grant.b.edwardsYow! Is this an out-take
  at   from the "BRADY BUNCH"?
  gmail.com

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

Re: I am new to python. I have a few questions coming from an armature!

[Marko Rauhamaa]

MRAB :

> C uses "->" for dereferencing a pointer to the member of a struct.

What "->" is for C, "." is Python and Java.

Python doesn't have C's ".".


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

Re: I am new to python. I have a few questions coming from an armature!

[MRAB]

On 2016-08-17 18:19, Jussi Piitulainen wrote:

MRAB writes:


On 2016-08-17 12:24, Jussi Piitulainen wrote:

BartC writes:


On 17/08/2016 07:39, Steven D'Aprano wrote:

Rather than ask why Python uses `trueval if cond else falseval`, you
should ask why C uses `cond ? trueval : falseval`. Is that documented
anywhere?


I'm not fond of C's a ? b : c but the principle is sound. I generally


[- -]


Anyway a?b:c was existing practice. At least the order of a,b,c could
have been retained if not the exact syntax.


The original was (c1 -> e1, c2 -> e2, ..., cn -> en) in John
McCarthy's 1960 paper on symbolic expressions, with an actual arrow
glyph in place of hyphen-greater-than.


[snip]

BCPL, the ancestor of  C, had:

a -> b, c


Nice. Add a redundant pair of parentheses and it's the same. (When used
as an expression, a final else-branch is mandatory-ish.)

But C uses -> for something else, I think. And other languages use it
for lambda expressions (succesfully, I think, but then they don't have
it available for this purpose).


C uses "->" for dereferencing a pointer to the member of a struct.

If "p" points to a struct (record), then "*p" is that struct, and if 
that struct has a member (field) "m", then that member can be accessed 
by "(*p)->m" (the parens are necessary because of the operator 
precedence). This can be abbreviated to "p->m".


Pascal, on the other hand, dereferences with a postfixed "^", so that 
would be "p^.m".


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

[issue27786] longobject.c: simplify x_sub(), inline _PyLong_Negate()

[STINNER Victor]

STINNER Victor added the comment:

Thanks for the review Brett, I pushed my fix.

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

[issue27782] Multi-phase extension module initialization, inconsistent exceptions and conflicts between code and PEP

[Xiang Zhang]

Xiang Zhang added the comment:

Thanks Petr. I'd appreciate it if you are willing to review the patch.

Upload a patch to fix this, along with tests and doc updating.

But here is something different. In PEP489, it is explicitly stated that 
"Py_mod_create slot is not responsible for setting import-related attributes 
specified in PEP 451 (such as __name__ or __loader__ ) on the new module". So 
when an object(even ModuleType instances) is returned, it's __name__ attribute 
is not set and we can't rely on it (which means we can't even use 
PyModule_GetNameObject). I then use the name attribute of the spec. Looking 
forward to feedback.

--
keywords: +patch
Added file: http://bugs.python.org/file44136/issue27782.patch

___
Python tracker 

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

[issue27786] longobject.c: simplify x_sub(), inline _PyLong_Negate()

[Roundup Robot]

Roundup Robot added the comment:

New changeset be9dc240bf28 by Victor Stinner in branch 'default':
Issue #27786: Simplify x_sub()
https://hg.python.org/cpython/rev/be9dc240bf28

--
nosy: +python-dev

___
Python tracker 

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

[issue27786] longobject.c: simplify x_sub(), inline _PyLong_Negate()

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

LGTM.

Maybe use size_a instead of Py_SIZE(z)?

And look at "sign". Currently it takes values 1 and -1. Is it worth to replace 
it with boolean variable "negative"? Or Py_ssize_t variable size_z that takes 
values size_a and -size_a?

--

___
Python tracker 

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

[issue27755] Retire DynOptionMenu with a ttk Combobox

[Mark Roseman]

Mark Roseman added the comment:

Justin, as you say, I think your patch is entirely reasonable as an interim 
step, as eventually doing a broader improvement on the preferences dialog as 
suggested in #24781 makes sense. 

My reworked version used Combobox in similar ways; I think we can safely do 
away with the wrapper class and just use the ttk widget directly in the dialog 
(as the widget already handles the dynamic changes to the list, which the old 
tk_optionMenu didn't)

--

___
Python tracker 

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

[issue27706] Random.seed, whose purpose is purportedly determinism, behaves non-deterministically with strings due to hash randomization

[Glyph Lefkowitz]

Glyph Lefkowitz added the comment:

Changing the affected version to just 2.7.

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

[issue27706] Random.seed, whose purpose is purportedly determinism, behaves non-deterministically with strings due to hash randomization

[Glyph Lefkowitz]

Glyph Lefkowitz added the comment:

It does seem to be stable on python 3, but on python 2.7 it's definitely a 
problem:

$ python -Rc "import random; r=random.Random('abc'); print(''.join(map(str, 
(r.randrange(10) for x in range(10, hash('abc'))"
('9553343809', -1972659830997666042)
$ python -Rc "import random; r=random.Random('abc'); print(''.join(map(str, 
(r.randrange(10) for x in range(10, hash('abc'))"
('5519010739', 5520208254012363023)
$ python -Rc "import random; r=random.Random('abc'); print(''.join(map(str, 
(r.randrange(10) for x in range(10, hash('abc'))"
('7519888435', 3560222494758569319)
$ python -Rc "import random; r=random.Random('abc'); print(''.join(map(str, 
(r.randrange(10) for x in range(10, hash('abc'))"
('9612648103', 4134882069837806740)

--

___
Python tracker 

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

Re: What's the best way to minimize the need of run time checks?

[Michael Selik]

On Sun, Aug 14, 2016 at 11:01 AM  wrote:

> On Sunday, August 14, 2016 at 7:09:47 AM UTC+1, Paul Rubin wrote:
> > Steven D'Aprano writes:
> > > If the Python community rallies around this "record" functionality and
> > > takes to it like they took too namedtuple
> >
> > I like namedtuple and I think that it's a feature that they're modified
> > by making a new copy.  I know that has overhead but it's palpably
> > bug-avoidant.  I've used them extensively in some programs and they took
> > a considerable burden off my mind compared to using something like
> > structs or records.
>
> You might find this https://glyph.twistedmatrix.com/2016/08/attrs.html an
> interesting read.
>

I disagree with a few points from that blog post.

1. I don't mind typing so much. I like to be explicit. The attrs library
uses some overly-concise abbreviations. For example, what's the meaning of
``@attrs.s`` or ``attrs.ib``?
2. When inheriting from a namedtuple, I use the same class name for the
base and the child, so my reprs look good.
3. I don't bother to fieldnames.split() when passing fieldnames as a
space-separated string, because the split is unnecessary.
4. I *like* that namedtuple is backwards-compatible with tuples, so that
refactoring from tuples to namedtuples is easy.
5. Inheritance is useful. Sure, there are times it fails, but that's true
for any technique.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: I am new to python. I have a few questions coming from an armature!

[Jussi Piitulainen]

MRAB writes:

> On 2016-08-17 12:24, Jussi Piitulainen wrote:
>> BartC writes:
>>
>>> On 17/08/2016 07:39, Steven D'Aprano wrote:
 Rather than ask why Python uses `trueval if cond else falseval`, you
 should ask why C uses `cond ? trueval : falseval`. Is that documented
 anywhere?
>>>
>>> I'm not fond of C's a ? b : c but the principle is sound. I generally
>>
>> [- -]
>>
>>> Anyway a?b:c was existing practice. At least the order of a,b,c could
>>> have been retained if not the exact syntax.
>>
>> The original was (c1 -> e1, c2 -> e2, ..., cn -> en) in John
>> McCarthy's 1960 paper on symbolic expressions, with an actual arrow
>> glyph in place of hyphen-greater-than.
>>
> [snip]
>
> BCPL, the ancestor of  C, had:
>
> a -> b, c

Nice. Add a redundant pair of parentheses and it's the same. (When used
as an expression, a final else-branch is mandatory-ish.)

But C uses -> for something else, I think. And other languages use it
for lambda expressions (succesfully, I think, but then they don't have
it available for this purpose).
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue26988] Add AutoNumberedEnum to stdlib

[Ethan Furman]

Ethan Furman added the comment:

Raymond, I appreciate your review and your poll.  I am open to removing 
AutoEnum, but would like to give it a couple more weeks of review.  (I'll post 
on py-dev.)

The only point you made that I will firmly refute is the "unexpected breakage": 
you ran your test script with the -m "run module as script" flag, which is what 
caused the problem.

--

___
Python tracker 

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

[issue27181] Add geometric mean to `statistics` module

[Mark Dickinson]

Mark Dickinson added the comment:

> self.assertEqual(self.nroot(x**12, 12), float(x))
> AssertionError: 1.1865 != 1.1868

That looks like a case where the test should simply be weakened to an 
`assertAlmostEqual` with a suitable tolerance; there's no strong reason to 
expect that `nroot` will give a faithfully rounded result in this case or any 
other.

--

___
Python tracker 

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

[issue27786] longobject.c: simplify x_sub(), inline _PyLong_Negate()

[STINNER Victor]

STINNER Victor added the comment:

Updated patch.

--
Added file: http://bugs.python.org/file44135/x_sub-2.patch

___
Python tracker 

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

Re: JSON confusion

[Steve Simmons]

On 17/08/2016 17:49, Jon Ribbens wrote:

On 2016-08-17, Steve Simmons  wrote:

I'm trying to write a small utility to find the closest railway station
to a given (UK) postcode but the result is in JSON and I'm not familiar
with it. I've got as far as extracting the JSON object and I can print
the first level elements ("success" and "result") but I've totally
confused myself about how to delve into the rest of the data structure.
Can anyone point me to a 'how-to' for tackling a fairly complex SJON
object or give me some pointers. ... or maybe point out if I'm taking an
unnecessarily complex approach. Initially, I'm Looking to extract
'stationname', 'distance' and one or two of the coordinate pairs. To be
honest, I'd rather have some hints rather than the whole solution
otherwise I'll not learn anything :-) SteveS

It's not clear what the problem is.
Yes, that was the problem!  I wasn't sure if I was being stupid (yes!) 
about the Python or the JSON.  Turns out, it was a bit of both ;-)

Does this help:

   print(p_json["result"][0]["stationname"])
   print(p_json["result"][0]["latlong"]["coordinates"])

?

Yes, immensely.


(To extract an item from a JSON object you index it with a string,
e.g. ["foo"]; to extract an item from an array you use an integer,
e.g. [0].)

Thanks very much, hopefully that'll set me on my way.

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

Re: JSON confusion

[Jon Ribbens]

On 2016-08-17, Steve Simmons  wrote:
> I'm trying to write a small utility to find the closest railway station 
> to a given (UK) postcode but the result is in JSON and I'm not familiar 
> with it. I've got as far as extracting the JSON object and I can print 
> the first level elements ("success" and "result") but I've totally 
> confused myself about how to delve into the rest of the data structure. 
> Can anyone point me to a 'how-to' for tackling a fairly complex SJON 
> object or give me some pointers. ... or maybe point out if I'm taking an 
> unnecessarily complex approach. Initially, I'm Looking to extract 
> 'stationname', 'distance' and one or two of the coordinate pairs. To be 
> honest, I'd rather have some hints rather than the whole solution 
> otherwise I'll not learn anything :-) SteveS

It's not clear what the problem is. Does this help:

  print(p_json["result"][0]["stationname"])
  print(p_json["result"][0]["latlong"]["coordinates"])

?

(To extract an item from a JSON object you index it with a string,
e.g. ["foo"]; to extract an item from an array you use an integer,
e.g. [0].)
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue27785] Module platform: Versions of Windows

[Steve Dower]

Steve Dower added the comment:

Platform module version 1.0.8 added support for Windows 8.1 and later. You 
actually downgraded to 1.0.7, which is why you lost functionality.

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

[issue27786] longobject.c: simplify x_sub(), inline _PyLong_Negate()

[Brett Cannon]

Brett Cannon added the comment:

That works too. :)

--

___
Python tracker 

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

JSON confusion

[Steve Simmons]

I'm trying to write a small utility to find the closest railway station 
to a given (UK) postcode but the result is in JSON and I'm not familiar 
with it. I've got as far as extracting the JSON object and I can print 
the first level elements ("success" and "result") but I've totally 
confused myself about how to delve into the rest of the data structure. 
Can anyone point me to a 'how-to' for tackling a fairly complex SJON 
object or give me some pointers. ... or maybe point out if I'm taking an 
unnecessarily complex approach. Initially, I'm Looking to extract 
'stationname', 'distance' and one or two of the coordinate pairs. To be 
honest, I'd rather have some hints rather than the whole solution 
otherwise I'll not learn anything :-) SteveS def main():

import urllib
import urllib.request
import urllib.parse
import urllib.response
import json

url ='https://data.gov.uk/data/api/service/transport/naptan_railway_stations/postcode?postcode=CT16+1ez=2' 
req = urllib.request.urlopen(url)


req_json = req.read()
str_json = req_json.decode("utf-8")

p_json = json.loads(str_json)
print(p_json)
print ('==')
print(repr(p_json))
print('SUCCESS: ',repr(p_json['success']))
print ('==')
print('RESULT : ',repr(p_json['result']))

if __name__ =="__main__":
main()

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

[issue27786] longobject.c: simplify x_sub(), inline _PyLong_Negate()

[STINNER Victor]

STINNER Victor added the comment:

> I would add a comment as to why the assertion is there, otherwise it seems 
> somewhat random that it exists.

Hum. Maybe it's even better to remove the assertion :-)

--

___
Python tracker 

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

[issue27786] longobject.c: simplify x_sub(), inline _PyLong_Negate()

[Brett Cannon]

Brett Cannon added the comment:

I would add a comment as to why the assertion is there, otherwise it seems 
somewhat random that it exists.

--
nosy: +brett.cannon

___
Python tracker 

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

[issue27781] Change sys.getfilesystemencoding() on Windows to UTF-8

[Brett Cannon]

Changes by Brett Cannon :


--
nosy: +brett.cannon

___
Python tracker 

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

[issue27785] Module platform: Versions of Windows

[Brett Cannon]

Changes by Brett Cannon :


--
nosy:  -brett.cannon

___
Python tracker 

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

[issue27785] Module platform: Versions of Windows

[Brett Cannon]

Changes by Brett Cannon :


--
nosy: +brett.cannon

___
Python tracker 

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

[issue27788] platform module's version number doesn't match its docstring

[Brett Cannon]

New submission from Brett Cannon:

Not sure if it's worth keeping the version number around, but ATM the module 
has __version__ set to 1.0.7 while the docstring mentions a 1.0.8.

--
components: Library (Lib)
messages: 272964
nosy: brett.cannon, lemburg
priority: normal
severity: normal
status: open
title: platform module's version number doesn't match its docstring
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

Re: I am new to python. I have a few questions coming from an armature!

[MRAB]

On 2016-08-17 12:24, Jussi Piitulainen wrote:

BartC writes:


On 17/08/2016 07:39, Steven D'Aprano wrote:

Rather than ask why Python uses `trueval if cond else falseval`, you
should ask why C uses `cond ? trueval : falseval`. Is that documented
anywhere?


I'm not fond of C's a ? b : c but the principle is sound. I generally


[- -]


Anyway a?b:c was existing practice. At least the order of a,b,c could
have been retained if not the exact syntax.


The original was (c1 -> e1, c2 -> e2, ..., cn -> en) in John McCarthy's
1960 paper on symbolic expressions, with an actual arrow glyph in place
of hyphen-greater-than.


[snip]

BCPL, the ancestor of  C, had:

a -> b, c

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

[issue27781] Change sys.getfilesystemencoding() on Windows to UTF-8

[Steve Dower]

Steve Dower added the comment:

Ah I see, if we end up sticking with MBCS and offering a switch to enable 
UTF-8. In that case, we'll definitely ensure the flag is the same (but I'm 
hopeful we will just make the reliable behavior on Windows the default, so it 
won't matter).

--

___
Python tracker 

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

[issue27781] Change sys.getfilesystemencoding() on Windows to UTF-8

[STINNER Victor]

STINNER Victor added the comment:

Steve Dower added the comment:
> By portable, do you mean not using an environment variable?

I mean that "python3 -X utf8" should force sys.getfilesystemencoding()
to UTF-8 on UNIX/BSD, it would ignore the current locale setting.

--

___
Python tracker 

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

[issue27781] Change sys.getfilesystemencoding() on Windows to UTF-8

[Steve Dower]

Steve Dower added the comment:

By portable, do you mean not using an environment variable?

Command line parsing is potentially affected by this on Windows - I'd have to 
look deeper - as command lines are provided as UTF-16. But we may not ever 
expose them as bytes.

I don't even know that this matters on the UNIX/BSD side as the file system 
encoding provided there is correct, no? It's just Windows where the file system 
encoding used for bytes doesn't match what the file system actually uses.

I was afraid a PEP would be necessary out of this, but I want to see how the 
python-dev discussion goes first.

--

___
Python tracker 

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

Re: I am new to python. I have a few questions coming from an armature!

[Marko Rauhamaa]

Grant Edwards :

> On 2016-08-17, Marko Rauhamaa  wrote:
>
>> Somewhat analogously, I remember how confusing it was to learn formal
>> logic in college. I was having a hard time getting the point of
>> definitions like:
>>
>>(x ∧ y) is true iff x is true and y is true
>>
>> That's because I had learned in highschool that "x ∧ y" was just an
>> abbreviation of "x and y".
>
> It is. The expression "x ∧ y" is the same as "x and y". And that
> expression is true "iff x is true and y is true". It's just a sligtly
> more explicit way of writing the expression...

Well, not quite.

Notice the word "and" after "iff". That word is on a different plane
than "∧". The word "and" is on the semantic plane while "∧" is part of
the syntax. (Of course, that would be true even if "∧" were written
"and".)

The formal sentence template

   (x ∧ y)

contains the symbols "(", "∧" and ")". However, "x" and "y" are not part
of the formalism; rather, they are semantic placeholders for arbritrary
formal sentences.

The rest of the definition:

   is true iff x is true and y is true

is plain-English semantics.

In particular, the definition is *not* identical with the formal
sentence:

   (x ∧ y) ↔ (x ∧ y)


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

[issue27731] Opt-out of MAX_PATH on Windows 10

[Steve Dower]

Steve Dower added the comment:

No, the flag that we add to the binary is backwards compatible. Earlier 
versions will just ignore it.

--

___
Python tracker 

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