Re: Configuring an object via a dictionary

[Anders Munch via Python-list]

dn wrote:
>Loris Bennett wrote:
>> However, with a view to asking forgiveness rather than
>> permission, is there some simple way just to assign the dictionary
>> elements which do in fact exist to self-variables?
>
>Assuming config is a dict:
>
>   self.__dict__.update( config )

Here's another approach:

config_defaults = dict(
 server_host='localhost',
 server_port=443,
# etc.
)
...
def __init__(self, config):
self.conf = types.SimpleNamespace(**{**config_defaults, **config})

This gives you defaults, simple attribute access, and avoids the risk of name 
collisions that you get when updating __dict__.

Using a dataclass may be better:

@dataclasses.dataclass
class Settings:
 group_base : str
 server_host : str = 'localhost'
 server_port : int = 443
...
def __init__(self, config):
self.conf = Settings(**config)

regards, Anders

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

[issue43323] UnicodeEncodeError: surrogates not allowed when parsing invalid charset

[Anders Kaseorg]

Anders Kaseorg  added the comment:

It could and does, as quoted in my original report.

Content-Type: text/plain; charset*=utf-8”''utf-8%E2%80%9D

That’s a U+201D right double quotation mark.

This is not a valid charset for the charset of course, but it seems like the 
code was intended to handle an invalid charset value without crashing, so it 
should also handle an invalid charset charset (despite the absurdity of the 
entire concept of a charset charset).

--

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

[issue46637] Incorrect error message: "missing 1 required positional argument"

[Anders Hovmöller]

Anders Hovmöller  added the comment:

For `foo(a, /, b)`, it could be:

"TypeError: foo() missing 1 required argument 'a', and one required positional 
argument 'b'.

If we start on this road there are some more, like for `def foo(a, *, b)` you 
get the error "TypeError: foo() missing 1 required positional argument: 'a'" 
which leaves out that the keyword only argument is also required. 

Another solution would be something like:

TypeError: foo() missing 3 required arguments: 'a' (positional only), 'b', 'c' 
(keyword only)

This solution scales to the worst complex cases, and is a lot clearer imo. 
Could even be further improved with some nicer formatting:

TypeError: foo() missing 3 required arguments: 
'a' (positional only)
'b'
'c' (keyword only)

But that might be a bit overkill :)

--

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

[issue46637] Incorrect error message: "missing 1 required positional argument"

[Anders Hovmöller]

Anders Hovmöller  added the comment:

Just dropping the word "positional" is very good. That word is a lie, and just 
removing it makes it true.

--

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

[issue46637] Incorrect error message: "missing 1 required positional argument"

[Anders Hovmöller]

New submission from Anders Hovmöller :

>>> def foo(a):
... pass
... 
>>> foo()
Traceback (most recent call last):
  File "", line 1, in 
TypeError: foo() missing 1 required positional argument: 'a'

This error is incorrect. It says "positional argument", but it's just 
"argument". The proof is that if you call it with

foo(a=3)

it works fine.

--
components: Interpreter Core
messages: 412510
nosy: Anders.Hovmöller
priority: normal
severity: normal
status: open
title: Incorrect error message: "missing 1 required positional argument"
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

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

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

[Anders Kaseorg]

Anders Kaseorg  added the comment:

> While optparse that it isn't being developed further, therebut will not
> be taken away.  IIRC the reason for this was that it too had become
> difficult to build out and that is what necessitated the creation of
> argparse -- there wasn't clean way to add the desired features
> (subparsers, actions, etc).

My concern is not that optparse will be taken away.  My concern is that the 
documentation incorrectly discourages its use.

https://docs.python.org/3/library/optparse.html
“Deprecated since version 3.2: The optparse module is deprecated and will not 
be developed further; development will continue with the argparse module.”

Given that the apparent conclusion of this bug is that argparse has also become 
too difficult to fix, either argparse should be deprecated for exactly the same 
reason, or optparse should be un-deprecated.

Most programs don’t need the extra features of argparse, and optparse doesn’t 
have this bug, so optparse is a better default choice; the documentation should 
not be encouraging argparse over it.

--

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

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

[Anders Kaseorg]

Anders Kaseorg  added the comment:

If argparse will not be developed further to fix this bug, then we should undo 
the deprecation of optparse in the documentation 
(https://bugs.python.org/issue37103), since the stated justification for that 
deprecation was that optparse will not be developed further.

The documentation should encourage programmers to use correct libraries, and 
optparse is correct here where argparse is not.  People who need the extra 
features of argparse and aren’t bothered by its incorrectness are welcome to 
decide to use it, but this is not the right default decision for the 
documentation to promote.

--

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

Create a contact book

[anders Limpan]

i would like to create a contact book were you can keep track of your friends. 
With this contact book you will both be able to add friends and view which 
friends that you have added. anyone interested in helping me out with this one 
?=)
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue44967] pydoc should return non-zero exit code when a query is not found

[Gregory Anders]

Change by Gregory Anders :


--
keywords: +patch
pull_requests: +26323
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/27868

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

[issue44967] pydoc should return non-zero exit code when a query is not found

[Gregory Anders]

New submission from Gregory Anders :

Currently pydoc returns an exit code of zero no matter what, even with e.g.

pydoc lsjdfkdfj

However, the ability to know whether or not pydoc successfully found a result 
is useful in tools that embed pydoc in some way.

Here's one use case: Vim and Neovim have a feature that allows a user to run an 
external command for the keyword under the cursor (keywordprg). In Python 
files, this defaults to pydoc. In Neovim, we would like to automatically close 
the PTY buffers that we create for these processes when they finish without any 
errors, but if it returns a non-zero exit code we want to keep the PTY buffer 
open so the user can see what went wrong. Because pydoc returns immediately 
when it fails to find a match and does not indicate that it failed via a return 
code, the PTY buffer is closed immediately with no indication to the user that 
anything went wrong.

I have a patch prepared for this that I will link to the issue.

--
components: Demos and Tools
messages: 400012
nosy: gpanders
priority: normal
severity: normal
status: open
title: pydoc should return non-zero exit code when a query is not found
type: enhancement

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

[issue44680] Reference cycles from a WeakKeyDictionary value to its key aren’t collected

[Anders Kaseorg]

Anders Kaseorg  added the comment:

> extra_states[o] = ExtraState(obj)

(Typo for extra_states[obj] = ExtraState(obj), obviously.)

--

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

[issue44680] Reference cycles from a WeakKeyDictionary value to its key aren’t collected

[Anders Kaseorg]

New submission from Anders Kaseorg :

Because WeakKeyDictionary unconditionally maintains strong references to its 
values, the garbage collector fails to collect a reference cycle from a 
WeakKeyDictionary value to its key.  For example, the following program 
unexpectedly leaks memory:

from weakref import WeakKeyDictionary
class C: pass
d = WeakKeyDictionary()
while True:
c = C()
d[c] = [c]

I would expect a WeakKeyDictionary value to be marked live _if_ its key is 
marked live, not unconditionally.  This could be implemented with garbage 
collector support for ephemerons 
(https://www.researchgate.net/publication/221320677_Ephemerons_A_New_Finalization_Mechanism).

To motivate this issue, a typical use of WeakKeyDictionary is as a hygienic 
replacement for patching extra properties into third-party objects:

# before:
obj._extra_state = ExtraState(obj)
# after:
extra_states = WeakKeyDictionary()
extra_states[o] = ExtraState(obj)

However, such a conversion will introduce this memory leak if ExtraState(obj) 
has any transitive references to obj.

This leak does not occur in JavaScript:

class C {}
const d = new WeakMap();
while (true) {
  const c = new C();
  d[c] = [c];
}

--
components: Library (Lib)
messages: 397841
nosy: andersk
priority: normal
severity: normal
status: open
title: Reference cycles from a WeakKeyDictionary value to its key aren’t 
collected
type: resource usage
versions: Python 3.9

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

[issue44283] Add jump table for certain safe match-case statements

[Anders Munch]

Anders Munch  added the comment:

Are you sure you want to do this?

This optimisation is not applicable if the matched values are given symbolic 
names.  You would be encouraging people to write bad code with lots of 
literals, for speed.

--
nosy: +AndersMunch

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

[issue43323] UnicodeEncodeError: surrogates not allowed when parsing invalid charset

[Anders Kaseorg]

New submission from Anders Kaseorg :

We ran into a UnicodeEncodeError exception using email.parser to parse this 
email 
<https://lists.cam.ac.uk/pipermail/cl-isabelle-users/2021-February/msg00135.html>,
 with full headers available in the raw archive 
<https://lists.cam.ac.uk/pipermail/cl-isabelle-users/2021-February.txt>.  The 
offending header is hilariously invalid:

Content-Type: text/plain; charset*=utf-8”''utf-8%E2%80%9D

but I’m filing an issue since the parser is intended to be robust against 
invalid input.  Minimal reproduction:

>>> import email, email.policy
>>> email.message_from_bytes(b"Content-Type: text/plain; 
>>> charset*=utf-8\xE2\x80\x9D''utf-8%E2%80%9D", policy=email.policy.default)
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/local/lib/python3.10/email/__init__.py", line 46, in 
message_from_bytes
return BytesParser(*args, **kws).parsebytes(s)
  File "/usr/local/lib/python3.10/email/parser.py", line 123, in parsebytes
return self.parser.parsestr(text, headersonly)
  File "/usr/local/lib/python3.10/email/parser.py", line 67, in parsestr
return self.parse(StringIO(text), headersonly=headersonly)
  File "/usr/local/lib/python3.10/email/parser.py", line 57, in parse
return feedparser.close()
  File "/usr/local/lib/python3.10/email/feedparser.py", line 187, in close
self._call_parse()
  File "/usr/local/lib/python3.10/email/feedparser.py", line 180, in _call_parse
self._parse()
  File "/usr/local/lib/python3.10/email/feedparser.py", line 256, in _parsegen
if self._cur.get_content_type() == 'message/delivery-status':
  File "/usr/local/lib/python3.10/email/message.py", line 578, in 
get_content_type
value = self.get('content-type', missing)
  File "/usr/local/lib/python3.10/email/message.py", line 471, in get
return self.policy.header_fetch_parse(k, v)
  File "/usr/local/lib/python3.10/email/policy.py", line 163, in 
header_fetch_parse
return self.header_factory(name, value)
  File "/usr/local/lib/python3.10/email/headerregistry.py", line 608, in 
__call__
return self[name](name, value)
  File "/usr/local/lib/python3.10/email/headerregistry.py", line 196, in __new__
cls.parse(value, kwds)
  File "/usr/local/lib/python3.10/email/headerregistry.py", line 453, in parse
kwds['decoded'] = str(parse_tree)
  File "/usr/local/lib/python3.10/email/_header_value_parser.py", line 126, in 
__str__
return ''.join(str(x) for x in self)
  File "/usr/local/lib/python3.10/email/_header_value_parser.py", line 126, in 

return ''.join(str(x) for x in self)
  File "/usr/local/lib/python3.10/email/_header_value_parser.py", line 798, in 
__str__
for name, value in self.params:
  File "/usr/local/lib/python3.10/email/_header_value_parser.py", line 783, in 
params
value = value.decode(charset, 'surrogateescape')
UnicodeEncodeError: 'utf-8' codec can't encode characters in position 5-7: 
surrogates not allowed

--
components: email
messages: 387685
nosy: andersk, barry, r.david.murray
priority: normal
severity: normal
status: open
title: UnicodeEncodeError: surrogates not allowed when parsing invalid charset
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

[issue43115] locale.getlocale fails if locale is set

[Anders Munch]

Anders Munch  added the comment:

>> What does use getlocale is time.strptime and datetime.datetime.strptime, so 
>> when getlocale fails, strptime fails.

> Would they work with getlocale() returning None for the encoding ?

Yes. All getlocale is used for in _strptime.py is comparing the value returned 
to the previous value returned.

I expect changing _strptime._getlang to return the unnormalized value 
locale._setlocale(locale.LC_TIME, None) would work as well and more robustly.

--

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

[issue43115] locale.getlocale fails if locale is set

[Anders Munch]

Anders Munch  added the comment:

> BTW: What is wxWidgets doing with the returned values ?

wxWidgets doesn't call getlocale, it's a C++ library (wrapped by wxPython) that 
uses C setlocale.

What does use getlocale is time.strptime and datetime.datetime.strptime, so 
when getlocale fails, strptime fails.

> We could enhance this to return None for the encoding instead
> of raising an exception, but would this really help ?

Very much so.

Frankly, I don't get the impression that the current locale preferred encoding 
is used for *anything*.  Other than possibly having a role in implementing 
getpreferredencoding.

> Alternatively, we could add "en_DE" to the alias table and set
> a default encoding to use. 

Where would you get a complete list of all the new aliases that would need be 
to be added?

As the "en_DE" example shows, you'd need all combinations of languages and 
regions.  That's going to be a very long list.

--

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

[issue43115] locale.getlocale fails if locale is set

[Anders Munch]

Anders Munch  added the comment:

getlocale is documented to return None for the encoding if no encoding can be 
determined.  There's no need to guess.

I can't change the locale.setlocale call, because where I'm actually having the 
problem, I'm not even calling locale.setlocale: wxWidgets is calling C 
setlocale, that's where it comes from.

wxWidgets aside, it doesn't seem right that getlocale fails when setlocale 
succeeded.

--

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

[issue43115] locale.getlocale fails if locale is set

[Anders Munch]

Anders Munch  added the comment:

I discovered that this can happen with underscores as well:

Python 3.8.7 (tags/v3.8.7:6503f05, Dec 21 2020, 17:59:51) [MSC v.1928 64 bit 
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_ALL, 'en_DE')
'en_DE'
>>> locale.getlocale()
Traceback (most recent call last):
  File "", line 1, in 
  File "C:\flonidan\env\Python38-64\lib\locale.py", line 591, in getlocale
return _parse_localename(localename)
  File "C:\flonidan\env\Python38-64\lib\locale.py", line 499, in 
_parse_localename
raise ValueError('unknown locale: %s' % localename)
ValueError: unknown locale: en_DE

locale.setlocale does validate input - if you write nonsense in the second 
argument then you get an exception, "locale.Error: unsupported locale setting". 
 So I'm guessing the en_DE locale is actually being set here, and the problem 
is solely about getlocale making unfounded assumptions about the format.

Same thing happens in 3.10.0a4.

--

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

[issue43115] locale.getlocale fails if locale is set

[Anders Munch]

New submission from Anders Munch :

getlocale fails with an exception when the string returned by _setlocale is 
already an RFC 1766 language tag.

Example:

Python 3.10.0a4 (tags/v3.10.0a4:445f7f5, Jan  4 2021, 19:55:53) [MSC v.1928 64 
bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_ALL, 'en-US')
'en-US'
>>> locale.getlocale()
Traceback (most recent call last):
  File "", line 1, in 
  File "C:\flonidan\env\Python310\lib\locale.py", line 593, in getlocale
return _parse_localename(localename)
  File "C:\flonidan\env\Python310\lib\locale.py", line 501, in _parse_localename
raise ValueError('unknown locale: %s' % localename)
ValueError: unknown locale: en-US

Expected result:
  ('en-US', None)

See https://github.com/wxWidgets/Phoenix/issues/1637 for an example of the 
ensuing problems.  wx.Locale calls C setlocale directly, but, as far as I can 
see, correctly, using dashes in the language code which is consistent with not 
only RFC 1766 but also the examples in Microsoft's documentation 
(https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/setlocale-wsetlocale?view=msvc-160).
  CPython seems to assume underscored names such as 'en_US' instead, as shown 
by getdefaultlocale inserting an underscore.

--
components: Library (Lib), Windows
messages: 386203
nosy: AndersMunch, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: locale.getlocale fails if locale is set
versions: Python 3.10, Python 3.8, Python 3.9

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

[issue37909] Thread pool return ref hold memory

[Anders]

Anders  added the comment:

Note: due to a change in Python 3.8 this example would be a lot less noticeable 
if tested. The problem remains the same though.

If you run this snippet with Python 3.7, which is before the thread reuse was 
introduced into the ThreadPoolExecutor, each thread will keep around 600mb of 
memory in use.

This can be solved by shutting down the ThreadPoolExecutor which this example 
does.

Now, the big problem is that asyncio uses a long-running ThreadPoolExecutor, 
per default, for run_in_executor. Those threads will stay around forever and 
consume memory until the application is shut down.

If you have a job that consumes a lot of memory for a short period of time and 
use any long-running ThreadPoolExecutor then the memory will just keep growing 
as the job hits various threads that are never cleaned up.

--
import asyncio
import concurrent
import threading


def prepare_a_giant_list():
d = {}
for i in range(1000):
d[i] = {}
for j in range(1000):
d[i][j] = {}
for k in range(30):
d[i][j][k] = 'a' * 1000
del d

th_num = threading.active_count()
print("Thread number is {}".format(th_num))


async def main():
loop = asyncio.get_running_loop()
with concurrent.futures.ThreadPoolExecutor(max_workers=20) as 
async_executor:
await loop.run_in_executor(async_executor, prepare_a_giant_list)
await asyncio.sleep(5)
await loop.run_in_executor(async_executor, prepare_a_giant_list)
await asyncio.sleep(5)
await loop.run_in_executor(async_executor, prepare_a_giant_list)
await asyncio.sleep(5)
await loop.run_in_executor(async_executor, prepare_a_giant_list)
await asyncio.sleep(5)
print('Done!')
await asyncio.sleep(15)


if __name__ == "__main__":
asyncio.run(main())
--

--
nosy: +johndoee
versions: +Python 3.6, Python 3.7

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

[issue32308] Replace empty matches adjacent to a previous non-empty match in re.sub()

[Anders Hovmöller]

Anders Hovmöller  added the comment:

We were also bitten by this. In fact we still run a compatibility shim in 
production where we log if the new and old behavior are different. We also 
didn't think this "bug fix" made sense or was treated with the appropriate 
gravity in the release notes. 

I understand the logic in the bug tracker and they it matches other languages 
is good. But the bahvior also makes no sense for the .* case unfortunately. 

> On 21 Jan 2020, at 05:56, David Barnett  wrote:
> 
> 
> David Barnett  added the comment:
> 
> We were also bitten by this behavior change in 
> https://github.com/google/vroom/issues/110. I'm kinda baffled by the new 
> behavior and assumed it had to be an accidental regression, but I guess not. 
> If you have any other context on the BDFL conversation and reasoning for 
> calling this behavior correct, I'd love to see additional info.
> 
> --
> nosy: +mu_mind
> 
> ___
> Python tracker 
> <https://bugs.python.org/issue32308>
> ___

--

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

[issue38673] REPL shows continuation prompt (...) when comment or space entered

[Anders Lorentsen]

Anders Lorentsen  added the comment:

As a person without much experience, it sounded like a simple enough task, but 
having dug a bit, I found it quite complicated. It seems to me that the 
interpreter loop (in the standard REPL, that you get when you start ./python, 
blocks for input somewhere inside a massive function called 'parsetok' (in 
Parser/parsetok.c). Now, I could maybe investigate further, to have it return 
to the interpreter loop if it reads a comment (or empty line), but I'm afraid 
to mess up something.

>From my understanding, there aren't that many other choices, because 
>parsetok() doesn't return before you finish the statement (in other words, it 
>does not return if you type a comment line or a blank line - it instead waits 
>for more input, as indicated by the '... ').

Am I way off in concluding that this would be a change to the parser?

--
nosy: +Phaqui

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

Re: Recursive method in class

[Anders Märak Leffler]

What do you mean by transformed? This is probably your understanding
already, but a further consequence of when arguments are evaluated
plus what you said about data attributes is that the fib(self, n - 1)
call will follow the standard LEGB-lookup of whatever "fib" is, from
the point of view of the function object. As far as I know, there is
no transformation of these scopes - either when it comes to creating
the class, or creating the instances. (self is just the instance,
passed as an argument.)

Cf when you change a binding:

>>> def factorial(self, n):
... if not n:
... return 1
... else:
... return n * factorial(self, n - 1)
...
>>> Dummy = type("DummyObject", (object, ), {"factorial" : factorial})
>>> instance = Dummy()
>>> def factorial(self, n):
... print("Hello!")
... return 999
...
>>> instance.factorial(5)   # Where will the call go ("old" or "new" 
>>> factorial?)? Where will possible recursive calls go (and why)?
Hello!
4995

Oh, and as others have pointed out on this list - you/whoever runs the
system sending the mail might want to change the return address.
n...@gmail.com is somewhat consistently classed as spam.



//Anders

PS. We could further complicate this by adding a call to
self.factorial in the new function, but let's not go there. :)


On Mon, Sep 30, 2019 at 9:58 AM ast  wrote:
>
> Le 27/09/2019 à 14:26, Jan van den Broek a écrit :
> > On 2019-09-27, ast  wrote:
> >> Is it feasible to define a recursive method in a class ?
> >> (I don't need it, it's just a trial)
> >>
> >> Here are failing codes:
> >>
> >>
> >> class Test:
> >>   def fib(self, n):
> >>   if n < 2: return n
> >>   return fib(self, n-2) + fib(self, n-1)
> >self.fib(...)
> >
> > [Schnipp]
> >
>
> Yes you are right. I forgot that class methods
> don't see class attributes
>
> An other workaround:
>
>   def fib(self, n):
>   if n < 2: return n
>   return Test.fib(self, n-2) + Test.fib(self, n-1)
>
> It comes from https://www.pythonsheets.com/notes/python-object.html
>
>  >>> def fib(self, n):
> ... if n <= 2:
> ... return 1
> ... return fib(self, n-1) + fib(self, n-2)
> ...
>  >>> Fib = type('Fib', (object,), {'val': 10,
> ...   'fib': fib})
>  >>> f = Fib()
>  >>> f.val
> 10
>  >>> f.fib(f.val)
> 55
>
> So it means that when classes are constructed explicitely
> with type(name, bases, dict_), some methods are transformed
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue31956] Add start and stop parameters to the array.index()

[Anders Lorentsen]

Anders Lorentsen  added the comment:

I have actually managed to lost my local branch of this fix, though I assume I 
can just start another one, manually copy over the changes, somehow mark this 
current PR as cancelled, aborted, or in my option the best: 
"replaced/superseeded by: [new PR]". In any case, there were discussions that 
seem to be unresolved, allow me to summarize:

* Document that index() raises ValueError when *value* is not found?
> vstinner: We don't do this, remove this addition.
> serhiy: Other index() methods does this.
---> My patch current does this. Who has final saying here?

* 'start' and 'stop' arguments are not keyword arguments, and also not shown in 
the signature as '.. start=0 ..' for this very reason (it may make them look as 
keyword arguments). Also, this lines up with list.index() for consistency. 
Wishes about changing this for all index()-methods has been expressed, but it 
seems to be consensus on doing this in unison for all index()-methods at once, 
in a bigger change... So, what is currently in the PR is good enough for now, 
or?

* Wording in documentation: Clarify that "the returned index is still relative 
to the start of the array, not the searched sub sequence" or not?

* Comment in the code about checking the length of the array on each iteration? 
There were comments about it being "confusing" - and while I agree, the other 
index()-code for lists, does not comment on this. Again I followed the path of 
most consistency, but I did receive comments about this. Yes to descriptive 
comments, or not?



Generally speaking: In the end, all I really did was mimic how list.index() is 
both written and documented, and that's when discussions about issues related 
to that started occurring, and so I now remember that I halted my PR, waiting 
for these issues to be resolved.

--

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

[issue31956] Add start and stop parameters to the array.index()

[Anders Lorentsen]

Anders Lorentsen  added the comment:

As far as I can recall, the patch is generally speaking good to go. A number of 
discussions arose on various details, however. In any event, I'll take a look 
at it during the next few days.

--

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

[issue37103] Undo deprecation of optparse

[Anders Kaseorg]

New submission from Anders Kaseorg :

The optparse library is currently marked in the documentation as deprecated in 
favor of argparse.  However, argparse uses a nonstandard reinterpretation of 
Unix command line grammars that makes certain arguments impossible to express, 
and causes scripts to break when ported from optparse to argparse.  See the bug 
report I filed nine years ago:

https://bugs.python.org/issue9334
argparse does not accept options taking arguments beginning with dash 
(regression from optparse)

The conclusion of the core developers (e.g. msg309691) seems to have been that 
although it’s a valid bug, it can’t or won’t be fixed with the current argparse 
architecture.

I was asked by another core developer to file a bug report for the 
de-deprecation of optparse 
(https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/20),
 so here it is.

--
assignee: docs@python
components: Documentation, Library (Lib)
messages: 343997
nosy: andersk, docs@python
priority: normal
severity: normal
status: open
title: Undo deprecation of optparse
versions: Python 3.8

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

[issue32308] Replace empty matches adjacent to a previous non-empty match in re.sub()

[Anders Hovmöller]

Anders Hovmöller  added the comment:

That might be true, but that seems like a weak argument. If anything, it means 
those others are broken. What is the logic behind "(.*)" returning the entire 
string (which is what you asked for) and exactly one empty string? Why not two 
empty strings? 3? 4? 5? Why not an empty string at the beginning? It makes no 
practical sense.

We will have to spend considerable effort to work around this change and adapt 
our code to 3.7. The lack of a discussion about backwards compatibility in 
this, and the other, thread before making this change is also a problem I think.

--

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

[issue32308] Replace empty matches adjacent to a previous non-empty match in re.sub()

[Anders Hovmöller]

Anders Hovmöller  added the comment:

Just as a comparison, sed does the 3.6 thing:

> echo foo | sed 's/\(.*\)/x\1y/g'
xfooy

--

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

[issue32308] Replace empty matches adjacent to a previous non-empty match in re.sub()

[Anders Hovmöller]

Anders Hovmöller  added the comment:

This was a really bad idea in my opinion. We just found this and we have no way 
to know how this will impact production. It's really absurd that 

re.sub('(.*)', r'foo', 'asd')

is "foo" in python 1 to 3.6 but 'foofoo' in python 3.7.

--
nosy: +Anders.Hovmöller

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

[issue36485] Add a way to clear all caches

[Anders Hovmöller]

Anders Hovmöller  added the comment:

I think this is a great idea. We would have needed this many times for tests 
over the years.

--
nosy: +Anders.Hovmöller

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

[issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew installs fragile

[Anders Hovmöller]

Anders Hovmöller  added the comment:

I just discovered this ticket again and see that it's stuck! 

I have read through the thread but it's still a bit unclear what would be 
required to test this with homebrew like Guido says is needed for this to go 
forward. Is there anyone who can explain or better yet test?

--

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

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

[Anders Kaseorg]

Anders Kaseorg  added the comment:

porton: Please don’t steal someone else’s issue to report a different bug.  
Open a new issue instead.

--
title: argparse: add a full fledged parser as a subparser -> argparse does not 
accept options taking arguments beginning with dash (regression from optparse)

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

Re: PEP 394

[Anders Wegge Keller]

På Sat, 20 Oct 2018 12:57:45 +1100
Ben Finney  skrev:
> Anders Wegge Keller  writes:
> 
> > Short and simple: Do you expect PEP 394 to change status  
> 
> The status of PEP 394 today is “Active”. What change of status would you
> expect in this Informational PEP?

 One possible change would be that it would become archived, ceased to be,
bereft of life, resting in peace or maybe even retired. 

 I don't have any particular status change I want to see; I merely ask
what other experienced python developers expect to happen.

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

Re: logging output

[Anders Wegge Keller]

På Fri, 19 Oct 2018 08:05:28 -0700 (PDT)
Sharan Basappa  skrev:

...

> delimiter=r'\s"') #data_df = pd.read_csv("BGL_MERGED.log")
> logger.debug("data frame %s \n", data_df)

 Do this help?
 


-- 

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

PEP 394

[Anders Wegge Keller]

Short and simple: Do you expect PEP 394 to change status or
recommendation when official support for Python2 ends in 13½ months time, or
at least some time thereafter? 

For those that don't have the habit of memorizing PEPs, 394 is the one
stating 

* python2 will refer to some version of Python 2.x.
* python3 will refer to some version of Python 3.x.
* for the time being, all distributions should ensure that python, if
installed, refers to the same target as python2, unless the user
deliberately overrides this or a virtual environment is active.

-- 

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

[issue34861] Improve cProfile standard output

[Anders Hovmöller]

Anders Hovmöller  added the comment:

Output before this patch:

 3666 function calls (3556 primitive calls) in 0.005 seconds

   Ordered by: standard name

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
20.0000.0000.0020.001 :1009(_handle_fromlist)
70.0000.0000.0000.000 :103(release)
50.0000.0000.0000.000 :143(__init__)
50.0000.0000.0000.000 :147(__enter__)
50.0000.0000.0000.000 :151(__exit__)
70.0000.0000.0000.000 :157(_get_module_lock)
50.0000.0000.0000.000 :176(cb)
20.0000.0000.0000.000 :194(_lock_unlock_module)
  7/10.0000.0000.0030.003 :211(_call_with_frames_removed)
   530.0000.0000.0000.000 :222(_verbose_message)
50.0000.0000.0000.000 :307(__init__)
50.0000.0000.0000.000 :311(__enter__)
50.0000.0000.0000.000 :318(__exit__)
   200.0000.0000.0000.000 :321()
40.0000.0000.0000.000 :35(_new_module)
50.0000.0000.0000.000 :369(__init__)
90.0000.0000.0000.000 :403(cached)
70.0000.0000.0000.000 :416(parent)
50.0000.0000.0000.000 :424(has_location)
50.0000.0000.0000.000 :504(_init_module_attrs)
50.0000.0000.0000.000 :576(module_from_spec)
50.0000.0000.0000.000 :58(__init__)
  5/10.0000.0000.0040.004 :663(_load_unlocked)
50.0000.0000.0000.000 :719(find_spec)
70.0000.0000.0000.000 :78(acquire)
50.0000.0000.0000.000 :792(find_spec)
   150.0000.0000.0000.000 :855(__enter__)
   150.0000.0000.0000.000 :859(__exit__)
50.0000.0000.0010.000 :882(_find_spec)
  5/10.0000.0000.0040.004 :948(_find_and_load_unlocked)
  5/10.0000.0000.0040.004 :978(_find_and_load)
10.0000.0000.0000.000 :1072(__init__)
10.0000.0000.0000.000 :1083(create_module)
10.0000.0000.0000.000 :1091(exec_module)
10.0000.0000.0000.000 :1233(_path_hooks)
   120.0000.0000.0000.000 :1246(_path_importer_cache)
50.0000.0000.0010.000 :1283(_get_spec)
50.0000.0000.0010.000 :1315(find_spec)
10.0000.0000.0000.000 :1362(__init__)
80.0000.0000.0000.000 :1368()
50.0000.0000.0000.000 :1394(_get_spec)
   100.0000.0000.0010.000 :1399(find_spec)
10.0000.0000.0000.000 :1447(_fill_cache)
10.0000.0000.0000.000 :1476()
10.0000.0000.0000.000 :1488(path_hook_for_FileFinder)
80.0000.0000.0000.000 :282(cache_from_source)
   100.0000.0000.0000.000 :36(_relax_case)
50.0000.0000.0000.000 :412(_get_cached)
40.0000.0000.0000.000 :444(_check_name_wrapper)
40.0000.0000.0000.000 :481(_classify_pyc)
   120.0000.0000.0000.000 :51(_r_long)
40.0000.0000.0000.000 :514(_validate_timestamp_pyc)
   510.0000.0000.0000.000 :56(_path_join)
40.0000.0000.0000.000 :566(_compile_bytecode)
   510.0000.0000.0000.000 :58()
50.0000.0000.0000.000 :617(spec_from_file_location)
80.0000.0000.0000.000 :62(_path_split)
   230.0000.0000.0000.000 :74(_path_stat)
40.0000.0000.0000.000 :762(create_module)
  4/10.0000.0000.0040.004 :765(exec_module)
40.0000.0000.0010.000 :836(get_code)
90.0000.0000.0000.000 :84(_path_is_mode_type)
40.0000.0000.0000.000 :927(__init__)
80.0000.0000.0000.000 :93(_path_isfile)
40.0000.0000.0000.000 :952(get_filename)
40.0000.0000.0000.000 :957(get_data)
10.0000.0000.0000.000 :98(_path_isdir)
40.0000.0000.0000.000 :994(path_stats)
  1000.0000.0000.0010.000 __init__.py:183(dumps)
10.0000.0000.0030.003 __init__.py:97()
10.0000.0000.0020.002 decoder.py:2()
10.0000.0000.0000.000 decoder.py:20(JSONDecodeError)
10.0000.0000.0000.000 decoder.py:254(JSONDecoder)
10.0000.0000.0000.000

[issue34861] Improve cProfile standard output

[Anders Hovmöller]

Anders Hovmöller  added the comment:

There is an example output on github. Should I paste it here too? I can do it 
once I get home if you want.

--

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

[issue34861] Improve cProfile standard output

[Anders Hovmöller]

Change by Anders Hovmöller :


--
keywords: +patch
pull_requests: +9046
stage:  -> patch review

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

[issue34861] Improve cProfile standard output

[Anders Hovmöller]

New submission from Anders Hovmöller :

The standard output for cProfile when run from a command line is not very 
useful. It has two main flaws:

- Default sort order is by name of function
- It strips the full path of source files

The first makes it very hard to look at the output. The second is very annoying 
when you get a bunch of __init__.py in the output.

Suggested solution:

- Default cumulative time sort order
- Show one additional folder level when filename is __main__ or __init__

--
components: Library (Lib)
messages: 326793
nosy: Anders.Hovmöller
priority: normal
severity: normal
status: open
title: Improve cProfile standard output
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

Re: Non-GUI, single processort inter process massaging - how?

[Anders Wegge Keller]

På Sat, 21 Jul 2018 09:07:23 +0100
Chris Green  skrev:

> So - what's the best approach to this?  I've done some searching and
> most/many of the solutions seem rather heavyweight for my needs. Am I
> overlooking something obvious or should I try rethinking the original
> requirement and look for another approach?

 What do you consider heavyweight? Number of dependencies, memory footprint,
amount of code or a fourth thing? Also, which platform will the code
eventually run on?

 If your update frequency is low enough that it wont kill the filesystem and
the amount of data is reasonably small, atomic writes to a file is easy to
work with:

  def atomic_write(filename, data):
handle, name = tempfile.mkstemp()
os.write(handle, data)
os.fsync(handle)
os.close(handle)
os.replace(tmpname, filename)

 The imports are trivial to deduce, so I removed the clutter. If you have
multiple filesystems, you may have to read into the details of calling
mkstemp.


 If you have an update frequency that will kill the filesystem (for instance
a RPi on a SD card), or have a larger data set where you only want to do
partial updates, the mmap module could be an option. It require some more
boilerplate. You will probably also have to consider a semaphore to
guarantee that the clients read a consistent result set.

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

Re: Unicode [was Re: Cult-like behaviour]

[Anders Wegge Keller]

På Mon, 16 Jul 2018 11:33:46 -0700
Jim Lee  skrev:

> Go right ahead.  I find it surprising that Stephen isn't banned, 
> considering the fact that he ridicules anyone he doesn't agree with.  
> But I guess he's one of the 'good 'ol boys', and so exempt from the code 
> of conduct.

Well said!

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

Re: Unicode [was Re: Cult-like behaviour]

[Anders Wegge Keller]

> The buzzing noise you just heard was the joke whizzing past your head 
> *wink*

 I have twins aged four. They also like to yell "I cheated!", whenever they
are called out.

 In general, you need to get rid of tat teenage brat persona you practice.
The "ranting rick" charade was especially toe-curling.

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

Re: Sorting NaNs

[Anders Munch]

Steven D'Aprano:


It is not a guess if the user explicitly specifies that as the behaviour.


If that was the context, sure, no problem.

- Anders

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

Re: Sorting NaNs

[Anders Munch]

Richard Damon wrote:


The two behaviors that I have heard suggested are:

1) If any of the inputs are a NaN, the median should be a NaN.
(Propagating the NaN as indicator of a numeric error)

2) Remove the NaNs from the input set and process what is left. If
nothing, then return a NaN (treating NaN as a 'No Data' placeholder).


3) Raise an exception.

I can't believe anyone even suggested 2).  "In the face of ambiguity, 
refuse the temptation to guess."


regards, Anders

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

Re: object types, mutable or not?

[Anders Wegge Keller]

På Wed, 16 May 2018 14:48:27 +0100
Paul Moore  skrev:

> C++ called that an "rvalue". And then went on to define things that
> could go on the left hand side of an assignment as "lvalues". And now
> we have two confusing concepts to explain - see what happens when you
> let a standards committee define your language? :-)

 I'm not sure the C++ committee has to bear the responsibility for those
terms. They are pretty well defined in the C world, so I think you need to
point the finger of accusation at either Brian or Dennis. 

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

Re: want to export some of the packets from a big pacp file to another file.

[Anders Wegge Keller]

På Thu, 5 Apr 2018 08:06:10 -0700 (PDT)
supsw...@gmail.com skrev:
> Hi,
> 
> I am using dpkt python package to parse .pcap file and I am able to do
> successfully.
> 
> My requirement is to filter some of the traffic from the big .pcap file
> and to export the result to another file.
> 
> I don't know how to do this.

 What kind of filtering do you need? In many cases it would be faster and
more convenient to use wireshark or other similar tools as a pass-through
filter, rather than rolling your own. 

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

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

[Anders Wegge Keller]

På Sat, 31 Mar 2018 11:58:39 -0400
Etienne Robillard  skrev:

> Are you trolling? Do you understand that a modern mobile device 
> typically require a Internet subscription and an additional subscription 
> for the smart phone?

 I think the question is why you equate python3 with the need for internet
connected tablets. That's quite the non sequitur. 

Consider this my +1 the the request of you to clarify what you mean.

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

[issue33143] encode UTF-16 generates unexpected results

[Anders Rundgren]

Anders Rundgren <anders.rundgren@gmail.com> added the comment:

Thanx for the superquick response!
I really appreciate it.

I'm obviously a Python n00b

Anders

--

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

[issue33143] encode UTF-16 generates unexpected results

[Anders Rundgren]

New submission from Anders Rundgren <anders.rundgren@gmail.com>:

Python 3.5.1 (v3.5.1:37a07cee5969, Dec  6 2015, 01:54:25) [MSC v.1900 64 bit 
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> v = '\u20ac'
>>> print (v)
€
>>> v.encode('utf-16')
b'\xff\xfe\xac '
>>> v.encode('utf-16_be')
b' \xac'

I had expected to get pair of bytes with 20 AC for the € symbol

--
components: Unicode
messages: 314443
nosy: anders.rundgren@gmail.com, ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: encode UTF-16 generates unexpected results
type: behavior
versions: Python 3.5

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

Re: Are the critiques in "All the things I hate about Python" valid?

[Anders Wegge Keller]

På Tue, 20 Feb 2018 12:28:25 + (UTC)
Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> skrev:
> On Mon, 19 Feb 2018 16:34:29 +0100, Anders Wegge Keller wrote:
> 
> > På Mon, 19 Feb 2018 15:15:19 + (UTC) Steven D'Aprano
> > <steve+comp.lang.pyt...@pearwood.info> skrev:  
> >> On Mon, 19 Feb 2018 14:06:36 +0100, Anders Wegge Keller wrote:
> >>   
>  [...]  
> >> 
> >> That's a mighty powerful claim that goes against the documentation for
> >> the array module. Can you back your claims up?
> >> 
> >> Here's an array and a list:  
> > 
> >  Make me an array of tuples with two integers and a string, and we can
> >  talk.  
> 
> The array module's failure to support the specific type you want has no 
> bearing on whether or not Python is statically typed.

 You claimed Array could do what I requested, i.e. container type that
guaranteed only one type inside. Furthermore, you are misrepresenting C with
malice. 

 I don't care why you feel that a simple observation is a personal attack,
but I see you behave as a spoiled kid. I haven\t got the time for it, sop go
and pout in your corner. 

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

Re: Are the critiques in "All the things I hate about Python" valid?

[Anders Wegge Keller]

På Mon, 19 Feb 2018 15:15:19 + (UTC)
Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> skrev:
> On Mon, 19 Feb 2018 14:06:36 +0100, Anders Wegge Keller wrote:
> 
> > Array is not even close to providing a strongly typed container.  
> 
> That's a mighty powerful claim that goes against the documentation for 
> the array module. Can you back your claims up?
> 
> Here's an array and a list:

 Make me an array of tuples with two integers and a string, and we can talk.

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

Re: Are the critiques in "All the things I hate about Python" valid?

[Anders Wegge Keller]

På Mon, 19 Feb 2018 04:39:31 + (UTC)
Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> skrev:
> On Mon, 19 Feb 2018 04:26:32 +0100, Anders Wegge Keller wrote:
> 
> > På Mon, 19 Feb 2018 08:47:14 +1100
> > Tim Delaney <timothy.c.dela...@gmail.com> skrev:  
> >> On 18 February 2018 at 22:55, Anders Wegge Keller <we...@wegge.dk>
> >> wrote:  
> > 
> >   
>  [...]  
> >   
> >> You couldn't have got the above much more wrong.  
> >
> >> As others have said, typing is about how the underlying memory is
> >> treated.  
> > 
> >  And that is exactly my point. Python does not have a typed list. It
> >  have a list that takes whatever is thrown into it.
> > 
> >  I'll skip the rest, as you totally missed the point.  
> 
> I think its actually you have totally missed the point. What you want is 
> a homogeneous list, a list which only accepts items of the same type. The 
> built-in list is not that data structure, but Python already has 
> something similar: see the array module.

 Given that I'm the one making a point about the unwarranted smugness, I
know that I'm not missing anything. Array is not even close to providing a
strongly typed container. For all of the yakking about other languages
weak, blah, BCPL, blah, I still wonder where that need to feel superior to
anything else comes from.  

 Python isn't particular strong typed. In fact, apart from asking an object
what type it is, types are not that important. It's the interface that
matters. I wonder why this is a sore point for Python developers?


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

Re: Are the critiques in "All the things I hate about Python" valid?

[Anders Wegge Keller]

På Mon, 19 Feb 2018 08:47:14 +1100
Tim Delaney <timothy.c.dela...@gmail.com> skrev:
> On 18 February 2018 at 22:55, Anders Wegge Keller <we...@wegge.dk> wrote:


> >  That list is not only weakly typed, but rather untyped. There are no
> > safeguards in the language, that enforce that all elements in a list or
> > other container are in fact of the same type. Before type annotations and
> > mypy, I could not enforce that other than at runtime.

> You couldn't have got the above much more wrong.
 
> As others have said, typing is about how the underlying memory is treated.

 And that is exactly my point. Python does not have a typed list. It have a
list that takes whatever is thrown into it.

 I'll skip the rest, as you totally missed the point.
-- 
//Wegge
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[Anders Wegge Keller]

På Sun, 18 Feb 2018 07:34:03 -0500
Richard Damon  skrev:

> Python is much stronger typed than PHP, because in PHP you can do things 
> like 1 + '2' and get 3, as string values will naturally convert 
> themselves to numbers, Python won't do this. Yes Python will freely 
> convert between numeric types, but I wouldn't say that Python claims to 
> be a language that focuses on numerics.

 Type coercion is not the same as weak typing. Let me stress that the
difference between languages having 1 + 1.23 as a valid construct and
languages having 1 + '1.23' as a valid construct, is merely a design
descision. PHP is fully aware that a string and an integer have different
types, and makes a implicit cast, rather than throw an error. 

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

Re: Are the critiques in "All the things I hate about Python" valid?

[Anders Wegge Keller]

På Sat, 17 Feb 2018 15:05:34 +1100
Ben Finney  skrev:
> boB Stepp  writes:


> He blithely conflates “weakly typed” (Python objects are not weakly, but
> very strongly typed) 

 Python is more strongly typed than PHP, but that doesn't really say much.
However, compared to a language like C, there are big holes in the type
safety.

>>> alist = [1, 'two', ('three', four), 5*'#']

 That list is not only weakly typed, but rather untyped. There are no
safeguards in the language, that enforce that all elements in a list or
other container are in fact of the same type. Before type annotations and
mypy, I could not enforce that other than at runtime. 

 So claiming Python to have very strongly typed objects is a bit of a
strecth. PHP that many of us like to be smug about is equally strongly
typed. It just comes with a metric ton of inane type coersions that have
gone too far. However, we are happy to add an integer to a float without
having to make an explicit conversion every time, so ... Thread carefull and
all that.

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

[issue31961] subprocess._execute_child doesn't accept a single PathLike argument for args

[Anders Lorentsen]

Anders Lorentsen <pha...@gmail.com> added the comment:

What do you mean "is a bug", and "the PR would encourage this"? Can't it be 
fixed?

Are you saying that just because it is a bug now, we should be discouraged from 
making it work in the way you'd expect it to work?

If `exe` is a path, these two lines of code should do exactly the same, right? 
It seems unintuitive to me if they produce different results.

run(exe)
run([exe])

--

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

[issue31961] subprocess._execute_child doesn't accept a single PathLike argument for args

[Anders Lorentsen]

Anders Lorentsen <pha...@gmail.com> added the comment:

> # runs this weird file
> subprocess.run([bin])

> # Currently an error; if this is implemented, would run
> # /bin/ls, and pass it the -l argument. Refers to something
> # completely different than our .exists() call above.

I do not understand where it is stated that this is the behavior. My 
understanding was that if run() is passed a single argument, it will interpret 
the string "/bin/ls -l" to mean "run the `/bin/ls` program, and pass it one 
argument `-l`, whereas if instead run() is given a list, it will literally 
treat the first element as the program to run, regardless of how many spaces or 
whatever else it contains ... And as such, if `bin` is a Path-like object, this 
issue tries to resolve that
run([bin]) works as excepted, but run(bin) fails horribly.

Sure, I can understand that for strings it may not feel natural how these two 
things are interpreted differently, but if `bin` is a Path-like object, it at 
least feels very natural to me that then it should be run as the program name 
itself (as "paths" does not have arguments).

--

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

[issue32764] Popen doesn't work on Windows when args is a list

[Anders Lorentsen]

Anders Lorentsen <pha...@gmail.com> added the comment:

Wait a minute. The failing test is test_nonexisting_with_pipes, and it fails 
because args[0] is a tuple - how can that be? Nobody is supposed to pass 
cmd=sequence-where-first-element-is-a-tuple!

Is everything all right with the test itself?

--

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

[issue32764] Popen doesn't work on Windows when args is a list

[Anders Lorentsen]

Anders Lorentsen <pha...@gmail.com> added the comment:

Also, isn't there continuous integration testing? Everything passed on the PR, 
so where does this come from?

--

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

[issue32764] Popen doesn't work on Windows when args is a list

[Anders Lorentsen]

Anders Lorentsen <pha...@gmail.com> added the comment:

This is strange, because _execute_child calls os.fsdecode with `args` as the 
argument, which may be a list. os.fsdecode calls fspath. Now, the python 
docstring of _fspath, as defined in Lib/os.py on line 1031, clearly states that 
it will raise a TypeError if the argument is not of type bytes, str or is a 
os.PathLike object, and that's probably why I wrote the initial code the way I 
did (catching TypeError from os.fsdecode).

Doesn't the try-except block actually catch this TypeError? I don't understand 
off the top of my head why my code doesn't catch this exception..

--

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

[issue32601] PosixPathTest.test_expanduser fails in NixOS build sandbox

[Anders Kaseorg]

New submission from Anders Kaseorg <ande...@mit.edu>:

PosixPathTest.test_expanduser fails in the NixOS build sandbox, where every 
user has home directory /, so it falls off the end of the for pwdent in 
pwd.getpwall() loop.

nixbld:x:30001:3:Nix build user:/:/noshell
nobody:x:65534:65534:Nobody:/:/noshell

==
FAIL: test_expanduser (__main__.PosixPathTest)
--
Traceback (most recent call last):
  File "/nix/store/mdak9gcy16dc536ws08rshyakd1l7srj-test_pathlib.py", line 
2162, in test_expanduser
self.assertEqual(p3.expanduser(), P(otherhome) / 'Documents')
AssertionError: PosixPath('/Documents') != PosixPath('Documents')

--
components: Tests
messages: 310282
nosy: andersk
priority: normal
pull_requests: 5091
severity: normal
status: open
title: PosixPathTest.test_expanduser fails in NixOS build sandbox
type: behavior
versions: Python 3.7

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

[issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew installs fragile

[Anders Hovmöller]

Change by Anders Hovmöller <bo...@killingar.net>:


--
nosy: +Anders.Hovmöller

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

[issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew installs fragile

[Anders Hovmöller]

Change by Anders Hovmöller <bo...@killingar.net>:


--
versions: +Python 3.6

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

[issue31956] Add start and stop parameters to the array.index()

[Anders Lorentsen]

Anders Lorentsen <pha...@gmail.com> added the comment:

Writing my tests, I originally looked at Lib/test/seq_tests.py. One test case 
uses indexes that are (+-)4*sys.maxsize. This does not fit in Py_ssize_t, and 
so these tests cause my array implementation to raise an overflow exception.

A solution is of course to have the function take general objects instead, and 
then truncate them down to a number that can fit in Py_ssize_t if it's too 
negative or positive).

But I concur. It seems more reasonable to stay consistent with the rest of the 
module, too.

I'll look over the test code to make sure I test for every given scenario (or 
as many as I can think of), and prepare a PR for this, then :)

--

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

[issue31956] Add start and stop parameters to the array.index()

[Anders Lorentsen]

Anders Lorentsen <pha...@gmail.com> added the comment:

I decided to work on this, and I would like some review, as this would be my 
second contribution to cpython. Also, a general question:

As I defined the start and end arguments Py_ssize_t, bigger indexes (more 
negative or more positive) than what can fit in Py_ssize_t will trigger an 
overflow error. This should be OK, though, as other functions with index 
arguments has them as Py_ssize_t - and getarrayitem() itself accepts a 
Py_ssize_t. Or?

--
nosy: +Phaqui
Added file: https://bugs.python.org/file47261/WIP-issue-31956

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

[issue31961] subprocess._execute_child doesn't accept a single PathLike argument for args

[Anders Lorentsen]

Anders Lorentsen <pha...@gmail.com> added the comment:

While researching this, I discovered that on MS Windows

>>> subprocess.run([pathlike_object, additional_arguments])

did not run like it did on Posix. My PR includes this problem and it's fix.

--

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

[issue31961] subprocess._execute_child doesn't accept a single PathLike argument for args

[Anders Lorentsen]

Anders Lorentsen <pha...@gmail.com> added the comment:

I was able to make a test that reproduces your code, and expectedly fails. Also 
implemented a fix for it. See a temporary diff here: 
https://pastebin.com/C9JWkg0i

However, there is also a specific MS Windows version of _execute_child() (a 
phrase only computer-folks can say out loud without feeling very...wrong...). 
It uses a different method to extract and parse arguments, and it should be 
corrected and tested under windows, before I submit a PR for this.

Also, my test messes up the formatting. Instead of saying "ok", they both 
say "... total 0\nok". I have no idea why.

--
nosy: +Phaqui

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

[issue31843] sqlite3.connect() should accept PathLike objects

[Anders Lorentsen]

Anders Lorentsen <pha...@gmail.com> added the comment:

Had my first go at a python patch. Added a test case for it, and all tests
passing when I test with

`./python -bb -E -Wd -m test -v test.test_sqlite -r -w -uall -R 3:2`

--
nosy: +Phaqui

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

Re: SIGSEGV and SIGILL inside PyCFunction_Call

[Anders Wegge Keller]

På Thu, 20 Jul 2017 07:44:26 +0200
dieter <die...@handshake.de> skrev:
> Anders Wegge Keller <we...@wegge.dk> writes:

...

>>  Weird observation #1: Sometimes the reason is SIGSEGV, sometimes it's
>> SIGILL.   
 
> Python tends to be sensitive to the stack size. In previous times,
> there have often be problems because the stack size for threads
> has not been large enough. Not sure, whether "nnrpd" is multi threaded
> and provides a sufficiently large stack for its threads.

 Luckily, the "threading model" of nnrpd is fork().

> A "SIGILL" often occurs because a function call has destroyed part
> of the stack content and the return is erroneous (returning in the midst
> of an instruction).

 I think you're right. That also explains why gdb have trouble with the last
stack frame. 


>>  I'm not ready to give up yet, but I need some help proceeding from here.
>> What do the C_TRACE really do,  
 
> The casing (all upper case letters) indicates a C preprocessor macro.
> Search the "*.h" files for its definition.

 I know where it is. I just don't feel like deciphering a 60 lines
monstrosity before at least asking if someone has a intimate enough
relationship with it, to give a TL;DR.

> I suppose that with a normal Python build (no debug build), the
> macro will just call "PyCFunction_Call".
> Alternatively, it might provide support for debugging, tracing
> (activated by e.g. "pdb.set_trace()").

 Probably. I can see I have to dig into it.

>> and is there some way of getting a level
>> deeper, to see what cause the SEGV. Also, how can the C code end up with
>> an illegal instruction_  

...

> Unfortunately, stack corruption is a non local problem (the point
> where the problem is caused is usually far away from the point
> where it is observed).
> 
> If the problem is not "too small stack size", you might need
> a tool to analyse memory overrides.

 The trouble with that is that nnrpd is a system daemon, and as such is a
bit difficult to trace in place. That's why I am asking for help
reasoning the cause, before I have to resort to running a debugger as a
privileged user.


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

SIGSEGV and SIGILL inside PyCFunction_Call

[Anders Wegge Keller]

 I have an ongoing issue with my usenet setup. I'm that one dude who don't
want to learn perl. That means that I have to build inn from source, so I
can enable the python interpreter. That's not so bad, and the errors that
show up have been something that I have been able to figure out by myself.
At least up until now. I have an almost 100% repeatable crash, when nnrpd
performs the user authentication step. Backtracing the core dum gives this:

#0  0x564a864e2d63 in ?? ()
#1  0x7f9609567091 in call_function (oparg=, 
pp_stack=0x7ffda2d801b0) at ../Python/ceval.c:4352

Note:   Line 4352 C_TRACE(x, PyCFunction_Call(func,callargs,NULL));

#2  PyEval_EvalFrameEx (
f=Frame 0x7f9604758050, for file /etc/news/filter/nnrpd_auth.py, 
line 67, in __init__ (self=

Re: Grapheme clusters, a.k.a.real characters

[Anders Wegge Keller]

På Tue, 18 Jul 2017 11:27:03 -0400
Dennis Lee Bieber  skrev:

>   Probably would have to go to words predating the Roman occupation
> (which probably means a dialect closer to Welsh or other Gaelic).
> Everything later is an import (anglo-saxon being germanic tribes invading
> south, Vikings in the central area, as I recall southern Irish displacing
> Picts in Scotland, and then the Norman French (themselves starting from
> Vikings ["nor(se)man"]).

 English is known to be lurking in back alleys, waiting for unsuspecting
 languages, that can be beat up for loose vocabulary. So defining anything
 "pure" about it, is going to be practically impossible.

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

Re: Grapheme clusters, a.k.a.real characters

[Anders Wegge Keller]

På Tue, 18 Jul 2017 23:59:33 +1000
Chris Angelico  skrev:
> On Tue, Jul 18, 2017 at 11:11 PM, Steve D'Aprano


>> (I don't think any native English words use a double-V or double-U, but
>> the possibility exists.)  
 
> vacuum.

 That's latin. 

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

[issue15873] datetime: add ability to parse RFC 3339 dates and times

[Anders Hovmöller]

Anders Hovmöller added the comment:

@larsonreever That lib is pretty limited, in that it doesn't handle dates or 
deltas. Again: my lib that is linked above does and has comprehensive tests.

--

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

[issue8376] Tutorial offers dangerous advice about iterators: “__iter__() can just return self”

[Anders Kaseorg]

Anders Kaseorg added the comment:

Usui, this is a tutorial intended for beginners.  Even if the change from 
“most” to “built-in” were a relevant one (and I don’t see how it is), beginners 
cannot possibly be expected to parse that level of meaning out of a single word.

The difference between iterators and containers deserves at least a couple of 
sentences and preferably an example that includes both, as I proposed in 
http://bugs.python.org/issue8376#msg102966.  Do you disapprove of that proposal?

--

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

Re: Python slang

[Anders J. Munch]

Lawrence D’Oliveiro:
>> [...] as much like C++ as
>> possible.
>
> Nevertheless, Python copied the C misfeature [...]

You segued a little too easily from C++ to C.  When talking language
evolution and inspirations, they are entirely different things.

- Anders

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

Re: Python slang

[Anders J. Munch via Python-list]

Marco Sulla via Python-list:
> Well, they are the most used languages.

They weren't when Python was created.

Python's terms raise/except and self were normal for the time. C++ was
the odd one out.  throw/catch and this are Stroustrup's inventions, no
other language used those terms.

It was only later that language designers fell into the notion that it
was crucial for a new language's success to look as much like C++ as
possible.

regards, Anders

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

[issue27623] int.to_bytes() and int.from_bytes(): raise ValueError when bytes count is zero

[Anders Lorentsen]

Anders Lorentsen added the comment:

I updated my patch to account for that second corner case. But ideally, 
shouldn't it rather be accounted for in the function that does the actual 
conversion, that is, in _PyLong_AsByteArray?

--
Added file: 
http://bugs.python.org/file43942/int_to_bytes_overflow_cornercase2.patch

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

[issue27623] int.to_bytes() and int.from_bytes(): raise ValueError when bytes count is zero

[Anders Lorentsen]

Anders Lorentsen added the comment:

So, am I to understand that the only corner case we should fix is that
>>> (-1).to_bytes(0, 'big', signed=True)
should raise an overflow error (currently it returns  b'') ?

--
Added file: 
http://bugs.python.org/file43925/int_to_bytes_overflow_cornercase.patch

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

[issue27623] int.to_bytes() and int.from_bytes(): raise ValueError when bytes count is zero

[Anders Lorentsen]

Anders Lorentsen added the comment:

Isn't it possible to just add a small line of code that checks if length is 
less than or equal to 0, and if it is, call the necessary c functions to have 
python raise a valueerror...? Sorry if this is giving a solution without 
actually submitting the patch - but this is all very new to me. I have never 
contributed to anything yet (fourth year CS-student), and I am as fresh to the 
process as can be. I registered here just now. This seems like an issue I could 
handle.. I just need to take the time to learn about the process of how things 
are done around here.

--

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

[issue27623] int.to_bytes() and int.from_bytes(): raise ValueError when bytes count is zero

[Anders Lorentsen]

Changes by Anders Lorentsen <pha...@gmail.com>:


--
nosy: +Phaqui

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

[issue15873] datetime: add ability to parse RFC 3339 dates and times

[Anders Hovmöller]

Anders Hovmöller added the comment:

Hmm, ok. I guess I was confused by "dates and times" part of the subject. Ok, 
so only datetimes. My other comments still apply though. 

> On 19 Jul 2016, at 16:20, Mathieu Dupuy <rep...@bugs.python.org> wrote:
> 
> 
> Mathieu Dupuy added the comment:
> 
> because it limits itself to only support the RFC 3339 subset, as
> explained in the begining of the discussion.
> 
> 2016-07-19 16:07 GMT+02:00 Anders Hovmöller <rep...@bugs.python.org>:
>> 
>> Anders Hovmöller added the comment:
>> 
>> The tests attached to this ticket seem pretty bare. Issues that I can spot 
>> directly:
>> 
>> - only tests for datetimes, not times or dates
>> - only tests for zulu and "-8:00” timezones
>> - no tests for invalid input (parsing a valid date as a datetime for example)
>> - only tests for -MM-DDTHH:MM:SSZ, but ISO8601 supports:
>>- Naive times
>>- Timezone information (specified as offsets or as Z for 0 offset)
>>- Year
>>- Year-month
>>- Year-month-date
>>- Year-week
>>- Year-week-weekday
>>- Year-ordinal day
>>- Hour
>>- Hour-minute
>>- Hour-minute
>>- Hour-minute-second
>>- Hour-minute-second-microsecond
>>- All combinations of the three "families" above!
>> (the above list is a copy paste from my project that implements all ISO8601 
>> that fits into native python: https://github.com/boxed/iso8601 
>> <https://github.com/boxed/iso8601>)
>> 
>> This is a more reasonable test suite: 
>> https://github.com/boxed/iso8601/blob/master/iso8601.py#L166 
>> <https://github.com/boxed/iso8601/blob/master/iso8601.py#L166> although it 
>> lacks the tests for bogus inputs.
>> 
>>> On 2016-07-16, at 03:41, Alexander Belopolsky <rep...@bugs.python.org> 
>>> wrote:
>>> 
>>> 
>>> Alexander Belopolsky added the comment:
>>> 
>>> I would very much like to see this ready before the feature cut-off for 
>>> Python 3.6.  Could someone post a summary on python-ideas to get a show of 
>>> hands on some of the remaining wrinkles?
>>> 
>>> I would not worry about a C implementation at this point.  We can put 
>>> python implementation in _strptime.py and call it from C as we do for the 
>>> strptime method.
>>> 
>>> --
>>> 
>>> ___
>>> Python tracker <rep...@bugs.python.org>
>>> <http://bugs.python.org/issue15873>
>>> ___
>> 
>> --
>> 
>> ___
>> Python tracker <rep...@bugs.python.org>
>> <http://bugs.python.org/issue15873>
>> ___
> 
> --
> 
> ___
> Python tracker <rep...@bugs.python.org>
> <http://bugs.python.org/issue15873>
> ___

--

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

[issue15873] datetime: add ability to parse RFC 3339 dates and times

[Anders Hovmöller]

Anders Hovmöller added the comment:

The tests attached to this ticket seem pretty bare. Issues that I can spot 
directly:

- only tests for datetimes, not times or dates
- only tests for zulu and "-8:00” timezones
- no tests for invalid input (parsing a valid date as a datetime for example)
- only tests for -MM-DDTHH:MM:SSZ, but ISO8601 supports:
- Naive times
- Timezone information (specified as offsets or as Z for 0 offset)
- Year
- Year-month
- Year-month-date
- Year-week
- Year-week-weekday
- Year-ordinal day
- Hour
- Hour-minute
- Hour-minute
- Hour-minute-second
- Hour-minute-second-microsecond
- All combinations of the three "families" above!
(the above list is a copy paste from my project that implements all ISO8601 
that fits into native python: https://github.com/boxed/iso8601 
<https://github.com/boxed/iso8601>)

This is a more reasonable test suite: 
https://github.com/boxed/iso8601/blob/master/iso8601.py#L166 
<https://github.com/boxed/iso8601/blob/master/iso8601.py#L166> although it 
lacks the tests for bogus inputs.

> On 2016-07-16, at 03:41, Alexander Belopolsky <rep...@bugs.python.org> wrote:
> 
> 
> Alexander Belopolsky added the comment:
> 
> I would very much like to see this ready before the feature cut-off for 
> Python 3.6.  Could someone post a summary on python-ideas to get a show of 
> hands on some of the remaining wrinkles?
> 
> I would not worry about a C implementation at this point.  We can put python 
> implementation in _strptime.py and call it from C as we do for the strptime 
> method.
> 
> --
> 
> ___
> Python tracker <rep...@bugs.python.org>
> <http://bugs.python.org/issue15873>
> ___

--

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

[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()

[Anders Hovmöller]

Anders Hovmöller added the comment:

> The `arrow` library depends on the supposed "strict" behaviour of strptime 
> that has never been guaranteed, which often results in very buggy behaviour 
> under some conditions.

Well… the arrow library accepts all sorts of broken input and gives you a date 
back. I think they even think that’s a feature and not a bug so no use in 
trying to help people who are adamant that they don’t want to be helped :/

--

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

[issue15873] datetime: add ability to parse RFC 3339 dates and times

[Anders Hovmöller]

Anders Hovmöller added the comment:

> 
> By the way, I just discovered, that the way we treat microseconds differs 
> from the strptime one : we are smarter read every digits and smartly round to 
> six, strptime doesn't go that far and just *truncate* to this. Should go that 
> way, for consistency with what strptime does, maybe ?

I'm strongly against silently throwing away data and calling it even. If we 
want compatibility with strptime then it should be a separate flag like 
silent_truncate_milliseconds=True. 

On another matter: does the latest proposed code pass the tests in my ISO8601 
implementation that I mentioned 2013 (! time flies)?

--

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

Re: sobering observation, python vs. perl

[Anders J. Munch]

Charles T. Smith:

I've really learned to love working with python, but it's too soon
to pack perl away.  I was amazed at how long a simple file search took
so I ran some statistics:


Write Python in pythonic style instead of translated-from-Perl style, and the 
tables are turned:


$ cat find-rel.py
| import sys
| def main():
| for fn in sys.argv[1:]:
| tn = None
| with open(fn, 'rt') as fd:
| for line in fd:
| if ' is ready' in line:
| tn = line.split(' is ready', 1)[0]
| elif 'release_req' in line:
| print tn
| main()


$ time python find-rel.py *.out
real0m0.647s
user0m0.616s
sys0m0.029s

$ time perl find-rel.pl *.out
real0m0.935s
user0m0.910s
sys0m0.023s

I don't have your log files and my quickly assembled test file doesn't actually 
contain the phrase 'release_req', so my results may be misleading. Perhaps 
you'll try it and post your results?


regards, Anders

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

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

[Anders Wegge Keller]

On Mon, 29 Feb 2016 23:29:43 +
Mark Lawrence  wrote:

> On 29/02/2016 22:40, Larry Martell wrote:

>> I think for the most part, the mental health industry is most
>> interested in pushing drugs and forcing people into some status quo.

> I am disgusted by your comments.  I'll keep my original reply in reserve.

 Actually, if you view it by raw numbers, where depression makes up the bulk
of the total number of mental problems, Larry's statement is true.

 Studies not performed by the industry shows that an un-medicated depression
ends on average half a day later than one that's treated with some sort
of SSRI. 

Disclaimer: I'm depressed myself, and I've taken an interest into the hows
and whys of SSRI medications.

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

[issue26229] Make number serialization ES6/V8 compatible

[Anders Rundgren]

Anders Rundgren added the comment:

In ES6/V8-compatible implementations which include "node.js", Chrome, Firefox, 
Safari and (of course) my Java reference implementation you can take a 
cryptographic hash of a JSON object with a predictable result.

That is, this request is in no way limited to JCS.

Other solutions to this problem has been to create something like XML's 
canonicalization which is much more complex.

The JSON RFC is still valid, it just isn't very useful for people who are 
interested in security solutions.  The predictable property order introduced in 
ES6 makes a huge difference!  Now it is just the number thing left...

The other alternative is dressing your JSON objects in Base64 to maintain a 
predictable signature like in IETF's JOSE.  I doubt that this is going to be 
mainstream except for OpenID/OAuth which JOSE stems from.

--

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

[issue26229] Make number serialization ES6/V8 compatible

[Anders Rundgren]

Anders Rundgren added the comment:

An easier fix than mucking around in the pretty complex number serializer code 
would be adding an "ES6Format" option to the "json.dump*" methods which could 
use the supplied conversion code as is.

For JSON parsing in an ES6-compatible way you must anyway use an "OrderedDict" 
hook option to get the right (=original) property order.

--

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

[issue26229] Make number serialization ES6/V8 compatible

[Anders Rundgren]

Anders Rundgren added the comment:

As I said, the problem is close to fixed in 3.5.

You should not consider the JCS specification as the [sole] target but the 
ability to creating a normalized JSON object which has many uses including 
calculating a hash of such objects.

##
# Convert a Python double/float into an ES6/V8 compatible string #
##
def convert2Es6Format(value):
# Convert double/float to str using the native Python formatter
pyDouble = str(value)
pySign = ''
if pyDouble.find('-') == 0:
#
# Save sign separately, it doesn't have any role in the rest
#
pySign = '-'
pyDouble = pyDouble[1:]
pyExpStr = ''
pyExpVal = 0
q = pyDouble.find('e')
if q > 0:
#
# Grab the exponent and remove it from the number
#
pyExpStr = pyDouble[q:]
if pyExpStr[2:3] == '0':
#
# Supress leading zero on exponents
#
pyExpStr = pyExpStr[0:2] + pyExpStr[3:]
pyDouble = pyDouble[0:q]
pyExpVal = int(pyExpStr[1:])
#
# Split number in pyFirst + pyDot + pyLast
#
pyFirst = pyDouble
pyDot = ''
pyLast = ''
q = pyDouble.find('.')
if q > 0:
pyDot = '.'
pyFirst = pyDouble[0:q]
pyLast = pyDouble[q + 1:]
#
# Now the string is split into: pySign + pyFirst + pyDot + pyLast + pyExpStr
#
if pyLast == '0':
#
# Always remove trailing .0
#
pyDot = ''
pyLast = ''
if pyExpVal > 0 and pyExpVal < 21:
#
# Integers are shown as is with up to 21 digits
#
pyFirst += pyLast
pyLast = ''
pyDot = ''
pyExpStr = ''
q = pyExpVal - len(pyFirst)
while q >= 0:
q -= 1;
pyFirst += '0'
elif pyExpVal < 0 and pyExpVal > -7:
#
# Small numbers are shown as 0.etc with e-6 as lower limit
#
pyLast = pyFirst + pyLast
pyFirst = '0'
pyDot = '.'
pyExpStr = ''
q = pyExpVal
while q < -1:
q += 1;
pyLast = '0' + pyLast
#
# The resulting sub-strings are concatenated
#
return pySign + pyFirst + pyDot + pyLast + pyExpStr

--

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

[issue26241] repr() and str() are identical for floats in 3.5

[Anders Rundgren]

New submission from Anders Rundgren:

According to the documentation repr() and str() are different when it comes to 
number formatting.  A test with a 100 million random and selected IEEE 64-bit 
values returned no differences

--
components: Interpreter Core
messages: 259244
nosy: anders.rundgren@gmail.com
priority: normal
severity: normal
status: open
title: repr() and str() are identical for floats in 3.5
versions: Python 3.5

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

[issue26241] repr() and str() are identical for floats in 3.5

[Anders Rundgren]

Anders Rundgren added the comment:

Apparently the docs have changed since 2.7:
https://docs.python.org/3.5/tutorial/floatingpoint.html

However, the documentation still "sort of" mentions repr() as the most accurate 
form which isn't entirely correct since it nowadays is identical to str() for 
floats.

No big deal, I just thought I was doing something wrong :-)

related: http://bugs.python.org/issue26229

--

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

[issue26229] Make number serialization ES6/V8 compatible

[Anders Rundgren]

New submission from Anders Rundgren:

ECMA has in their latest release defined that JSON elements must be ordered 
during serialization.  This is easy to accomplish using Python's OrderedDict.  
What is less trivial is that numbers have to be formatted in a certain way as 
well.  I have tested 100 millions specific and random values and found out that 
Python 3.5.1 is mathematically identical to ES6/V8 but has some differences in 
formatting:

   IEEE DoubleECMAScript 6/V8Python 3.5.1

c43211ede4974a35, -0,-3.333e+20
c3fce97ca0f21056, -6000, -3.3336e+19
c3c7213080c1a6ac, -3334000,  -3.334e+18
c39280f39a348556, -333400,   -3.334e+17
c35d9b1f5d20d557, -33340,-3.334e+16

c327af4c4a80aaac, -3334, -3334.0

bf0179ec9cbd821e, -0.5,  -3.3335e-05
becbf647612f3696, -0.03, -3.e-06

4024, 10,10.0
, 0, 0.0
4014, 5, 5.0
3f0a36e2eb1c432d, 0.5,   5e-05
3ed4f8b588e368f1, 0.05,  5e-06

3ea0c6f7a0b5ed8d, 5e-7,  5e-07

Why could this be important?

https://github.com/Microsoft/ChakraCore/issues/149

# Python test program
import binascii
import struct
import json

f = open('c:\\es6\\numbers\\es6testfile100m.txt','rb')

l = 0;
string = '';

while True:
  byte = f.read(1);
  if len(byte) == 0:
exit(0)
  if byte == b'\n':
l = l + 1;
i = string.find(',')
if i <= 0 or i >= len(string) - 1:
  print('Bad string: ' + str(i))
  exit(0)
hex = string[:i]
while len(hex) < 16:
  hex = '0' + hex
o = dict()
o['double'] = struct.unpack('>d',binascii.a2b_hex(hex))[0]
py3Double = json.dumps(o)[11:-1]
es6Double = string[i + 1:]
if es6Double != py3Double:
  es6Dpos = es6Double.find('.')
  py3Dpos = py3Double.find('.')
  es6Epos = es6Double.find('e')
  py3Epos = py3Double.find('e')
  if py3Epos > 0:
py3Exp = int(py3Double[py3Epos + 1:])
  if es6Dpos < 0 and py3Dpos > 0:
if es6Epos < 0 and py3Epos > 0:
  py3New = py3Double[:py3Dpos] + py3Double[py3Dpos + 1:py3Epos - 
len(py3Double)]
  q = py3Exp - py3Epos + py3Dpos
  while q >= 0:
py3New += '0'
q -= 1
  if py3New != es6Double:
print('E1: ' + py3New)
exit(0)
elif py3Epos < 0:
  py3New = py3Double[:-2]
  if py3New != es6Double:
print('E2: ' + py3New)
exit(0)
else:
  print (error + hex + '#' + es6Double + '#' + py3Double)
  exit(0)
  elif es6Dpos > 0 and py3Dpos > 0 and py3Epos > 0 and es6Epos < 0:
py3New = py3Double[py3Dpos - 1:py3Dpos] + py3Double[py3Dpos + 1:py3Epos 
- len(py3Double)]
q = py3Exp + 1
while q < 0:
  q += 1
  py3New = '0' + py3New
py3New = py3Double[0:py3Dpos - 1] + '0.' + py3New 
if py3New != es6Double:
  print('E3: ' + py3New + '#' + es6Double)
  exit(0)
  elif es6Dpos == py3Dpos and py3Epos > 0 and es6Epos > 0:
py3New = py3Double[:py3Epos + 2] + str(abs(py3Exp))
if py3New != es6Double:
  print('E4: ' + py3New + '#' + es6Double)
  exit(0)
  elif es6Dpos > 0 and py3Dpos < 0 and py3Epos > 0 and es6Epos < 0:
py3New = py3Double[:py3Epos - len(py3Double)]
q = py3Exp + 1
while q < 0:
  q += 1
  py3New = '0' + py3New
py3New = '0.' + py3New 
if py3New != es6Double:
  print('E5: ' + py3New + '#' + es6Double)
  exit(0)
  else:
print ('Unexpected: ' + hex + '#' + es6Double + '#' + py3Double)
exit(0)
string = ''
if l % 1 == 0:
  print(l)
  else:
string += byte.decode(encoding='UTF-8')

--
components: Interpreter Core
messages: 259105
nosy: anders.rundgren@gmail.com
priority: normal
severity: normal
status: open
title: Make number serialization ES6/V8 compatible
type: enhancement
versions: Python 3.5

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

[issue26191] pip on Windows doesn't honor Case

[Anders Rundgren]

New submission from Anders Rundgren:

pip install Crypto

Terminates correctly and the package is there as well.
Unfortunately the directory is named "crypto" rather than "Crypto" so when I 
perform

>>>import Crypto

the interpreter fails.

>>>import crypto 

seems to work but is incompatible over platforms.

If this is a problem with pycrypto or pip is beyond my knowledge of python.

--
components: Installation
messages: 258887
nosy: anders.rundgren@gmail.com
priority: normal
severity: normal
status: open
title: pip on Windows doesn't honor Case
type: compile error
versions: Python 3.5

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

Parsing and displaying C structs in a semi-intelligent way.

[Anders Wegge Keller]

 In my day job, we have a large code base of mostly identical projects, each
with their own customizations. The customizations can be a real pain
sometimes. Especially when debugging binary data. The interesting part of
the binary dumps are most often the stuff that are tweaked from project to
project. The prime suspect is a structure like this:

typedef struct
{
bytenext ;  /* Index to next wedge  */
byteflags ; /* ricd-control flags   */
wordalt [MAX_alt] ; /* Alternative wedges   */
...
} ConvResult ;

typedef struct
{
bytestate ; /* UCART_ (see cart.h)  */
wordheadcart ;  /* Cart number for header cart  */
ConvResult  conv ;
...
} cartUTable_t ;

 The actual structure with substructures are much larger. This structure
contains all the information used when sorting stuff[1]. For historical
reasons, the data is dumped to a binary file at the end of the items
life-cycle. We do have a debugging tool, that reads an in-house file format
specifying the members of the structure, and how to display them. However,
updating this description is error-prone, and just about as funny as waiting
for the Norwegian Blue to fly out over the fiords. So most often it's either
not done, or is unusable. 

 To clean up this mess, I've devised a cunning plan, involving a C-parser,
that can write a structure definition as XML. Reading this is simple enough,
and going from that to a format string for struct.unpack() is mostly
trivial. Except for the arrays of some C-type, that happens to be something
else than an array of char. Due to the normal use case[2] of dumping this
binary data, I need to get the parsed data munged into a form, that can be
put into a namedtuple as single member, even when I have an array of
(typical) six conv.alt values. I'm getting stuck with the limitations of
struct and namedtuple. While inheriting either of them to get the job done,
seem to be feasible, I still feel that I somehow should be able to do
something list comprehension-ish, to avoid going there. I just can't see
the light.

(Thank you for reading all the way to here!)


1. Luggage, parcels, shop replenishments ... In short: mostly rectangular
   things that has a barcode attached.

2. Random ordering, not displaying all members, and only a part of the
   arrays.

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

Hello Group and how to practice?

[Anders Johansen]

Hi my name is Anders I am from Denmark, and I am new to programming and python.

Currently, I am doing the codecademy.com python course, but sometime I feel 
that the course advances to fast and I lack repeating (practicing) some of the 
concepts, however I don't feel confident enough to start programming on my own.

Do you guys have some advice to how I can practicing programming and get the 
concept in under the skin?

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

Re: Hello Group and how to practice?

[Anders Johansen]

Den søndag den 31. maj 2015 kl. 16.22.10 UTC+2 skrev Cem Karan:
 On May 31, 2015, at 9:35 AM, Anders Johansen sko...@gmail.com wrote:
 
  Hi my name is Anders I am from Denmark, and I am new to programming and 
  python.
  
  Currently, I am doing the codecademy.com python course, but sometime I feel 
  that the course advances to fast and I lack repeating (practicing) some of 
  the concepts, however I don't feel confident enough to start programming on 
  my own.
  
  Do you guys have some advice to how I can practicing programming and get 
  the concept in under the skin?
 
 Choose something that you think is small and easy to do, and try to do it.  
 When you have trouble, read the docs you find online, and ask us questions; 
 the python community is pretty friendly, and if you show us what you've 
 already tried to do, someone is likely to try to help you out.
 
 The main thing is to not get discouraged.  One of the hardest things to do is 
 figuring out what you CAN do with a computer; some things that look like they 
 should be easy, are actually major research questions.  Just keep trying, and 
 it will get easier over time.
 
 Good luck!
 Cem Karan

Thank you Cem Karan for your reply. I will try and follow your advice. I am yet 
to install python on my computer, do you know of any easy to follow 
instructions on how to do so? Where do I start?
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue23123] Only READ support for Decimal in json

[Anders Rundgren]

Anders Rundgren added the comment:

 Antoine Pitrou added the comment:
 
 To cope with this potential problem, compliant parsers must preserve the 
 original textual representation of properties internally in order to support 
 JCS normalization requirements
 
 That sounds ridiculous. Did someone try to reason the IETF guys?:)

The alternative is either doing what Bob suggested which is almost the same as 
writing a new parser or take the IETF route and shroud the message payload in 
base64.

So all solutions are by definition bd :-)

FWIW my super-bad solution has the following compatibility issues:
- Whitespace: None, all parsers can stringify, right?
- Escaping: None, all parsers MUST do it to follow the JSON spec.
- Property order: A problem in some parsers.  If you take a look on 
stackoverflow lots of folks request that insertion/reader order should be 
honored since computers  humans.  Fixed in Python. Works in browsers as well.
- Floating point: an almost useless JSON feature anyway, it doesn't work for 
crypto-numbers or money.  It is only a validation problem though.  Now fixed 
in Python.

http://www.ietf.org/mail-archive/web/acme/current/msg00200.html

--

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

[issue23123] Only READ support for Decimal in json

[Anders Rundgren]

Anders Rundgren added the comment:

 Antoine Pitrou added the comment:
 
 I won't claim to know/understand the specifics, but message payload in 
 base64 actually sounds reasonable to me, if far from optimal (both from 
 readibility and space overhead POV) :-).

It is indeed a working solution.  I do though think that communities that 
previously used XML would accept base64-encoded messages.  It becomes really 
messy when applied to counter-signed messages like the following:

{
  @context: http://xmlns.webpki.org/wcpp-payment-demo;,
  @qualifier: AuthData,
  paymentRequest: 
{
  commonName: Demo Merchant,
  amount: 8600550,
  currency: USD,
  referenceId: #100,
  dateTime: 2014-12-18T13:39:35Z,
  signature: 
{
  algorithm: RS256,
  signerCertificate: 
{
  issuer: CN=Merchant Network Sub CA5,C=DE,
  serialNumber: 1413983542582,
  subject: CN=Demo Merchant,2.5.4.5=#1306383936333235,C=DE
},
  certificatePath: 
[
  
MIIDQzCCAiugAwIBAgIGAUk3_J02M...eMGlY734U3NasQfAhTUhxrdDbphEvsWTc,
  
MIIEPzCCAiegAwIBAgIBBTANBgkqh...gU1IyRGA7IbdHOeDB2RUpsXloU2QKfLrk
],
  value: 
Ny4Qe6FQhd5_qcSc3xiH8Kt7tIZ9Z...9LEjC6_Rulg_G20fGxJ-wzezFpsAGbmuFQg
}
},
  domainName: merchant.com,
  cardType: SuperCard,
  pan: 1618342124919252,
  dateTime: 2014-12-18T13:40:59Z,
  signature: 
{
  algorithm: RS256,
  signerCertificate: 
{
  issuer: CN=Mybank Client Root CA1,C=US,
  serialNumber: 1413983550045,
  subject: CN=The Cardholder,2.5.4.5=#13083935363733353232
},
  certificatePath: 
[MIIENzCCAh-gAwIBAgIGAUk3_LpdM...IGcN1md5feo5DndNnV8D0UM-oBRkUDDFiWlhCU],
  value: 
wyUcFcHmvM5ZozZKOEwOQkYic0D7M...S_HbaPGau5KfZjCaksvb5U1lYZaXxP8kAbuGPQ
}
}

--

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

[issue23123] Only READ support for Decimal in json

[Anders Rundgren]

Anders Rundgren added the comment:

I guess my particular requirement/wish is unusual (keeping the original textual 
representation of a floating point number intact) while using Decimal should be 
fairly universal.

If these things could be combined in a Decimal support option I would (of 
course) be extremely happy.  They do not appear to be in conflict.

Currently I'm a bit bogged down by the crypto-stuff since it is spread over 
different and incompatible modules which makes it awkward creating a nice 
unified RSA/EC solution.  I may end-up writing a wrapper...

--

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

[issue23123] Only READ support for Decimal in json

[Anders Rundgren]

Anders Rundgren added the comment:

Bob,
Your'e right, I have put up a requirement for JSON serializing that may be 
over the top.  OTOH, there are (AFAICT...) only two possible solutions:
1. Outlaw floating point data from the plot
2. Insist that serializers conform to the spec

As a pragmatic I have settled on something in between :-)
https://openkeystore.googlecode.com/svn/resources/trunk/docs/jcs.html#Interoperability

I don't think that the overhead in Decimal would be a problem but I'm not a 
Python platform maintainer so I leave it to you guys.

--

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