On 12/11/2013 12:34 AM, Devin Jeanpierre wrote:
On Tue, Dec 10, 2013 at 2:02 PM, Ethan Furman wrote:
Doesn't sound like they do, as that's causing plenty of problems. In
today's world that level of knowledge isn't always necessary, especially if
your degree is not in C
f members of the list.
Now that you've given some background you may get better answers.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
His credibility with me has been long dead. :(
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
s__.__name__ = 'some_proxy'
--> t.__class__.__name__
'some_proxy'
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
t obj.__class__ to a class, type(obj) returns
the new (external) type. How the hell does it decide which one to return?
However it does it, it does it in C. ;)
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
es is false.
Only object-oriented languages have *objects*. C does not have objects,
it has values.
The word 'object' has many more meanings than the one implied by Object
Oriented Programming, as you well know.
And yes, I'm being pedantic.
No, you're being an ass.
--
~Et
llion lines of code out there and
GBytes of program state, but right here, right now, within this circle
I've drawn in the sand,
Considering how easy it is to disable assertions, a circle in the sand is an
amazingly appropriate metaphor. :)
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
...]
First, the bug: there are circumstances where no exception is raised even if
all the strategies fail.
Since Steven wasn't explicit about the circumstances, I'll list the two I'm aware of: if Python is started with -O or
-OO then assertions are cut from the code and do not r
On 12/23/2013 07:10 AM, Roy Smith wrote:
In article ,
Ethan Furman wrote:
On 12/22/2013 08:57 PM, Roy Smith wrote:
In article <52b7a0e4$0$29994$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
Anyway, I may be completely misinterpreting what I'm read
r shout at you for
sending eyeballs to look at such a pile of steaming bullshit.
http://nuitka.net/posts/re-about-python-3.html is a response.
Wow -- another steaming pile! Mark, are you going for a record? ;)
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
On 12/30/2013 08:25 PM, Devin Jeanpierre wrote:
On Mon, Dec 30, 2013 at 2:38 PM, Ethan Furman wrote:
Wow -- another steaming pile! Mark, are you going for a record? ;)
Indeed. Every post that disagrees with my opinion and understanding of
the situation is complete BS and a conspiracy to
Accidental off-list reply. :)
On Tue, Dec 31, 2013 at 10:03 AM, Ethan Furman wrote:
On 12/30/2013 08:25 PM, Devin Jeanpierre wrote:
On Mon, Dec 30, 2013 at 2:38 PM, Ethan Furman wrote:
Wow -- another steaming pile! Mark, are you going for a record? ;)
Indeed. Every post that
class assign(object):
def set(self, value):
self._assignment = value
return value
def get(self):
return self._assignment
m = assign()
if m.set(r1.search(w)):
handleMatch1(m.get())
elif m.set(r2.search(w)):
handleMatch2(m.get())
else:
print("No matc
re wrong on this one, the split was simply
never noticed by anybody :)
Actually, the split was so severe the universe itself noticed and split
into two -- one where folks noticed, and one where nobody did... I
wonder which one we're in?
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
O?)
I haven't tested it, but your __new__ looks fine. The only thing you
lose by not calling super() is the inability for cooperative multiple
inheritance, except as the ultimate base class.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
On 01/03/2014 02:24 AM, Chris Angelico wrote:
I worked that out with a sheet of paper and a pencil. The pencil was a
little help, but the paper was three sheets in the wind.
Beautiful!
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
ceptions display a warning but continue to work, and in Python
2.6 they generate a compile-time SyntaxError.
Oh? Doesn't look like it.
Oh, it's a runtime TypeError, not SyntaxError.
The main point being that in 2.6 and 2.7 string exceptions do /not/ work.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
Matěj,
Thanks for your efforts!
However, you should only have one 'p' in scraping and scraper. ;)
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
ant my implicit conversion of 2 + '3' to get '23'
Huh. And here I thought 'twenty-three' was the right answer! ;)
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
really annoying. ;) On the upside adding 'from None' was a small enough project that I was
able to get it going, and that was the bridge to eventually becoming a dev. :D
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
g, but really it's just a bunch of integers:
--> b'abc
'b'abc'
--> b'abc'[1]
98
Maybe for 3.5 somebody *cough* will make a bytestring type for those of us who
have to support the lower-level protocols...
--
~Ethan~
*Cast your vote over on Python Ideas!
--
https://mail.python.org/mailman/listinfo/python-list
easily imagine the nightmare.
The most unfortunate aspect is that even if we did "fix" it in 3.5, it wouldn't help any body who has to support
multiple versions... unless, of course, a backport could also be made.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
On 01/05/2014 06:23 PM, Ethan Furman wrote:
Using my own project [1] as a reference
[1] https://pypi.python.org/pypi/dbf
--
https://mail.python.org/mailman/listinfo/python-list
ascii
text, you'd be wrong -- the field names are also encoded, as are the Character and Memo fields.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
2 did 'abc'[1] return 98.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
/AsciiDoc
Thanks for that!
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
On 01/06/2014 09:27 AM, Steven D'Aprano wrote:
Ethan Furman wrote:
Chris didn't say "bytes and ascii data", he said "bytes and TEXT".
Text != "ascii data", and the fact that some people apparently think it
does is pretty much the heart of the problem.
bytearrays) are containers of ints, so indexing returns an int. One big problem with this whole scenario is
that bytes then lies about what it contains. (And I hate lies! [1])
Anyway, I believe that's the rationale behind the change.
--
~Ethan~
[1] http://www.quickmeme.com/meme/3ts325
x27;abc\xFF'.decode('ascii-compatible')
That would be:
bytestring(b'abc\xFF')
Bytes outside the ASCII range would be mapped to Unicode low
surrogates:
bytestring(b'abc\xFF') == bytestring('abc\uDCFF')
Not sure what you mean here. The resulting
On 01/07/2014 04:15 PM, Steven D'Aprano wrote:
Ethan Furman wrote:
On 01/07/2014 07:19 AM, David Robinow wrote:
Python 3 grudgingly allows the "abomination" of byte strings (is that
what they're called?)
No, that is *not* what they're called. If you find any place
ive, you have a mess (temporal-bake, anyone?).
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
It looks like the .fromtimestamp also accepts tz=timezone.utc, so perhaps that is the simple way to get the timezone
aware datetime. I haven't tested, I'm going to bed. :/
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
into looking after issues.
Mark, I hope you are addressing the community at large and not the core-devs. There are only so many of us, with
limited time available.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
a time_t will cover
everything in an ugly way, but that a class wrapping it up could fix
that. And fundamentally, the only problem with datetime (which, for
the most part, is exactly that wrapper) is that it's unobvious how to
get a simple UTC timestamp.
It has at least one other problem: bool(
him. His one, minor, contribution has been completely swamped by the rest of his belligerent, unfounded, refuted
posts.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
On 01/09/2014 10:18 AM, Mark Lawrence wrote:
On 09/01/2014 16:01, Ethan Furman wrote:
On 01/09/2014 12:42 AM, Mark Lawrence wrote:
On 09/01/2014 01:27, Roy Smith wrote:
Naive datetimes are what everybody uses. It's what utcnow() gives you.
So why make life difficult for everybody? Pyt
ammer.
With the timezone stuff we're looking for The One Obvious Way, which should be
a method, not a recipe.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
#x27;t. Further investigation revealed that "py6" is made up of the bytes d1
80 d1 83 d0 b1.
Any ideas on what that means, exactly?
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
On 01/09/2014 10:49 AM, Ethan Furman wrote:
So I'm working with postgres, and I get a datadump which I try to restore to my
test system, and I get this:
ERROR: value too long for type character varying(4)
CONTEXT: COPY res_currency, line 32, column symbol: "руб"
"py6
lly.
A useful data point for why you don't just use bytes on the Python side would be valuable for the discussions currently
taking place on PyDev.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
list can be a help to all wanting to go
this (not always smooth :-) way.
ENDQUOTE
Thanks for finding this mailing list. I have subscribed to it. :)
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
Python 3 has a new method, __bytes__. The docs say: Called by bytes() to compute a byte-string representation of an
object. This should return a bytes object.
I must admit I'm not entirely clear how this should be used. Is anyone using
this now? If so, how?
--
~Ethan~
--
On 01/11/2014 04:53 PM, Daniel da Silva wrote:
Where did you read this? I can't find any documentation about __bytes__ on
google.
http://docs.python.org/3.3/reference/datamodel.html?highlight=__bytes__#object.__bytes__
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
.
I don't think so, for two reasons:
1) bytes objects do not have a __bytes__ method,
2) if the function is expecting a bytes object, it is unlikely to call bytes()
on it.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
On 01/11/2014 08:56 PM, Daniel da Silva wrote:
I agree with you that realistic use cases are hard to think of.
Does that answer your question better?
Well, since I was asking if anybody was already using the feature, no. ;)
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
On 01/14/2014 01:26 PM, Dan Stromberg wrote:
On Sat, Jan 11, 2014 at 2:04 PM, Dan Stromberg wrote:
Hi folks.
I have a setup.py problem that's driving me nuts.
Anyone? I've received 0 responses.
I have no answer, but forwarding to Distutils (hopefully it's an appropriate
topic ;)
I hav
On 01/15/2014 07:47 PM, Ben Finney wrote:
Steven D'Aprano writes:
(4) Don't return anything, but raise an exception. (But
which exception?)
+1. I'd like a custom exception class, sub-classed from ValueError.
+1
--
~Ethan~
--
https://mail.python.org/mailman/
least is
usually close to catastrophic in nature [2].
I'd say a ValueError subclass because, while not an strictly an error, it is values you don't know how to deal with.
But either that or plain Exception, just not RuntimeError.
--
~Ethan~
[1] http://docs.python.org/3/library/e
.pyo offer better protection?
No and no.
Distribute your code with a copyright notice, accept that a few people
will rip you off, and have done with it.
Yes. One of the nice things about Python is being able to fix bugs myself [1].
--
~Ethan~
[1] Yes, I file upstream bug reports
A BOM!!!" :)
Special delivery, a berm! Were you expecting one?
Endian detection: Does my BOM look big in this?
LOL!
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
gt; quux1(2.3)
'3.3'
--> quux2(2.3)
Traceback (most recent call last):
File "", line 1, in
File "", line 1, in quux2
TypeError: hex() argument can't be converted to hex
(Will be) fixed in 3.5 [1] :)
--
~Ethan~
[1] Which is to say, both will raise a
On 01/19/2014 08:38 AM, Chris Angelico wrote:
On Mon, Jan 20, 2014 at 3:14 AM, Ethan Furman wrote:
--> def quux1(x): return str(x+1)
--> quux1(2.3)
'3.3'
(Will be) fixed in 3.5 [1] :)
[1] Which is to say, both will raise an exception.
Why would that raise?
Sorry, shoul
On 01/19/2014 10:41 AM, Chris Angelico wrote:
On Mon, Jan 20, 2014 at 4:50 AM, Ethan Furman wrote:
The difference I was thinking of is:
"%h" % 3.14 # this works
vs.
hex(3.14) # this raises
In 3.5 both will raise.
Now you have me *thoroughly* intrigued. It's not
ery few members. ;)
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
& YMMV)
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
On 01/22/2014 11:23 AM, Mark Lawrence wrote:
I thought this blog might interest some of you
http://pydanny.com/awesome-slugify-human-readable-url-slugs-from-any-string.html
Thanks!
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
, ch.upper()))
search = ''.join(new_search)
found = glob(search)
return bool(found)
---
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
y, but under typical circumstances you tell 'except' which exceptions you are prepared to deal with.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
On 01/26/2014 10:46 PM, me wrote:
[...] I'm satisfied that the except: syntax yields
undefined behavior, and in my mind it shouldn't be
syntactically allowed then.
Two points:
1) Python is not C++
2) You asked for help; you received it. Coming back
with an attitude of "Python mus
;d replace "find them handy" with "totally addicted
to".
+1000
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
datetime(2014, 1, 29, 22, 9, 56, 494967, tzinfo=)
--> s.astimezone(GMT)
datetime.datetime(2014, 1, 29, 22, 9, 56, 494967, tzinfo=)
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
finally block doesn't have a return:
--> def paradox3():
try:
raise Exception("Raise")
except:
print("Except")
return [print("Return"), True][1]
finally:
print("Finally")
return None
--> print(paradox3())
Except
Return
Finally
True
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
On 01/30/2014 11:03 AM, Chris Angelico wrote:
On Fri, Jan 31, 2014 at 5:56 AM, Roy Smith wrote:
Yes, that's probably how I would write that, although, this is even simpler:
(x > -1) and (y >= 5)
Be careful; that's not the same thing.
How so?
--
~Ethan~
--
https://mail.py
ed at runtime.
"
Should the wording of the above be changed to clearly reflect that we have an
initialiser here and that __new__ is the
constructor?
I would say yes. Go ahead and create an issue if one doesn't already exist.
Thanks.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
ated but before it is returned.
I think that would be much clearer.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
s, good point. Also, __init__ initializes so it is a good choice.
Ignore the names comment in my previous post.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
tor and an initializer), but I found calling __init__ the constructor very confusing.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
tance
creation, to initialise the new instance.
But __new__ does not call __init__, type does [1].
--
~Ethan~
[1] And I seem to think pickle does, too, but I'm not sure.
--
https://mail.python.org/mailman/listinfo/python-list
On 01/31/2014 05:10 PM, Roy Smith wrote:
In article ,
Ethan Furman wrote:
I found calling __init__ the constructor very confusing.
I've heard many people say this, and it's always sort of befuddled me.
I have never learned C++, so I don't know its screwy semantics. ;)
On 01/31/2014 07:16 PM, Terry Reedy wrote:
On 1/31/2014 7:13 PM, Ethan Furman wrote:
On 01/31/2014 03:43 PM, Ned Batchelder wrote:
On 1/31/14 6:05 PM, Ben Finney wrote:
Ned Batchelder writes:
I'm not hoping to change any official terminology. I just think that
calling __init__ any
(or not be) __init__ed).
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
on's. Part of the effort is in learning what the terms mean, what the
ideology is, the differences, the similarities, etc., etc..
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
and being able to further customize with __init__ (where the kitchen goes, how many
bedrooms, to follow along with Terry) is quite useful. One of my favorite Enum recipes uses that pattern to have some
basic behavior, with some other behavior that is easily overridable/extendable [1].
--
~
ing at the answer change it?
No, looking at it is what collapses it. Before that it was just
another Schroedinger's cat
So, what you're saying is when I delete an object, __del__() has both
been called and not been called?
That would certainly explain the problems with __del__!
On 02/04/2014 07:45 AM, Steven D'Aprano wrote:
Before I bother Python-Dev with this, can anyone else confirm that
building Python 3.4 from source using the latest version in the source
repository fails?
This is the check-out I'm using:
ethan@media:~/source/python/cpython$
space bar four times for each level of indentation? ;)
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
On 02/07/2014 06:48 PM, Steven D'Aprano wrote:
That is not a trade-off that the core developers have chosen to make,
and I agree with them.
Even though you haven't broken all the build-bots yet, you can still stop saying
"them". ;)
--
~Ethan~
--
https://mail.python.
the verb performs. If, on the other hand, I had:
Shouldn't that be:
class Pig:
def fly(self):
"Soar gracefully through the air if a hot place is very cold."
if hell is frozen:
self.sprout_wings()
self.altitude += 10
se
). Might be
fairer to remove those from consideration.
Not at all. Even private routines get used by somebody! ;)
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
On 02/02/2016 07:26 PM, Rick Johnson wrote:
a bunch of garbage.
*sigh*
Time to update my procmail filters...
Anyone know one for deleting all responses to a troll post?
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
h the file system you have no way
to know if the path is unique.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
On 02/22/2016 02:25 PM, Cameron Simpson wrote:
On 22Feb2016 10:11, Ethan Furman wrote:
On 02/14/2016 04:08 PM, Ben Finney wrote:
I am unconcerned with whether there is a real filesystem entry of that
name; the goal entails having no filesystem activity for this. I want a
valid unique
ready done a
`from module import data` as those will be unaffected by the rebinding.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
the module. :)
You should also import it before anything else does to make sure your
change is visible to all other code.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
On 02/27/2016 01:37 AM, Steven D'Aprano wrote:
Although the connection to Python is only quite slim, I found it fascinating
to read.
Thanks to you and Kenneth for sharing that.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
mmend it if you find that sort of thing
interesting. They made a movie from it that was popular but I gather
was Hollywood-fluffified as one could expect (I haven't seen it).
I'm sure it was fluffified, but it is a good movie.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
ding memo files, conversion from whatever to Unicode if
needed, ...
Or you can use my dbf module [1] which has been in the wild for several
years now and is fairly robust instead of waiting for John's module
which has been in the "soon to be released" category for nearly as
Il giorno mercoledì 15 luglio 2009 18:30:29 UTC+2, John Machin ha
scritto:
Hmm, looks like that email was sent back in 2009. Sorry for the noise.
I'm still not able to find a dbf module from John, though.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
On 03/01/2016 06:08 PM, Dennis Lee Bieber wrote:
On Tue, 01 Mar 2016 08:49:08 -0800, Ethan Furman declaimed the following:
Hmm, looks like that email was sent back in 2009. Sorry for the noise.
I'm still not able to find a dbf module from John, though.
Is it one of:
better way to break lines I'm missing which will make
flake8 happy?
This is the idiomatic way:
if some_condition and \
some_other_condition and \
some_final_condition:
play_bingo()
No, it isn't. Using '\' for line continuation is strongly dis
On 03/02/2016 02:10 PM, Marko Rauhamaa wrote:
Ethan Furman :
No, it isn't. Using '\' for line continuation is strongly discouraged.
Why would you discourage valid syntax?
1) It's ugly
2) Any non-newline whitespace after the '\' and you don't have li
ndentation levels for conditions version body to
be very helpful.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
If it's a single-use name I stop remembering after its single use.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
uch more likely that I'll
read the first token of the next line.
And, as any pythonista knows: The conditions aren't over until the
indentation changes. ;)
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
On 03/04/2016 03:45 PM, Mark Lawrence wrote:
> PEP8 is not a standard that must be adhered to under all
> cicumstances, it is only a style guide [...]
Not only that, it's a style guide for code /in the stdlib/.
Make your own style guide for your own projects. ;)
--
~Etha
actly one place.
>
>> You're not the boss of me!
>
> Nor am I your father.
What was that disturbance? The Force whimpering away...
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
On 03/04/2016 05:17 PM, sohcahto...@gmail.com wrote:
I just can't understand why so many people get their panties all up in a bunch
over how other people choose to format their code.
s/panties/undies/g
;)
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
silence errors?
The try/except paradigm is very useful -- it's worth learning.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
On 03/17/2016 10:35 AM, Charles T. Smith wrote:
On Thu, 17 Mar 2016 10:26:12 -0700, Ethan Furman wrote:
On 03/17/2016 09:36 AM, Charles T. Smith wrote:
Yes, your point was to forgo REs despite that they are useful.
I could have thought the search would have been better as:
're
if re.search('timezone', line):
found.append(line)
print ''.join(found)
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
801 - 900 of 1941 matches
Mail list logo
