[issue37515] `open("aux.txt", "w")` fails unexpectedly with FileNotFoundError on Windows
New submission from Carsten :
I maintain a package which includes a package named "aux.py".
I could not install it on my windows machine via pip and others had the same
problem also with windows.
I tracked down the problem to `io.open`. On my Windows 7 System with Python
3.7.1 from Anaconda, the following statements all result in a FileNotFoundError:
open("aux", "w")
open("Aux", "w")
open("AUX", "w")
open("aux.py", "w")
open("aux.py", "wb")
open("aux.txt", "w")
On the other hand the following commands work as expected:
open("aaux", "w")
open("AUX1.txt", "w")
open("aux2.py", "w")
etc.
Can anybody confirm this?
On Linux (I could not reproduce the problem.)
--
components: IO
files: bug.png
messages: 347436
nosy: CarK
priority: normal
severity: normal
status: open
title: `open("aux.txt", "w")` fails unexpectedly with FileNotFoundError on
Windows
versions: Python 3.7
Added file: https://bugs.python.org/file48459/bug.png
___
Python tracker
<https://bugs.python.org/issue37515>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37515] `open("aux.txt", "w")` fails unexpectedly with FileNotFoundError on Windows
Carsten added the comment:
This is a good explanation. Indeed Windows complains if I manually want to
create a file "aux.txt" ("This device name is not allowed").
If I want to copy-paste such a file from within a zip-file (Windows Explorer
can open zip files) I get an "Unexpected Error".
I think a descriptive error message would be very helpful here. The best
mechanism would be if this was generated on system level and then just passed
through by io.open to the generated Exception. But just throwing a
"FileNotFoundError" without any hint is potentially frustrating.
Suggestion for a better Error message: "Could neither open nor create the
desired file. Maybe the filename is not allowed by the underlying os".
--
___
Python tracker
<https://bugs.python.org/issue37515>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28837] 2to3 does not wrap zip correctly
New submission from Carsten: The following Python 2.7 code is not converted correctly to Python 3 by 2to3: c = [(1, 10), (2, 20)] # get a tuple with the first entries of every tuple in c, # i.e. (1, 2) x = zip(*c)[0] print x The result is c = [(1, 10), (2, 20)] # get a tuple with the first entries of every tuple in c, # i.e. (1, 2) x = zip(*c)[0] print(x) However running it with python3 gives the following exception Traceback (most recent call last): File "result.py", line 7, in x = zip(*c)[0] TypeError: 'zip' object is not subscriptable Tested with 2to3-2.7 and 2to3-3.4 on debian stable (jessie) -- components: 2to3 (2.x to 3.x conversion tool) messages: 282075 nosy: cvk priority: normal severity: normal status: open title: 2to3 does not wrap zip correctly type: behavior versions: Python 2.7, Python 3.4 ___ Python tracker <http://bugs.python.org/issue28837> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1063] Small typo in properties example
New submission from Carsten Grohmann: The example for property() contains a typo / small bug: class C(object): def __init__(self): self.__x = None [...] should be: class C(object): def __init__(self): self._x = None [...] Source: http://docs.python.org/lib/built-in-funcs.html -- components: Documentation messages: 55505 nosy: cgrohmann severity: minor status: open title: Small typo in properties example versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1063> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1087] py3k os.popen result is not iterable, patch attached
Changes by Carsten Haese: -- components: Library (Lib) severity: normal status: open title: py3k os.popen result is not iterable, patch attached type: behavior versions: Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1087> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1087] py3k os.popen result is not iterable, patch attached
Changes by Carsten Haese: __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1087> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9659] frozenset, when subclassed will yield warning upon call to super(...).__init__(iterable)
New submission from Carsten Klein : Example class a(frozenset): def __init__(self, iterable): super(a, self).__init__(iterable) i = a([1,2,3]) > __main__:3: DeprecationWarning: object.__init__() takes no parameters > a([1, 2, 3]) This might be due to the fact that the frozenset type structure does not initialize the tp_init field in setobject.c, thus inheriting the original __init__ from object. Subclassing set will not issue that warning as it actually defines the tp_init field to (initroc)set_init. This holds true also for the Python 2.7 release and maybe also later releases. Expected behaviour: do not output that warning message and provide an initproc for the tp_field. -- components: None messages: 114676 nosy: carsten.kl...@axn-software.de priority: normal severity: normal status: open title: frozenset, when subclassed will yield warning upon call to super(...).__init__(iterable) type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue9659> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9659] frozenset, when subclassed will yield warning upon call to super(...).__init__(iterable)
Carsten Klein added the comment: Thanks for the information. Where is this documented? I cannot find it in the official Python docs... TIA. -- ___ Python tracker <http://bugs.python.org/issue9659> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9680] Add in declaration order support for the dictionary passed in to the meta class __init__ and __new__ methods
New submission from Carsten Klein : Example class Meta(type): def __new__(cls, name, bases, locals): print repr(locals.keys()) class Test(object): __metaclass__ = Meta A = 1 B = 2 C = 3 D = 4 E = 5 The above will yield the keys in a somewhat random order, everytime you start up the Python interpreter: ['__module__', 'E', 'C', 'D', 'B', '__metaclass__', 'A'] While the above example is far from complete, it shows the basic dilemma when having some concept that relies on the order in which the elements have been declared and in the order by which they have been processed during the parse phase and ast traversal phase. In the aforementioned first two phases one can rely on the declaration order, but as soon as we enter the __new__ method, the order becomes irrelevant and is completely lost. For a framework of mine, I would like the locals dict that is being passed as an argument to the __new__ method to give out references to the keys in the order in which they have been declared in the dict. Thus, the above example would yield ['__metaclass__', '__module__', 'A', 'B', 'C', 'D', 'E'] The basic reason is that I find it more intuitive to class A(object): __metaclass__ = Meta A = 5 Z = 9 than class A(object): __metaclass__ = Meta __fields__ = ((A,5), (Z,9)) As you might easily guesses, the main application for the above is a new enum type I am currently developing, where the order is important as every new instance of that class must always yield the same ordinals for the individual constants declared. This should not break with the overall contract of the dict, which defines that keys returned are in no specific order. Thus, adding a specific order to keys in the above locals dict for class instantiation purposes only, would not break with existing code and should be both backwards and forwards compatible. -- components: Interpreter Core messages: 114890 nosy: carsten.kl...@axn-software.de priority: normal severity: normal status: open title: Add in declaration order support for the dictionary passed in to the meta class __init__ and __new__ methods type: feature request versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue9680> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2193] Cookie Colon Name Bug
Carsten Klein added the comment:
Guess you are right...
I did overlook the quoted-string reference in the RFC:
av-pair = attr ["=" value]; optional value
attr= token
value = word
word= token | quoted-string
The actual production rules for quoted-string are not specified, so I guess
that anything resembling unicode data would be allowed in that string provided
that:
[...] from RFC 2109
10.1.3 Punctuation
In Netscape's original proposal, the values in attribute-value pairs
did not accept "-quoted strings. Origin servers should be cautious
about sending values that require quotes unless they know the
receiving user agent understands them (i.e., "new" cookies). A
("new") user agent should only use quotes around values in Cookie
headers when the cookie's version(s) is (are) all compliant with this
specification or later.
in RFC 2965 there is no such notice...
However, and this is important, the cookie values not matching token must be
quoted by the origin server upon setting and the client must return these as
quoted strings as well.
--
___
Python tracker
<http://bugs.python.org/issue2193>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2193] Cookie Colon Name Bug
Carsten Klein added the comment:
Ups forgot to also mention the production rule for token, which is defined in
the HTTP RFC RFC2616:
token = 1*
separators = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
and here it clearly states that a value that is not a quoted string
must not contain colons, and other characters as is specified by separators.
--
___
Python tracker
<http://bugs.python.org/issue2193>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2193] Cookie Colon Name Bug
Carsten Klein added the comment: Perhaps the best solution would be for the Python cookie module to gracefully adapt to servers not quoting cookie values as is required by the RFCs and make these quoted-strings instead? -- ___ Python tracker <http://bugs.python.org/issue2193> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11774] Issue tracker sends notification mails twice...
New submission from Carsten Klein : Currently I am receiving duplicates of the notification mails by your issue tracker. -- messages: 133062 nosy: carsten.kl...@axn-software.de priority: normal severity: normal status: open title: Issue tracker sends notification mails twice... ___ Python tracker <http://bugs.python.org/issue11774> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11774] Issue tracker sends notification mails twice...
Carsten Klein added the comment: It seems that it only happens when commenting upon an existing issue. -- ___ Python tracker <http://bugs.python.org/issue11774> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11774] Issue tracker sends notification mails twice...
Carsten Klein added the comment: Nope, it only happens on issue [issue2193] Cookie Colon Name Bug but not for this one. -- ___ Python tracker <http://bugs.python.org/issue11774> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11774] Issue tracker sends notification mails twice...
Carsten Klein added the comment: Ah, I see, thanks for the input. Will close this then. -- ___ Python tracker <http://bugs.python.org/issue11774> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11774] Issue tracker sends notification mails twice...
Carsten Klein added the comment: I wonder how this happened... Thanks for the finding! -- ___ Python tracker <http://bugs.python.org/issue11774> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2193] Cookie Colon Name Bug
Changes by Carsten Klein : -- nosy: +carsten.klein -carsten.kl...@axn-software.de ___ Python tracker <http://bugs.python.org/issue2193> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11774] Issue tracker sends notification mails twice...
Carsten Klein added the comment: Actually I logged in using carsten.kl...@axn-software.de and the tracker changed my login name to that... Will issue a bug against the tracker... -- nosy: +carsten.klein ___ Python tracker <http://bugs.python.org/issue11774> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11774] Issue tracker sends notification mails twice...
Changes by Carsten Klein : -- nosy: -carsten.kl...@axn-software.de ___ Python tracker <http://bugs.python.org/issue11774> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11788] Decorator class with optional arguments and a __call__ method gets not called when there are no arguments
New submission from Carsten Klein : Scenario: class deco(object): def __init__(self, optional = False): self._optional = optional def __call__(self, decorated): decorated.optional = self._optional return decorated @deco class y(object): pass will fail decorating the class since y is passed in as the first parameter to deco.__init__, and deco.__call__ will never be called. @deco(optional = True) class y(object): pass will succeed. I wonder why there is a distinction between decorator class w/ arguments and decorator class w/o arguments? Guessing that one would like to have a decorator class decorating another class and also acting as a kind of proxy by implementing a __call__ method, this could also be achieved by further indirection, provided that it will not break existing code. A working alternative would be a decorator function like this: def deco(_decorated = None, optional = False): def _wrapped(decorated): decorated.optional = optional return decorated if _decorated is not None: return _wrapped(decorated) return _wrapped Is there a chance that the behavior of the decorator class will be fixed in a future release? Expected behavior for the decorator class would be: if formal parameter list has optional parameters and actual parameter list is empty and there are no formal mandatory parameters: if decorator class is callable: deco = decorator class () decor.__call__(decorated) else: fall back to old behaviour, requiring the decorator class __init__ method to have one mandatory parameter else: deco = decorator class(actual parameters...) deco.__call__(decorated) TIA -- components: Interpreter Core messages: 133171 nosy: carsten.klein priority: normal severity: normal status: open title: Decorator class with optional arguments and a __call__ method gets not called when there are no arguments type: behavior versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue11788> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11788] Decorator class with optional arguments and a __call__ method gets not called when there are no arguments
Carsten Klein added the comment: will fail decorating the class since y... actually means that instead of an instance of class y, an instance of the decorator class will be returned, with y being lost along the way... -- ___ Python tracker <http://bugs.python.org/issue11788> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11789] Extend upon metaclass/type class documentation, here: zope.interface and usage of instances of classes as base classes
New submission from Carsten Klein : In zope.interface, you have something the following construct: class InterfaceBase: pass Interface = InterfaceBase() Using the above Interface as a derivation base for your own classes, will make that instance a type derived class: class IFoo(Interface): pass type(IFoo) -> Interface type(Interface) -> type I wonder why this behavior is not documented in the official documentation, or at least, I was unable to find it there... -- assignee: docs@python components: Documentation messages: 133173 nosy: carsten.klein, docs@python priority: normal severity: normal status: open title: Extend upon metaclass/type class documentation, here: zope.interface and usage of instances of classes as base classes type: feature request versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue11789> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11788] Decorator class with optional arguments and a __call__ method gets not called when there are no arguments
Carsten Klein added the comment: I think it is, actually, considering @foo @bar class A: pass with foo and bar being both decorator classes, the chained call foo(bar(A)) will return and instance of foo instead of A With decorator classes you need to actually do this: foo()(bar()(A)) which will give you the "required" result, an instance of class A. -- ___ Python tracker <http://bugs.python.org/issue11788> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11788] Decorator class with optional arguments and a __call__ method gets not called when there are no arguments
Carsten Klein added the comment: Ok, looks like a valid work around to me. However, IMO it is not the same as with decorator functions. These will be called and will return the correct result, whereas the decorator class will instead return an instance of self instead of being called when no parameters are given. -- ___ Python tracker <http://bugs.python.org/issue11788> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10813] Suppress adding decimal point for places=0 in moneyfmt()
New submission from Carsten Grohmann :
Hi,
the documentation of the decimal module contains a small recipe called
moneyfmt() for format decimal values. It's very usefull.
I'd like to suggest a small improvement because the output is incorrect with
given dp="." (default) and places=0.
Example:
>>> moneyfmt(decimal.Decimal('-0.02'), neg='<', trailneg='>', places=1)
'<0.0>'
>>> moneyfmt(decimal.Decimal('-0.02'), neg='<', trailneg='>', places=0)
'<0.>'
Change:
--- moneyfmt.py 2011-01-03 13:56:32.774169788 +0100
+++ moneyfmt.py.new 2011-01-03 13:56:58.130165330 +0100
@@ -33,7 +33,8 @@
build(trailneg)
for i in range(places):
build(next() if digits else '0')
- build(dp)
+if places:
+build(dp)
if not digits:
build('0')
i = 0
What do you think about the change?
Regrads,
Carsten
--
assignee: d...@python
components: Documentation
messages: 125164
nosy: cgrohmann, d...@python
priority: normal
severity: normal
status: open
title: Suppress adding decimal point for places=0 in moneyfmt()
___
Python tracker
<http://bugs.python.org/issue10813>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10813] Suppress adding decimal point for places=0 in moneyfmt()
Carsten Grohmann added the comment: Setting dp to an empty string is only a workaround from my perspective. I get the value of the places parameter from a configuration instance and have to implement an additional check "places == 0" every time I call the original moneyfmt(). To reduce this effort I've changed my moneyfmt() function and applied the patch above. I see only a valuable posibilities from my perspective: apply the patch. Because it would simplify life a little bit :-) At end it's up to you because the current documentation stated "dp: ... only specify as blank when places is zero". Regards, Carsten -- ___ Python tracker <http://bugs.python.org/issue10813> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue410547] os.statvfs support for Windows
Carsten Koch added the comment: Here is what I am doing now: ... if sys.platform == "win32": import win32file else: import statvfs ... def get_free_space(path = '.'): """ Determine the free space in bytes for the given path. """ if sys.platform == "win32": sizes = win32file.GetDiskFreeSpace(path) return sizes[0] * sizes[1] * sizes[2] else: status = os.statvfs(path) return status[statvfs.F_BAVAIL] * status[statvfs.F_FRSIZE] def get_partition_size(path = '.'): """ Determine the total space in bytes for the given path. """ if sys.platform == "win32": sizes = win32file.GetDiskFreeSpace(path) return sizes[0] * sizes[1] * sizes[3] else: status = os.statvfs(path) return status[statvfs.F_BLOCKS] * status[statvfs.F_FRSIZE] -- versions: +Python 2.6 ___ Python tracker <http://bugs.python.org/issue410547> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2193] Cookie Colon Name Bug
Carsten Klein added the comment: Personally I believe that this is WONTFIX. Why? Because, the original RFC states that the colon is part of the unwanted characters, regardless of whether Perl or other similar implementations ignore the standard. Besides that, and most important: The cookies are always set by the server or application thereof. Therefore, the server must behave just like what is stated in the original RFC. And it must also expect existing browsers to behave just like what is requested in the RFC. IMO, the original requester and supporters, both here and over on the trac issue tracker are simply not able to figure out a proper cookie tracking mechanism for marketing or whatever purposes. Or, perhaps, they want to exploit some unwanted behaviour in existing user agents, who knows. Besides that, if the original poster and follow up requesters supporting the issue persist on using a non standard implementation of the cookie library, hey, who cares. Let them figure out how to patch or rewrite the existing library, and how to include it with their favourite server/user agent exploiting implementation. And the same is true for the request on the trac issue tracker. Since the cookies are set by the server, there is no need to actually weaken the existing pseudo standard by incorporating ways to hierarchically define a cookie name other than what is already present in the scheme or could be accomplished using different characters other than those blacklisted. -- nosy: +carsten.klein ___ Python tracker <http://bugs.python.org/issue2193> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2193] Cookie Colon Name Bug
Carsten Klein added the comment:
One more: if you look closer at the accepted patch by CMLENZ over @ t.e.o., you
will find:
if self.req.headers_in.has_key('Cookie'):
-self.incookie.load(self.req.headers_in['Cookie'])
+#self.incookie.load(self.req.headers_in['Cookie'])
+cookie = self.req.headers_in['Cookie']
+old_set = self.incookie._BaseCookie__set
+bad_cookies = []
+def safe_set(key, real_value, coded_value):
+try:
+old_set(key, real_value, coded_value)
+except CookieError:
+bad_cookies.append(key)
+dict.__setitem__(self.incookie, key, None)
+# override Cookie.set to ignore cookies with parse errors
+self.incookie._BaseCookie__set = safe_set
+ # load the cookie values
+self.incookie.load(cookie)
+# clean up the Cookie.set overriding
+self.incookie._BaseCookie__set = old_set
+for key in bad_cookies:
+del self.incookie[key]
+
which will eventually delete all cookies that do not match the original
production rule.
Besides that, the original poster of the issue forgot to properly limit the
cookies set by the other site to just a single host path, so these invalid
cookies got routed to the trac instance running on some different host.
--
___
Python tracker
<http://bugs.python.org/issue2193>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2193] Cookie Colon Name Bug
Carsten Klein added the comment: if you'd take a close look at the following lines accepted as part of the patch for stripping out unwanted/non standard cookies over trac: +try: +old_set(key, real_value, coded_value) +except CookieError: +bad_cookies.append(key) then you will find that trac actually behaves just like what is requested in the "original" RFC, namely that the colon is part of the reserved or special characters not meant for inclusion with the cookie name or, as it was stated in the referred rfc, the token. Please do not fix. -- nosy: +carsten.kl...@axn-software.de ___ Python tracker <http://bugs.python.org/issue2193> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2193] Cookie Colon Name Bug
Carsten Klein added the comment: Besides that, BM is wrong in the assumption that *who ever he is* Davi M. Kristol states that the colon is a valid character. There is no such notion in the article. In fact, DMK repeats the definition found in the original RFC on cookies, which also was referred to in the follow up RFC and then again referred to in the current RFC which seeks to get rid of the set-cookie2 directive, combining the two RFCs into a single RFC/pseudo standard. -- ___ Python tracker <http://bugs.python.org/issue2193> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3185] Documentation of time.time() differs from source documentation
New submission from Carsten Grohmann <[EMAIL PROTECTED]>: The current python documentation of the time module (http://docs.python.org/lib/module-time.html) means that time.time() returns the "seconds since the epoch, in UTC". But in the current source documentation of the time module (http://svn.python.org/view/python/trunk/Modules/timemodule.c?rev=64048&view=markup) is written that "time() -- return current time in seconds since the Epoch". time.time() returns the current local unix seconds during tests on a system using Python 2.5. Please adapt the documentation. Thanks, Carsten -- assignee: georg.brandl components: Documentation messages: 68666 nosy: cgrohmann, georg.brandl severity: normal status: open title: Documentation of time.time() differs from source documentation versions: Python 2.5 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3185> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3185] Documentation of time.time() differs from source documentation
Carsten Grohmann <[EMAIL PROTECTED]> added the comment: "current local unix seconds" means seconds since the Epoch in local timezone. I've attached a small example to show that is no difference between the time returned by time.localtime() and time.time(). So I assume that time.time() also returns local time and not UTC. >>> time.mktime(time.localtime()) 1214290130.0 >>> time.time() 1214290130.697067 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3185> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2648] decimal receipe moneyfmt suppress leading 0
New submission from Carsten Grohmann <[EMAIL PROTECTED]>: The current version of the receipe moneyfmt doesn't have a leading "0" for 1 < value < -1. The attached patch adds a new parameter "zero". The parameter is empty per default and can set to "0" print a leading "0". The examples are updated also. Possibly the new option should be "0" per default. Regards, Carsten -- assignee: georg.brandl components: Documentation files: moneyfmt.diff keywords: patch messages: 65581 nosy: cgrohmann, georg.brandl severity: normal status: open title: decimal receipe moneyfmt suppress leading 0 versions: Python 2.5 Added file: http://bugs.python.org/file10046/moneyfmt.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2648> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36792] [Windows] time: crash on formatting time with de_DE locale
Change by Carsten Fuchs : -- nosy: +Carsten Fuchs ___ Python tracker <https://bugs.python.org/issue36792> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43692] Raise SyntaxError on implicit string concatentation in list
New submission from Carsten Docktor : I recently found several bugs, which came from the "feature" shown below. Is python supposed to use string concatenation in a list environment like this? Why would this be appreciated? ## Expected Behavior The example below should raise a SyntaxErorr for a missing comma. String concatenation in a list should require brackets. ## Current Behavior Missing commas in a string list lead to unnoticed concatenated strings. ## Steps to Reproduce ```python my_list = [ "a", "b" "c", "d" ] interpreted_list = [ "a", "bc", "d", ] assert my_list == interpreted_list # unwanted behavior ``` -- components: Interpreter Core messages: 389970 nosy: carsten.docktor priority: normal severity: normal status: open title: Raise SyntaxError on implicit string concatentation in list type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue43692> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43692] Raise SyntaxError on implicit string concatentation in list
Carsten Docktor added the comment: I'd consider this a bug, because I find it quite error prone. But I get the point that it might be currently used. Thank you for your response. I'll rely on third party checkers for this. -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue43692> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42173] Drop Solaris support
Carsten Grzemba added the comment: Please continue support for Solaris/IllumOS! For build resources on the most recent Solaris platforms you can contact opencsw.org. -- nosy: +cgrzemba ___ Python tracker <https://bugs.python.org/issue42173> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12370] Use of super overwrites use of __class__ in class namespace
Carsten Klein added the comment: The change was introduced in r30 (Python/symtable.c @ near where it reads /* Special-case super: it counts as a use of __class__ */) which now enforces that a class that calls super on init will have the correct class information present. I do not think that this is a bug and that it should be fixed. Instead it enforces both type safety in respect to classes deriving from a given class hierarchy being forced to report their actual class instead of some fabricated and customly induced one. If you require such behaviour then you should implement your own meta class that will then override the __class__ property. And, yes, I do think that Python < 3.0 was wrong in the assumption that one could build up class hierarchies and then break out of that class hierarchy by simply providing a __class__ property that would return a different value as what one would expected. What do the others think? -- nosy: +carsten.kl...@axn-software.de ___ Python tracker <http://bugs.python.org/issue12370> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16394] Improving tee() memory footprint
New submission from Carsten Milkau: The memory footprint of itertools.tee can be reduced substantially by using a shared buffer for the child iterators (see sample code). If local queues are desired for efficient threading support, they can be combined with a global queue, allowing to constrain the size of local queues. -- components: Library (Lib) files: tee.py messages: 174632 nosy: cami priority: normal severity: normal status: open title: Improving tee() memory footprint type: performance versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file27856/tee.py ___ Python tracker <http://bugs.python.org/issue16394> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16394] Improving tee() memory footprint
Carsten Milkau added the comment: No. The sample code is a demonstration how to do it, it's by no means a full-fledged patch. The drawback of the current implementation is that if you tee n-fold, and then advance one of the iterators m times, it fills n queues with m references each, for a total of (n-1)*m references. The documentation explicitly mentions this is unfortunate. I only demonstrate that it is perfectly unnecessary to fill n separate queues, as you can use a single queue and index into it. Instead of storing duplicate references, you can store a counter with each cached item reference. Replacing duplicates by refcounts, it turns (n-1)*m references into 2*m references (half of which being the counters). Not in the demo code: you can improve this further by storing items in iterator-local queues when that iterator is the only one that still needs to return it, and in a shared queue with refcount when there are more of them. That way, you eleminate the overhead of storing (item, 1) instead of item for a fix-cost per-iterator. -- versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue16394> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16394] Improving tee() memory footprint
Carsten Milkau added the comment: Oh great! Then I can use it as-is. How about reassigning the issue to documentation (for clarifying the inefficiency warning)? -- ___ Python tracker <http://bugs.python.org/issue16394> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16394] Improving tee() memory footprint
Changes by Carsten Milkau : -- assignee: -> docs@python components: +Documentation -Library (Lib) nosy: +docs@python ___ Python tracker <http://bugs.python.org/issue16394> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11159] Sax parser crashes if given unicode file name
Changes by Carsten Grohmann : -- nosy: +cgrohmann ___ Python tracker <http://bugs.python.org/issue11159> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16806] col_offset is -1 for multiline string expressions resembling docstrings
New submission from Carsten Klein:
Given an input module such as
class klass(object):
"""multi line comment
continued on this line
"""
"""single line comment"""
"""
Another multi
line
comment"""
and implementing a custom ast.NodeVisitor such as
import as
class CustomVisitor(ast.NodeVisitor):
def visit_ClassDef(self, node):
for childNode in node.body:
self.visit(childNode)
def visit_Expr(self, node):
print(node.col_offset)
print(node.value.col_offset)
and feeding it the compiled ast from the module above
f = open('./module.py')
source = f.read()
node = ast.parse(source, mode = 'exec')
visitor = CustomVisitor()
visitor.visit(node)
should yield -1/-1 for the docstring that is the first
child node expression of the classdef body.
it will, however, yield the correct col_offset of 4/4 for
the single line docstring following the first one.
the multi line docstring following that will again
yield a -1/-1 col_offset.
It believe that this behaviour is not correct and instead
the col_offset should be 4 for both the expression node
and its str value.
--
components: Interpreter Core
messages: 178444
nosy: carsten.kl...@axn-software.de
priority: normal
severity: normal
status: open
title: col_offset is -1 for multiline string expressions resembling docstrings
type: enhancement
versions: Python 3.4
___
Python tracker
<http://bugs.python.org/issue16806>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16806] col_offset is -1 for multiline string expressions resembling docstrings
Carsten Klein added the comment: Please note that, regardless of the indent level, the col_offset for multi line str expressions will always be -1. -- ___ Python tracker <http://bugs.python.org/issue16806> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16806] col_offset is -1 for multiline string expressions resembling docstrings
Carsten Klein added the comment: In addition, the reported lineno will be set to the last line of the multi line string instead of the first line where parsing the parse began parsing the string. -- ___ Python tracker <http://bugs.python.org/issue16806> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16806] col_offset is -1 for multiline string expressions resembling docstrings
Carsten Klein added the comment: Please see the attached patch that will resolve the issue. It also includes a test case in test_ast.py. What the patch does is as follows: - tok_state is extended by two fields, namely first_lineno and multi_line_start - first_lineno will be set by tok_get as soon as the beginning of a STRING is detected and it will be set to the current line tok->lineno. - multi_line_start is the beginning of the first line of a string - in parsetok we now distinguish between STRING nodes and other nodes. in case of STRING nodes, we will use the values of the above fields for determining the actual lineno and the col_offset, otherwise tok->col_offset and tok->lineno will be used when creating the token. The included test case ensures that the col_offset and lineno of multi line strings is calculated correctly. -- keywords: +patch Added file: http://bugs.python.org/file28477/issue1680.diff ___ Python tracker <http://bugs.python.org/issue16806> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16806] col_offset is -1 and lineno is wrong for multiline string expressions
Changes by Carsten Klein : -- title: col_offset is -1 for multiline string expressions resembling docstrings -> col_offset is -1 and lineno is wrong for multiline string expressions ___ Python tracker <http://bugs.python.org/issue16806> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16806] col_offset is -1 and lineno is wrong for multiline string expressions
Changes by Carsten Klein : Removed file: http://bugs.python.org/file28477/issue1680.diff ___ Python tracker <http://bugs.python.org/issue16806> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16806] col_offset is -1 and lineno is wrong for multiline string expressions
Changes by Carsten Klein : Added file: http://bugs.python.org/file28478/issue16806.diff ___ Python tracker <http://bugs.python.org/issue16806> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16801] Preserve original representation for integers / floats in docstrings
Carsten Klein added the comment: The problem with this is that at the time that pydoc gets the information via inspect, the numbers have already been parsed as long or double and the original notation is no longer available. This is due to the fact that during build of the AST node for the NUMBER type, the value will already be deserialized into its machine representation, which is either long or double. The only way to preserve that information would be to extend the NUM_type with an additional 's' field which then would preserve its original notation and which can be retrieved from the AST. pydoc, however, would still fail as it does not use the AST. In order to restore the original information, pydoc must then source the original file or source of the function or class method and parse it using the AST. A much simpler approach would be to simply get the function or method source and extract its formal parameter list using for example a regular expression. However, preserving the original notation in the runtime is not required and shouldn't be done. -- nosy: +carsten.kl...@axn-software.de ___ Python tracker <http://bugs.python.org/issue16801> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16801] Preserve original representation for integers / floats in docstrings
Carsten Klein added the comment: Here are some links into the sources: Python/ast.c, ast_for_atom(), line 1872ff. Python/ast.c, parsenumber(), line 3632ff. -- ___ Python tracker <http://bugs.python.org/issue16801> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16801] Preserve original representation for integers / floats in docstrings
Carsten Klein added the comment: However, hinting inspect to use a different format when serializing the default values for existing keyword parameters of methods or functions seems to be a good idea and +1 by me for that. Personally, I'd rather have the decorator based solution than having to manually add additional fields to a given method or function. -- ___ Python tracker <http://bugs.python.org/issue16801> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16806] col_offset is -1 and lineno is wrong for multiline string expressions
Carsten Klein added the comment: I have created a patch for Python 2.7.3 that fixes the issue for that release, too. -- Added file: http://bugs.python.org/file28499/python2.7.3.diff ___ Python tracker <http://bugs.python.org/issue16806> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17067] Examples in documentation for 3.x in 23.1.3.4. Deferred translations are rather weak
New submission from Carsten Klein:
The examples for the topic presented are rather weak. In fact, they merely
present do nothing replacements for an actually working, deferred localization
mechanism or some sort of prototypical implementation thereof.
As such I propose that they be replaced with something more meaningful,
for example such as
class DeferredTranslation(object):
def __init__(self, message, ...):
self.message = message
def __str__(self):
return gettext.translation(...).lgettext(self.message)
def _(message, ...):
return DeferredTranslation(message, ...)
MSG = _('localized message')
Or something else along that way other than the currently presented examples :D
--
assignee: docs@python
components: Documentation
messages: 180882
nosy: carsten.kl...@axn-software.de, docs@python
priority: normal
severity: normal
status: open
title: Examples in documentation for 3.x in 23.1.3.4. Deferred translations are
rather weak
type: enhancement
versions: Python 3.3
___
Python tracker
<http://bugs.python.org/issue17067>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23102] distutils: isinstance checks fail with setuptools-monkeypatched Extension/Distribution
Changes by Carsten Grohmann : -- nosy: +cgrohmann ___ Python tracker <http://bugs.python.org/issue23102> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
